Cryptology Overview
The first thing you need to know is that cryptology and cryptography are not the same things. Cryptology is the overall art and science of making and breaking codes. Cryptography and cryptanalysis are disciplines within cryptology.
The second thing you need to know is that in attempting to define any one term in the field of cryptology, a floodgate of other new terminology, many starting with the letter “c,” is opened!
Here are some basic definitions of words that start with “crypt”:
- Cryptography. Code making. It is the art of creating and using simple word or character substitutions to hide the original meaning.
- Cryptanalysis. Code breaking. It is the process of analyzing a cryptographic algorithm for weaknesses and exploiting them to break the code.
- Cryptosystem. Any system that implements codes to encrypt and decrypt messages.
- Cipher. A cryptographic algorithm (or “encryption algorithm”) used to encrypt and decrypt files and messages.
- Ciphertext. An encrypted message or file. Code.
- Cleartext (or plaintext). An unencrypted message or file.
- Encryption (Enciphering). Cryptosystems encrypt by rendering cleartext into ciphertext. Encoding.
- Decryption (Deciphering). The message recipient’s cryptosystem decrypts by rendering the ciphertext back into cleartext. Decoding.
The terms enciphering and deciphering, while technically accurate, are not commonly used anymore. Let’s talk about a common misuse of terminology. There is no such action as unencryption because there is no verb “unencrypt.” Encrypted messages are decrypted, not unencrypted, by a cryptosystem. Unencrypted is an adjective that refers to a message that is sent in cleartext.
An example of a real-time use of cryptology would be an IPsec VPN cryptosystem, which uses cryptographic algorithms (ciphers) to encrypt messages into ciphertext and decrypt those same messages back to cleartext. A cryptanalyst (a hacker, for example) would use the science of cryptanalysis as a form of man-inthe-middle attack to try to break the code. There, we’ve used all the terms in the list of definitions that we’ve created so far!
Figure 6.1 illustrates the elements of a cryptosystem. The data flow is left to right.
All the traffic from the A network to the B network is encrypted by router A and becomes ciphertext for transmission inside an IPsec VPN to router B. Attackers (cryptanalysts!) would not be able to read the ciphertext because they possess neither the encryption key nor the encryption algorithm, both of which would be needed to decrypt this coded transmission. When the ciphertext arrives at router B, it is decrypted using the same encryption algorithm and encryption keys as were used by router A to encrypt it. When the message is forwarded by router B to network B, its final destination, it has been rendered back into cleartext.
Theoretically, it is possible to break any code because an attacker would only need to try by brute force every possible key (a large universe of possibilities) in combination with all known ciphers (a small universe of possibilities). The emphasis, of course, is on the word theoretical. Part of the art of encryption in a Cisco network, or any network security architecture, is to find the balance between usability and security. In this case, the encryption algorithms may be well known and therefore guessable, but we must make the keys reasonably difficult to break such that a knowledgeable attacker cannot access our sensitive information. You can read the specifics of how to implement an IPsec VPN cryptosystem in Chapter 7, but it would be useful to look at some of the building blocks first.
Understanding the fundamentals of a cryptosystem at a high level will aid you greatly in understanding, rather than simply memorizing, the concepts. In turn, you will find it much easier to configure the crypto features of the Cisco IOS, including IPsec VPNs. If that isn’t motivation enough, troubleshooting issues that deal with cryptography requires a high-level understanding at a minimum.
Historically, earlier efforts in creating cryptosystems relied on the secrecy of the cipher itself to achieve confidentiality. Examples of this would be the Caesar cipher or the Enigma machine used by the German military during World War II. With most modern cryptosystems, secrecy relies on the strength of the keys because knowledge of the crypto algorithms themselves is largely in the public domain.
We hadn’t used the term key until the last two paragraphs. Basically, there are two main elements in a cryptosystem that are used to turn cleartext into ciphertext: ciphers, defined earlier, and keys. A key (also known as an encryption key or cryptographic key) is a collection of bits, usually stored in a file, that are used with a cipher to encrypt and decrypt a message.
Fair to say, the larger the number of bits in your bit collection, the stronger the resulting encryption. There is more about keys in the sections “Exploring Symmetric Key Encryption” and “Exploring Asymmetric Key Encryption and Public Key Infrastructure” later in this chapter.
To place all this into a networking context, encryption can occur at several layers of the OSI model, including the following:
- Data Link Layer (OSI Layer 2). Proprietary link layer encryption devices; examples include Ethernet NICs with encryption chips, which encrypt the payload of frames.
- Network Layer (OSI Layer 3). Protocols such as the IPsec framework, which create encrypted payload in network layer packets.
- Transport Layer (OSI Layer 4). Protocols such as Transport Layer Security (TLS) and Secure Sockets Layer (SSL), which create encrypted payload in transport layer segments.
- Application Layer (OSI Layers 5–7). Protocols such as Microsoft’s Remote Desktop Protocol (RDP) for remote terminal sessions or secure messaging applications, such as Lotus Notes, and secure database applications, such as Oracle’s SQL*Net, which create encrypted payload at the application layer.
There are examples of both IPsec and SSL in Chapter 7 because they are useful in setting up the vendor-neutral, real-time network cryptosystems called virtual private networks (VPNs).
Cryptanalysis
It’s a question of perspective. If you’re a hacker, you’re not attacking, you’re cryptanalyzing, right? At least, that’s what you tell the judge. If you are the victim, it’s a cryptographic attack. Table 6.1 explains some examples of cryptographic attacks.
You may recall from Chapter 2, “Building a Secure Network Using Security Controls,” that encryption, and thus cryptosystems, are examples of technical controls. The organization’s security policy will dictate what constitutes “reasonable security,” hopefully after using industry-standard metrics to measure the organization’s vulnerability to the threat of certain exploits. Physical controls must be defined and implemented to safeguard the technical controls.
In January of 1999, the Data Encryption Standard (DES) cipher developed by IBM, and which uses 56-bit keys, was cracked in just over 22 hours as part of the RSA Data Security’s “DES Challenge III” (see http://www.networkworld.com/news/1999/0120cracked.html). It is estimated that using the same method, the Advanced Encryption Standard (AES) could be cracked in 149 trillion years.
Encryption Algorithm (Cipher) Desirable Features
A good encryption algorithm should be resistant to the attacks outlined in Table 6.1. Table 6.2 lists other key features desirable in an encryption algorithm.
Symmetric Key Versus Asymmetric Key Encryption Algorithms
Encryption keys work with encryption algorithms to turn cleartext into ciphertext. But be careful with our terminology because it isn’t the keys that are symmetric or asymmetric; it is the method in which they are used by encryption algorithms that determines their symmetry. There are two broad categories of use for encryption keys:
- Symmetric Encryption Algorithm. Uses the same key to encrypt and decrypt data.
- Asymmetric Encryption Algorithm. Requires different keys—one key to encrypt the cleartext, and another to decrypt the ciphertext.
Complete sections later in this chapter explore examples of each in more detail.
“I want examples!” you say. OK, here’s one. As was noted earlier, since the focus on modern cryptosystems is the strength of the encryption key, safeguarding the key is of primary importance. A related issue is key distribution. For example, if the modern cryptosystem is an IPsec VPN using symmetric keys, generating a shared secret key for encryption between two VPN gateways over a hostile network such as the Internet is a critical issue. For example, the keys could be distributed out-of-band using a courier service or a phone call and then manually inputted on the devices. This is probably secure but hardly convenient. The Diffie-Hellman (DH) key exchange solves this issue. It defines an in-band (and slightly magical!) way of securely creating a shared key using the same hostile network that the data will eventually be encrypted and transmitted across. This is explained in Chapter 7.
Symmetric Key Algorithms
Because symmetric key algorithms are based on simple mathematical operations, they are quite fast and often used for encryption services; they are easily accelerated by hardware. We will see examples of hardware acceleration in Cisco hardware in Chapter 7. Key management algorithms, such as Diffie-Hellman mentioned in the previous note, provide secure key exchange. Examples of symmetric key algorithms and their key lengths include the following:
- DES (Data Encryption Standard). 56 bits.
- 3DES (Triple DES). 112 and 168 bits.
- AES (Advanced Encryption Standard). 128, 192, and 256 bits.
- IDEA (International Data Encryption Algorithm). 128 bits.
- RC (Rivest Cipher or Ron’s Code) Series:
- RC2: 40 and 64 bits.
- RC4: 1 to 256 bits.
- RC5: 0 to 2040 bits.
- RC6: 128, 192, and 256 bits.
- Blowfish. 32 to 448 bits.
- SEAL (Software Encryption Algorithm). 160 bits.
Know the names of all the ciphers in the previous list, as well as the key length that they each require.
AES, also known as Rijndael after the last names of the co-inventors, resulted from a competition by the National Institute of Standards and Technology (NIST) for a successor to the pervasive DES cipher. RC6 was one of the finalists in that same competition. AES was adopted in November 2001 and approved by NIST as FIPS 197. It is remarkable for its speed, relative ease of use, and little memory requirement. Since its adoption, it has quickly become the de facto standard for encryption worldwide and not just for the U.S. federal government.
Asymmetric Key Algorithms
Asymmetric key algorithms are more commonly referred to as public key algorithms. For example, in an IPsec VPN, a device such as an IOS router will use its peer’s public key to encrypt data to that peer and decrypt data from that same peer using its own private key. The asymmetry is found in the fact that each peer requires a key pair consisting of a private key and public key. The private key is almost never transmitted to the peer, but the public key can be freely exchanged because only the holder of the matching private key will be able to decrypt messages encrypted with that public key. This makes the resulting cryptosystem highly resistant to attacks … assuming that a key of sufficient length and complexity is chosen of course.
Examples of encryption algorithms that make use of asymmetric keys (usually in lengths of 512 to 4096 bits) include the following:
- Diffie-Hellman (DH)
- Rivest Shamir Adleman (RSA)
- Elliptic Curves Cryptography (ECC)
- ElGamal Encryption System (ElGamal)
Asymmetric encryption algorithms are slower than symmetric encryption algorithms because they are based on complex computations. Also, the lengths of the encryption keys, while longer than symmetric keys, do not equate to equivalent security bit-to-bit, according to the following key equivalency:
- RSA with 1024-bit key equal to 80-bit symmetric key
- RSA with 2048-bit key equal to 112-bit symmetric key
- RSA with 3072-bit key equal to 128-bit symmetric key
Block Versus Stream Ciphers
Now that we’ve categorized encryption algorithms by their use of keys (symmetric or asymmetric), let’s look at categorizing ciphers by the way they organize data prior to encryption. Encryption algorithms can be either block ciphers or stream ciphers.
Block ciphers have the following characteristics:
- A data stream is parsed into fixed-length units (blocks) of plaintext data and then transformed into ciphertext of the same length.
- The size of the block used varies with the cipher (DES uses 8 bytes = 64 bits).
- Block sizes have to be uniform so padding is common.
- The resulting ciphertext is typically longer than the plaintext (see the last bullet in the following stream cipher characteristics list for comparison).
Stream ciphers have the following characteristics: - Stream ciphers work at a more granular level, using smaller units of plaintext data; bits, for example.
- Because blocking is not used, padding is not needed, and therefore the size of the messages does not change when they are transformed to ciphertext.
Do not confuse the number of bits in a block used by a block cipher with the number of bits in its key. For example, 3DES uses a 168-bit key, but 64-bit blocks.
Stream ciphers can be much faster than block ciphers because they do not need to block and pad the data and can encrypt an arbitrary number of bits. Common block ciphers include the following:
- DES and 3DES when used in Electronic Code Book (ECB) or Cipher Block Chaining (CBC) mode
- AES
- IDEA
- Secure and Fast Encryption Routine (SAFER)
- Skipjack
- Blowfish
- RSA
Common stream ciphers include the following:
- DES and 3DES when used in Output Feedback (OFB) or cipher feedback (CFB) mode
- RC4
- Software Encryption Algorithm (SEAL)
Which Encryption Algorithm Do I Choose?
We’ve categorized encryption algorithms by whether they use block or stream ciphers and whether they use symmetric or asymmetric keys. At a high level, we have looked at some of the features of these categories. This still doesn’t answer the over-arching question as to which encryption algorithm we should choose. Is there a body of industry best practices that will help? According to Cisco, it is a matter of trust and an algorithm’s resistance to brute force attack. Two basic criteria for choosing an encryption algorithm are as follows:
- The algorithm provides sufficient protection against brute force attacks. (For more about who defines “sufficient,” see Chapter 2 and the following note.)
- The algorithm is trusted by the greater cryptographic community. With respect to the last point, symmetric algorithms that are considered trusted are DES, 3DES, IDEA, RC4, and AES. Asymmetric algorithms that are considered trusted are RSA and DH.
Practically speaking, the organization’s security policy will determine whether a cipher provides sufficient protection against attack based on such factors as the likelihood of an exploit and the cryptosystem’s vulnerability against specific threats. One would think that the most secure cipher should always be the one to choose, as long as it doesn’t introduce unacceptable tradeoffs in terms of performance and latency. In reality, it is the trustworthiness and not just the security of a cipher that may tip the balance when deciding the cipher to use in a cryptosystem such as an IPsec VPN. Trust is hard to quantify, but the idea of trust is easier to quantify with industry data. For example, because they are trusted by industry, an IPsec VPN might be configured to use the following:
- AES as a symmetric algorithm for protecting data and the negotiations between the peers.
- DH for automating the generation and exchange of encryption keys between the peers.
Other encryption algorithms might not be trusted. For example, ECC is considered to be relatively immature. However, depending on the cryptosystem’s requirements, it might be an acceptable tradeoff, especially if the devices in the cryptosystem do not possess much processing power.
Cryptographic Hashing Algorithms
A cryptographic hash is sometimes described as a one-way encryption—encryption where there is no possibility of decryption. Hashing algorithms, like encryption algorithms, take cleartext data and using an encryption key, transform the cleartext data into something different and unreadable by an attacker. But what comes out of the hashing process is not ciphertext as with encryption algorithms, but rather a fixed-length hash. The implication with ciphertext is that it will be deciphered. With a hash, the whole purpose is that it cannot be deciphered.
Hashes are most commonly used as a method of integrity assurance. (Recall CI-A from Chapter 1.) When a device in a cryptosystem wants to ensure that the data that it is sending to its peer is not being tampered with, it can append a hash of a message with the original message. The receiving device can create its own hash of the received message and compare it with the hash that is appended to the message. If they are the same, then the message has not been tampered with.
What prevents an attacker from altering a message and then altering the hash to reflect the altered message’s new contents? Nothing actually, except both the sender and the receiver are not only using the same hashing algorithm, but they are hashing the message with a shared secret key added. Only the devices that knows the key (and they’re not sharing it with an attacker) will be able to create and compare the hashes correctly. There’s another use of keys, again underlining how important it is to properly manage and secure these keys.
Hashing algorithms are described in more detail in the “Exploring Cryptographic Hashing Algorithms and Digital Signatures” section of this chapter.
Principles of Key Management
A recurring thread has been the necessity of proper key management because attacks against modern cryptosystems are not against the encryption algorithms, but against the keys. Principles of key management include the following:
- Key management policies describe the secure generation (or issuance), verification, exchange, storage, and destruction of keys.
Getting way ahead of ourselves for a moment, Public Key Infrastructure (PKI) is a good example of the principles of key management. PKI defines a whole protocol for the secure issuance, exchange, revocation, destruction, storage, and backup of digital certificates and integral asymmetric keys used for device and individual authentication and encryption, typically in an enterprise setting. PKI is examined later in the section, “Exploring Asymmetric Key Encryption and Public Key Infrastructure.”
- Key management is often considered the most difficult task of designing, implementing, and maintaining cryptosystems.
- Secure key management is vitally important in a cryptosystem.
- Compared to encryption algorithms, key management is a more common avenue of attack on modern cryptosystems.
Following is a summary of the component tasks in a key management policy. A key management policy manages key: - Generation
- Verification
- Storage
- Exchange
- Revocation
- Destruction
Other Key Considerations
Because we have established that attackers will pry away at a modern cryptosystem’s keys, it stands to reason that we should do nothing to aid the attackers in their tasks. Two considerations with respect to keys stand out: the concept of keyspaces and the issue of key length.
Keyspaces
A keyspace is the set of all possible values that a key might draw from. This is the “universe of choices.” The larger the keyspace, the more difficult it will be for a brute force attack to be successful. An effective comprehensive network security policy will recognize these keyspace concepts:
- The keyspace of an encryption algorithm is the set of all possible key values.
- Each bit has two possible values, 1 or 0; thus, an n-bit key has 2 n possible key values.
- Most encryption algorithms can be configured to use weak (easily guessable and repeating) keys.
- Manual definition of keys can be difficult because care must be taken to avoid the use of known weak keys.
Key Length
The longer the key length, the larger the keyspace, the more difficult it is to crack the code. If an encryption algorithm is considered trustworthy (see the earlier section, “Which Encryption Algorithm Do I Choose?”), then the only way that an attacker can crack the code is by attempting to brute-force the keys. The goal is to make this kind of attack unfeasible.
A largely unspoken axiom of network security is that you are making your network unattractive to attackers. The more unattractive you make your network, the more likely that an attacker will move on to another network. This is the philosophy that many people use in burglar-proofing their homes. It’s not so much that they are burglar-proof; rather, that there is often a visible deterrent that makes the burglar move on to a neighbor’s house. Remember from an earlier chapter, network security is not a risk elimination exercise; it is a risk mitigation exercise. Long keys are unfeasible to crack. A sufficiently long key with a modern cryptosystem could conceivably take millions or billions of years to crack. The sun will have exploded and the earth turned to dust by that time.
On average, cryptanalysis by brute force will crack the code after searching through half the keyspace.
The length of your keys should be dictated by the tradeoff between security and usability. Knowing your attackers (including how well-funded they are) through a proper risk assessment will indicate the encryption algorithm to use and the length of encryption keys to use with that algorithm.
SSL VPNs
SSL VPNs are becoming increasingly common. SSL is also a good way to demonstrate some of the encryption algorithms, hashing algorithms, and the use of encryption keys that we have looked at so far. Chapter 7 contains a quick overview of some of Cisco’s SSL VPN solutions. Here we will do a quick overview of what SSL is and then use it to glue some of the ideas we have come across to our synapses. SSL is a cryptosystem that was invented by Netscape Corporation in the mid 1990s.
SSL characteristics include the following:
- Symmetric key algorithms for encryption.
- Asymmetric key algorithms for authentication and key exchange.
- Hashes during the authentication process. Cleartext passwords are never exchanged.
- Similar to IPsec in that it specifies methods to negotiate encryption algorithms and then uses the negotiated algorithms to transform data.
- Used worldwide by many e-commerce sites (at least the ones we trust!).
- Secures not only web communication but is also popular to secure email protocols such as SMTP, FTP, IMAP, and POP3.
- Gaining rapid acceptance as an alternative to IPsec for remote-access VPNs.
- Transport Layer Security (TLS) is the newer, standards-based, replacement for SSL. (But we still call the whole paradigm SSL.)
- Employs key lengths between 40 and 256 bits for encryption algorithms.
Figure 6.2 illustrates Cisco’s new remote-access AnyConnect SSL VPN client establishing a VPN to a central site ASA 5500 Series adaptive security appliance using SSL. As noted, SSL defines methods for negotiating the ciphers, as well as authenticating the peers and performing a secure key exchange. This is the same exchange as would occur if a user were to visit a secure e-commerce site such as would be established for online banking.
Step 6 in Figure 6.2 is included for the sake of completeness, however it is not part of a standard SSL tunnel establishment process
After the secure SSL tunnel is established, the VPN client obtains an IP address, subnet mask, default gateway, and other information from the VPN server, the ASA. The result is illustrated in Figure 6.3. Look for these two things on Figure 6.3:
A. The client has obtained IP address 192.168.20.8.
B. An RSA_AES_128_SHA1 cipher has been negotiated to protect the data in the VPN tunnel.
