Public-Key Encryption


Public-key encryption differs significantly from secret-key encryption. In a public- key system, each user has a key pair, composed of two keys that are mathematically related. It isn’t feasible to derive one key if you know the other one. (“Feasible” means that it is technically possible, but it would require so much computing power and time that it is practically impossible.) One of the keys in the key pair is a public key that can be distributed freely to others; the other key is a private key that must be closely held and protected against compromise. Because the keys are mathematically related, they have two very interesting properties.

First, a message encrypted with the private key can only be decrypted by the corresponding public key. This allows someone to prove that he or she owns a particular private key by encrypting a message; to verify ownership, a verifier can try decrypting the message with the corresponding public key. In conjunction with the right kind of digital signature algorithm, this property allows users to digitally sign data. In addition, it makes a great authentication mechanism. A domain controller can ask a domain computer to prove that it has the private key that corresponds to the computer certificate in Active Directory, making it impossible for an imposter to usurp the identity of a real domain member.

Second, a message encrypted with a particular public key can only be decrypted by the matching private key. Because the public key might be widely distributed, anyone can encrypt a message for a particular recipient by using the recipient’s public key, but only the recipient can decrypt it.

There are a number of real-world analogues to public-key cryptosystems. For example, the drop boxes used by overnight package delivery companies allow anyone to drop in a package, but only a delivery-truck driver with the right key can open the box. Another example is the lockboxes used by real estate agents to securely store keys at properties listed for sale.

There are drawbacks to pure public-key systems, however. One has to do with the methods used to distribute the key material; we’ll discuss that in a minute. The other is speed: public-key encryption, decryption, and verification operations are much slower than standard symmetric encryption because the algorithms are more complicated and generally require more difficult calculations. This problem is exacerbated because we’d often like to gain the benefits of public-key systems by applying them to large documents, network traffic, or other content with which processing speed might be important. The solution to the problem is actually quite elegant, but before we can get to it, we have to solve the problem of getting keys securely to the users who need them.

Digital Certificates

Public keys themselves aren’t particularly useful; they’re just bits. To make them useful, we need some additional information, like the name of the key holder, so we can find the right key. It would also be useful to have information about who issued the key, when it was generated, when it expires, and so on—basically, the same kinds of information we find on real-world identity credentials like drivers’ licenses or military ID cards.

Digital certificates combine a set of attributes with the actual public key belonging to a user or computer. The private key, of course, stays private and isn’t a part of the certificate. The attributes in a public key provide information about the certificate issuer and certificate holder (see Figure 2-2), ranging from the obvious (a serial number, the unique name of the holder) to the subtle (a list of flags indicating what this particular certificate can be used for). The binding between the certificate and the attributes is secured by having the issuer digitally sign the certificate. The issuer’s signature in effect says, “I promise that these attributes are valid.” Some attributes, like the friendly display name of the certificate holder, can be left unsigned so that they can be modified after the certificate has been issued. This is useful, but it’s important to remember that unsigned attributes are untrustworthy— after all, they’re not signed!


Figure 2-2: Some of the attributes for a digital certificate.

Of course, the degree to which you trust a particular issuer is critical. For real-world credentials, we have expectations of authenticity. A drivers’ license issued by the State of Alabama is more credible than one issued by Paul’s Pretty Good DMV. It can be more difficult to assess the validity of digital certificates, but one workable solution is to use a chain or hierarchy of certificate issuers. Issuer A issues a certificate to me; as long as no one tampers with it, A’s signature can be validated. How do you know to trust A? One route is to have A use a certificate signed by B, a presumably more trusted authority. (Substitute “Verisign” or “U.S. Postal Service” for “B” and you’ll see how this works.) At some point, however, there’s no one left to vouch for an issuer’s authenticity; in that case, the issuer can always sign its own certificate. We call such certificates self-signed, and they require you to make a decision about their validity based on what you know about the issuer, not based on who has signed the issuer’s certificate.

There are a few other subtle certificate facts you should know. Certificates contain a validity date range that specifies the useful lifetime of the certificate. The Secure Multipurpose Internet Mail Extensions (S/MIME) and IPsec security standards prohibit using expired certificates and certificates that have been revoked by the issuer. That might lead you to wonder how to find out whether a certificate has been revoked. Each issuer has to maintain a certificate revocation list (CRL), which is a signed list of certificate serial numbers. If a particular certificate’s number appears on the CRL, it has been revoked. Public-key clients like Microsoft Outlook 2002 and PGP check the CRL each time a certificate is used so they can immediately reject any certificates that have been invalidated since the last time a CRL was published.

The Comit Consultatif International T l graphique et T l phonique (CCITT) X.509 standard (currently at version 3) defines a format and usage for digital certificates. Although other proprietary formats exist, X.509 is far and away the most widely deployed standard. An X.509 certificate issued by one vendor’s CA, the certificate issuer, can be used with other applications that correctly implement X.509. For example, I can use a certificate issued by Verisign’s commercial CA as the root certificate for my own local CA, which uses Microsoft’s Windows certificate server. My CA, in turn, can issue certificates that can be used by Netscape Communicator, Microsoft Outlook Express, Microsoft Outlook, or any other S/MIME client.

Plumbing for Digital Certificates

With symmetric systems, we have to figure out some way to get the same shared key to all of the recipients of a message. Public-key systems remove that requirement, as we can broadly distribute certificates containing users’ public keys. For them to be useful, however, we still need a way to widely distribute those certificates to the right audience. The generic term public-key infrastructure (PKI) describes all of the components needed to generate keys, make public keys available to end users, and control the issuance and revocation of digital certificates. In the Exchange world, the PKI consists of several pieces:

  • The CA is the certificate issuer. The term CA can refer to an entity (like a bank or professional licensing board) that issues certificates; most often, though, it’s used when talking about the software that actually issues the certificate. Microsoft Windows 2000 includes a CA (the Windows 2000 Certificate Service) that can issue certificates for users or computers; it’s what we discuss in this book. Some organizations contract out CA services to a third party, trusting them to properly verify the attributes of certificate requestors and to safeguard the sensitive CA key material. In addition to issuing certificates, the CA is also responsible for generating CRLs, which means there must be some provision for an administrator to specify that Joe User’s certificate should be revoked.

  • The certificate publisher is responsible for making certificates available to the outside world. That implies some other capabilities, like being able to store certificates efficiently, answer queries (“please give me the certificate for paul@robichaux.net”) , and securely receive updates when the CA issues or reissues a certificate. For Microsoft Exchange 5.5, the certificate publisher is the Exchange directory, which stores the certificate as an attribute of the user’s mailbox. In Microsoft Exchange 2000, Active Directory acts as the certificate publisher, because the certificate is just another attribute of an Active Directory user account. In either case, it’s possible to use a separate directory service (like a third-party Lightweight Directory Access Protocol [LDAP] directory) as the publisher.

  • Key and certificate management tools, like the Windows 2000 Certificates Microsoft Management Console (MMC) snap-in, allow end users and administrators to manage their certificates. CA administrators can control the CA’s behavior, including whether it automatically issues certificates on request or waits for human confirmation. Individual end users can see which user and CA certificates they have loaded, edit their unsigned attributes, securely move them between machines, and so on. Microsoft Outlook 2000 and Outlook 2002 implement some certificate management functionality (see Chapter 13, “Securing Outlook”), as does Microsoft Internet Explorer.

  • Certificate-aware applications are the whole reason that we bother with PKI implementations. Because certificates provide a means of making both authentication and trust decisions, these applications run the gamut from e- mail programs like Outlook and Outlook Express to system services like the Windows 2000 Routing and Remote Access Service (RRAS) and the Microsoft Windows XP 802.1x wireless LAN client.

How Public-Key Encryption Works

Now that we know what certificates are for and how the PKI creates and delivers them, we can examine how they’re actually used in public-key-based applications. There’s a twist, though. Remember that public-key algorithms are relatively very slow. That makes them unsuitable for decrypting or encrypting large volumes of data. To solve this problem, modern public-key systems combine public- and secret-key ciphers to provide speed and security. Figure 2-3 illustrates how this process works:

  1. The sender composes a plaintext message. Depending on the software implementation, the plaintext might be compressed to remove redundancy before it’s encrypted.

  2. The sender’s computer generates a random key for use with a symmetric block cipher. The random-number generator used to create this key must be cryptographically strong; that is, it must generate real random numbers and not pseudo-random numbers, or the key will be easy to guess.

  3. Symmetric encryption, with the random key, is used to encrypt the plaintext, producing a block of ciphertext.

  4. The randomly generated symmetric key is encrypted using the recipient’s public key. That means that only the recipient can decrypt the key needed to decrypt the message text itself.

  5. The encrypted symmetric key is decrypted with the recipient’s private key. To decrypt the ciphertext, producing the original plaintext, the decrypted symmetric key is used. The exact format of this combination varies among different security protocols.

    click to expand
    Figure 2-3: Public-key encryption in action.

Public-Key Algorithms

The Rivest-Shamir-Adelman (RSA) public-key algorithm is the best known and most thoroughly studied public-key cryptosystem. First publicly disclosed in 1978, the RSA algorithm uses large prime numbers as the basis of its security. The algorithm’s strength depends on the difficulty of factoring very large numbers; the de facto standard RSA key size is 1024 bits, so breaking RSA probably requires the ability to factor the product of two 1024-bit primes. ( I say “probably” because it’s certainly possible that a more efficient method exists, but is unknown outside the government cryptanalysis community.)

More Info

There are interesting intimations that the U.K. GCHQ and U.S. National Security Agency knew of and were using public-key systems much earlier than 1978. See Steve Bellovin’s paper at http://www.research.att.com/~smb/nsam-160/index.html.

The most common type of digital certificate contains the public half of a 1024-bit RSA key pair (remember, the public and private keys are each 1024 bits, so “half” just means that the certificate contains one of the two keys from the pair). RSA is also commonly implemented in smart cards and various types of hardware accelerators, and it is the public-key protocol used in the SSL and SSH protocols, as well as in a number of other lesser known protocols.

Besides RSA, there are a number of other interesting, although less widely used, public-key algorithms, including the ElGamal algorithm (named for its creator, Taher ElGamal), the family of elliptic-curve cryptography (ECC) algorithms, and the NTRU cryptosystem. These algorithms will undoubtedly become more popular as RSA ages and new theoretical or practical attacks against it are discovered. However, it’s unlikely that you’ll encounter any of them in an Exchange messaging environment.




Secure Messaging with Microsoft Exchange Server 2000
Secure Messaging with Microsoft Exchange Server 2000
ISBN: 735618763
EAN: N/A
Year: 2003
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net