Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Introduction to PKI

A public key infrastructure (PKI) is the sum total of the components (certificates, certification authority, registration authority, and Certificate Revocation List) and processes (key management, certificate enrollment, certificate revocation, etc.) that are necessary to implement the use of public key cryptographic processes. Although some uses of public key cryptography can be integrated into a process without a PKI in place, public key cryptography is easier to manage when the structure and processes provided by a PKI is present. An example of public key encryption outside of PKI and the problems that result is detailed later in this chapter in the section "Self-signed Certificates."

Public Key Cryptographic Processes

Two major uses of public key cryptography are encryption and signing. Unlike symmetric key cryptography, which uses a single key to encrypt and decrypt, public key cryptography uses an associated key pair: a public key and a private key. In public key cryptography, one key is used to encrypt and the other to decrypt. Because there are two keys, the public key can be made available to anyone, and the private key can and should be kept secret.

Encryption

Figure 12-1 illustrates the public key encryption process.

Figure 12-1. Two keys are used in public key encryption: one encrypts and the other decrypts.

Two common uses for public key encryption are email and the Encrypting File System (EFS). In both cases, symmetric and public key cryptography is used. The reason for this is the slow speed of public key encryption. (More information on EFS can be found in Chapter 6, "EFS Basics.") The following process is used to send encrypted emails:

A symmetric key is generated and used to encrypt the message.

The public key of the recipient is used to encrypt the symmetric key.

The encrypted message and the encrypted symmetric key are sent.

Upon receipt, the recipient's private key decrypts the symmetric key.

The symmetric key decrypts the message.

NOTE: Incorrect Definitions Abound

It is common to find descriptions of secure email and other uses of public key encryptions that do not mention the use of a symmetric key. Instead, they just describe the process as if the public key encrypts the entire message or file, and the private key is then used to decrypt it. This is incorrect.

Digital Signing

Digital signing is the process of using cryptography to ensure the authenticity of some electronic data, such as a software application. Digital signing of email is also used to provide non-repudiation. Non-repudiation provides non-deniability; if an email is digitally signed by the sender, the sender cannot claim that the email was not sent by him. A digital signature, which is the result of digital signing, can also aid in determining the integrity of the message. Of course, the private key used for the digital signature must be protected. If someone can obtain the key, they could sign an email as the individual.

To create a digital signature, public key cryptography is used in a slightly different way than it is for encryption. The following process is used to sign an email:

A message digest of the message is created.

Applying a cryptographic hash algorithm to the message creates a message digest. The hash algorithms produce a small, unique abstract of the message. The message digest itself cannot be decrypted, but if the same algorithm is used against the same message, the message digests will match, and a hash of a different message will not produce the same message digest.

The sender's private key encrypts the message digest.

The plain text message and the encrypted message digest are sent to the recipient.

Upon receipt, the public key of the sender decrypts the encrypted message digest. (The message digest itself is not decrypted.)

The recipient creates a message digest of the message and compares this message digest to the one sent with the message. If the two message digests match, this proves the message was sent by the sender because only the sender holds the private key, and his public key decrypted the encrypted message digest. If the two message digests match, the message has not changed.

Public Key Cryptography Pros and Cons

Symmetric key cryptography is faster and less complex but cannot solve some problems that public key cryptography can. When symmetric key cryptography is used, the security of the message depends on knowledge of the key. Because the key must be distributed to both parties, this creates a problem. How can the key be securely communicated to both parties? Symmetric keys may also create a management problem. Imagine that email messages between 100 users must be secured, and only the sender and recipient of a given message can be allowed to read it. This means that a large number of keys must be generated, shared between users, and both stored and managed. Public key cryptography can solve these problems. Because the private key can be kept secret and never transported, it is easier to protect it. On the other hand, all the associated public keys can be stored in a public database and made available to everyone. Knowledge of public keys is acceptable.

Public key cryptography appears to be a sound solution for these issues. Then why is it not used more? The following issues may have kept this technology from widespread use:

Speed
Public key encryption is slow. Compared to symmetric key encryption, asymmetric key encryption is very slow. Even with the enormous improvement in processing speed today compared to when the technique was first developed, encrypting large messages is not practical. In most uses of public key encryption today, a combination of public key (asymmetric) and private key (symmetric) encryption is used.

Identity
If a large number of keys are stored in a public database, how can we be sure that a stored key actually belongs to whom the database says it belongs to? Some way of representing the relationship between the public key and its owner must be present. Implementations of public key technology today use a data structure called a certificate for this purpose.

Private key storage
Public keys can be stored in a database because the public key cannot decrypt what it has encrypted. The secrecy of the message relies on the secrecy of the private key. The private key must be protected and kept from public access.

Portability
A certificate and its associated private key are typically installed on a single computer. Although it may be possible to export the certificate and key and import them into another computer, the process may be complicated for typical users, and its practice may mean a reduction in security. Someone other than the assigned owner might obtain access to the keys.

Key safety
Public keys can be copied, distributed, managed, and protected from loss and destruction in a central location under the control of knowledgeable people using well-developed processes. The safety and storage of private keys relies on the technical controls provided by the operating system, and, when these technical controls must be enforced by the owner, on the whims of their owner in applying them. Private keys can become corrupt and lost. In some implementations, this means only that new keys must be issued, and the only loss is the current message, which can be resent. The loss may be substantial depending on the nature of the message, but the process is recoverable. However, in other uses, such as file encryption, loss of a private key can mean the loss of critical data. Key backup and key archival databases are possible solutions for this problem.

Key distribution
Obtaining a public key so that a message can be encrypted and sent to another person may or may not be a problem. If the public key database belongs to an organization, it may be easy to provide access for all employees. This does present a problem for others from outside the organization, though. How can they obtain public keys when they want to use them to communicate with the organization's employees?

Enrollment
In order to put the public key in a database, an enrollment process must take place. If only a few sophisticated users must follow some process in order to do so, this is not a problem. But enrolling thousands of individuals by this method is a major impediment to the adoption of the technology.

All these problems can be managed by the use of a public key infrastructure. Then, the problem becomes complexity and cost. The technology can seem complex and obscure, necessitating teams of consultants to make it work. In addition, the cost of the products has been high in the past, but this is no longer true. Both Windows 2000 and Windows Server 2003 include certificate services with the base operating system, which can be used to create a PKI.

PKI Components

A public key infrastructure may be implemented in different ways. The model used by Windows Server 2003 is the certification authority (CA) hierarchy model. In this model, a root CA serves as the parent of additional CAs. This type of PKI consists of the following components:

Practice Policy Statement
Provides the rules by which the CA is managed.

Certificates
The data structure used to bind a public key to an identity.

Keys
Encryption keys.

Certification Authority (CA)
The computer that issues certificates.

Registration Authority (RA)
The computer that provides enrollment services. In many PKI implementations, the CA and RA function are performed at one computer.

Certification Revocation List (CRL)
A list of revoked certificates.

Certificate Trust List (CTL)
A list that identifies CAs approved to issue certificates for a web site.

Practice Policy Statement

The Practice Policy Statement is a document that details exactly how the PKI will be managed. Some of its information may be expressed in a file and used to enforce adherence to the policy. The statement may identify the following:

How enrollment is approved

The revocation process and the reasons for revocation

The location of the CRL

The publication schedule for the CRL

The location where a copy of the CA certificate may be downloaded

Who may administer the CA

How administrative duties are split

The CA hierarchy

The types of certificates that are issued and whom they can be issued to

The Practice Policy Statement is a result of planning, development, and approval of management. Subjects that should be addressed in the planning stage include those listed previously, as well as the following:

The solutions and goals of using this technology, including the projected cost and return on investment (ROI)

Requirements of applications that will use PKI

Service-level requirements

The use of CRLs, delta CRLS, and possibly the Online Certificate Status Protocol (OCSP), a protocol in which an enquiry on the status (expired, unknown, or current) may be made in lieu of checking revocation against a CRL

Some of the CA practice policy can be implemented through the use of a capolicy.inf file. You must create the file and name it capolicy.inf. It should be added to the computer to be used as the CA before certificate services are installed. Both the Authority Information Access (AIA), the location where a copy of the root CA certificate can be downloaded, and the CRL Distribution Point (CDP), the location where the CRL can be downloaded, should be empty in the root CA because they are not needed on the root CA certificates. If the root CA is kept offline, which is recommended as a best practice, any attempt to locate the certificate or the CRL will fail. Leaving the AIA and CDP empty prevents such false attempts. The locations can be kept empty by designating them as empty in the capolicy.inf file. The locations should be added to the CA configuration files after its installation, and then they will be included in each certificate the CA issues. The capolicy.inf file can contain the following:

The location from where the CA certificate can be downloaded.

The location where the CRL and, if implemented, delta CRLs can be downloaded.

A constraint on the number of subordinate levels by adding a maximum path length in the basic constraints extension of a CA certificate and defining the constraint and path length in the capolicy.inf file. A path length of zero means that the CA can only issue end-entity certificates (smart card, EFS, etc., as opposed to CA certificates).

Use A Hardware Security Module

A hardware security module (HSM) is a dedicated hardware device that can store CA keys. The device is managed separately from the operating system. Protection is provided via multi-layered hardware and software tokens and may additionally

Provide load balancing and failover if multiple HSMs are linked together in a daisy chain.

Secure management of private keys.

Provide cryptographic acceleration. The host server does not have to perform processor-intensive cryptographic calculations.

Provide hardware-based protection of private keys.

Provide hardware-based cryptographic operations, including random number generation, key generation, digital signatures, and key archival and recovery.

HSMs are available from multiple sources.

Certificates

A certificate is a data structure that binds the public key to an identity. A data structure is a programming construct that represents a collection of different types. The x.509 certificate standard is an international standard that defines parts of a certificate. If the certificate meets this standard, it may be used in applications written to the standard. You can view the certificate information by clicking its Details tab when viewing the certificate. When one of the fields is selected, any additional contents will be displayed. Figure 12-2 displays the Details tab. The information that may be viewable on the details pane is:

Basic Constraints
Identifies subject type and path length constraints. More information on constraints is listed in the section "Cross-Certification and Qualified Subordination."

CRL Distribution Points
Indicates the location where the CRL may be downloaded.

Issuer
The name of the CA that issued the certificate.

Key Usage
Indicates what the certificate may be used for.

Netscape Cert Type
Lists the certification usage information in the Netscape browser format.

Public Key
A copy of the public key from the public/private key pair.

Serial Number
A serial number assigned to the certificate.

Signature algorithm
Indicates the algorithm used to create the thumbprint.

Subject Alternative Name
The RFC 822 name format for the subject name.

Subject Name
The name of the identity the certificate was issued to, such as the user's Active Directory identity.

Thumbprint
A hexadecimal string that contains the SHA-1 hash of the certificate.

Valid From
The beginning date that the certificate is valid.

Valid To
The date at which the certificate is no longer valid.

Version
The version number of the certificate. x.509 certificates have been through three versions.

Identity of the owner of the certificate.

Figure 12-2. Examine the Details page to learn about the certificate.

NOTE: The Public Key is Included with the Certificate, But Not the Private Key

Note that the public key is included with the certificate. The private key is never part of the certificate. Although it is a common misconception that both keys are part of the certificate, you can use your common sense to see why this could not be soif the private key were part of the certificate, it wouldn't be private. It would be available to anyone that could retrieve the certificate.

Certificates can be saved to a file for storage, backup, and transfers. Different file formats are used for different purposes. When standard file formats are used, applications can be written that can import the certificates for use. Common file formats are

Cryptographic Message Syntax Standard (PKCS #7)
Enables the transfer of the certificate and all the certificates in its certification path. Uses the .p7b extension.

Personal Information Exchange (PKCS #12)
The certificate and its private key are stored in the same file. This format is often used for archiving the private key. Uses the .pfx extension.

Distinguished Encoding Rules (DER) Encoded Binary x.509
A platform-independent method for encoding objects for transfer. Most applications use DER because a portion of the certificate must be DER-encoded in order to be signed. Uses the .cer extension.

Base64 Encoded x.509
Uses an encoding method for Secure/Multipurpose Internet Mail Extensions (S/MIME). Uses the .cer extension.

Keys

A key pair is required for public key cryptography. The public key is provided as part of the certificate. Each certificate maps to an identity. Each certificate holds one and only one public key, and there must be an associated private key for each public key. Although a single certificate can only hold one key, many certificates can be bound to a single identity; therefore, any identity may have multiple key pairs. For any encryption done with a public key, only the associated private key can decrypt it. Though an identity (user or computer) can have multiple public key pairs, only one private key can be used to decrypt something encrypted by a specific public key.

How Strong Are Public Encryption Keys?

We often hear that encryption is only as good as the key, and that in general, the larger the key, the stronger the encryption. We know this intuitively. If a key is composed of only two digits, for example, we can surmise that it would be a lot easier to guess that key than if it were 50 digits long. Only a few possible combinations of digits exist for a two-digit key, while many exist for the 50-digit key. The possible combinations that can make up a key of a specific length and type are called its keyspace. The larger the key length, the larger the keyspace and the harder it is to guess any given key. Numerous attacks have been developed in an attempt to deduce a key. Brute-force attacks attempt every possible combination. When passwords or other alphabetical keys may be used, dictionary attacks use a dictionary of words encrypted via the same algorithm in an attempt to find a match. If the algorithm is weak, it may be possible to use some flaw in the algorithm to more quickly discover the key. Even well-known modern encryption algorithms with no apparent flaws are constantly tested with new mathematical attacks in an attempt to find a method to break them. The strongest algorithms resist these attacks or require a very long time frame in order for any key to be cracked. As the speed and processing power of computing systems increase, it may be that algorithms that cryptographers projected would take a long time to break may be broken in a few days or even hours. This has already happened. The Data Encryption Standard (DES) algorithm was once projected to take thousands of years to crack and at much expense. It now can be cracked with minimal equipment investment (several years ago, less than $30,000) and in a few days.

The strength of any encryption algorithm is partially based on the size of the key, partially on the strength of the algorithm used, and partially on the power and availability of computing devices that can be used to break it. Public key algorithms are very strong; there are no commercial or readily available applications for cracking their code. However, keys produced via the public key algorithms used today have been cracked in contests. This means that you should carefully evaluate the need for large keys for your CAs and keep tuned to advances in technologies and contest results to determine when you should change the key size in the future. For information about such cryptographic contests, visit http://www.rsasecurity.com/rsalabs/challenges/indexl.

When reading the results of successful challenges, note the length of time and resources taken to decrypt the message, and remember that this represents the decryption of one key. If the algorithm is implemented and configured to change keys, the process used to solve the puzzle for one key would have to be repeated for each key used.

Certification Authority

The certification authority (CA) is the server application that both issues the certificates and manages the certificate database. The name may also represent a public entity that offers certificates for sale to third parties, but that is not the meaning used in this chapter. The CA also manages revocation. The CA does not issue keys. Instead, the device used by the entity to which they will be bound generates the keys. The public key is then transferred to the CA where it is added to the certificate that will be issued. The private key remains on the device that generates it.

The CA also has a certificate. The keys for this certificate are generated on the CA computer. The root CA issues its own certificate and issues CA certificates for subordinate CAs. The CA's private key is used to digitally sign the certificates it issues. Digital signatures are effective proofs of certificate origination. Copies of the signed CA certificate are publicly available so that the digital signature may be verified.

Registration Authority

In some PKI implementations, a second server application, the Registration Authority (RA), shares some of the CA duties. The RA and the CA are implemented on separate servers. The RA handles certificate enrollment. In this arrangement, the RA receives the enrollment request, verifies the identity of the requestor, and passes the public key and credentials to the CA. The CA issues the certificate and passes it back to the RA that passes it back to the requestor. By separating the contact with the requestor from the CA, an additional layer of protection can be provided. One example of this protection is that network access to the CA can be restricted to the RA. If no RA is used, every computer and user must be provided access to the CA so they can request certificates. Restricting access to the CA can provide protection from attack.

Certification Revocation List

Certificates are issued with a designated expiration date. Even so, you may need to prevent some certificates from being used before they expire. They may have been compromised, an employee may have left the company, or the certificate may need to be replaced by one with different characteristics. The revoked certificates are placed on a Certificate Revocation List (CRL), and the list is published. Applications can then check the CRL to see if the keys used in a transaction are still good.

TIP: Which Key?

Although the certificate is revoked, the private key must be made useless. The private key cannot be destroyed or accessed by the CA because it does not reside in the CA database. The key is made useless when its associated public key, which is part of the certificate, can no longer be used. For example, if a client were to use their private key to encrypt authentication information, the public key would need to be available to decrypt the data and thus prove the identity of the client. If the certificate is on the CRL, and the application checks this list, the client will not be authenticated.

Certificate Trust List (CTL)

A certificate trust list is a list of CAs whose issued certificates will be accepted by a web site. The list is signed by a trusted entity. If a certificate is received and a CA included in the list did not issue the certificate, the certificate is rejected.

PKI Interoperability

When PKI components are implemented according to standards, interoperability may be the result. For example, SSL certificates issued by many different vendor CAs are used to provide SSL-secured transactions on the Internet. You can purchase an SSL certificate issued by a non-Microsoft CA, install it in your IIS web server, and it will work. It may not be possible to do this for other applications. Standards do not specify how the standard should be implemented, and often, the standards provide alternatives or optional items that an implementer may use. Each implementation may therefore vary, and full interoperability between them may not be possible. One of the areas where problems may occur is in the use of the Certificate extension.

If certificates are constructed to the specification, it may be possible for certificates produced by one PKI to be used in another. Yet certificates produced to the specification by one PKI may not be 100 percent compatible with the applications developed to be used with certificates produced to the specification from another PKI. The is because there are alternative fields or extensions within the certificate specification. If an application is expecting a specific extension, and it is not found, the certificate cannot be used. Alternatively, if an extension is present in a certificate, and an application does not understand it, the certificate may be invalidated. An example of issues with interoperability is EFS and IPSec certificates. Third-party EFS certificates can be used, but they must meet Microsoft specifications. Third-party IPSec certificates can be used, but if they do not make CRL checking available, you may need to turn off CRL checking or IPSec authentication will fail.

CRL Location Is Important

A few years ago, VeriSign, a public Certification Authority, issued two Microsoft software signing certificates to someone who did not work for Microsoft. Because Microsoft software signing certificates are used to validate software produced and distributed by Microsoft, the implications of such a breach in trust could have been very damaging. To correct the problem, VeriSign revoked the certificates. However, the VeriSign certificates did not include the location of the VeriSign CRL. Applications written to use the certificate and to check the CRL could not have done so because there would have been no way to locate the CRL. To prevent the use of these certificates, Microsoft created a patch for Internet Explorer that would reject the specific certificates.