Public-Key Infrastructures

Now that we've looked at more basic security concepts, let's examine some of the security-enabled protocols. In recent years, public-key infrastructures (PKIs) have gained momentum in both commercial and government sectors. Based on public-key technology, a PKI describes a system of public-key certificate generation and management, including distribution and revocation. The important elements of this infrastructure are certificate authorities (CAs) that issue certificates, clients that use certificates, and directories that store certificates. Many PKIs use a registration authority that assures user identity and authorization before certificates are granted. Figure 18-1 shows a typical Microsoft Windows 2000 PKI.

Figure 18-1. A typical public-key infrastructure.

One of the distinct advantages of using public-key certificates for authentication is that servers no longer need to store and maintain a password list for their individual users. Because identification is based on a trust relationship with the CAs, the servers need to trust only the authority that issued the requestor's certificate. Once the chain of trust is determined and the certificate is verified, authentication can be established.

RSA Laboratories maintains a list of public-key cryptography standards (PKCS) that define public-key-related formats. Table 18-2 contains four notable standards.

Table 18-2. Important public-key cryptography standards

Standard Subject

PKCS #7

Cryptographic Message Syntax Standard, the basis for Secure Multi-purpose Internet Mail Extensions (S/MIME). Defines the format of signed and encrypted messages. The degenerate case allows the exchange of public-key certificates and certificate revocation lists (CRLs).

PKCS #10

Certification Requests. Used by clients to request certificates from CAs.

PKCS #11

Cryptographic Token Interface. Analogous to Microsoft's CryptoAPI.

PKCS #12

Personal Information Exchange (PFX). Enables the encrypted transfer of private keys and associated certificates from one computer to another.

More Info

You can find a list of current Internet-draft categories associated with the Internet Engineering Task Force (IETF) at http://www.ietf.org/1id-abstracts.html. A number of categories listed there are relevant to this chapter: IP Security (IPSec), Public-Key Infrastructure (X.509; PKI), S/MIME Mail Security (S/MIME), and Transport Layer Security (TLS).

Public-Key Encryption vs. Symmetric-Key Encryption

Although PKIs depend heavily on public-key technology, many of the functions performed by PKI entities combine public-key encryption and symmetric-key encryption. Symmetric-key encryption has been around for hundreds of years. It involves the use of a single encryption key for both the encryption and decryption of data. Encrypting data this way is analogous to placing a document in a safe and locking it with a key. When the document needs to be retrieved, the same key is used to unlock the safe. Relatively speaking, this method is secure and fast. Unfortunately, this type of encryption doesn't lend itself well to encrypting data to a person. Because the key must remain private, the difficulty exists in transmitting the key. After all, if there's a secure means to send the key, why not send the message using that means to begin with?

Public-key encryption, also known as asymmetric encryption, emerged from the necessity to share encrypted data with people, where no secure path existed to pass an encryption key. Public-key encryption uses a pair of keys: a public key that is distributed, and a private key that remains secret. To encrypt a message to someone, the encryption algorithm uses the recipient's public key. The resulting encrypted message can be decrypted only by the recipient's private key. This method is analogous to a safe with an entry slot. Anyone can slip a document in, but only the person with the correct private key can retrieve it. This scheme works for self-encryption of files as well. The Windows 2000 EFS, for instance, protects data with the user's public key. To decrypt, the user's private key is accessed and used.

Unfortunately, public-key encryption algorithms are slow and are rarely used to encrypt large amounts of data. Instead, public keys are used to protect symmetric keys that encrypt large chunks of data. For example, suppose Rosemary wants to encrypt a portfolio to Harold. Rosemary encrypts the portfolio using a symmetric-key algorithm like the Data Encryption Standard (DES). She then encrypts the symmetric key with Harold's public key, producing an encrypted symmetric key. Harold, on receiving the encrypted portfolio and key, decrypts the encrypted symmetric key with his private key and uses the resulting symmetric key to decrypt the message.

Public-key encryption extends to digital signatures as well. Digital signature algorithms actually reverse the encryption process. Encrypting the hash of a message with a user's private key generates a digital signature. The signature can be verified later by decrypting the hash with the user's public key.

Public-Key Certificates and Private Keys

Most public-key infrastructures, including Windows 2000 PKI, revolve around the use of X.509 public-key certificates. We know that PKI users have a private key and a circulated public key. A public-key certificate cryptographically binds a public key to the user who holds the corresponding private key. Certificates are issued and digitally signed by a CA. Table 18-3 lists the fields of an X.509 certificate.

When a certificate is used, it is validated by verifying the signature with the issuing authority's public key. As long as the issuing CA is trusted (or is within a trusted path), you can be certain that the user or entity named in the certificate holds the corresponding private key.

Table 18-3. Public-key certificate fields

Certificate Field Description

X.509 version

Windows 2000 supports X.509 version 3 certificates.

Serial number

Unique number that the CA assigns to a certificate.

Signature algorithm

ID of the algorithm that the CA uses to digitally sign the certificate.

Issuer

Name of the CA that issues the certificate.

Validity period

A pair of dates indicating when certificate validation begins and when it ends.

Subject

Name of the certificate user.

Public key

Public key that, with the corresponding private key, makes up a user's key pair.

Extensions

Additional information that a CA can include in the certificate. Examples of extensions are alternate names, such as the user's email address; key usage, which indicates which operations a public key can be used for; and basic constraints, which show whether the certificate is a CA certificate.

Signature

Digital signature generated by the issuer.

Of course, certificates aren't issued solely to users. CAs have their own certificates. CAs can also issue certificates to services and devices that need to be accessed on the network. A Web server that accepts Secure Socket Layer-encrypted transmissions and a directory that provides two-way authentication are both good examples of entities that use certificates.

Even though certificates belong to users and other entities, that doesn't mean that a user or entity is limited to one certificate—or, for that matter, that a user can be a member of only one root hierarchy. Certificates are issued for many different purposes: server authentication, file encryption, and code signing, to name a few. A user holds any number of certificates and private keys under different CAs or under the same CA; each might differ in usage, privilege, key size, and algorithm. For example, a security model might need multiple levels of access with separate CAs handling each level. On the other hand, a single user might hold Level 2 and Level 4 certificates; another might hold Level 1 and Level 3 certificates.

Having certificates under different root certificate authorities (root CAs) is common, too. Consider Celine, a human resources director who has both an enterprise certificate, which allows her to access her company's human resources server, and a certificate from a commercial CA, which allows her to browse the company's 401(k) stock portfolio over the Internet.

At the very least, the functions of encryption and digital signatures should be split into separate certificates. Private keys used for encryption can be archived so that encrypted data of a lost key can be recovered. Because the integrity of digital signatures depends on sole possession of the private key, digital signature private keys should not be archived.

Certificate Authorities

Certificate authorities exist to issue certificates for entities—including users, services, devices, subordinate authorities, or the CA itself—that meet the policy set forth for the CA. The CA accepts and fulfills certificate requests and revocation requests and might also manage the policy-directed registration process that a user completes to get his or her certificate. For information on how to install a CA using Microsoft Certificate Services, see Chapter 20.

Root and Subordinate Certificate Authorities

CAs can issue and revoke certificates for a host of users, but larger companies might be too big to administer with a single CA. In addition, enterprises might want to delegate authority of certain certificate types, or they might have divisions that manage their own resources and need to enforce separate certificate-issuing policies. Production, for instance, might want to issue certificates to anyone whose email address is within the company domain. Engineering might require a picture ID for registration. On the other hand, by using autonomous CAs, users between the two divisions are cryptographically isolated. A digitally signed message sent from a user in production to a user in engineering has no common basis of trust.

To solve this dilemma, CAs can be stacked hierarchically. Root CAs preside over domains, using a certificate they issue to themselves (a self-signed certificate). They also issue certificates to subordinated authorities and in general do not issue user certificates. Subordinate authorities issue certificates to users and other end entities and might also issue certificates to other subordinate CAs. Root CAs are implicitly trusted—subordinate CAs and clients derive trust from the root.

Figure 18-2 shows an example of a CA hierarchy. By stacking CAs hierarchically, an enterprise can manage the certification system from a single authority while delegating control of policy decisions to discrete authorities.

Windows 2000 also distinguishes between enterprise CAs and stand-alone CAs. The primary difference is that the enterprise CA uses Active Directory for user information and policy decisions and can publish certificates and CRLs to Active Directory. The stand-alone CA requires the certificate requestor to supply all user-identifying information.

Figure 18-2. A certificate authority hierarchy.

Chain Verification and Trust

Before a received digital signature can be verified, the signer's certificate must be validated. This is true of any application, whether it's a service, device, or user performing the verification. Without a hierarchical chain back to a trusted root CA, the identity of the user in the certificate can't be confirmed.

Chain verification is a two-step process. The first step is to build the certificate chain from the signer's certificate to a trusted root CA. Consider the CA hierarchy in Figure 18-2. Suppose User 1 in engineering is trying to verify a signature from User 5 in finance. User 1 builds the certificate chain for User 5 back to the root CA, Netsolvers root CA, which is in User 1's trusted store. The certificate chain, built bottom up, would be User 5: Finance CA: Corporate CA: Netsolvers root CA. The verifying entity obtains these certificates from the transmission protocol if they're included or from an accessible certificate store. The root CA certificate, because it's the pivotal trust component, should always come from a protected, trusted certificate store such as Active Directory.

The second step of chain verification is to verify the certificate chain top down. The verifying entity checks each certificate for validity, starting with the trusted root. Validity checking includes verifying the certificate's digital signature, checking the certificate's validity period, and ensuring that the certificate hasn't been revoked. Depending on policy, applications might also check any certificate extensions that the certificate contains.

Currently, typical PKI implementations include two-tier or three-tier hierarchies. As the popularity of the public-key infrastructure spreads, CA vendors will make more attempts to unite and centralize certificate authorities and root certificate authorities, resulting in longer certificate chains.

Cross-Root Certification

Even with a central root CA and a multitiered CA hierarchy that spans the breadth of a company, users might need to verify digital signatures under different root CAs. This verification is especially important when integrating commercial CAs, such as Verisign, to perform code signing, among other tasks. Using cross-root certification, root CAs can be connected so that validation paths of certificates under different roots extend back to the user's root CA.

Certificate Registration

Before being able to use his or her generated public/private key pair for encryption or digital signatures, a user must first obtain a certificate from a CA. A user does this by sending a certificate request—which includes his or her name and public key—to a CA. A number of registration models can exist depending on the registration policy a CA wants to uphold. Many commercial CAs handle PKCS #10 certificate requests and also allow Web-based certificate generation.

For more secure needs, a registration authority can act as a certificate-requesting agent to ensure proper proof-of-identity procedures and to forward certificate requests to the CA. Microsoft Certificate Services includes an enroll-on-behalf-of station where administrators, using enrollment agent certificates, can program smart cards for users. Figure 18-3 shows two examples of certificate request scenarios.

In the first example, a client requests a certificate from an enterprise CA, perhaps using the Certificates snap-in Certificate Request Wizard. User information and certificate rights are obtained from Active Directory. The Certificate Request Wizard generates a public/private key pair for the user. The public key is included in the certificate request and sent to the CA. The private key is saved on the user's computer. On receipt of the certificate request, the CA issues and signs the certificate and pushes it to a directory where other users and entities can retrieve it.

The second example shows an administrator programming a smart card through the enroll-on-behalf-of station. In this case, the private key is written directly to the card. In neither scenario is the private key exposed to the CA or anyone else. Again, once the certificate is issued, it's written to a directory for public availability. The smart card is returned to the user and is ready for authentication.

Figure 18-3. Two certificate request scenarios.

Certificate Directories

An important piece of the PKI is the directory in which certificates are stored and from which they can be retrieved. To encrypt data to a user, the user's public-key certificate is needed. Similarly, when verifying a digitally signed message, the certificate chain back to the verifier's root must be established.

In a Windows 2000 environment, Active Directory acts as a repository for certificates; any user or computer with appropriate rights can retrieve them. In addition, external users' certificates can be mapped to Active Directory user accounts.

Typically, once a client application retrieves a given certificate, it caches the certificate locally to save the overhead of another retrieval. Use the Certificates snap-in to view stored certificates by purpose or by storage category, such as personal or trusted roots.

Certificate Revocation

In addition to issuing and signing certificates, CAs are responsible for maintaining a list of certificates that are no longer valid. This list, called a certificate revocation list (CRL), is digitally signed by the issuing authority.

Such a list is a necessary requirement for a public-key infrastructure. Consider Julio, a laptop user who dials in to his company's network to access a server that contains finance accounts. He uses his certificate and corresponding private key to authenticate himself to the finance server. Now suppose Julio's laptop is stolen. In the past, a compromised password might have resulted in the administrator changing the user's password.

In a public-key infrastructure, however, verification is based on possession of a private key. The finance server has no knowledge of a specific user, only the CAs that it trusts. By using the CRL as a revoking mechanism, the finance server can retrieve a current list of revoked certificates. Once the stolen certificate has been placed on the CRL and the CRL has been published and retrieved, verification of the certificate results in a failure and access is denied.

Like user certificates, a CRL is digitally signed by the issuing CA and can be verified with the CA's certificate. Table 18-4 describes the fields of an X.509 CRL.

Table 18-4. Certificate revocation list fields

CRL Field Description

X.509 version

X.509 CRLs version. The current CRL version is X.509 version 2.

Signature algorithm

ID of the algorithm that the CA uses to digitally sign the CRL.

Issuer

Name of the CA that issues the CRL.

Last update

Date and time that the current CRL is issued.

Next update

Date and time that the next CRL will be issued.

List of revoked certificates

Each entry in the list includes the certificate serial number and the date when the certificate was revoked. Optional extensions can be added, such as a reason flag.

Extensions

Optional information that the CA can include in the CRL.

Signature

Digital signature that the issuer generates.

Just as with the certificate registration and issuing procedures, policies are established for CAs that dictate certificate revocation. These policies should include such procedural decisions as how often CAs refresh their CRLs, which mandatory and discretional extensions CAs can include in their CRLs, and under what circumstances certificates get revoked. Under one policy, for instance, certificates of employees who leave the company are subject to revocation. Under another, a user merely being denied certain privileges is grounds for revoking his or her certificate.

Because certificates have a validity period, CRLs need contain only revoked certificates that aren't yet expired. Once a certificate expires (in other words, the Valid To date has passed), verifying entities refuse the certificate and it can be removed from the CRL.

We should also consider CRL dispersal. The rate at which CRLs are issued, or "refreshed," is a policy decision made by the CA and can be as frequent as once a day. For highly secure domains, the refresh rate can be even more frequent. To be current, verifying entities need to obtain the latest CRL. Microsoft Certificate Services allows CRLs to be published to Active Directory, to a URL for HTTP access, or to a CRL file.

Certificate Renewal

Another set of certificate policy decisions relates to the certificate renewal procedure—specifically, whether certificates are allowed to be renewed, when they are renewed, and how they are renewed. Renewing certificates with the same key allows a user to extend the life of a public/private key pair. In contrast, renewing a certificate with a different public key once a user's certificate expires could make it difficult to read previously encrypted messages.



Microsoft Windows 2000 Server Administrator's Companion
Microsoft Windows 2000 Server Administrators Companion
ISBN: 0735617856
EAN: 2147483647
Year: 2003
Pages: 320

Similar book on Amazon

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