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:
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 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:
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
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.
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.
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:
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:
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:
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.
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:
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:
Some common private key formats are:
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 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
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