Lesson 1: Understanding Certificates

Lesson 1: Understanding Certificates

Before you can begin to use certificates and certificate authorities, you need to understand what certificates are and how they work. This lesson covers the core concepts of certificates, along with encryption, public key encryption, and digital signatures.

---

After completing this lesson, you will be able to

• Understand encryption

• Understand public key encryption

• Explain the difference between secret keys, public keys, and private keys

• Understand digital signatures

• Understand certificates

Estimated lesson time: 20 minutes

---

How Encryption Works

Encryption is the technological basis behind certificates. While certificates use public key encryption, you must understand basic secret key encryption to understand public key encryption.

Secret Key Encryption

With secret key encryption, also called symmetric key encryption, you use a single key for both encrypting and decrypting data. In traditional secret key encryption systems, a document (called a plain text) is encoded by performing a mathematical operation (called an algorithm) on each character in the text using another number (called the key). For example, you might encrypt a locker combination of 21-17-42 using the algorithm "add" and a key of 21:

21 + 21 = 42

17 + 21 = 38

42 + 21 = 63

The resulting encrypted combination is 42-38-63. Only users who know the algorithm ("add") and the key (21) can decrypt the combination, so you can publicize the encrypted value without fear that anyone will know the true combination.

To decrypt the encrypted text, the reverse function must be used. In this example, "add" was used to encrypt the text, so "subtract" must be used to decrypt the encrypted value. However, the same key is used to perform the decryption. Because the same key value is used for encryption and decryption, secret key algorithms are referred to as symmetrical algorithms.

While this example is simple, all secret key cryptosystems work this way. Only the complexity of the algorithm and the length of the key changes.

There's a problem with secret key algorithms, though: while you can transmit the encrypted text to any party without fear of it being decrypted, you cannot transmit the key to the party that should decrypt it because, if the key is intercepted during transmission, it can be used to decrypt the text. The inability to transmit a secret key to remote parties makes pure secret key systems inappropriate for transmitting information over public venues like the Internet.

Public Key Encryption

The solution to the key transfer problem was discovered in 1975 by cryptographic researchers. They arrived at a class of mathematical functions that have two different keys: one key to encrypt data, and a different key to decrypt the data. Because they use different keys for encryption and decryption, these algorithms are referred to as asymmetrical algorithms.

You still can't transmit the decryption key across a public medium because it could be intercepted and used to decrypt the encrypted data. But you can transfer the encryption key across a public medium without compromise because it cannot be used to decrypt the message.

To transmit a message securely, the sender asks the receiver for its encryption key. Because the encryption key can't be used to decrypt the message, this transfer is safe no matter how it's sent. The sender then uses the encryption key to encrypt the message, and sends the encrypted text to the receiver. The encrypted text is indecipherable without the decryption key, so this transfer is also safe. Finally, the receiver uses the decryption key to decode the message. The decryption key has never left the receiver's possession, so it has remained secure throughout the process, as shown in Figure 5.1.

Figure 5-1. The public key exchange process

Because the encoding key is sent over a public medium, it is referred to as the public key. The decryption key cannot be revealed, so it is referred to as the private key.

Anyone can encrypt a message to a receiver using an intercepted public key. Public key encryption cannot be used to verify identity because the ability to transmit messages to the receiver is open to anyone. However, once encrypted, the messages cannot be decrypted by anyone but the intended receiver.

Verifying Identities with Digital Signatures

Digital signatures are used to verify identities by encrypting identity information, such as contact information, in such a way that anyone can decrypt the information to verify it, but only the originator can encrypt the information. This is similar to the concept of a traditional signature: anyone can read and verify it, but only the person who developed the signature can sign a valid copy of it.

Digital signatures work by using the concept of public key encryption in reverse. Using the same type of algorithms as public encryption (in many cases, the same algorithms), digital signatures reverse the role of the encryption and decryption keys.

• In a public key cryptosystem, the encrypting key is the public key and the decrypting key is the private key.

• In a digital signature system, the encrypting key is the private key and the decrypting key is the public key.

By holding the encryption key privately and publicizing the decryption key, digital signatures allow transmitters to prove that they are undoubtedly the same security principal that encrypted the message using the original encryption key that they hold private.

By appending a digital signature to any plain text document, the receiver of the document can prove the document's validity by decrypting the digital signature using the decryption key. Of course, that proves only that the digital signature is valid the remainder of the plain text is unprotected.

To extend this protection to the entire document, the plain text portion of the document is processed through a checksum algorithm, one that can be as simple as adding all the data in the document into a single, large number, and including the resultant number inside the encrypted digital signature. The receiver can verify the entire contents of the document by running the same checksum algorithm on the document and ensuring that its calculated checksum equals the stored checksum inside the encrypted portion of the digital signature.

To summarize, digital signatures can guarantee that the entity that created a certain digital signature key is the same entity that later used it to transmit various documents. But no algorithm can tie the identity of an individual or organization to a specific pair of keys.

Combining Encryption and Certificates

Certificates combine numerous features of public key encryption and digital signatures to create a complete encryption and proof-of-identity solution.

Certificates are data structures that can contain numerous public keys, private keys, secret keys, and digital signatures. Primarily, certificates are used to perform trusted third-party authentication. Trusted third-party authentication allows trust to exist between parties who have no trust relationship, but who both trust a third-party service, called a certificate authority (CA), to process certificate requests. Both parties trust that the certificate authority has verified the identity of the other party.

To create a certificate:

1. The user generates a pair of encryption keys for use in public key encryption, and optionally another pair for use in digitally signing documents. These keys, along with identity information like the user's name, taxpayer ID, and e-mail address, are then encoded into a certificate request.

2. The certificate request is sent to a CA for certification.

3. The CA applies its own standards for verifying the identity of the requester and either rejects the request, if it's determined to be invalid, or signs the request.

At this point, the certificate contains the digital signature decryption key of the user, which has been validated by the digital signature of the CA. That signature contains a checksum that validates the user's digital signature decryption key. This signature key can be used to validate any remaining information in the certificate, such as a separately generated public key that can be used to encrypt documents going to the user who generated the certificate.

Because the transmitter's digital signature decryption key was decryptable using the CA's decryption key, the CA has vouched for the identity of the transmitter. The receiver can add the user's digital signature decryption key to its cache of trusted entities and can use it to validate documents from the user in the future. By this mechanism, trust in the CA has been conferred upon the user whose signature was signed by the CA. When a CA vouches for an entity by signing its digital signature, it is certified.

Signing with a digital signature means that the CA first uses some physical means to verify the user's identity, such as an administrator identifying the person by sight, then performs a checksum operation on the user's digital signature, and finally includes that checksum in an additional digital signature that is appended to the certificate.

Certificate Hierarchies

A hierarchy of CA certification can go on indefinitely any CA can be certified by any other CA, ad infinitum. For example, engineers at Fabrikam can have their certificates signed by the engineering CA at Fabrikam. This means that any two engineers at Fabrikam can trust each other because their identities have been verified by the engineering CA. The engineering CA can in turn be certified by the Fabrikam enterprise CA, which certifies all the subordinate CAs in the enterprise. With this certification, an engineer can present his certificate to any other user at the company, and that receiver can extend trust because they can decrypt the Fabrikam enterprise CA digital signature, which allows them to trust the engineering CA digital signature, which allows them to trust the engineer's digital signature.

When certificates are used pervasively throughout an enterprise and the CAs that have issued these certificates have the same root CA, the collection of CAs and certificate-based services is referred to as a public key infrastructure (PKI).

If users at Fabrikam need to trust engineers at Microsoft, both companies can have their enterprise root certificates signed by a third party that they both trust, such as VeriSign, Inc. When both companies have their enterprise root certificates signed by the same trusted third party, trust can be extended across corporate boundaries, with the parties secure in the knowledge that all are who they say they are. Figure 5.2 shows a list of some of the CAs that are, by default, trusted by Microsoft Internet Explorer.

Figure 5-2. Certificate authorities in Internet Explorer

Root Certification Authorities

Ultimately, users and companies have to trust some authority to act as a root certifying authority. In an ideal world, there would be one single root certifying authority that everyone trusts, but because trust cannot be legislated, this single authority might never exist.

Currently, users and companies choose a certifying authority that they reasonably believe will authenticate the identities of everyone that they certify. There are numerous companies that perform this function for a fee. When two independent organizations need to establish a trust relationship, they must agree on a third party to certify each of them. The other option is to sign each other's root certificates and agree to trust one another without a third party.

In the United States, the National Institute of Standards and Technology (NIST) is establishing a government-run root certifying authority for purposes of authenticating communications among government agencies. However, the government lags far behind commercial certifying authorities, which are currently available world wide to perform validation services and to provide certificates rooted in their trust hierarchies.

Anyone can create a root CA by setting up a CA that does not have its certificate signed by another CA. To establish a trust hierarchy, this root CA can sign the certificates of other CAs. It is not necessary to have a CA's certificates signed by anyone if all parties involved in the certified transaction trust the CA. For most businesses, this means that certificates used entirely within the company, such as to perform logon authentication or encrypt internal e-mail, can be self-certified by the company without relying on external trust providers. In fact, it's safer, because trust won't be conferred on anyone who has managed to forge a certificate from a popular certifier.

Certificate Expiration

Certificates have a built-in expiration date included in their identity information that tells recipients when the certificate should no longer be trusted. Expiration is important in digital certificates to prevent factoring, or brute force, attacks against the certificate.

In a brute force or factoringattack, a hacker attempts to determine the private key by signing a document using all possible values until the digital signatures match. With a single computer, this would take an extraordinarily long time, but with the Internet's ability to pool the resources of millions of computers in a single attack, it would become possible to factor all possible values of an extremely important digital signature for example, a digital signature used by Microsoft to prove the validity of an update or a root certificate used by a popular CA like VeriSign or Thawte. If the private keys for these digital signatures could be factored, the hackers could forge certificates using their identities and convince any party that trusted the exploited party to trust them. Once these single certificates have been factored, trust in the CA would evaporate. Therefore, root certificates for public certifiers are a likely target for massive factoring efforts by large groups of hackers.

Certificate expiration thwarts this attack by telling certificate receivers to distrust the certificate after a reasonably short period of time, such as two years. Because no factoring attack could take less time using means available before the expiration date, factoring attacks will not succeed in time for them to be useful. If computing methods become available that make decryption easier, future certificates can use shorter expiration times or change the algorithm to a stronger mechanism.

Figure 5.3 shows the Certificate dialog box for a selected certificate. This information includes the certificate's expiration date.

Figure 5-3. The Certificate dialog box

Before a certificate expires, most CA implementations negotiate with the trusted CA to which the certificate applies to receive an updated certificate with new keys (and potentially, specifying a new and stronger encryption algorithm). If the expiration date goes by without a new certificate exchange, both parties must manually establish trust using the same method that was used to establish trust originally.

Certificate Revocation Lists

Brute force attacks are only one possible reason why certificates should be periodically invalidated. The most important reason to invalidate a certificate is that the association between the CA and the certified entity has changed. For example, an employee might change positions within a company or leave the company. This means that the company should no longer certify that employee's certificates.

It's also possible that a hacker might have obtained access to a user's computer and extracted the private keys for that user's certificate. This would enable the hacker to impersonate the user by signing documents.

In these and many other cases, it's important for a CA to be able to revoke certificates before their expiration date. The mechanism for revoking specific certificates is simple: the CA publishes a list of certificates that are no longer valid. This list is called a certificate revocation list (CRL). When a certificate is received, the receiver can check the CA's published CRL to ensure that the certificate has not been revoked. Figure 5.4 shows an example of a CRL.

Figure 5-4. A CA's certificate revocation list

The actual mechanism of publishing a CRL is not standardized. Some PKI systems publish their CRL using HTTP; others publish text files on FTP sites. Microsoft uses two methods: publishing a text file using Internet Information Services (IIS), and publishing the CRL in Active Directory. All Microsoft services use the Active Directory-integrated CRL, while third-party services that are not Active Directory-integrated can use the text file published by IIS to determine whether certificates have been revoked.

Uses for Certificates

Because certificates validate identity and can contain other useful information, they are used primarily in situations where verifying identity is critical, such as logon authentication and computer authentication. For example, Windows 2000 can be configured to use certificates stored on smart cards for log on rather than storing them in the registry and asking users for a user name and password.

Chapter 6, "Managing a Public Key Infrastructure," details the issuance and use of encrypted certificates.

Because certificates can contain information in addition to the digital signature keys, they are often used to transport public keys for encryption. The certificate simultaneously validates the identity of the person publishing the public key and delivers the key, so that the receiver can send encrypted texts to the publisher.

By including public keys for encryption inside certificates, both parties to a secure exchange can be certain of each other's identity. In this way, certificates are used to assure identity in a way that public key encryption alone cannot.

Public key encryption is primarily used to send encrypted e-mail and to establish Secure Sockets Layer (SSL) encrypted Web sessions between a Web browser and a Web server.

Finally, the PKI system uses certificates to validate the identities of CAs to create a hierarchy of trust.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

1. What is the difference between a symmetrical algorithm and an asymmetrical algorithm?

2. How does a digital signature system differ from a public key cryptosystem?

3. How does a certificate authority sign a document?

4. How does a CA certify another CA?

Lesson Summary

• Secret key encryption allows two parties to exchange documents securely over a public medium by encrypting the documents using an algorithm and a secret key known to both parties. There is no way to transmit the secret key without risking interception, however.

• Public key encryption solves the key transmission problem by using asymmetrical algorithms that use a public key to encrypt data and a separate private key to decrypt data. The public key can be sent over a public medium because it cannot be used to decrypt the encrypted text.

• Digital signatures reverse the purpose of the keys used in public key encryption to allow any recipient to decrypt a text that can be encrypted only by the holder of the secret key. As long as the original digital signature public key is trusted, any document sent by the signer can be trusted.

• Certificates are digital signatures that have themselves been signed by one or more CAs.

• CAs vouch for the identity of the entities whose certificates they've signed. CAs themselves are verified by superior CAs up to a root CA that is self-certified. As long as all participants trust the root CA, the identities of all participants in the trust hierarchy can be trusted.