Digital Signatures

Message authentication protects two parties who exchange messages from any third party. However, it does not protect the two parties against each other.

In situations where there is not complete trust between sender and receiver, something more than authentication is needed. The most attractive solution to this problem is the digital signature. The digital signature is analogous to the handwritten signature. It must have the following properties:

• It must verify the author and the date and time of the signature. • It must to authenticate the contents at the time of the signature. • It must be verifiable by third parties, to resolve disputes.

Thus, the digital signature function includes the authentication function. On the basis of these properties, we can formulate the following requirements for a digital signature:

• The signature must be a bit pattern that depends on the message being signed. • The signature must use some information unique to the sender, to prevent both forgery and denial. • It must be relatively easy to produce the digital signature. • It must be relatively easy to recognize and verify the digital signature. • It must be computationally infeasible to forge a digital signature, either by constructing a new message for an existing digital signature or by constructing a fraudulent digital signature for a given message. • It must be practical to retain a copy of the digital signature in storage.

A variety of approaches has been proposed for the digital signature function. These approaches fall into two categories: direct and arbitrated.

Direct Digital Signature

The direct digital signature involves only the communicating parties (source, destination). It is assumed that the destination knows the public key of the source. A digital signature may be formed by encrypting the entire message with the sender’s private key or by encrypting a hash code of the message with the sender’s private key.

Confidentiality can be provided by further encrypting the entire message plus signature with either the receiver’s public key (public-key encryption) or a shared secret key (symmetric encryption. Note that it is important to perform the signature function first and then an outer confidentiality function. In case of dispute, some third party must view the message and its signature. If the signature is calculated on an encrypted message, then the third party also needs access to the decryption key to read the original message. However, if the signature is the inner operation, then the recipient can store the plaintext message and its signature for later use in dispute resolution.

All direct schemes described so far share a common weakness. The validity of the scheme depends on the security of the sender’s private key. If a sender later wishes to deny sending a particular message, the sender can claim that the private key was lost or stolen and that someone else forged his or her signature. Administrative controls relating to the security of private keys can be employed to thwart or at least weaken this ploy, but the threat is still there, at least to some degree. One example is to require every signed message to include a timestamp (date and time) and to require prompt reporting of compromised keys to a central authority.

Another threat is that some private key might actually be stolen from X at time T. The opponent can then send a message signed with X’s signature and stamped with a time before or equal to T.

Arbitrated Digital Signature

The problems associated with direct digital signatures can be addressed by using an arbiter. As with direct signature schemes, there is a variety of arbitrated signature schemes. In general terms, they all operate as follows. Every signed message from a sender X to a receiver Y goes first to an arbiter A, who subjects the message and its signature to a number of tests to check its origin and content. The message is then dated and sent to Y with an indication that it has been verified to the satisfaction of the arbiter. The presence of A solves the problem faced by direct signature schemes: that X might disown the message. The arbiter plays a sensitive and crucial role in this sort of scheme, and all parties must have a great deal of trust that the arbitration mechanism is working properly.

Table 1 gives several examples of arbitrated digital signatures. In the first, symmetric encryption is used. It is assumed that the sender X and the arbiter A share a secret key Kxa and that A and Y share secret key Kay. X constructs a message M and computes its hash value H(M). Then X transmits the message plus a signature to A. The signature consists of an identifier IDX of X plus the hash value, all encrypted using Kxa. A decrypts the signature and checks the hash value to validate the message. Then A transmits a message to Y, encrypted with Kay. The message includes IDX, the original message from X, the signature, and a timestamp. Y can decrypt this to recover the message and the signature. The timestamp informs Y that this message is timely and not a replay. Y can store M and the signature. In case of dispute, Y, who claims to have received M from X, sends the following message to A:

[1] The following format is used. A communication step in which P sends a message M to Q is represented as P

Q: M.

Table 1. Arbitrated Digital Signature Techniques

(1) X A: M||E(Kxa, [IDX||H(M)])
(2) A Y: E(Kay, [IDX||M||E(Kxa, [IDX||H(M)])||T])

(a) Conventional Encryption, Arbiter Sees Message

(1) X A: IDX||E(Kxy, M)||E(Kxa, [IDX||H(E(Kxy, M))]) (2) A Y: E(Kay,[IDX||E(Kxy, M)])||E(Kxa, [IDX||H(E(Kxy, M))||T])

(b) Conventional Encryption, Arbiter Does Not See Message

(1) X A: IDX||E(PRx, [IDX||E(PUy, E(PRx, M))]) (2) A Y: E(PRa, [IDX||E(PUy, E(PRx, M))||T])

(c) Public-Key Encryption, Arbiter Does Not See Message

Notation:
X = sender
Y = recipient
A = Arbiter
M = message
T = timestamp
The arbiter uses Kay to recover IDX, M, and the signature, and then uses Kxa to decrypt the signature and verify the hash code. In this scheme, Y cannot directly check X’s signature; the signature is there solely to settle disputes. Y considers the message from X authentic because it comes through A. In this scenario, both sides must have a high degree of trust in A:

• X must trust A not to reveal Kxa and not to generate false signatures of the form E(Kxa, [IDX||H(M)]). • Y must trust A to send E(Kay, [IDX||M||E(Kxa, [IDX||H(M)])||T]) only if the hash value is correct and the signature wasgenerated by X. • Both sides must trust A to resolve disputes fairly.

If the arbiter does live up to this trust, then X is assured that no one can forge his signature and Y is assured that X cannot disavow his signature.

The preceding scenario also implies that A is able to read messages from X to Y and, indeed, that any eavesdropper is able to do so. Table 1b shows a scenario that provides the arbitration as before but also assures confidentiality. In this case it is assumed that X and Y share the secret key Kxy. Now, X transmits an identifier, a copy of the message encrypted with Kxy, and a signature to A. The signature consists of the identifier plus the hash value of the encrypted message, all encrypted using Kxa. As before, A decrypts the signature and checks the hash value to validate the message. In this case, A is working only with the encrypted version of the message and is prevented from reading it. A then transmits everything that it received from X, plus a timestamp, all encrypted with Kay, to Y.

Although unable to read the message, the arbiter is still in a position to prevent fraud on the part of either X or Y. A remaining problem, one shared with the first scenario, is that the arbiter could form an alliance with the sender to deny a signed message, or with the receiver to forge the sender’s signature.

All the problems just discussed can be resolved by going to a public-key scheme, one version of which is shown in Table 1c. In this case, X double encrypts a message M first with X’s private key, PRx and then with Y’s public key, PUy. This is a signed, secret version of the message. This signed message, together with X’s identifier, is encrypted again with PRx and, together with IDX, is sent to A. The inner, double-encrypted message is secure from the arbiter (and everyone else except Y). However, A can decrypt the outer encryption to assure that the message must have come from X (because only X has PRx). A checks to make sure that X’s private/public key pair is still valid and, if so, verifies the message. Then A transmits a message to Y, encrypted with PRa. The message includes IDX, the double-encrypted message, and a timestamp. This scheme has a number of advantages over the preceding two schemes. First, no information is shared among the parties before communication, preventing alliances to defraud. Second, no incorrectly dated message can be sent, even if PRx is compromised, assuming that PRa is not compromised. Finally, the content of the message from X to Y is secret from A and anyone else. However, this final scheme involves encryption of the message twice with a public-key algorithm. We discuss more practical approaches subsequently.

Authentication Protocols

In this section, we focus on two general areas (mutual authentication and one-way authentication) and examine some of the implications of authentication techniques in both.

Mutual Authentication

An important application area is that of mutual authentication protocols. Such protocols enable communicating parties to satisfy themselves mutually about each other’s identity and to exchange session keys.

Central to the problem of authenticated key exchange are two issues: confidentiality and timeliness. To prevent masquerade and to prevent compromise of session keys, essential identification and session key information must be communicated in encrypted form. This requires the prior existence of secret or public keys that can be used for this purpose. The second issue, timeliness, is important because of the threat of message replays. Such replays, at worst, could allow an opponent to compromise a session key or successfully impersonate another party. At minimum, a successful replay can disrupt operations by presenting parties with messages that appear genuine but are not.

Lists the following examples of replay attacks:

• Simple replay: The opponent simply copies a message and replays it later. • Repetition that can be logged: An opponent can replay a timestamped message within the valid time window. • Repetition that cannot be detected: This situation could arise because the original message could have been suppressed and thus did not arrive at its destination; only the replay message arrives. • Backward replay without modification: This is a replay back to the message sender. This attack is possible if symmetric encryption is used and the sender cannot easily recognize the difference between messages sent and messages received on the basis of content.

One approach to coping with replay attacks is to attach a sequence number to each message used in an authentication exchange. A new message is accepted only if its sequence number is in the proper order. The difficulty with this approach is that it requires each party to keep track of the last sequence number for each claimant it has dealt with. Because of this overhead, sequence numbers are generally not used for authentication and key exchange. Instead, one of the following two general approaches is used:

• Timestamps: Party A accepts a message as fresh only if the message contains a timestamp that, in A’s judgment, is close enough to A’s knowledge of current time. This approach requires that clocks among the various participants be synchronized. • Challenge/response: Party A, expecting a fresh message from B, first sends B a nonce (challenge) and requires that the subsequent message (response) received from B contain the correct nonce value.

It can be argued that the timestamp approach should not be used for connection-oriented applications because of the inherent difficulties with this technique. First, some sort of protocol is needed to maintain synchronization among the various processor clocks. This protocol must be both fault tolerant, to cope with network errors, and secure, to cope with hostile attacks. Second, the opportunity for a successful attack will arise if there is a temporary loss of synchronization resulting from a fault in the clock mechanism of one of the parties. Finally, because of the variable and unpredictable nature of network delays, distributed clocks cannot be expected to maintain precise synchronization. Therefore, any timestamp-based procedure must allow for a window of time sufficiently large to accommodate network delays yet sufficiently small to minimize the opportunity for attack.

On the other hand, the challenge-response approach is unsuitable for a connectionless type of application because it requires the overhead of a handshake before any connectionless transmission, effectively negating the chief characteristic of a connectionless transaction. For such applications, reliance on some sort of secure time server and a consistent attempt by each party to keep its clocks in synchronization may be the best approach.

Symmetric Encryption Approaches

As you know there is a two-level hierarchy of symmetric encryption keys can be used to provide confidentiality for communication in a distributed environment. In general, this strategy involves the use of a trusted key distribution center (KDC). Each party in the network shares a secret key, known as a master key, with the KDC. The KDC is responsible for generating keys to be used for a short time over a connection between two parties, known as session keys, and for distributing those keys using the master keys to protect the distribution. This approach is quite common.

Secret keys Ka and Kb are shared between A and the KDC and B and the KDC, respectively. The purpose of the protocol is to distribute securely a session key Ks to A and B. A securely acquires a new session key in step 2. The message in step 3 can be decrypted, and hence understood, only by B. Step 4 reflects B’s knowledge of Ks, and step 5 assures B of A’s knowledge of Ks and assures B that this is a fresh message because of the use of the nonce N2. Purpose of steps 4 and 5 is to prevent a certain type of replay attack. In particular, if an opponent is able to capture the message in step 3 and replay it, this might in some fashion disrupt operations at B.

Despite the handshake of steps 4 and 5, the protocol is still vulnerable to a form of replay attack. Suppose that an opponent, X, has been able to compromise an old session key. Admittedly, this is a much more unlikely occurrence than that an opponent has simply observed and recorded step 3. Nevertheless, it is a potential security risk. X can impersonate A and trick B into using the old key by simply replaying step 3. Unless B remembers indefinitely all previous session keys used with A, B will be unable to determine that this is a replay. If X can intercept the handshake message, step 4, then it can impersonate A’s response, step 5. From this point on, X can send bogus messages to B that appear to B to come from A using an authenticated session key.

Public-Key Encryption Approaches

This protocol assumes that each of the two parties is in possession of the current public key of the other. It may not be practical to require this assumption.

In this case, the central system is referred to as an authentication server (AS), because it is not actually responsible for secret keydistribution. Rather, the AS provides public-key certificates. The session key is chosen and encrypted by A; hence, there is no risk ofexposure by the AS. The timestamps protect against replays of compromised keys.

This protocol is compact but, as before, requires synchronization of clocks. Another approach, proposed by Woo and Lam, makes use of nonces. The protocol consists of the following steps:

1. A KDC: IDA||IDB
2. KDC A: E(PRauth, [IDB||PUb])
3. A B: E(PUb, [Na||IDA])
4. B KDC: IDA||IDB||E(PUauth, Na)
5. KDC B: E(PRauth, [IDA||PUa])||E(PUb, E(PRauth, [Na||Ks||IDB]))
6. B A: E(PUa, E(PRauth, [(Na||Ks||IDB)||Nb]))
7. A B: E(Ks, Nb)

In step 1, A informs the KDC of its intention to establish a secure connection with B. The KDC returns to A a copy of B’s public-key certificate (step 2). Using B’s public key, A informs B of its desire to communicate and sends a nonce Na (step 3). In step 4, B asks the KDC for A’s public-key certificate and requests a session key; B includes A’s nonce so that the KDC can stamp the session key with that nonce. The nonce is protected using the KDC’s public key. In step 5, the KDC returns to B a copy of A’s public-key certificate, plus the information {Na, Ks, IDB}. This information basically says thatK s is a secret key generated by the KDC on behalf of B and tied toN a; the binding of Ks and Na will assure A that Ks is fresh. This triple is encrypted, using the KDC’s private key, to allow B to verify that the triple is in fact from the KDC. It is also encrypted using B’s public key, so that no other entity may use the triple in an attempt to establish a fraudulent connection with A. In step 6, the triple {Na, Ks, IDB}, still encrypted with the KDC’s private key, is relayed to A, together with a nonce Nb generated by B. All the foregoing are encrypted using A’s public key. A retrieves the session keKy s and uses it to encrypt Nb and return it to B. This last message assures B of A’s knowledge of the session key.

This seems to be a secure protocol that takes into account the various attacks.

1. A KDC: IDA||IDB
2. KDC A: E(PRauth, [IDB||PUb])
3. A B: E(PUb, [Na||IDA])
4. B KDC: IDA||IDB||E(PUauth, Na)
5. KDC B: E(PRauth, [IDA||PUa])||E(PUb, E(PRauth, [Na||Ks||IDA||IDB])
6. B A: E(PUa, E(PRauth, [(Na||Ks||IDA||IDB)||Nb]))
7. A B: E(Ks, Nb)

The identifier of A, IDA, is added to the set of items encrypted with the KDC’s private key in steps 5 and 6. This binds the session keKys to the identities of the two parties that will be engaged in the session. This inclusion of IDA accounts for the fact that the nonce value Na is considered unique only among all nonces generated by A, not among all nonces generated by all parties. Thus, it is the pair {IDA, Na} that uniquely identifies the connection request of A.

In both this example and the protocols described earlier, protocols that appeared secure were revised after additional analysis. These examples highlight the difficulty of getting things right in the area of authentication.

One-Way Authentication

One application for which encryption is growing in popularity is electronic mail (e-mail). The very nature of electronic mail, and its chief benefit, is that it is not necessary for the sender and receiver to be online at the same time. Instead, the e-mail message is forwarded to the receiver’s electronic mailbox, where it is buffered until the receiver is available to read it.

The “envelope” or header of the e-mail message must be in the clear, so that the message can be handled by the store-and-forward e-mail protocol, such as the Simple Mail Transfer Protocol (SMTP) or X.400. However, it is often desirable that the mail-handling protocol not require access to the plaintext form of the message, because that would require trusting the mail-handling mechanism. Accordingly, the e-mail message should be encrypted such that the mail-handling system is not in possession of the decryption key.

A second requirement is that of authentication. Typically, the recipient wants some assurance that the message is from the alleged sender.

Symmetric Encryption Approach

Using symmetric encryption, the decentralized key distribution scenario is impractical. This scheme requires the sender to issue a request to the intended recipient, await a response that includes a session key, and only then send the message.

With some refinement, the KDC strategy is a candidate for encrypted electronic mail. Because we wish to avoid requiring that the recipient (B) be on line at the same time as the sender (A), steps 4 and 5 must be eliminated. For a message with content M, the sequence is as follows:

1. A KDC: IDA||IDB||N1
2. KDC A: E(Ka, [Ks||IDB||N1||E(Kb, [Ks||IDA])])
3. A B: E(Kb, [Ks||IDA])||E(Ks, M)

This approach guarantees that only the intended recipient of a message will be able to read it. It also provides a level of authentication that the sender is A. As specified, the protocol does not protect against replays. Some measure of defence could be provided by including a timestamp with the message. However, because of the potential delays in the e-mail process, such timestamps may have limited usefulness.

Public-Key Encryption Approaches

We have already presented public-key encryption approaches that are suited to electronic mail, including the straightforward encryption of the entire message for confidentiality. These approaches require that either the sender know the recipient’s public key (confidentiality) or the recipient know the sender’s public key (authentication) or both (confidentiality plus authentication). In addition, the public-key algorithm must be applied once or twice to what may be a long message.

If confidentiality is the primary concern, then the following may be more efficient:

A B: E(PUb, Ks)||E(Ks, M)

In this case, the message is encrypted with a one-time secret key. A also encrypts this one-time key with B’s public key. Only B will be able to use the corresponding private key to recover the one-time key and then use that key to decrypt the message. This scheme is more efficient than simply encrypting the entire message with B’s public key.

If authentication is the primary concern, then a digital signature may suffice:

A B:M||E(PRa, H(M))

This method guarantees that A cannot later deny having sent the message. However, this technique is open to another kind of fraud. Bob composes a message to his boss Alice that contains an idea that will save the company money. He appends his digital signature and sends it into the e-mail system. Eventually, the message will get delivered to Alice’s mailbox. But suppose that Max has heard of Bob’s idea and gains access to the mail queue before delivery. He finds Bob’s message, strips off his signature, appends his, and requeues the message to be delivered to Alice. Max gets credit for Bob’s idea.

To counter such a scheme, both the message and signature can be encrypted with the recipient’s public key:

A B: E(PUb, [M||E(PRa, H(M))])

The latter two schemes require that B know A’s public key and be convinced that it is timely. An effective way to provide this assurance is the digital certificate. Now we have

A B:M||E(PRa, H(M))||E(PRas, [T||IDA||PUa])

In addition to the message, A sends B the signature, encrypted with A’s private key, and A’s certificate, encrypted with the private key of the authentication server. The recipient of the message first uses the certificate to obtain the sender’s public key and verify that it is authentic and then uses the public key to verify the message itself. If confidentiality is required, then the entire message can be encrypted with B’s public key. Alternatively, the entire message can be encrypted with a one-time secret key; the secret key is also transmitted, encrypted with B’s public key.