news     faq     contact us     prov

Appendix Two: Digital Signature Infrastructures

Table of Contents

1. Who signs the record and when?
     1.1 Signing by creator at point of record creation
     1.2 Signing by application at point of record archiving
     1.3 Summary
2. Where is the private key of the signer kept?
     2.1 Keyring Files
     2.2 Key Databases
     2.3 Dumb Smartcards
     2.4 Smart Smartcards
     2.5 Biometrics
     2.6 Summary
3. Where is the public key of the signer kept?
     3.1 Use unsecured public keys
     3.2 Public Keys stored as Records within VERS
     3.3 Unsecured Agency Directory
     3.4 Summary

In developing a digital signature infrastructure there are three broad areas where implementation options are feasible. These areas are:

• When the record is digitally signed and by whom

• The association between the private key and the signer

• Where the public key of the signer is kept

1. Who signs the record and when?

Who should sign a record and at what point in the record’s life should it be signed?

The first aspect to consider when answering this question is immutability. A signature locks the record. Once signed, the record cannot be modified. This immutability has both positive and negative features. On the positive side, the signature can demonstrate who signed the record, when it was signed, and that it has not been subsequently tampered with. On the negative side, the record cannot be modified even if this is necessary (e.g. to add more information). So the point at which the signature is applied will be a compromise; sufficiently late that information in the record will not change, but sufficiently early to provide maximum protection to the information.

The second aspect to consider is responsibility. When a person (or a system) signs a record they are taking responsibility for authenticity and reliability of the record. A signature by the officer authorising the record has a different meaning to the signature of an Electronic Document Management System.

1.1 Signing by creator at point of record creation

Figure 6: Signing by creator at record creation

The first option is that the person (or system) that creates the record signs it at the point of creation. In the paper world, this is equivalent to an officer signing the a record as the last action before filing it. In an electronic environment, a digital signature could be affixed as part of the work flow (for example, as a step in the process of authorising an action or creating a document). Alternatively, the digital signature could be affixed a side effect of taking an action in the system (for example, checking a document into an EDMS as a ‘version’ instead of a ‘draft’, or putting a document up on a Web server). Finally the user could consciously invoke a program to turn a document into a record and file it, and this program could affix the digital signature.

The major advantages of the creator signing the record at point of creation are:

• Responsibility. It is possible for the system to explicitly prompt the user to agree to the signing of the record. This ensures that the application of the digital signature is a conscious act of will by the creator. Even if the signature is automatically applied by the system (without an explicit act of will by the creator), the signature explicitly ties the record to a particular user and a particular time without depending on other systems. Both aspects increase the evidentiary weight of the record.

• Protection. Signing at point of creation gives maximum protection against alteration. Once signed, the evidentiary status of the record is not dependent on the security of the database or data storage system that is holding the record. Once again, this increases the evidentiary weight of the record.

The disadvantages to the creator signing the record at point of creation are:

• Immutability. Once signed, the record cannot be modified (is immutable). This means that the record must be, at point of creation, in the VERS archive format. Apart from the storage issue (to be considered in the next bullet point), any valid alteration or augmentation of the metadata associated with the record requires the formation of an ‘onion’ record where the new metadata is layered around the original record and the resulting record resigned. Metadata may be legitimately altered over the life of a record, examples include refiling the record, correcting the descriptive information, and making new links between related records. Metadata may also be extended, for example the continual accretion of audit logs recording accesses to the record and management decisions about the record.

• Storage. Immutability requires the record to be in the VERS archive format at the point of creation. At this point it may still be necessary to keep a copy of the content in the original format in another system (e.g. for further work). This will require storage of multiple copies.

1.2 Signing by application at point of record archiving

The second option is to sign the record when it is transferred to a Record Keeping System as a VEO. Technically, the previous option satisfied this definition (the VEO was created and transferred to the Record Keeping System immediately it was created), but the model in this scenario is for the record to be first managed in an application (e.g. an EDMS or RMS) for a period of time. Subsequently the VEO is formed, signed and transferred to the Record Keeping System. This transfer may occur after a set period of time (e.g. 1 year), or may be triggered by an event (e.g. closing of a project, or a file). In the following discussion, it is assumed that the record is initially stored in an EDMS, but the record may be stored in other types of system (e.g. an RMS).

Figure 7: Signing by application at point of record archiving

If the VEO is created by a system well after the actual creation of the record, the creator of the record cannot sign it as the creator’s private key is unlikely to be available when the record is signed. If the system stored the creator’s private key to allow later signing, this would destroy the evidential validity of the signature as the system could use the stored key to sign any record at any time. Asking the user to subsequently sign the record during transfer will not work, first because the user may not be available, and second because the user would be required to inspect the record to ensure that it really was the record.

The alternative to the creator signing the VEO during record creation is for the EDMS to sign the VEO during transfer to the Record Keeping System. This signature signifies that at the time of creating the VEO, the EDMS believed that the record was created by the recorded user, at the recorded time, and has not been subsequently changed.

The long term evidentiary status of the record clearly depends on a chain of authenticity. The digital signature will guarantee the evidential status after construction of the VEO and transfer to the Record Keeping System. But the accuracy of the information included in the VEO clearly depends on the security of the EDMS. Essentially, in this model, the EDMS has to act as a vault that protects information stored in it from undetectable modification. This is achieved by providing a limited set of functions for modifying information and logging all uses of these function.

The major advantages of the EDMS signing the record at some time after creation include:

• Simplified private key management. Individual creators of records do not need to be issued with a public/private keypair, only the EDMS itself.

• Simplified metadata management. A problem with creating and signing the VEO at creation of the record was the difficulty of modifying or extending the metadata. This problem is less severe if the VEO is created subsequently. While the record is held within the EDMS, any of the metadata may be modified or extended. The EDMS audit logs document the changes. This audit log forms part of the VEO when it is finally produced. This is a particular benefit as changes to the metadata are most likely early in the life of the record.

• Clear functional delineation. In this model, the EDMS becomes the system where documents and records are kept while they are actively being worked upon. The Record Keeping System is where the records are kept after they have become ‘fixed’ and only need to be viewed.

• Reduced load on Record Keeping System. Many documents and records created in an agency have an extremely short life and many will be discarded before creation as a VERS object.

The major disadvantages of signing the record after creation include:

• Weakened evidential status. The evidential status of a record depends on an evidential chain. To decide whether a record is reliable now depends on four issues (i) how the EDMS knew who the user was that created the record; (ii) the integrity of the EDMS to prevent undocumented modifications to the record (including software back doors and bugs); (iii) the integrity of the conversion to a VEO; and (iv) the digital signature after conversion.

1.3 Summary

Storing a record in an EDMS (or similar application) significantly simplifies implementation of the VERS Record Keeping System. The major disadvantage is the longer chain of evidence required to prove integrity. However, this chain of evidence is no different to that required to introduce records from an HR or financial system into court; which is commonly done now.

In practice, different records may be treated differently. Records that are normally unsigned today could be initially managed within an EDMS and signed by it when the VEO is subsequently created. Such records will have a slightly stronger evidential status than similar paper records. On the other hand, records that are formally signed today could be signed immediately upon creation by the user.

2. Where is the private key of the signer kept?

A digital signature does not actually prove who signed a record. All it proves is that someone in possession of a particular private key signed the record. The proof that a particular person signed a record consequently depends on the system that stores the private keys and ensures that only one person can use a particular key. A secure infrastructure implies a strong association that a particular person did actually sign the record. A weak infrastructure has a weak association.

This system is doubly crucial due to the complexity of the private key. Unlike conventional passwords which are selected by the user and are normally selected to be easy to remember, private keys are long (up to four times the length of this paragraph), and are composed of random characters. The length and randomness of the private key make it impossible for users to remember the key, or to type it in when required. Private keys must be electronically stored somewhere.

The two crucial aspects of storing private keys are:

• How strong is the association between the user and the private key?

• How secure is the storage of the private key?

2.1 Keyring Files

The cheapest and simplest solution is to store the private key in the user’s home directory. This solution is adopted (by default) by PGP where the private key is stored in a special ‘keyring’ file. This keyring file is only readable by the user, or by software being run under the authority of the user. When it is necessary to sign a digital object, the user runs the signature software (or the signature software is run on their behalf) which reads the keyring file to extract the private key.

Figure 8: Keyring Files

This approach is cheap to implement as no special hardware to store private keys is required to be installed or maintained.

However, storing the private key in a file on a fileserver only provides a relatively weak association between the user and the private key, and is relatively insecure.

Basically, the association between the user and the private key is achieved by the user’s logon identity which is based on the knowledge of a user name and password. The association between the user and the private key is relatively weak because the private key can be used by anyone who:

• Can read the file (in particular system administrators can normally bypass system security).

• Has been given the account password by the user

• Uses the computer while the user is logged in.

• Discovers the account password. This may occur by simply guessing, or an exhaustive search of the possible passwords, and is more likely if the user chooses a poor password (i.e. one that is short, contains only letters, is a common word or easily found out). It may also occur due to observing a user logging in, or due to a compromise of system security (e.g. a keystroke sniffer).

Fundamentally, the private key is relatively insecure when stored as a file as access to the private key is only protected by means of the normal file system security. Most operating systems have security holes, and many have a lot of holes.

Although storing the private key in a file on the fileserver gives a relatively weak association between the user and the private key, and is relatively insecure, the level of security may be sufficient. This security is no worse than is currently accepted within many agencies for their normal operations. The sender of an email, for example, is usually only identified by the login account from which the email was sent, and documents within many agencies are only protected using the normal file system security.

2.2 Key Databases

An alternative to storing the private keys in a file is to store the key in a database. This is, for example, how some Lotus Notes implementations store private keys.

Figure 9: Key Databases

Like keyring files, storing the private key in a database is a relatively simple solution. It has an advantage over files in that the database security can be higher than the file system security. In addition, there can be a stronger association between the user and the public key as it may be necessary to for the user to authenticate themselves to the database before being allowed to retrieve the private key. However, even if provided, this level of authentication is often turned off for convenience.

In summary, using key databases provides similar advantages and disadvantages to storing private keys in files, but key databases may provide slightly stronger security and association between users and keys.

2.3 Dumb Smartcards

The weakness with storing the private key in a file or database on the computer is that this depends on the normal system security. Anyone with access to the file or database, or anyone who can break the normal system security, can use the private key. An alternative is to store the private key outside the computer on a smartcard under the user’s control.

Figure 10: Dumb Smartcards

Smartcards are simply pieces of plastic which contain an embedded computer chip. The chip can vary in complexity; at one extreme the chip is a small piece of memory, at the other the chip can be a sophisticated computer in its own right. When inserted into a smartcard reader, connections are made to the chip and information can be transferred to and from the chip. Smartcard technology is becoming quite common; for example the current thick plastic Telstra phonecards are simple smartcards.

Simple smartcards can be used to store private keys. When it is necessary to sign a digital object, the user inserts their smartcard into a smartcard reader. Access to the smartcard can be protected by a password which the user is prompted to enter (this protects against casual theft of the smartcard). The signature program then reads the private key from the smartcard and uses it to sign the object. For security, it is essential that the signature program deletes its copy of the private key once the signature has been calculated.

Clearly, implementing a smartcard solution costs money. Smart card readers have to be added to all computers on which documents will be signed (probably most, if not all, computers). This cost includes purchasing the hardware, installing it on the computers, and ongoing maintenance and support. In addition, an infrastructure needs to be developed to create and distribute smartcards to users.

Even simple smartcards provide a stronger association between the user and the private key than storing the key in a file or database because the private key is stored on a object that the user can directly control. The user can remove the smartcard from the computer when it is not being used to sign objects and also simply having access to a user’s account no longer means that objects can be signed as if from that user. In addition, the private key will be available for shorter period in the computer and this will make it more difficult to copy or access the private key.

However, a dumb smartcard is not a complete solution to private key security. Although it is possible for a user to remove the smartcard from the computer, there is nothing that makes them remove the smartcard. A user could leave the card in the computer for days. This can be protected against by requiring the user to enter a password every time the smartcard is actually used. Smartcards can, of course, be lent or stolen. Passwords can protect the card against unauthorised use, but not use authorised by the card holder.

From the point of view of protecting the private key from access, the use of a Smartcard means that the private key is held in the computer for shorter periods. However, the private key must be read from the card and stored in the computer when it is used. There is nothing to prevent the software from saving the private key somewhere and not deleting it after use. At a more paranoid level, an intruder could obtain a core image of the running program and analyse it to capture the private key.

2.4 Smart Smartcards

One problem with the dumb smart card described in the previous section is a security weakness. To use the private key, it must be read from the smartcard and copied into the memory of a computer. There is no way of ensuring that this copy is destroyed after use.

Figure 11: Smart Smartcards

To address this weakness, an alternative is to use a ‘smart’ smartcard. The chip on a smartcard can be a reasonably powerful computer in it own right. The smartcard computer can be programmed to calculate digital signatures independently of the main computer.

To sign a digital object with a ‘smart’ smartcard, the user inserts it into the host computer. The host computer passes the object to be signed to the smartcard which calculates the digital signature using the private key kept on the card. The signature is returned to the host computer. The private key never leaves the smart card.

By keeping the private key on the smartcard, and making no provision to extract the key from the card, a smart smartcard provides the ultimate secure storage.

The use of a ‘smart’ smartcard does not give a stronger association between the smartcard and its owner than the use of a ‘dumb’ smartcard. Possession of the smartcard (and the password to use, if required) allows the possessor to sign objects.

2.5 Biometrics

Biometrics is the measurement of biological features such as fingerprints, palm prints, and retinal scans. Biometrics does not replace the use of a private key in a digital signature, or make the storage of a digital signature more secure. The use of biometrics can, however, strengthen the association between the private key and the user. For example, a ‘smart’ smartcard can store the user’s retinal scan and only sign an object after being given a matching retinal scan freshly scanned from the user. Essentially, the biometrics provide a more reliable replacement for the password. Users cannot disclose or loan their retinal scan!

In practice, however, the strength of the association still depends on the system. The smartcard, for example, will sign a record after it receives the correct retinal scan. The smartcard cannot know if this retinal scan was freshly scanned, or has been previously stored by the system and replayed.

The obvious weakness of biometrics is the cost of the scanners necessary to generate the biometric.

2.6 Summary

The two key aspects to the storage of private keys are:

• The strength of the association between the private key and the user

• The security of the storage of the private key.

The security of the storage is a straightforward technical problem. Solutions range from storing the key as data in a computer system, to storage on a smartcard, to processing on a smartcard. Security is increased as potential access to the private key is reduced. Security is maximised when the private key is locked on the smartcard from which it cannot be copied. The cost of implementing a security solution increases as the security increases. For most records handled within government, storing the private key in the user’s home directory or in a database is likely to give sufficient security. Records created by particular users (e.g. Ministers, Departmental Secretaries, and Assistant Secretaries) may be sufficiently important to warrant at least a ‘dumb’ smartcard solution.

The association between the private key and the user is a more difficult problem to solve. In most cases, the association depends on the user knowing a password which either provides access to an account, or to the smartcard. Users often disclose their password to other users. The use of biometrics to replace the password provides a stronger association, although at a significant increase in cost.

3. Where is the public key of the signer kept?

To check a digital signature requires the public key of the signer. A public key infrastructure (PKI) can ensure that the public key can be trusted. There are, however, three issues with implementing a PKI in a Victorian government agency:

• PKIs are not designed to reliably store certificates for long periods of time

• PKI implementations are complex and difficult to run

• There is currently no WOVG PKI.

The following discussion refers to ‘user certificates’ and ‘CA certificates’. User certificates contain the public key of a user and are signed by certification authorities. CA certificates contain the public key of a certification authority and are signed by other certification authorities.

Each VEO contains copies of the user certificates for each user that signed the record. This allows the digital signatures protecting the contents of the VEO to be checked without accessing an external PKI. The only remaining issue is checking the validity of the certificate contained within the VEO.

3.1 Use unsecured public keys

Figure 12: Use of Unsecured Public Keys

It is possible to check the validity of the public keys without using a PKI. Since each VEO contains the public key of the user that signed the record, it is not necessary to use a PKI to obtain the user certificate. To check the validity of the public key, all that is necessary is to compare the key with that stored in other records signed by the user around the same time. If all of these stored public are identical, then either someone has forged the entire body of records by that user, or the public key is correct.

Conceptually, this approach mirrors how we validate conventional handwritten signatures, particularly of historical records. If we have a document that is purported to be signed by a particular person, we compare the signature on the purported document with other documents supposed to be signed by that person. If all of the signatures are the same (or very similar), then the assumption is that they are valid.

Since the user certificates are part of the preserved record, there is no problem in storing the user certificates as long as required. The difficulty with using just this approach is that it is not possible to formally check the validity of the certificate if this is subsequently necessary.

3.2 Public Keys stored as Records within VERS

Figure 13: Public Keys stored as Records within VEO

A certificate is simply a data structure which could be stored in the Record Keeping System like any other record. Effectively, the Record Keeping System is keeping the records of the public keys issued to a particular user (or certification authority). These ‘certificate records’ can be linked together to form a PKI.

The advantage of this approach is that the Record Keeping System is responsible for preserving the public keys as long as they are required. In addition, a file of certificate records can be transferred or copied to other repositories if the records that refer to them are transferred.

An issue with this approach is the requirement that the process for issuing a new public/private key must be extended to generate a certificate record.

3.3 Unsecured Agency Directory

The third option is to store public keys in an organisational directory (for example in a Lotus Notes public address book). The public keys need not be stored within certificates.

Clearly, the user checking a digital signature must trust that the organisational directory has returned the correct public key (and no substitution has occurred while the public key was in transit on the network). There is little reason why the user should not trust the directory and network in this fashion. Many agencies do not currently encrypt, nor sign, traffic over the network and consequently trust both their servers and their network. If either were subverted, the intruder could do far worse damage than altering the public keys used for checking signatures on records.

Figure 14: Unsecured Agency Directory

>Note that the assumption is that the public key is only being used to check the validity of records. If it is also being used for other security applications (e.g. as the basis for encrypting traffic over the network) then the security issues become far more severe.

The organisational directory will need to be set up to store the sequence of public keys that have been allocated to individual users over time. It will need to be integrated into the process that allocates public/private key pairs. The directory must be capable of returning the key that was in use at a particular time. If the records are ever transferred from the agency (e.g. to PROV or to another government agency), the public keys must be transferred with the records.

Again, the difficulty with using just this approach is that it is not possible to formally check the validity of the public key if this is subsequently necessary.

3.4 Summary

A key concern with the storage of public keys is their long term storage. The public keys need to be kept for as long as the records signed by that key are kept. The only effective method of long term storage is to treat the public key (or the certificate containing the public key) as a record and store them in the Record Keeping System. This is particularly useful if the records are migrated as it means the public keys can be migrated or copied with them.

There is currently no large scale public key infrastructure systems widely deployed within Australia. This, however, is expected to change over the next two to five years.

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