0 Flares Filament.io 0 Flares ×
FSML 2.0 Logging Proposal
Proposal for Logging of FSML Documents

Ken Goldman – IBM Research
914-784-7646 (863-7646) kgold@watson.ibm.com
Time-stamp: “10 May 2001 12:07:39”


Logging of FSML documents is for repudiation (the document generator
such as a check writer can prove that his electronic checkbook token
did not sign a document) or non-repudiation (the document recipient
such as a bank can prove that the token did indeed sign)

  1. The current FSML 1.5 implementation provides non-repudiation for check documents. Each check has a unique sequence number (the check number), allowing a deleted log entry to be detected. Endorsements have no unique number, making log entry deletion difficult or impossible to detect. Other documents are not logged at all.
  2. Even for checks, the data to be logged is presented, and the unique check number is generated, when the check block is hashed. The signing is done later. In order to prevent a user from logging one set of data and signing another, some state (such as the hash) must be retained from hashing time to signing time. This is cumbersome at best and impossible with some checkbook tokens. Software solutions are subject to attack.
  3. The data to be logged varies with the document type. Token hardware memory limitations restrict the data to a subset, with potential truncation of fields.
Proposed Solution

The solution includes these algorithm changes:

  • Rather than log check data at hash time, log the hash of the user <sigdata> (i.e. the hash that is signed) at signature time.
  • At signature time, add a <sigdata> tag to the <sigdata> sub-block before hashing.
  • When outputting the log, create a log block containing a list of hashes (of the <sigdata> sub-block) plus the sequence tag for that sub-block.

The solution has these features:

  • There is no longer a link required between hashing and signing.
  • The procedure is generic, not specific to any FSML document type. All documents are signed and logged using the same procedure.
  • The log has consistent, standard, compact size, independent of the document type.
  • Deletion of a log results in an easily detected gap in the sequence numbers.
  • It is straightforward to search the log. Given a <sigdata> sub-block, use the sequence number to locate the log entry. Use a hash of the <sigdata> sub-block to validate the log entry.
  • A recipient reading the log can only use it to match a known document. Document data is not revealed by the log, adding to privacy. This was not a requirement.

The solution has two drawbacks:

  • A change to the FSML specification is required.
  • Since the log contains only hashes, it is not human readable. It thus cannot be used as an audit trail. This was not a requirement.

Proposed <sigdata> sub-block

The <sigdata> tag has been added.

<hash alg=”sha”>65CA29BE501F9184929BE359AF81C45B4AD33874
<hash alg=”sha”>65BC1E70FFCBF57A0B1401AB3B8EB2CA71B6B0F0
<hash alg=”sha”>15724CF5FABDADA83E957FE7FE3AEAE07AF096C4

Proposed log document format

The format is quite similar to a check document type.

The action, account, user signature, bank signature, user certificate,
and bank certificate blocks are identical to a check document.

The check block is replaced by a log block.

Note: Indentation is for understanding. The actual document will
not have indentation.

<fsml-doc docname=”check log” type=”log”>

<hash alg=”sha”>4587234543857348573485734857165010585484
<hash alg=”sha”>0954896510165784635346593425623456345632
<hash alg=”sha”>5234625463563245649285842564325862451611
<hash alg=”sha”>6894327830258932523056110134503135638444
account block
user signature of action, log, and account blocks
user certificate
bank signature of account and user cert blocks
bank certificate