Problem - Kevin Tafuro

Discussion
One of the big motivators behind public key cryptography is that there is some hope
for securely exchanging encryption keys in an insecure medium. However, that is not
as easy as it sounds. If used in a naïve manner, the basic public key methods for communication
are susceptible to a man-in-the-middle attack, in which the two parties
end up talking to an attacker who relays messages, instead of to each other (we discuss
this attack in Recipe 7.1).
Man-in-the-middle attacks are possible because public key cryptography in and of
itself provides no means of establishing trust. PKI provides the means to establish
trust by binding public keys and identities together in a way that gives reasonable
assurance that you are communicating securely with the expected entity.
Using public key cryptography, * you can be sure that if you encrypt data with a public
key, only someone with the corresponding private key can decrypt it. If you simply
exchange public keys over an insecure medium, there is no easy way to be sure
that the public keys you receive belong to the people you think they do. In other
words, traditional public key cryptography does not establish trust between entities.
That is where PKI comes in.
One solution to the trust problem is to exchange public keys over a secure medium
(or to authenticate them in a secure medium by comparing cryptographic hashes of
the key, often called a fingerprint). The problem with this solution is that it is not
very scalable. If parties need to exchange public keys offline to communicate
securely, they might as well exchange symmetric keys and save themselves the computational
effort.
The basic idea behind public key infrastructure is to introduce a trusted third party
to the mix. The idea is that we somehow acquire the public key of the trusted third
party over a secure medium. In addition, each entity registers its public key with that
trusted party, along with information about that entity. Basically, the trusted party is
expected to ensure that the public key really does belong to the registrant and all of
the associated data is accurate. If the authority approves, it signs your certificate,
which is a piece of data containing your public key along with other identifying
information.
Once your certificate has been signed, you can hand that certificate to anyone, and as
long as that person has securely obtained the authority’s public key, he can take your
certificate and validate it by checking the authority’s signature. As a result, a client
can authenticate a server, even when the server’s public key is obtained over an insecure
medium (see Figure 10-1).
* Specifically, RSA. Not all public key algorithms are capable of performing encryption. RSA supports encryption,
key agreement, and digital signatures; DSA supports only digital signatures; and Diffie-Hellman supports
only key agreement.
Understanding Public Key Infrastructure (PKI) | 503
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.