news     faq     contact us     prov

3 Using Digital Signatures for Authentication

3.1 Paper Records and Evidence
3.2 What Does a Digital Signature Really Prove?
3.3 The Lifespan of a Digital Signature
3.4 Digital Signatures
3.5 Public and Private keys
3.6 Securing the Private Key
3.7 Public Key Infrastructure
     3.7.1 Certificates
     3.7.2 Certificate Paths
     3.7.3 Certificates and Archives
3.8 Encryption

One of the fundamental reason for keeping records is as evidence. The business requirements of an organisation impose different evidential standards on different types of records. A second external requirement is the certainty of change. Many computer security techniques are in their infancy, particularly the use of digital signatures. In can be expected that, over time, the cost of digital signature security will fall and required standards will rise. Any solution put in place today must look forward to a different environment in the future.

The use of digital signatures requires an infrastructure to apply the signatures and to store the associated public and private keys. This infrastructure can be implemented in a variety of ways, but implementation decisions have consequences for the strength of the proof that the resulting digital signature will give and the cost of the infrastructure. Like most systems, strong proof requires an expensive infrastructure. This is particularly true of non-repudiation.

3.1 Paper Records and Evidence

In a traditional record keeping system, authenticity is shown by a mixture of

• Pragmatism. Courts have taken the pragmatic view that records kept as part of the everyday transaction of business can generally be taken at face value as, if these records were not reasonably accurate, the business could not be carried out.

• Provenance. Provenance is essentially the history of the record, including being able to show who had the record over time, and what happened to it.

• Signatures (where necessary). A small set of significant records are signed. Typically these are records which demonstrate an incurred liability or act as evidence of a decision.

The standard of proof required depends on the type of record. Many current paper records, for example, are neither signed nor dated and are completely unprotected against modification or substitution.

In an electronic record keeping system, authenticity is expected to be shown in a similar fashion. However, electronic records are considered to be easier to undetectably modify than paper records, hence the interest in digital signatures that allow the detection of modifications. In theory, digital signatures can also be used to serve the same non-repudiation function as the handwritten signature on paper records.

3.2 What Does a Digital Signature Really Prove?

In theory, a digital signature proves who signed the record and that the record has not been modified since the signature was applied. In practice, however, the strength of this proof depends strongly on the process by which digital signatures are applied.

In many ways, a digital signature is closer in concept to a seal than to a conventional handwritten signature.

A handwritten signature is unique to an individual; no other person can match the sequence of muscle movements that produces the signature. There is consequently a very strong association between a handwritten signature and the signer.

A seal, however, is applied mechanically. Anyone in possession of the seal can seal a document. It is consequently impossible to prove who sealed a document from the seal itself, as there is a weak association between the seal on a document and the person that executed the seal. It is possible to trust seals provided there is a strong emphasis on control of the seal.

Like a seal, a digital signature is mechanically applied, and can be applied by anyone in possession of the appropriate private key. The evidentiary value of a digital signature, like a seal, is based on the system that associates the signer and the public/private keypair. A poor system will give little evidentiary integrity (just as an uncontrolled seal will result in sealed documents that have little weight). On the other hand, a strong system may be sufficiently expensive to outweigh the value of the records.

It is necessary for agencies to identify the options that provide a maximum amount of evidentiary status while minimising this cost.

3.3 The Lifespan of a Digital Signature

The conventional use of digital signatures is to protect messages for relatively short periods of time. Typical examples include the protection of messages during transmission over the Internet, and the authentication users or systems during communication.

Using digital signatures in a record keeping or archival environment requires applying digital signatures to objects that may exists for decades or centuries. It is necessary to preserve sufficient information to validate the digital signatures applied to records even though decades or centuries may have passed.

3.4 Digital Signatures

A well designed digital system infrastructure allows a user to verify that a message has not been modified and gives an indication of who signed the message. It is important to note that applying a digital signature does not encrypt the message; the original message remains unchanged after applying a digital signature.

The actual process of applying and checking a digital signature is simple (see figure 1).

The first step is to apply a hash function (a computer algorithm) to the original message. The hash function simply converts the long string of bits that forms the original message into a single number known as the hash value. A good hash function has a number of properties:

• If the hash function is reapplied to a message the same hash value is generated.

• If you change the message, even by one bit, the hash function will generate a different hash value.

• Given a particular hash value it is impossible to work out a message that would generate that value.

Figure 1: The process of applying digital signatures

The hash value is then encrypted using the signer’s private key. The resulting encrypted hash value is the digital signature.

Figure 2: The process of checking digital signatures

To check a digital signature is equally simple. The user recalculates the hash value from the message. The digital signature is then decrypted using the signer’s public key to retrieve the original hash value. If the two hash values are identical the message is unchanged and was actually signed by the purported signer. If the two hash values differ, then either the message has been modified since it was signed, or the wrong public key was used to decrypt the hash value.

3.5 Public and Private keys

Public key cryptography is normally used to encrypt and decrypt the hash value (secret key cryptography could also be used). This form of cryptography uses a pair of linked keys, known as the ‘public’ and ‘private’ keys. Anything encrypted by one of the keys can be decrypted by the other. One key (the ‘private’ key) is kept secret, and the other key (the ‘public’ key) is published. Knowledge of the public key does not allow the user to calculate the private key.

To sign a message, the signer uses their private key to encrypt the hash value. The receiver of the message uses the signer’s public key to decrypt the hash value.

Note that if the receiver uses the wrong public key, the decrypted hash value will not match the hash value calculated from the message.

3.6 Securing the Private Key

Possession of the private key allows a user to sign a record. Clearly, proving that it really was that user that signed that record requires examining the association between a user and their private key. Could the user have ‘lent’ their private key to another user? Could the private key have been used without the owner’s knowledge? Could the private key have been stolen?

The strength of the association between the user and their private key depends on how the key is stored. Some form of electronic storage is necessary. Private keys can be up to 1000 characters long (about three times as long as this paragraph), and are essentially random characters. In other words they are impossible to remember and difficult to type in accurately.

3.7 Public Key Infrastructure

To check the validity of a digital signature requires the public key of the person who signed the record. Users require access to thousands of public keys as they communicate with various people over their life. But how are these public keys obtained? Like private keys, public keys are sufficiently long to make it necessary to store them in an electronic directory. Apart from the technical problems with constructing a global directory, retrieving a public key from a directory raises the issue of trust: can the user trust the public key returned from the directory?

The Public Key Infrastructure (PKI) has been developed to deal with this question of trust. The PKI is simple in theory, but fiendishly complex in practice.

Figure 3: Digital Certificate

3.7.1 Certificates

The PKI is built around certificates (see figure 3). Essentially, a certificate is an assertion by someone (the Certification Authority) that a particular subject (user) has a particular public key.

The basic information in a certificate is:

• Issuer. This is the name of the Certification Authority (CA) that issued the certificate.

• Validity. The period over which the certificate is valid

• Subject. The name of the user (or system) that owns the public key

• Public Key. The public key belonging to the user.

Figure 4: An example of Public Key Infrastructure implemented within a single agency

With a certificate, the question of trust boils down to two questions:

• Do you trust the Issuer when they state that a particular subject has a particular public key? (How much trust would you place in a certificate issued by ‘Fly-by-Night Pty Ltd’?)

• Can you check that a certificate was really issued by the purported Certification Authority? (Just because the certificate says that it was issued by Acme Signatures Inc., it doesn’t mean that it was!)

The second question can, of course, be solved by signing the certificate with the Certification Authority’s private key. But this brings us nearly back to our starting point: to validate the public key of the subject, we need to validate the public key of the Certification Authority.

3.7.2 Certificate Paths

This simple approach works for small systems that are managed by one authority. It does not work if you need the public key of a user in another organisation (for example in another agency of government). This approach can be handled by another layer of certificates.

Certificate paths can be longer than the example shown in Figure 5 (for example there may be an Australian Government Certification Authority), but they all depend on each system knowing, a priori, at least one high level public key. Lotus Notes, for example, comes pre installed with the public keys of several US Certification Authorities such as Verisign.

All this is quite straightforward, except for three details. A system is given a certificate to check and to do this it needs the public key of the certification authority that signed the certificate. But to do this, it must (i) identify who signed the certificate, (ii) work out where to go to ask for a copy of the signer’s certificate, and (iii) that copy must be on a certificate path that leads to a public key known by the system doing the checking.

The last point needs to be clarified. A certification authority may have several certificates, each signed by a different superior certification authority. For example, in addition to an external agency having its certificate signed by the Victorian Government certification authority, it may also have a certificate signed by a commercial certification authority. The Victorian Government certificate is used by other government agencies (because that is the key the agency’s systems have been loaded with). Commercial companies will use the certificate signed by the commercial certification authority (because that is the key the commercial systems have been loaded with). Instead of a single path of certificates, there is actually a web of certificates. Validating a public key involves navigating this web.

A variety of algorithms have been developed to allow this web of certificates to be navigated.

Figure 5: An example of Public Key Infrastructure implemented within the Victorian Government

3.7.3 Certificates and Archives

From the VERS perspective, a major problem with the PKI is that no attention has been paid to the archival implications of digital signatures. Clearly, to check the digital signature of a document in 50 years requires that the public key of the signer is still accessible. However, public key technology was primarily developed to protect messages passing across a network. Public keys have consequently only been designed to be valid for very short periods of time and so destruction of old public keys is not considered a problem. In fact, certificates are only valid over a specified period over which the Certification Authority warrants that it will maintain information about the status of the certificate.

3.8 Encryption

This Standard does not recommend encryption of records stored in VERS long term format. PROV recognises that preventing unauthorised access to records is an important feature of an archive and encryption may significantly simplify the provision of this feature. PROV also recognises that without encryption, access control is dependent on the archive software preventing access to records. Also, the possibility of bugs and back doors in the hardware, operating system and archive software must be dealt with. However, if the record is encrypted, preservation of the record depends on preservation of two separate pieces of data: the record itself, and the key used to decrypt the record. Loss of either of these means loss of the record.

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