Chapter 1. Crypto Refresh
This chapter covers the following topics:
• Confidentiality, Integrity, Authenticity, Nonrepudiation
• Device Configuration: Certificates
Cryptography has been used throughout history to hide messages and keep secrets. There have been various techniques used that have been concurrent with the technology available for that time. In today’s world, ever increasing high-powered computing systems networked together have created a new paradigm. This complexity to provide data and identity security requires a new paradigm of information security.
This book assumes you are a network engineer who has been exposed to the basics of encryption technology. One of the goals of this chapter is to provide a refresher, but it also dives deeper into the theory of the core concepts than most engineers might have seen in the past. This is necessary because these foundations are at the heart of the concepts covered in this book.
This chapter covers the basics of encryption, which essentially is the mathematical concatenation of data with a key. This chapter sets the foundation of the topics to follow.
The basic concept of encryption is simple. Cryptography attempts to take unencrypted (clear text) data and mathematically manipulate it to create encrypted ciphertext. Following best practices for encryption provides the best possible chances for confidentiality, integrity, authenticity, and nonrepudiation.
Confidentiality, Integrity, Authenticity, Nonrepudiation
The core concepts of confidentiality, integrity, authenticity, and nonrepudiation are integral to all schemes of encryption. Secure delivery of data depends on all elements. Varying techniques provide different levels of strengths in these areas. PKI’s objective in IPsec is to provide the best methods for authenticity and nonrepudiation. PKI’s goal is not necessarily to provide a method for confidentiality.
Confidentiality
Corporations, the military, financial institutions, and even an end user sitting at a computer have sensitive data that should remain confidential. Ensuring confidentiality for this data keeps a corporation from losing a corporate secret, the military from losing a battle or lives, and financial institutions from losing personal credit information.
If you look closely, confidentiality is a part of your everyday lives. Every time you use an ATM to draw money, you probably look over your shoulder to make sure no one is looking while you enter the PIN. Even in nontechnical areas of life, there are personal and private things that we don’t want to make public.
We might want to share these private details about life only with someone like a close friend or family member. That takes us to the core of confidentiality. Confidentiality’s goal is to provide information only to those people with whom you want to share it and make information unviewable by others.
Figure 1-1 simply illustrates this concept. If Bob is at a ball game and wants to tell Alice he has poison ivy, he will not go up to the speaker system and tell Alice over the loudspeaker in plain English, “Hey Alice, I have poison ivy.” Assuming Alice and Bob are the only two people in the stadium that speak French, he might choose to announce it in French. If other people try to listen, they will likely be unable to understand what was said. Confidentiality of the conversation is maintained.
Figure 1-1 Only Alice Understands What Bob Is Saying
Confidentiality has legal, physical, and financial consequences. Should a financial institution not perform due diligence as defined in the PCI standard (Visa’s personal credit information standard) to protect personal credit information, that institution could face legal and financial consequences.
Integrity
The goal of integrity in cryptography is simple: to maintain the original message. While a message is in transit, it might be modified, and the original message might get changed by some intermediate vector.
Integrity verification detects an attempted change. You can use various techniques to verify integrity. One technique often used is hashing the original message and then encrypting the hash along with the message. If the message were altered in any way, the decrypted hash would not match the new hash. Consequently, the disruption of the message would be detected.
Authenticity and Nonrepudiation
Authenticity and nonrepudiation both involve identification as a way to protect data. Authenticity is the process to identify a sender. This is a necessary condition for nonrepudiation but not a sufficient one. For nonrepudiation to occur, the sender’s message must be proven beyond a doubt to have been sent by the sender. In PKI, this is achieved by using certificates.
Authenticity and nonrepudiation are one of the key objectives of most certificate systems. Typically, a digital signature is created using asymmetric key pairs (discussed later in the “Asymmetric Encryption” section and contrasted to symmetric encryption). The sender “signs” a message. A certificate is granted by a trusted third party who vouches for someone’s signature, consequently “certifying” the sender’s signature.
Symmetric Encryption
Symmetric encryption is a form of changing plain text to cipher text while using a shared secret. The shared secret is only known to the sender and receiver. Both parties use the same key to encrypt and decrypt.
This form of encryption has the most history and wide-spread use. Documented uses go far back into pretechnical eras. You can use a number of encryption ciphers, including straight substitutions and transformations.
All approaches have one element in common: the use of the shared secret, which is also a place of vulnerability. The goal to break this form of encryption is to obtain the common key or shared secret. Consequently, secure mechanisms must be used to exchange the shared secret. Diffie-Hellman is an example of an approach to exchanging a shared secret.
Advantages
The advantage of using symmetric encryption is in its fundamental simplicity. Performance becomes an advantage in this case. Also the strength of encryption is dependent on the key length for any given algorithm. The longer the shared secret, the longer it can take a hacker to decode it, and consequently, the stronger the confidentiality provided.
Challenges
A major disadvantage of symmetric encryption is in distribution of the shared secret. For this form of encryption to work, all parties must know the common key.
This creates two principal issues that have a common theme in security: availability versus security. First, a secure method to deliver the shared secret is required, which centers around availability. Without the shared secret being delivered to all parties, encryption or decryption can not be performed. The second issue is with security, which hinges on knowledge of the shared secret. If the shared secret is compromised by brute force, crypto analysis, or erroneous exposure, all transmissions will be compromised.
This introduces another related and significant challenge, arriving at a sufficiently strong shared secret. The shared secret, if compromised, would result in all conversations becoming readable. One approach to solve this problem is to use Diffie-Hellman.
Example Algorithm: DES and 3DES
DES is a symmetric encryption algorithm. The key used for encryption and decryption is the same. Portions of the cleartext are logically operated on by the “exclusive or” on portions of the key. Then this goes through other manipulations such as substitution by S-boxes (developed as part of collaboration between the NSA and IBM). Decryption uses the same key, although in the reverse order. The algorithm is considered symmetric because the same key decrypts the cipher text.
Asymmetric Encryption
Unlike symmetric encryption that uses a shared secret, asymmetric encryption uses multiple keys. Each sender has two keys: a public key and a private key. The public key is available to anyone and is freely distributed. The private key is kept hidden and known only to the sender. The private key being known only to the sender is a critical assumption to asymmetric encryption.
Converting plain text into cipher text uses a different paradigm in asymmetric encryption. Depending on the purpose of the transmission, either the private or the public key can encrypt data. The receiver uses the opposite key to decrypt data. To illustrate this further, now examine the two major applications in which asymmetric encryption are used.
Asymmetric Encryption Application: Authentication
Authentication is the principal application of most PKI solutions. The goal of authentication is not to provide confidentiality of information, but to verify the sender’s identity. Authentication in asymmetric encryption uses the sender’s private and public key. If any message is encrypted using the sender’s private key, the receiver can use the senders public key to decrypt it. Because the assumption is that the only user with the private key is the sender, and the message is successfully decrypted by the receiver with the public key, the message must have been sent by the sender. QED authentication is successful. Digital signatures use a specific schema of this form of authentication. A discussion on digital signatures is found later in this chapter in the “Digital Signatures” section.
In Figure 1-2, Bob encrypts the message “Hello” with his private key. Because Alice can decrypt the message with Bob’s public key, Bob must have sent the message (only Bob has the public key), and thus the message is authenticated.
Figure 1-2 Alice Verifies Bob Is the Sender of the Message
Asymmetric Encryption Application: Encryption
Encryption using an asymmetric schema uses the receiver’s public and private key. The sender obtains the receiver’s public key. Then the sender encrypts the message with the sender’s public key. It is assumed that the private key of a party is known only by that party; that is, the receiver is the only one with the private key. Consequently, when the receiver obtains a copy of the encrypted message, the receiver and only the receiver can decrypt it using the private key.
In Figure 1-3, Bob sends the message “Hello” to Alice. He uses Alice’s public key to encrypt the message. Because only Alice has her private key, she is the only one who can decrypt the message. Confidentiality of the message is maintained between Alice and Bob.
Figure 1-3 Alice Decrypts Bob’s Secret Message
Advantages
The principal advantage of using the asymmetric schema is availability. A shared secret does not need to be distributed to all communicating members; the public key is freely distributed.
Challenges
The major challenge in the asymmetric schema is the complexity of the algorithms. Typically, they require more processing power and take longer to perform encryption.
Example: RSA
The RSA algorithm has two keys: a public and a private key. The public key can decrypt ciphertext created with the private key and vice versa.
RSA finds its strength in a number of assumptions. One assumption is that it is easy to multiply two prime numbers together, and conversely, it is difficult to determine the prime factors used, assuming that the resultant is large. The public and private keys are inverse functions of one another, the function of which is related to the multiplicative product of both primes. To determine the inverse, the prime factors of the resultants must be determined, which is computationally expensive.
Other Crypto Functions
The two critical supporting functions for cryptography are hashes and digital signatures.
Hashes
The capability to take a multilength string and convert it to a fixed length unique string is a useful mechanism in cryptography. Creating the fixed-length unique string is computationally low cost. The reverse is computationally high cost, relatively speaking.
In Figure 1-4, hashes take mixed length generic inputs and produce fixed length, pseudo random outputs.
Figure 1-4 Variable Length Input Produces a Fixed Length Hash
Because of the irreversibility of hash functions, hashes are often used as methods to validate the integrity of a communication.
Digital Signatures
A sender uses digital signatures to authenticate a message. Digital signatures use asymmetric cryptography; specifically, digital signatures are based on the method of authentication in asymmetric cryptography.
Digital signatures operate in two distinct functions: signature construction and signature verification. Following are the steps in signature construction:
1. A message is created by the sender.
2. A hash is taken of that message.
3. That hash is encrypted with the sender’s private key.
4. The encrypted hash, the digital signature, is sent with the original message.
In Figure 1-5, a digital signature takes a copy of a message, hashes it, and then encrypts it with the sender’s private key. It is not used for confidentiality, but rather for authentication.
Figure 1-5 Creating a Digital Signature
Following are the steps in signature verification:
1. The encrypted hash is separated from the original message.
2. A hash is taken of the original message.
3. The encrypted hash is decrypted with the sender’s private key.
4. The decrypted hash is compared with the hash of the original message.
5. If both hashes are the same, the signature, and consequently the sender’s identity, is verified.
In Figure 1-6, a signature is verified by taking a hash of the message and comparing that hash to the decrypted copy of the signature, which is decrypted by using the sender’s public key. If both match, the signature of the message is verified.
Figure 1-6 Verifying a Digital Signature
In summary, a digital signature is the hash of a message, which is encrypted with the sender’s private key. The signature must be verified to verify the sender’s identity. This is done by the receiver, who decrypts the signature with the sender’s public key, makes a hash of the original message, and compares both hashes. If both are the same, the sender’s identity is verified.
Internet Key Exchange (IKE)
IKE is a method of exchange keys with the intent of establishing a peer relationship. This peer relationship enables a secure and authenticated exchange of cryptographic material. This exchange is followed by the encryption of data between peers. IKE is the control plane for an IPsec tunnel, which encrypts user data.
IKE can be broken into two distinct phases. Phase 1 establishes a secure, authenticated channel. By default, Cisco routers execute this phase in main mode. A less secure, but quicker approach, called aggressive mode for IKE authentication, can be configured.
Phase 2 negotiates the data plane security associations. In this discussion this is the IPsec parameters. This approach is referred to as quick mode. In this paradigm, certificates are used for authentication. Authentication occurs in Phase 1 of IKE; consequently, we focus on Phase 1.
For the authentication discussion for IKE assume that in a successful transaction, both sender and receiver have received a certificate from the same certification authority (CA). Consequently, both the sender and receiver have a copy of the CA’s public key.
At a high level, certificate authentication can involve verifying digital signatures. The digital signature of the IKE peer is verified. Also, the digital signature of the CA is verified to ensure the certificate provided by the authenticator has truly been issued by the CA. For the peer to receive a certificate from the CA, the peer must first have a public private key pair (typically RSA). This key pair is signed by the CA and used as part of the digital signature offered by the peer described later in this chapter.
IKE Phase 1
Main mode Phase 1 can be broken up into three main packet exchanges of two packets each. The first set of packets exchange negotiates the method, the SA (security association), used for IKE. These first two packets define the algorithms and hashes used to secure the IKE communications and are agreed upon in matching IKE SAs in each peer. In other words, the first exchange defines which IKE security association will be used. The second exchange sets up the secure channel and sets the stage for authentication. This exchange uses a Diffie-Hellman exchange, which is a process that generates a shared secret. This is done by using a method of exchanging nonces, which are random numbers sent to the other party. These nonces are digitally signed and returned as part of authenticating the communication channel. The third packet exchange proves the identity of the both peers to one another. This is where the authentication is completed. After all three packet exchanges are completed, a secure, authenticated control channel is created.
In Phase 1, six packets are exchanged. The contents of the packets vary if certificates or preshared keys are used for authentication. In each case, the general theme of each set of exchanges is the same. The first two packets negotiate the IKE SAs; the next two set up the secure channel; and the last two authenticate the other side.
In Figure 1-7, IKE main mode is handled in three distinct sets of packet exchanges: SA negotiation, secure channel creation, and authentication.
Figure 1-7 IKE Main Mode Exchanges
In Figure 1-8, preshared keys are authenticated in the last two packets exchanged in main mode.
Figure 1-8 Phase 1 Using Preshared Keys
When using certificates, the first packet exchange has the same purpose, to negotiate the Phase 1 SAs. In the second exchange, Diffie-Hellman creates a secure channel. In the third exchange each sender sends their respective certificates. This message is signed with the sender’s private key and verified with the sender’s public key. The sender’s certificate is verified using the CA’s public key.
Figure 1-9 shows certificates in IKE main mode that are requested in the second exchange and delivered in the third exchange.
Figure 1-9 Phase I Using Certificates
IKE Phase 2
IKE Phase 2 negotiates SAs for the data plane protocol in most cases, IPSEC SAs. This negotiation process is protected by the control channel established in Phase 1. Phase 2, also called quick mode, refreshes SAs periodically for increased security.
The Phase 2 exchange consists of three packets. These packets negotiate the IP addresses of the peers, the protected traffic, and the transforms that will be protecting that traffic. In the first two packets, each peer sends over its SA information. The third packet is a confirmation and keepalive message. Every packet is protected by the IKE secure channel (header) as indicated by HDR in Figure 1-10 and is also protected by a hash to ensure integrity of the transmission.
Figure 1-10 IKE Quick Mode Negotiation
Figure 1-10 shows that in IKE quick mode, the dataplane (common IKE) encryption SAs are negotiated.
Device Configuration: Certificates
The default configuration for the Isakmp policy is to use certificates. For this to be done, RSA keys need to be generated, and the router must be enrolled with a CA. (This process is covered in detail in Chapter 3.) The command crypto key generate rsa creates RSA keys locally in the router and must be done first.
Example 1-1 Configuration of the Router Using Certificates. Default Authentication Uses Certificates.
Summary
The basics covered in this chapter set a baseline understanding of encryption. Some key points to remember are that symmetric encryption uses the same key to encrypt and decrypt, where asymmetric encryption uses a private/public key pair. In asymmetric encryption, the private and public keys perform opposite functions. If data is encrypted with the public key, the private key decrypts it and vice versa.
One place certificates come into play is as part of IKE. During IKE certificates are used as a method of authentication. Certificates heavily depend on asymmetric encryption. The framework of how to generate and deliver certificates in a secure, scalable, and reliable fashion is the foundation of this text.