Digital signatures
Digital signatures provide a way to protect the integrity of a digital document and to verify who signed it. The document in question could be anything: an email message, a file on a floppy disk, or the information in a personal certificate.
Protecting a document's integrity is done by giving the recipient a way to determine whether or not the document has been modified since it was digitally signed. Doing this involves two cryptographic techniques: message digest algorithms and public-key encryption.
To allow a document's integrity to be verified, a mathematical function is applied to the bits that make up the digital document. The resulting number is called the "message digest." It has the property that if the document is altered, applying the same function would result in a different message digest. If a message digest computed at the time the document was signed can be compared with one computed at a later time, it is possible to know whether the document was--either accidentally or intentionally--modified at some point in between.
The diagram that follows illustrates how digital signatures can be applied to email, though the same ideas apply regardless of how a document is transmitted electronically, and regardless of whether it is thousands of pages of human-readable text or a short computer-to-computer message such as a public-key certificate.
(A) The author's message is altered by the man-in-the-middle attack and the recipient is not aware that the message has been changed. (B) The author uses a message digest (MD). The recipient recalculates the MD and, because the two MDs do not match, he knows the message was altered. (C) The man in the middle recalculates and replaces the MD on the altered message before sending it. The recipient will be fooled. (D) The author creates her digital signature by encrypting the MD with her private signing key. The man in the middle does not have the author's private key with which to alter the original MD, so the MDs do not match. |
Digital signatures work this way: The author of the document calculates a message digest by putting the data through a one-way mathematical hashing process (represented by "#" in the diagram). This binary representation ("7012" in the diagram) is like a fingerprint that can be produced only from the original message using the same hashing algorithm.
The message digest is sent along with the document so that the recipient can recalculate the message digest from the document and compare it with the digest received with the document ("B" in the diagram). If the digests are the same, then the message sent and the message received are exactly the same.
The challenge: Message digests alone are not a complete solution for ensuring that a document has not been modified. Someone might intercept a message and its digest, modify the message, recalculate a new digest, and send both on to the recipient ("C" in the diagram). This is called a "man-in-the-middle" attack.
Thus, a digital signature must be more than just a message digest value for the signed document. A digital signature wouldn't be worth its salt if it could be easily modified along with the document. So the message digest itself must somehow be protected from modification.
This is where the second cryptographic technique comes in. The message digest is encrypted using the private key of the document's author ("D" in the diagram). The recipient may then decrypt the message digest using the public key of the originator and, assuming they used the correct public key, have assurance that the message digest they decrypted has not been modified since the document was signed.
Thus, using a digital signature makes a man-in-the-middle attack more difficult to carry out because the process of digitally signing a document includes calculating the message digest and then encrypting it.
If, for example, you wish to digitally sign a document being sent to Tom, the message digest would be encrypted using your private signing key. Tom would then verify your digital signature by using your public key (the other half of your signing key pair).
What does a digital signature look like?
A digital signature is not a graphical representation of a handwritten signature (a "John Hancock"). It is data created by encrypting a message digest with a private signing key to identify and authenticate the sender and the message. If compatible encryption software is installed on the recipient's computer, it will automatically try to verify the signature.
The State of Washington provides this example:
-------BEGIN SIGNATURE------ IQB1AwUBMVSiA5QYCuMfgNYjAQFAKgL/ ZkBfbeNEsbthba4BlrcnjaqbcKgNv+a5kr4537y8RCd+RHm 75yYh5xxA1ojELwNhhb7cltrp2V7LlOnAelws4S87UX80cL BtBcN6AACf11qymC2h+Rb2j5SSU+rmXWru+=QFMx -------END SIGNATURE------
Keys, keys, and more keys
Public-key cryptography involves two keys, a public one and a private one. But it gets better.
A public-key infrastructure that enables personal certificates for authentication, digital signatures for protecting document integrity and identity, and encryption for privacy, will undoubtedly require managing multiple key pairs for everyone using these capabilities. Different service providers may require different certificates and keys, and different functions call for using different keys.
In particular, a digital signature key pair should not be the same key pair used for encrypting messages. Digital signature keys and encryption keys need to be managed differently:
- Encryption keys should be backed up and managed centrally in order to ensure the recovery of data that has been encrypted by them
- Digital signature keys should not be backed up or managed centrally because they need to stay in the users' control to ensure non-repudiation
The challenge: Although digital signature technology is available today, very difficult management and policy issues stand in the way of widespread deployment. Secure messaging is the primary place we would use digital signatures, and is the application that would drive deployment of a public-key infrastructure for personal certificates.
