【正文】 here is some broadly accepted publickey algorithm, such as RSA, any participant can send his or her public key to any other participant or broadcast the key to the munity at large (Figure ). For example, because of the growing popularity of PGP (pretty good privacy, discussed in Chapter 15), 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 Inter 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 (see Figure ). 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 (Figure ). Such a scheme would include the following elements: 1. The authority maintains a directory with a {name, public key} entry for each participant. 2. Each participant registers a public key with the directory authority. Registration would have to be in person or by some form of secure authenticated munication. 3. 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 promised in some way. 4. Participants could also access the directory electronically. For this purpose, secure, authenticated munication from the authority to the participant is mandatory. This scheme is clearly more secure than individual public announcements but still has vulnerabilities. If an adversary succeeds in obtaining or puting the private key of the directory authority, the adversary could authoritatively pass out counterfeit public keys and subsequently impersonate any participant and eavesdrop on messages sent to any participant. Another way to achieve the same end is for the adversary to tamper with the records kept by the authority. PublicKey Authority Stronger security for publickey distribution can be achieved by providing tighter control over the distribution of public keys from the directory. A typical scenario is illustrated in Figure , 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 Figure ) occur: 1. A sends a timestamped message to the publickey authority containing a request for the current public key of B. 2. The authority responds with a message that is encrypted using the authority39。s current public key 3. A stores B39。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. 6. A returns N2, encrypted using B39。s owner. 2. Any participant can verify that the certificate originated from the certificate authority and is not counterfeit. 3. Only the certificate authority can create and update certificates. These requirements are satisfied by the original proposal in [KOHN78]. Denning [DENN83] added the following additional requirement: 4. Any participant can verify the currency of the certificate. A certificate scheme is illustrated in Figure . Each participant applies to the certificate authority, supplying a public key and requesting a certificate. Figure . Exchange of PublicKey Certificates Application must be in person or by some form of secure authenticated munication. 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) The recipient uses the authority39。s private key is learned by an adversary. A generates a new private/public key pair and applies to the certificate authority for a new certificate. Meanwhile, the adversary replays the old certificate to B. If B then encrypts messages using the promised old public key, the adversary can read those messages. In this context, the promise of a private key is parable to the loss of a credit card. The owner cancels the credit card number but is at risk until all possible municants are aware that the old credit card is obsolete. Thus, the timestamp serves as something like an expiration date. If a certificate is sufficiently old, it is assumed to be expired. One scheme has bee universally accepted for formatting publickey certificates: the standard. certificates are used in most work security applications, including IP security, secure sockets layer (SSL), secure electronic transactions (SET), and S/MIME, all of which are discussed in Part Two. is examined in detail in Chapter 14. Distribution of Secret Keys Using PublicKey Cryptography Once public keys have been distributed or have bee accessible, secure munication that thwarts eavesdropping (Figure ), tampering (Figure ), or both (Figure ) is possible. However, few users will wish to make exclusive use of publickey encryption for munication because of the relatively slow