8.5
Management of Public Keys
Public-key cryptography makes it
possible for people who do not share a common key to communicate securely. It
also makes signing messages possible without the presence of a trusted third
party. Finally, signed message digests make it possible to verify the integrity
of received messages easily.
However, there is one problem that
we have glossed over a bit too quickly: if Alice and Bob do not know each
other, how do they get each other's public keys to start the communication
process? The obvious solution—put your public key on your Web site—does not
work for the following reason. Suppose that Alice wants to look up Bob's public
key on his Web site. How does she do it? She starts by typing in Bob's URL. Her
browser then looks up the DNS address of Bob's home page and sends it a GET
request, as shown in Fig. 8-23. Unfortunately, Trudy intercepts the
request and replies with a fake home page, probably a copy of Bob's home page
except for the replacement of Bob's public key with Trudy's public key. When
Alice now encrypts her first message with ET, Trudy decrypts it,
reads it, reencrypts it with Bob's public key, and sends it to Bob, who is none
the wiser that Trudy is reading his incoming messages. Worse yet, Trudy could
modify the messages before reencrypting them for Bob. Clearly, some mechanism
is needed to make sure that public keys can be exchanged securely.
As a first attempt at distributing
public keys securely, we could imagine a key distribution center available
on-line 24 hours a day to provide public keys on demand. One of the many
problems with this solution is that it is not scalable, and the key distribution
center would rapidly become a bottleneck. Also, if it ever went down, Internet
security would suddenly grind to a halt.
For these reasons, people have
developed a different solution, one that does not require the key distribution
center to be on-line all the time. In fact, it does not have to be on-line at
all. Instead, what it does is certify the public keys belonging to people,
companies, and other organizations. An organization that certifies public keys
is now called a CA (Certification Authority).
As an example, suppose that Bob
wants to allow Alice and other people to communicate with him securely. He can
go to the CA with his public key along with his passport or driver's license
and ask to be certified. The CA then issues a certificate similar to the one in
Fig. 8-24 and signs its SHA-1 hash with the CA's
private key. Bob then pays the CA's fee and gets a floppy disk containing the
certificate and its signed hash.
The fundamental job of a certificate
is to bind a public key to the name of a principal (individual, company, etc.).
Certificates themselves are not secret or protected. Bob might, for example,
decide to put his new certificate on his Web site, with a link on the main page
saying: Click here for my public-key certificate. The resulting click would
return both the certificate and the signature block (the signed SHA-1 hash of
the certificate).
Now let us run through the scenario
of Fig. 8-23 again. When Trudy intercepts Alice's
request for Bob's home page, what can she do? She can put her own certificate
and signature block on the fake page, but when Alice reads the certificate she
will immediately see that she is not talking to Bob because Bob's name is not
in it. Trudy can modify Bob's home page on-the-fly, replacing Bob's public key
with her own. However, when Alice runs the SHA-1 algorithm on the certificate,
she will get a hash that does not agree with the one she gets when she applies
the CA's well-known public key to the signature block. Since Trudy does not
have the CA's private key, she has no way of generating a signature block that
contains the hash of the modified Web page with her public key on it. In this
way, Alice can be sure she has Bob's public key and not Trudy's or someone
else's. And as we promised, this scheme does not require the CA to be on-line
for verification, thus eliminating a potential bottleneck.
While the standard function of a
certificate is to bind a public key to a principal, a certificate can also be
used to bind a public key to an attribute. For example, a certificate could
say: This public key belongs to someone over 18. It could be used to prove that
the owner of the private key was not a minor and thus allowed to access
material not suitable for children, and so on, but without disclosing the
owner's identity. Typically, the person holding the certificate would send it
to the Web site, principal, or process that cared about age. That site,
principal, or process would then generate a random number and encrypt it with
the public key in the certificate. If the owner were able to decrypt it and
send it back, that would be proof that the owner indeed had the attribute
stated in the certificate. Alternatively, the random number could be used to
generate a session key for the ensuing conversation.
Another example of where a
certificate might contain an attribute is in an object-oriented distributed
system. Each object normally has multiple methods. The owner of the object
could provide each customer with a certificate giving a bit map of which
methods the customer is allowed to invoke and binding the bit map to a public
key using a signed certificate. Again here, if the certificate holder can prove
possession of the corresponding private key, he will be allowed to perform the
methods in the bit map. It has the property that the owner's identity need not
be known, a property useful in situations where privacy is important.
If everybody who wanted something
signed went to the CA with a different kind of certificate, managing all the
different formats would soon become a problem. To solve this problem, a
standard for certificates has been devised and approved by ITU. The standard is
called X.509 and is in widespread use on the Internet. It has gone through
three versions since the initial standardization in 1988. We will discuss V3.
X.509 has been heavily influenced by
the OSI world, borrowing some of its worst features (e.g., naming and
encoding). Surprisingly, IETF went along with X.509, even though in nearly
every other area, from machine addresses to transport protocols to e-mail
formats, IETF generally ignored OSI and tried to do it right. The IETF version
of X.509 is described in RFC 3280.
At its core, X.509 is a way to
describe certificates. The primary fields in a certificate are listed in Fig. 8-25. The descriptions given there should
provide a general idea of what the fields do. For additional information,
please consult the standard itself or RFC 2459.
For example, if Bob works in the
loan department of the Money Bank, his X.500 address might be:
/C=US/O=MoneyBank/OU=Loan/CN=Bob/
where C is for country, O is for
organization, OU is for organizational unit, and CN is for common name. CAs and
other entities are named in a similar way. A substantial problem with X.500
names is that if Alice is trying to contact bob@moneybank.com and is given a
certificate with an X.500 name, it may not be obvious to her that the
certificate refers to the Bob she wants. Fortunately, starting with version 3,
DNS names are now permitted instead of X.500 names, so this problem may
eventually vanish.
Certificates are encoded using the
OSI ASN.1 (Abstract Syntax Notation 1), which can be thought of as being like a
struct in C, except with a very peculiar and verbose notation. More information
about X.509 can be found in (Ford and Baum, 2000).
Having a single CA to issue all the
world's certificates obviously would not work. It would collapse under the load
and be a central point of failure as well. A possible solution might be to have
multiple CAs, all run by the same organization and all using the same private
key to sign certificates. While this would solve the load and failure problems,
it introduces a new problem: key leakage. If there were dozens of servers
spread around the world, all holding the CA's private key, the chance of the
private key being stolen or otherwise leaking out would be greatly increased.
Since the compromise of this key would ruin the world's electronic security infrastructure,
having a single central CA is very risky.
In addition, which organization
would operate the CA? It is hard to imagine any authority that would be
accepted worldwide as legitimate and trustworthy. In some countries people
would insist that it be a government, while in other countries they would
insist that it not be a government.
For these reasons, a different way
for certifying public keys has evolved. It goes under the general name of PKI (Public
Key Infrastructure). In this section we will summarize how it works in general,
although there have been many proposals so the details will probably evolve in
time.
A PKI has multiple components,
including users, CAs, certificates, and directories. What the PKI does is
provide a way of structuring these components and define standards for the
various documents and protocols. A particularly simple form of PKI is a
hierarchy of CAs, as depicted in Fig. 8-26. In this example we have shown three
levels, but in practice there might be fewer or more. The top-level CA, the
root, certifies second-level CAs, which we call RAs (Regional Authorities)
because they might cover some geographic region, such as a country or
continent. This term is not standard, though; in fact, no term is really
standard for the different levels of the tree. These in turn certify the real
CAs, which issue the X.509 certificates to organizations and individuals. When
the root authorizes a new RA, it generates an X.509 certificate stating that it
has approved the RA, includes the new RA's public key in it, signs it, and
hands it to the RA. Similarly, when an RA approves a new CA, it produces and
signs a certificate stating its approval and containing the CA's public key.
Our PKI works like this. Suppose
that Alice needs Bob's public key in order to communicate with him, so she
looks for and finds a certificate containing it, signed by CA 5. But Alice has
never heard of CA 5. For all she knows, CA 5 might be Bob's 10-year-old
daughter. She could go to CA 5 and say: Prove your legitimacy. CA 5 responds
with the certificate it got from RA 2, which contains CA 5's public key. Now
armed with CA 5's public key, she can verify that Bob's certificate was indeed
signed by CA 5 and is thus legal.
Unless RA 2 is Bob's 12-year-old
son. So the next step is for her to ask RA 2 to prove it is legitimate. The response
to her query is a certificate signed by the root and containing RA 2's public
key. Now Alice is sure she has Bob's public key.
But how does Alice find the root's
public key? Magic. It is assumed that everyone knows the root's public key. For
example, her browser might have been shipped with the root's public key built
in.
Bob is a friendly sort of guy and
does not want to cause Alice a lot of work. He knows that she is going to have
to check out CA 5 and RA 2, so to save her some trouble, he collects the two
needed certificates and gives her the two certificates along with his. Now she
can use her own knowledge of the root's public key to verify the top-level
certificate and the public key contained therein to verify the second one. In
this way, Alice does not need to contact anyone to do the verification. Because
the certificates are all signed, she can easily detect any attempts to tamper
with their contents. A chain of certificates going back to the root like this
is sometimes called a chain of trust or a certification path. The technique is
widely used in practice.
Of course, we still have the problem
of who is going to run the root. The solution is not to have a single root, but
to have many roots, each with its own RAs and CAs. In fact, modern browsers
come preloaded with the public keys for over 100 roots, sometimes referred to
as trust anchors. In this way, having a single worldwide trusted authority can
be avoided.
But there is now the issue of how
the browser vendor decides which purported trust anchors are reliable and which
are sleazy. It all comes down to the user trusting the browser vendor to make
wise choices and not simply approve all trust anchors willing to pay its
inclusion fee. Most browsers allow users to inspect the root keys (usually in
the form of certificates signed by the root) and delete any that seem shady.
Another issue for any PKI is where
certificates (and their chains back to some known trust anchor) are stored. One
possibility is to have each user store his or her own certificates. While doing
this is safe (i.e., there is no way for users to tamper with signed
certificates without detection), it is also inconvenient. One alternative that
has been proposed is to use DNS as a certificate directory. Before contacting
Bob, Alice probably has to look up his IP address using DNS, so why not have
DNS return Bob's entire certificate chain along with his IP address?
Some people think this is the way to
go, but others would prefer dedicated directory servers whose only job is
managing X.509 certificates. Such directories could provide lookup services by
using properties of the X.500 names. For example, in theory such a directory
service could answer a query such as: ''Give me a list of all people named
Alice who work in sales departments anywhere in the U.S. or Canada.'' LDAP
might be a candidate for holding such information.
The real world is full of
certificates, too, such as passports and drivers' licenses. Sometimes these
certificates can be revoked, for example, drivers' licenses can be revoked for
drunken driving and other driving offenses. The same problem occurs in the
digital world: the grantor of a certificate may decide to revoke it because the
person or organization holding it has abused it in some way. It can also be
revoked if the subject's private key has been exposed, or worse yet, the CA's
private key has been compromised. Thus, a PKI needs to deal with the issue of
revocation.
A first step in this direction is to
have each CA periodically issue a CRL (Certificate Revocation List) giving the
serial numbers of all certificates that it has revoked. Since certificates
contain expiry times, the CRL need only contain the serial numbers of
certificates that have not yet expired. Once its expiry time has passed, a
certificate is automatically invalid, so no distinction is needed between those
that just timed out and those that were actually revoked. In both cases, they
cannot be used any more.
Unfortunately, introducing CRLs
means that a user who is about to use a certificate must now acquire the CRL to
see if the certificate has been revoked. If it has been, it should not be used.
However, even if the certificate is not on the list, it might have been revoked
just after the list was published. Thus, the only way to really be sure is to
ask the CA. And on the next use of the same certificate, the CA has to be asked
again, since the certificate might have been revoked a few seconds ago.
Another complication is that a
revoked certificate could conceivably be reinstated, for example, if it was
revoked for nonpayment of some fee that has since been paid. Having to deal
with revocation (and possibly reinstatement) eliminates one of the best
properties of certificates, namely, that they can be used without having to contact
a CA.
Where should CRLs be stored? A good
place would be the same place the certificates themselves are stored. One
strategy is for the CA to actively push out CRLs periodically and have the
directories process them by simply removing the revoked certificates. If
directories are not used for storing certificates, the CRLs can be cached at
various convenient places around the network. Since a CRL is itself a signed
document, if it is tampered with, that tampering can be easily detected.
If
certificates have long lifetimes, the CRLs will be long, too. For example, if
credit cards are valid for 5 years, the number of revocations outstanding will
be much longer than if new cards are issued every 3 months. A standard way to
deal with long CRLs is to issue a master list infrequently, but issue updates
to it more often. Doing this reduces the bandwidth needed for distributing the
CRLs.
No comments:
Post a Comment
silahkan membaca dan berkomentar