【正文】 tificate authority. The elements IDA and PUa provide the recipient with the name and public key of the certificate39。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. PublicKey Certificates The scenario of Figure is attractive, yet it has some drawbacks. The publickey 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, first suggested by Kohnfelder [KOHN78], is to use certificates that can be used by participants to exchange keys without contacting a publickey authority, in a way that is as reliable as if the keys were obtained directly from a publickey 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 munity. 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 user39。s public key from the authority in the same manner as A retrieved B39。s public key. Therefore, A is assured that the message originated with the authority. The message includes the following: ? B39。s private key, PRauth Thus, A is able to decrypt the message using the authority39。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. 4. B retrieves A39。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 other39。s public key, PUauth to decrypt the certificate. Because the certificate is readable only using the authority39。s public key. 3. A putes D(PRa, E(PUa, Ks)) to recover the secret key. Because only A can decrypt the message, only A and B will know the identity of Ks. 4. A discards PUa and PRa and B discards PUa. Figure . Simple Use of PublicKey Encryption to Establish a Session Key A and B can now securely municate using conventional encryption and the session key Ks. At the pletion 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 munication and none exist after the pletion of munication. Thus, the risk of promise of the keys is minimal. At the same time, the munication is secure from eavesdropping. The protocol depicted in Figure is insecure against an adversary who can intercept messages and then either relay the intercepted message or substitute another message (see Figure ). Such an attack is known as a maninthemiddle attack [RIVE84]. In this case, if an adversary, E, has control of the intervening munication channel, then E can promise the munication in the following fashion without being detected: 1. 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. 2. E intercepts the message, creates its own public/private key pair {PUe, PRe} and transmits PUe||IDA to B. 3. B generates a secret key, Ks, and transmits E(PUe, Ks). 4. E intercepts the message, and learns Ks by puting D(PRe, E(PUe, Ks)). 5. 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 munications 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. Secret Key Distribution with Confidentiality and Authentication Figure , based on an approach suggested in [NEED78], 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 B39。s public key ensures that only B can read it。 see [ELLI99] for a discussion. The purpose of the algorithm is to enable two users to securely exchange a key that can then be used for subsequent encryption of messages. The algorithm itself is limited to the exchange of secret values. The DiffieHellman algorithm depends for its effectiveness on the difficulty of puting discrete logarithms. Briefly, we can define the discrete logarithm in the following way. First, we define a primitive root of a prime number p as one whose powers modulo p generate all the integers from 1 to p 1. That is, if a is a primitive root of the prime number p, then the numbers a mod p, a2 mod p,..., ap1 mod p are distinct and consist of the integers from 1 through p 1 in some permutation. For any integer b and a primitive root a of prime number p, we can find a unique exponent i such that b ≡ ai (mod p) where 0 ≤ i ≤ (p － 1) The exponent i is referred to as the discrete logarithm of b for the base a, mod p. We express this value as dloga,p (b). See Chapter 8 for an extended discussion of discrete logarithms. The Algorithm Figure summarizes the DiffieHellman key exchange algorithm. For this scheme, there are two publicly known numbers: a prime number q and an integer that is a primitive root of q. Suppose the users A and B wish to exchange a key. User A selects a random integer