news     faq     contact us     prov

5.2 Public key storage in VERS

Validation of a digital signature requires the public key of the signer. If the public key has been lost or discarded the integrity of the preserved object cannot be verified using digital signatures. Further, verification depends on being certain that the stored public key actually belonged to the purported signer (otherwise the preserved object could be modified, resigned, and the public key replaced). Public keys must consequently be securely stored for the lifespan of the signed objects; this could be for a century or more. Note that private keys should not be archived; indeed, proof of authenticity is improved if it can be shown that private keys are destroyed once their use has ceased.

In a conventional digital signature application public keys are obtained from certificates produced and stored by certificate authorities. However, it is open to question whether a certificate authority can (or should) be trusted to store the certificates it produced for the very lengthy periods of time required for preservation activities. Certificate authorities are usually commercial organisations and there is no guarantee that if the organisation fails or exits the business that the certificate store will be retained. How many commercial organisations are still in existence after 100 years? Note that there is little commercial pressure to provide cast-iron guarantees of long-term access to certificates as most digital signatures have a relatively short life.

One solution to this challenge requires an agency holding preserved digital objects to also store the necessary public keys to verify the preserved objects. The public keys would normally be held within certificates. This should not be an onerous requirement as certificates are simply digital objects and can be preserved within the same archive system that manages the actual preserved objects.

Care needs to be taken with this approach to ensure that the necessary certificates are actually captured into the system. If preserved objects are moved from one system to another the relevant certificates must be identified and moved with the preserved object. Further, custom verification software will need to be written to obtain the certificates from the archive system rather than from conventional certificate authorities. Finally, very great care needs to be taken to prevent the unauthorised addition of certificates to the system. If a forger can add certificates to the archive then they can forge or modify any preserved object (just as conventional digital signature applications such as SSL will fail if a forger can convince a user to install a fake root certificate on their computer).

Figure 13. If a forger can add fake certificates to the archive, they can forge any records. In theory, users can detect the forgery by noticing that the certificate used to verify the signature is not the same certificate used to validate other records. In practice, users are unlikely to notice this, but VERS uses this approach as an alternative mechanism for verifying signatures.

A second option to obtaining a public key is to hold the necessary certificates within the preserved object itself. This is a particularly attractive option within VERS, as a key assumption of VERS was that preserved objects would outlive the archive system that held them so the preserved objects should stand alone from the archive system. Including the certificates within the preserved object reduces the dependency of the preserved object on other objects, ensures that the certificates are captured when the digital object is preserved, and ensure that the certificates are transferred with the preserved object. There are two problems, however. The minor problem is the inefficiency involved in storing multiple copies of certificates, though this is not serious as certificates are quite small. The major problem is that it is not secure. A little thought reveals the circular argument that you are validating the contents of a preserved object by means of a signature which, in turn, is verified by the contents of the object.

Figure 14. The VERS Encapsulated Object includes the digital signature and all of the certificates required to verify the digital signature. This makes archiving and subsequently managing the certificates trivial. This does not, however, prevent forgery as a forger can simply include their own certificates in the record.

A solution to this circular argument is to discard the conventional concept of digital signature verification by means of a certificate chain. An alternative is to adapt the process used to verify handwritten signatures in a paper-based archive. When it is necessary to verify a handwritten signature, the suspect signature is compared with other examples of the signature in the archive. If they match, the handwritten signature is treated as valid, otherwise the signature is considered suspect.

With electronic records, we compare the certificates stored with the records, not the digital signatures themselves. Clearly the digital signature will be different for each record (as the signature depends on the record). All the records signed by a user with a particular private key, however, should contain the same certificates.

When using this approach to verify the integrity of a digital signature on an electronic record, the first step is to verify the digital signature using the certificates contained in the record. This shows that the content of the record has not changed since the record was signed and that the certificates actually belong to the record. The second step is to choose another record signed by that user around that time and compare the certificates in the two records. The certificates should be identical. If they are, then either a forger has forged both records or both records are authentic. (In practice the test is slightly more involved than this, as a user's private key is periodically replaced and the certificates will validly change.) Clearly, the certificates in the suspect record should be compared with those in more than one record signed by that user; the more records compared, the more likely the records are valid. This is a probabilistic approach, but with a sufficiently large number of digital objects there would be strong evidence that the records have not been tampered with. The security can be increased further by arranging for a record to be signed multiple times.

Figure 15: The four records on the left are probably valid as they were signed using the same private key; this is shown by the fact that they contain the same certificates. The record on the right is suspect as it was signed using a different private key; shown by the fact that it contains a certificate that is different to the other records in the archive.

This is a particularly useful approach as it exploits the strengths of the archive and avoids having to trust the integrity of an archive of certificates.

One useful side-effect of this 'comparison' verification is that it is possible to demonstrate when a record was created - essentially providing a notarization service. This is achieved by setting up a procedure whereby the private key used to sign the records is regularly changed, say every month. Once the private key is changed the old private key is destroyed (in fact, the copy of the private key should be destroyed once it is loaded into the system and it should not be possible to extract the private key from the system). Every record signed during that period would contain the same certificates and you can consequently show that the record must have been created in that period (as the necessary private key is not available at any other time).

The VERS Standard strongly encourages implementors to use this 'comparison' approach. As described in the next section, a VEO allows the certificate chain used to verify a signature to be stored in the VEO.

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