Remote User Authentication Using Asymmetric Encryption

REMOTE USER AUTHENTICATION USING ASYMMETRIC ENCRYPTION

Mutual Authentication

In Chapter 14, we presented one approach to the use of public-key encryption for the purpose of session-key distribution (Figure 14.8). 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.

A protocol using timestamps is provided in [DENN81]:

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

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

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 basi- cally says that Ks is a secret key generated by the KDC on behalf of B and tied to Na; 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 key Ks, uses it to encrypt Nb, and returns 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. However, the authors themselves spotted a flaw and submitted a revised version of the algorithm in [WOO92b]:

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 key Ks 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

We have already presented public-key encryption approaches that are suited to electronic mail, including the straightforward encryption of the entire message for confidentiality (Figure 12.1b), authentication (Figure 12.1c), or both (Figure 12.1d). These approaches require that either the sender know the recipient’s public key (confidentiality), 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:

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 mes- sage. 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, as was illustrated in Figure 13.2:

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 mes- sage, 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:

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, described in Chapter 14. Now we have

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. This approach is explored in Chapter 18.