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.

**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 *N**a *(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 {*N**a*, *K**s*, *ID**B*}. This information basi- cally says that *K**s *is a secret key generated by the KDC on behalf
of B and tied to *N**a*;
the binding of *K**s *and *N**a *will assure A that *K**s *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 {*N**a*, *K**s*, *ID**B*}, still encrypted with the KDC’s private
key, is relayed to A, together
with a nonce *N**b *generated by B. All the foregoing are encrypted using
A’s public key. A retrieves the session key *K**s*, uses
it to encrypt *N**b*, 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, *ID**A*, is added to the set of items encrypted
with the KDC’s private key in steps 5 and 6. This binds the session key *K**s *to the identities of the two parties that will be engaged in the session.
This inclusion of *ID**A *accounts for the fact
that the nonce value *N**a *is considered unique only among
all nonces generated by A, not among all nonces
generated by all parties. Thus, it is the pair {*ID**A*, *N**a*} 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.

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

Cryptography and Network Security Principles and Practice : Mutual Trust : User Authentication : Remote User Authentication Using Asymmetric Encryption |

**Related Topics **

Privacy Policy, Terms and Conditions, DMCA Policy and Compliant

Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.