Public Key Infrastructure

Growing concerns by organizations with e-commerce presence for data security has fostered the adoption of a standard Internet security framework. PKI addresses issues such as data confidentiality, integrity, and authentication.

Secret Key Cryptography

Cryptography deals with keeping data confidential between clients and servers in a public insecure network. With secret key cryptography, both the client and server must each have a secret key in their possession that they both agree upon before any encryption can take place. They use their secret (or private) keys for both encrypting and decrypting information exchanged between them. The process is also called symmetric key cryptography because you can easily derive the two keys from one another mathematically. The keys are either the same or one is a transformation of the other using a mathematical function. Common symmetric key protocols are Data Encryption Standard (DES), Triple DES (3DES), Rivest Cipher 2 (RC2), and Rivest Cipher 4 (RC4). Figure 8-4 illustrates secret key cryptography.

Figure 8-4. Secret Key Cryptography

You can use two forms of ciphers to encrypt your data:

• Stream Ciphers Stream ciphers enable network devices to encrypt the individual bytes of the data stream. RC2 and RC4 are examples of symmetric key stream ciphers.

• Block Ciphers Block ciphers enable network devices to encrypt blocks of data containing many bytes each. DES and 3DES are examples of symmetric key block ciphers.

With the symmetric/secret key method of encryption, the question arises of how to exchange private keys without an existing private exchange mechanism available beforehandespecially between a server and a large number of clients on the Internet. Public-key cryptography helps resolve this issue.

Public-Key Cryptography

Public-key cryptography circumvents the need to exchange a single private encryption/decryption key for secure communication to take place. Instead, the server generates two keys: a private and a public key. The server keeps the private key secret and makes the public key available for anyone to see. These two keys make it possible for the public key to decrypt information encrypted by the private key and for the private key to decrypt information encrypted by the public key. The keys also have the asymmetric property that enables you to easily derive the public key from the private key using a hash function, but you cannot derive the private key from the public key. This scheme is called asymmetric key cryptography. Digital Signature Algorithm (DSA) and Rivest Shamir Adleman (RSA) are common encryption algorithms that you can use in public key cryptography.

Consider an example in which a client, C, needs to send a message to a server, R. The following then occurs, based on the diagram in Figure 8-5:

1. R generates a private/public key pair.

2. R sends the public key to C, and keeps the private key to itself.

3. C can now encrypt a message using R's public key and send it over the insecure network. R is the only one who can decrypt the message from C because nobody else has access R's private key but R.

Figure 8-5. Basic Public Key Cryptography

Figure 8-5 illustrates public key cryptography.

Because public keys are available to anyone, they need to be very large (for example, 1024-bit RSA public keys are common) in order to ensure the security of the messages that you transmit. In practice, computational load drastically increases on both C and R for keys large enough to avoid any possibility of brute force on the encryption algorithm compromising the keys. Symmetric keys prove much more practical for encrypting large amounts of traffic because they are private and can be shorter than asymmetric keys. For example, 128-bit RC4 and 56-bit DES keys are common. As such, most public key environments use a hybrid approach, combining the key exchange capabilities of public key schemes and processing efficiency of private key schemes.

In the example discussed previously, the following takes place using public-key cryptography, as illustrated in Figure 8-6.

Figure 8-6. Hybrid Public-Key Cryptography

1. The server R generates its private and public keys.

2. R sends its public key to client C.

3. Once C receives R's public key, it generates a random number.

4. C encrypts the random number using the server's public key and sends it to R.

5. R then decrypts the random number using its private key and uses the random number to create a symmetric key for further data encryption and decryption.

6. Further two-way secure communication between C and R occurs using a secret symmetric key based on the shared random number generated by C, as Figure 8-6 illustrates.

Using public-key cryptography, the server R maintains a single private/public key pair. The server's public key is available to any client that requires secure communication between itself and the server. The client and server generate a unique symmetric key for use during each session, which they discard at the end of the session. Combining asymmetric and symmetric keys provides a more practical hybrid encryption mechanism for encrypting bulk data. PKI uses public-key cryptography.

Note

Internet Key Exchange (IKE) also uses public-key cryptography to exchange secret keys for the symmetric encryption performed by IPSec, the popular site-to-site and remote access Virtual Private Network (VPN) protocol.

Note

Instead of using RSA or DSA to exchange a master secret key, you can use Diffie-Hellman key agreement. Diffie-Hellman is the protocol commonly used in IKE, but it can also be used in PKI.

Identity Theft Prevention Using Certificates

The nature of public-key cryptography allows for a malicious third party to create a separate private/public key pair and pose as a valid server. The client unknowingly uses the malicious server's public key to encrypt the random number. Once that happens, only the malicious server can decrypt with its private key. The client is unaware of the exchange because it did not verify that the public key actually belongs to the server in question. As a result, public key certificates are available for you to verify the authenticity of public key owners. Figure 8-7 illustrates how a malicious third party can pose as a valid server.

Figure 8-7. A Malicious Third Party Posing as a Valid Server

In Figure 8-7, the following sequence takes place:

1. The malicious server generates its private and public keys.

2. The client downloads the malicious server's public key, thinking that it is the valid server's public key.

3. The client and malicious server establish a secure connection to one another. The valid server remains unaware of the transaction.

Figure 8-8 shows how a CA creates a certificate to enable you to avoid the possibility of a malicious third-party server posing as your server. Based on the flow in Figure 8-8, the following sequence occurs:

1. When your server generates a private/public key pair, it also generates a Certificate Signing Request (CSR), containing the public key and other information to prove your identity (for example, your company name, address, and phone number).

2. You manually send the CSR that was generated by the server to a CA, normally via cut/paste onto the website of the CA.

3. The CA verifies the CSR with the Registration Authority (RA), thus making sure your organization is who they claim to be. The RA is a part of the PKI and is responsible for verifying requestors by looking them up in official business directories, calling them on the phone, or other such methods. If the RA verifies your organization, the CA will sign the CSR to vouch for your server.

4. The CA issues you a certificate for public use, including the expiration time of the certificate.

5. You can then install the certificate on your server. When a client accesses your server over the Internet, your server sends the certificate to the client so that it can verify that the public key belongs to you.

Figure 8-8. A Certificate Authority Signing a Certificate for a Server

Figure 8-9 illustrates how a client verifies a server's certificate and generates the symmetric session key. Before the CA issues you a certificate, it signs the certificate with its digital signature. The CA creates a digital signature by first computing a hash on the contents of the certificate. The CA then encrypts the hashed value using its private key to produce its digital signature.

Figure 8-9. Client Verifying a Server's Certificate

The following sequence takes place in Figure 8-9:

1. To verify the authenticity of origin server R's public key, the client browser, C, first downloads the CA-signed certificate from R.

2. C runs the same hash function that the CA ran on the certificate contents during the signing process.

3. C decrypts the CA's signature using the CA's public key and compares its hash to that of the CA. If the two hash values are the same, C can rest assured that the public key belongs to R, and no one else.

4. C extracts the server's public key from the certificate.

5. C generates a random number, encrypts it with R's public key, and generates the symmetric key.

6. C sends the encrypted random number to R.

7. R decrypts the random number with its private key and generates the symmetric key.

8. C and R exchange private information over the Internet using the symmetric secret key.

Note

Cisco content networking SSL-offloading devices use X.509 version 3 format certificates.

CAs also require certificates to verify their own authenticity in the PKI system. CA certificates are in the same form as regularly issued certificates. Root CAs, which are the largest CA providers, provide self-signed certificates. Verisign is an example of a root CA. Smaller intermediary CAs that want to provide CA services require root CAs to sign their certificates. When a server sends the client its certificate, it must also send the hierarchy of CA certificates involved in the certification chain. Certificate chains offer a means for a server to represent to the client the structured hierarchy of the CAs that are involved in the certificate authorization process. This ensures that a few well-known CAs are at the top of the hierarchy. When a client verifies the server certificate, it traverses the certificate chain until it detects a known certificate. The client then compares the CA's public key supplied by the server to the public key stored locally for the CA.

Note

All well-known certificates are stored directly on the client in a certificate store for comparison during the certificate verification process. In the case of SSL for use in HTTP web browsing, client browsers require obtaining the root CA certificates through a direct exchange. Most browser vendors include the common root CAs in the default browser download/ installation.

Some common certificate formats are:

• X.509 Privacy Enhanced Mail (PEM) RFCs 14211424 specify the X.509 PEM format. You must encode your PEM certificates in Base64, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----." Base64 is similar to ASCII, so you can cut/paste your certificates into your application's certificate import window. Your PEM-file may contain certificates, private keys, and CSRs (see Figure 8-8) also enclosed between the appropriate BEGIN/END-lines. X.509 PEM files may have ".crt," ".pem," or ".csr" file extensions.

• Public-Key Cryptography Standard (PKCS) PKCS is an RSA Data Security, Inc., standard that provides an industry standard interface for public-key cryptography. It provides a format for transferring data based on a public-key cryptography and an infrastructure to support that transfer.

  - PKCS #7 is a standard for signing or encrypting data but cannot contain your private keys. PKCS #7 may contain your certificate chain. PKCS #7 files have a ".p7c" file extension.

  - Personal Information Exchange (PFX)/PKCS#12 formatted certificates contain a certificate chain and a private key. These files have either a ".pfx" or a".p12" file extension.

• Distinguished Encoding Rules (DER) and Canonical Encoding Rules (CER) certificates DER encodes files in binary X.509 format with the extension ".der" and CER as Base64 X.509 format with the extension ".cer."

Note

You can use Openssl freeware utility to convert between these certificate formats.

PKI typically uses X.509 certificates for server authentication. They contain the following information:

• Version The version of the X.509 standard that applies to your certificate. There are three versions currently defined: versions 1, 2, and 3.

• Issuer Name The issuer is the name of the entity that signed the certificate. The issuer is most often a CA. However, you can also issue yourself certificates using third-party certificate-signing utilities.

  Note

  You can create and self-sign X.509 certificates if you require them for your internal applications only. However, if you will give public access to your certificates, then you should acquire them from a public CA.

  
  

• Serial Number The CA or certificate utility generates a serial number distinguishing it from other certificates that it issues.

• Signature Algorithm Identifier The CA or certificate utility must identify the algorithm that it uses to sign the certificate.

• Validity Period Your CA or certificate utility specifies the period for which the certificate is valid.

• Subject Name This is the Distinguished Name (DN) of your organization or entity. For example, the values "CN=www.contentnetworking.com," "OU=Network Engineering," "O=Cisco Systems Inc.," and "C=US" identify a sample subject. These refer to your common name, organizational unit, organization, and country.

• Public Key Information Your public key that clients use to encrypt a master secret.

Some common private key formats are:

• PKCS#8 format An encrypted private key format with the extension ".p8c."

• NET The NET format is a format that is compatible with older Netscape servers and Microsoft IIS .key files. NET is not very secure, so you should use this format only when necessary.

• PEM and DER You encrypt your private keys alone within PEM and DER formatted files.

Secure Sockets Layer

SSL provides a secure infrastructure for the exchange of information over public networks, between public web servers and anonymous clients on the Internet. SSL is a protocol of the PKI that applications, such as HTTP, FTP and SMTP, use to provide content confidentiality and integrity. Netscape originally developed SSL in 1994, but the IETF formally drafted RFC 2246, "The TLS Protocol Version 1.0" version 1 protocol based on SSL version 3.

SSL achieves confidentiality by using symmetric key encryption, with RC4 or DES protocols, to encrypt packets. SSL ensures integrity by appending a Message Authentication Code (MAC) to the SSL packet header. The major difference between TLS and SSL is that TLS 1.0 uses Keyed-Hashing for the Message Authentication Code (HMAC) algorithm for message integrity, as specified in RFC 2104. The difference between MAC and HMAC is that HMAC uses the shared symmetric key along with the underlying hash function (MD5 or SHA-1) to create message digests, whereas MAC uses only the underlying hash function. As a result, TLSv1 and SSLv3 do not interoperate.

You can think of SSL as residing in the session layer of the OSI reference model, as Figure 8-10 illustrates.

Figure 8-10. SSL Layers

SSL uses the following protocols:

• SSL Handshake Layer The SSL Handshake Layer includes three subprotocols and negotiates session information between the client and server. The session information includes:

  - Shared secret The shared secret is the random number that is used to create the symmetric key for encrypting bulk data.
  
  

  - Session identifier Participants use the session identifier to identify the SSL session. Content switches use this session identifier for SSL session stickiness, discussed in Chapter 10.
  
  

  - Server and client certificates Client certificates are optional, and not typical for most public Internet sites.
  
  

  - Cipher suite The cipher suite includes the protocol (TLS or SSL), asymmetric algorithm used for key exchange (RSA or DSA), the symmetric algorithm used for bulk encryption (DES or 3DES), and the hash algorithm for message integrity (MD5 or SHA-1). An example cipher suite string is "TLS_RSA_WITH_RC4_128_MD5."
  
  

• SSL Change Cipher Spec Protocol Clients or servers use the SSL Change Cipher Spec Protocol during a full handshake to indicate to the other to use the negotiated keys for the current session. It is also used to resume an idle session, thus avoiding having to perform another full handshake.

• Record Protocol The Record Protocol performs the bulk SSL encryption, using the shared secret key established in the handshake.

• SSL Alert Protocol The SSL Alert Protocol signals problems with the SSL session ranging from unknown, revoked, or expired certificates to fatal error messages that will terminate the SSL connection.

SSL uses the four-phased handshake shown in Figure 8-11 to establish an SSL connection between a client and server.

Figure 8-11. The Four-Phased SSL Handshake

Note

Due to its increased popularity resulting from its strong security mechanisms, SSL is also used in VPN for remote access to corporate resources (SSL-VPN). SSL-VPN uses SSL client certificates for client authentication.

Typically, the client initiates a session to the server by sending a Client Hello message to the server. The server responds with a Server Hello message and its server certificate. The server can optionally request a certificate from the client, but this is not normal practice for most Internet applications. If the server certificate does not contain a public key, which again is not normal practice, the Server Key Exchange message can optionally contain a temporary key for the client to encrypt the master secret.

The Client Hello packet contains the SSL version number, random number, and supported cipher suites. The Server Hello packet contains the SSL version number, random number, session ID, and supported cipher suites. The version number is the highest version that the client supports. SSL uses "Version 2" for SSLv2, "Version 3" for SSLv3, and "Version 3.1" for TLS 1.0.

The client then computes a master secret key using its random number and the random number received from the Server Hello message. The client then encrypts the master secret with the public key located in the server's certificate (or with the temporary key from the Server Key Exchange message if no public is available in the certificate) and sends the result back to the server within the Client Key Exchange message. Both parties now have a master secret key with which they can derive a master symmetric encryption key for use by the Record Protocol to encrypt data between the client and server.

The handshake protocol then completes, as shown in Figure 8-11, by each party sending a Change Cipher Spec message and a Finish message. The Record Protocol then performs the RC4 encryption and HMAC message integrity checks on the application data. The participants fragment and optionally compress each application payload into sizes appropriate for the encryption mechanism. The participants also compute the MAC or HMAC and append it to the application payload. They then can encrypt the fragmented and compressed payload containing the hash using the shared secret key and send it to their SSL peer.

If you leave an SSL session idle for an extended time, SSL may resume the session without requiring a full handshake. Avoiding the full handshake is beneficial because, as you learned previously, asymmetric key cryptography, which is used during the SSL full handshake to exchange the session keys, is much more computationally intensive than symmetric (session) key cryptography. Figure 8-12 shows sample TLS 1.0 dump output for resuming an SSL session between a client and a web server. Because the client already possesses the server's certificate, the server does not resend its certificate to the client, resulting in only a three-way handshake to reestablish the SSL session.

Figure 8-12. Three-Way Handshake to Resume an SSL Session