news     faq     contact us     prov

Appendix Three: Digital Signature Implementation Options

Option 1: Records signed by the application with local storage of private keys & no public key infrastructure
Option 2: Records signed by Users with file or database storage of private keys & public keys stored as records
Option 3: Records signed by Users with private keys stored in Smartcards and public keys stored as records

Option 1: Records signed by the application with local storage of private keys & no public key infrastructure

Figure 15: Illustration of Option 1

In this option, records are initially stored within an application such as an EDMS. VEOs are only created when the record is transferred to the Record Keeping System. The VEOs are signed by the application as part of the encapsulation process. This requires:

• That the application capture sufficient metadata to allow the VEO to be created at a subsequent point in time. In particular, the application must capture information about who created the record and when it was created.

• That the application provides a ‘vault’ that only allows modification to the record (and its associated) metadata through audited access points.

• That this information is securely transferred to the Capture System.

With this option only the applications are issued with a public/private key pairs. Individual users are not issued with public/private keys. The keypair issued to the application is stored securely in a file or database. The private key is used by the application to sign all generated VEOs. A certificate containing the matching public key is included in each record generated by the application. No public key infrastructure is implemented to authenticate the certificates. The public key is authenticated, when necessary, by comparing the public key contained in the corpus of records produced by the application.

While simple to implement, this package has the following weaknesses:

• A complicated chain of evidence. Showing that a particular user generated a record involves showing (i) that the application accurately captured the users’ identity, (ii) that it is only possible to modify records within the application, (iii) that the VEO generation is accurate, and (iv) that the record has not been tampered with subsequent to signing.

• Lack of the ability to formally demonstrate that the certificates stored in the records are valid.

Option 2: Records signed by Users with file or database storage of private keys & public keys stored as records

Figure 16: Illustration of Option 2

In this package, VEOs are created and signed by the user when the record is created (e.g. when checking a version into an EDMS). The VEOs are then immediately stored in the Record Keeping System. This means that the information is being stored twice; once in the EDMS and once in the Record Keeping System.

The users’ private key is kept in a file in their directory (i.e. PGP fashion), or in a database (e.g. in a Lotus Notes public address book). The users’ public key is included in a certificate included within each record signed by the user. The user certificates are signed by a certification authority. The certificates for this certification authority are kept as records within the Record Keeping System. Each normal record is linked to the CA record that can be used to verify its integrity.

This package is more difficult to implement that the previous package. The advantage over the previous package is that the evidence chain is much simpler and it is possible to show a conscious decision by the creator to sign the record. It is also possible to formally verify the certification chain. The package has the following weaknesses:

• User identity. In practice, the identity of the user is based on the user’s login. Anyone who has access to the user’s computer account (e.g. by cracking or guessing the password, being told the password, leaving the account logged in, or system administrators) can sign records as if by the user.

• The Record Keeping System must be tightly linked to the digital signature infrastructure. The Capture components must be able to retrieve the private key from the file or directory in which it is contained. Whenever the public key of a certificate authority is modified, a new Certificate record must be created in the Record Keeping System.

Since this package uses a (simple) public key infrastructure, it will be possible to link into Whole of Victorian Government PKI or Australian PKIs. However, this will add additional challenges in archiving the certificate records from the certificate authorities.

Option 3: Records signed by Users with private keys stored in Smartcards and public keys stored as records

Figure 17: Illustration of Option 3

This package is identical to the previous one, except that private keys are stored on smartcards.

The advantage of this is a user’s identity is linked to the possession of the smartcard and is not linked to a login id. There is consequently less scope for people forging signatures. The smartcard could be linked to other security practices such as building access or computer access. In practice, however, the cost of implementing a smartcard solution would be likely to be prohibitive. It would be necessary to attach smartcard readers to many, if not all, machines. It is necessary to implement a smartcard creation and distribution infrastructure.

Since there is a high implementation cost for this approach, it is assumed that a formal public key infrastructure would be put into place. Each record created would include the creator’s certificate. Whenever a certificate is created within the department, a record is made of the certificate.

back to top

printer friendly

VERS Story | Standard | Assessment | Projects | Digital Archive | Training | Toolkit | Publications

Site last reviewed: 20 Jul 2006
© State of Victoria 2008 | Disclaimer | Privacy Statement