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
VEO Certificate Signer's Public Key VEO Certificate Signer's Public Key VEO Certificate Signer's Public Key VEO Certificate Signer's Public Key
Q: The three top VEOs were signed by
this user. Was the fourth? A: Are all of the public
keys in the VEOs the same?
?
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 Certificate Creator's Public Key
VEO
Digital SignatureContent
Certificate CA's Public KeyVEO
Digital Signature Certificate CA's Public KeyFigure 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.
Certificate Creator's Public Key
VEO
Digital Signature ContentAgency
Public Key
DB
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.
Appendix Three: Digital Signature Implementation Options
Option 1: Records signed by the application with local storage of private keys & no