24 Key Management
Objectives:
- To introduce public-key encryption schemes are secure only if the authenticity of the public key is assured.
- To discuss about public-key certificate schemes and provides the necessary security.
- To learn about Diffie-Hellman key management protocol.
- To discuss about ECC and ECC- Diffie Hellman
Introduction:
Public-key encryption schemes are secure only if the authenticity of the public key is assured. A public-key certificate scheme provides the necessary security.
- A simple public-key algorithm is Diffie-Hellman key exchange. This protocol enables two users to establish a secret key using a public-key scheme based on discrete logarithms. The protocol is secure only if the authenticity of the two participants can be established. Elliptic curve arithmetic can be used to develop a variety of elliptic curve cryptography (ECC) schemes, including key exchange, encryption, and digital signature. For purposes of ECC, elliptic curve arithmetic involves the use of an elliptic curve equation defined over a finite field.
1. Key Management
We examine the problem of the distribution of secret keys. One of the major roles of public-key encryption has been to address the problem of key distribution. There are actually two distinct aspects to the use of public-key cryptography in this regard. The distribution of public keys, the use of public-key encryption to distribute secret keys
1.1 Distribution of Public Keys
Several techniques have been proposed for the distribution of public keys. Virtually all these proposals can be grouped into the following general schemes like public announcement, publicly available directory, public-key authority and public-key certificates
1.2 Public Announcement of Public Keys
On the face of it, the point of public-key encryption is that the public key is public. Thus, if there is some broadly accepted public-key algorithm, such as RSA, any participant can send his or her public key to any other participant or broadcast the key to the community at large (Fig.1).
For example, because of the growing popularity of PGP (pretty good privacy), which makes use of RSA, many PGP users have adopted the practice of appending their public key to messages that they send to public forums, such as USENET newsgroups and Internet mailing lists.
Although this approach is convenient, it has a major weakness. Anyone can forge such a public announcement. That is, some user could pretend to be user A and send a public key to another participant or broadcast such a public key.
Until such time as user A discovers the forgery and alerts other participants, the forger is able to read all encrypted messages intended for A and can use the forged keys for authentication.
1.3 Publicly Available Directory
A greater degree of security can be achieved by maintaining a publicly available dynamic directory of public keys. Maintenance and distribution of the public directory would have to be the responsibility of some trusted entity or organization (Fig.2). Such a scheme would include the elements such as the authority maintains a directory with a {name, public key} entry for each participant. Each participant registers a public key with the directory authority. Registration would have to be in person or by some form of secure authenticated communication. A participant may replace the existing key with a new one at any time, either because of the desire to replace a public key that has already been used for a large amount of data, or because the corresponding private key has been compromised in some way. Participants could also access the directory electronically. For this purpose, secure, authenticated communication from the authority to the participant is mandatory.
1.4 Public-Key Authority
Stronger security for public-key distribution can be achieved by providing tighter control over the distribution of public keys from the directory. A typical scenario is illustrated in Fig. 3, which is based on a figure in [POPE79]. As before, the scenario assumes that a central authority maintains a dynamic directory of public keys of all participants. In addition, each participant reliably knows a public key for the authority, with only the authority knowing the corresponding private key. The following steps (matched by number to Fig.
3)occur:
- A sends a timestamped message to the public-key authority containing a request for the current public key of B.
- The authority responds with a message that is encrypted using the authority’s private key, PRauth Thus, A is able to decrypt the message using the authority’s public key. Therefore, A is assured that the message originated with the authority. The message includes the following:
- B’s public key, PUb which A can use to encrypt messages destined for B.
- The original request, to enable A to match this response with the corresponding earlier request and to verify that the original request was not altered before reception by the authority
- The original timestamp, so A can determine that this is not an old message from the authority containing a key other than B’s current public key
- A stores B’s public key and also uses it to encrypt a message to B containing an identifier of A (IDA) and a nonce (N1), which is used to identify this transaction uniquely.
- B retrieves A’s public key from the authority in the same manner as A retrieved B’s public key.
At this point, public keys have been securely delivered to A and B, and they may begin their protected exchange. However, two additional steps are desirable:
B sends a message to A encrypted with PUa and containing A’s nonce (N1) as well as a new nonce generated by B (N2), Because only B could have decrypted
- Message (3), the presence of N1 in message (6) assures A that the correspondent is B.
- A returns N2, encrypted using B’s public key, to assure B that its correspondent is A.
Thus, a total of seven messages are required. However, the initial four messages need be used only infrequently because both A and B can save the other’s public key for future use, a technique known as caching. Periodically, a user should request fresh copies of the public keys of its correspondents to ensure currency.
- Public-Key Certificates
The scenario of Fig. 3 is attractive, yet it has some drawbacks. The public-
key authority could be somewhat of a bottleneck in the system, for a user must appeal to the authority for a public key for every other user that it wishes to contact. As before, the directory of names and public keys maintained by the authority is vulnerable to tampering.
An alternative approach, use certificates that can be used by participants to exchange keys without contacting a public-key authority, in a way that is as reliable as if the keys were obtained directly from a public-key authority. In essence, a certificate consists of a public key plus an identifier of the key owner, with the whole block signed by a trusted third party.
Typically, the third party is a certificate authority, such as a government agency or a financial institution that is trusted by the user community. A user can present his or her public key to the authority in a secure manner, and obtain a certificate. The user can then publish the certificate. Anyone needed this user’s public key can obtain the certificate and verify that it is valid by way of the attached trusted signature. A participant can also convey its key information to another by transmitting its certificate. Other participants can verify that the certificate was created by the authority. We can place the following requirements on this scheme:
1. Any participant can read a certificate to determine the name and public key of the certificate’s owner.
2. Any participant can verify that the certificate originated from the certificate authority and is not counterfeit.
- Only the certificate authority can create and update certificates.
- Any participant can verify the currency of the certificate.
Application must be in person or by some form of secure authenticated communication. For participant A, the authority provides a certificate of the form
CA = E(PRauth, [T||IDA||PUa])
Where PRauth is the private key used by the authority and T is a timestamp. A may then pass this certificate on to any other participant, who reads and verifies the certificate as follows:
D(PUauth, CA) = D(PUauth, E(PRauth, [T||IDA||PUa])) = (T||IDA||PUa).
- Distribution of Secret Keys Using Public-Key Cryptography
Once public keys have been distributed or have become accessible, secure communication that thwarts eavesdropping, tampering, or both is possible. However, few users will wish to make exclusive use of public-key encryption for communication because of the relatively slow data rates that can be achieved. Accordingly, public-key encryption provides for the distribution of secret keys to be used for conventional encryption.
3.1 Simple Secret Key Distribution
Merkle proposed simple secrete key distribution in 1979 .It generates a new temporary public key pair .A sends B the public key and their identity. B generates a session key K sends it to A encrypted using the supplied public key. A decrypts the session key and both problem is that an opponent can intercept and impersonate both halves of protocol
A and B can now securely communicate using conventional encryption and the session key Ks. At the completion of the exchange, both A and B discard Ks. Despite its simplicity, this is an attractive protocol. No keys exist before the start of the communication and none exist after the completion of communication. Thus, the risk of compromise of the keys is minimal. At the same time, the communication is secure from eavesdropping.
The protocol depicted in Fig. 5 is insecure against an adversary who can intercept messages and then either relay the intercepted message or substitute another message. Such an attack is known as a man-in-the-middle attack. In this case, if an adversary, E, has control of the intervening communication channel, then E can compromise the communication in the following fashion without being detected:
- A generates a public/private key pair {PUa, PRa} and transmits a message intended for B consisting of PUa and an identifier of A, IDA.
- E intercepts the message, creates its own public/private key pair {PUe, PRe} and transmits PUe||IDA to B.
- B generates a secret key, Ks, and transmits E(PUe, Ks).
- E intercepts the message, and learns Ks by computing D(PRe, E(PUe, Ks)).
- E transmits E(PUa, Ks) to A.
The result is that both A and B know Ks and are unaware that Ks has also been revealed to E. A and B can now exchange messages using Ks E no longer actively interferes with the communications channel but simply eavesdrops. Knowing Ks E can decrypt all messages, and both A and B are unaware of the problem. Thus, this simple protocol is only useful in an environment where the only threat is eavesdropping.
3.2 Secret Key Distribution with Confidentiality and Authentication
Based on an approach suggested in Fig 6 it provides protection against both active and passive attacks. We begin at a point when it is assumed that A and B have exchanged public keys by one of the schemes described earlier in this section. Then the following steps occur:
1. A uses B’s public key to encrypt a message to B containing an identifier of A (IDA) and a nonce (N1), which is used to identify this transaction uniquely.
2. B sends a message to A encrypted with PU a and containing A’s nonce (N1) as well as a new nonce generated by B (N2). Because only B could have decrypted message (1), the presence of N1 in message (2) assures A that the correspondent is B.
- A returns N2 encrypted using B’s public key, to assure B that its correspondent is A.
- A selects a secret key Ks and sends M = E(PUb, E(PRa, Ks)) to B. Encryption of this message with B’s public key ensures that only B can read it; encryption with A’s private key ensures that only A could have sent it.
- B computes D(PUa, D(PRb, M)) to recover the secret key.
Notice that the first three steps of this scheme are the same as the last three steps of Fig.3. The result is that this scheme ensures both confidentiality and authentication in the exchange of a secret key.
4 Hybrid Key Distribution
Yet another way to use public-key encryption to distribute secret keys is a hybrid approach in use on IBM mainframes. This scheme retains the use of a key distribution center (KDC) that shares a secret master key with each user and distributes secret session keys encrypted with the master key. A public key scheme is used to distribute the master keys. The following rationale is provided for using this three-level approach such as Performance: There are many applications, especially transaction-oriented applications, in which the session keys change frequently. Distribution of session keys by public-key encryption could degrade overall system performance because of the relatively high computational load of public-key encryption and decryption. With a three-level hierarchy, public-key encryption is used only occasionally to update the master key between a user and the KDC and Backward compatibility: The hybrid scheme is easily overlaid on an existing KDC scheme, with minimal disruption or software changes.
- SUMMARY
We have considered:
- Distribution of public keys
- Public-key distribution of secret keys
- Diffie-Hellman key exchange
- Elliptic Curve cryptography
you can view video on Key Management |