A network can be secured through device hardening, AAA access control, firewall features, and IPS implementations. These combined features protect the infrastructure devices as well as the end devices within the local network. But how is network traffic protected when traversing the public Internet? The answer is through cryptographic methods.
Cryptology is the science of making and breaking secret codes. The development and use of codes is called cryptography, and breaking codes is called cryptanalysis. Cryptography has been used for centuries to protect secret documents. For example, Julius Caesar used a simple alphabetic cipher to encrypt messages to his generals in the field. His generals would have knowledge of the cipher key required to decrypt the messages. Today, modern day cryptographic methods are used in multiple ways to ensure secure communications.
Secure communication requires a guarantee that the message is not a forgery and does actually come from whom it states (authentication). It also requires a guarantee that no one intercepted the message and altered it (integrity). Finally, secure communication ensures that if the message is captured, it cannot be deciphered (confidentiality).
The principles of cryptology can be used to explain how modern day protocols and algorithms are used to secure communications. Many modern networks ensure authentication with protocols such as HMAC. Integrity is ensured by implementing either MD5 or SHA-1. Data confidentiality is ensured through symmetric encryption algorithms, including DES, 3DES, and AES, or asymmetric algorithms, including RSA and the public key infrastructure (PKI). Symmetric encryption algorithms are based on the premise that each communicating party knows the pre-shared key. Asymmetric encryption algorithms are based on the assumption that the two communicating parties have not previously shared a secret and must establish a secure method to do so.
In a hands-on lab for the chapter, Exploring Encryption Methods, learners decipher a pre-encrypted message using the Vigenere cipher, create and decipher a Vigenere cipher message, and use steganography to embed a secret message in a graphic. The lab is found in the lab manual on Academy connection at cisco.netacad.net.
The first goal for network administrators is to secure the network infrastructure, including routers, switches, servers, and hosts. This is accomplished using hardening, AAA access control, ACLs, firewalls, and monitoring threats using IPS.
The next goal is to secure the data as it travels across various links. This may include internal traffic, but of greater concern is protecting the data that travels outside of the organization to branch sites, telecommuter sites, and partner sites.
Secure communications involves a few primary tasks:
Authentication
Authentication guarantees that a message comes from the source that it claims to come from. Authentication is similar to entering a secure personal information number (PIN) for banking at an ATM. The PIN should only be known to the user and the financial institution. The PIN is a shared secret that helps protect against forgeries.
Authentication can be accomplished with cryptographic methods. This is especially important for applications or protocols, such as email or IP, that do not have built-in mechanisms to prevent spoofing of the source.
Data nonrepudiation is a similar service that allows the sender of a message to be uniquely identified. With nonrepudiation services in place, a sender cannot deny having been the source of that message. It might appear that the authenticity service and the nonrepudiation service are fulfilling the same function. Although both address the question of the proven identity of the sender, there is a difference between the two.
The most important part of nonrepudiation is that a device cannot repudiate, or refute, the validity of a message sent. Nonrepudiation relies on the fact that only the sender has the unique characteristics or signature for how that message is treated. Not even the receiving device can know how the sender treated this message to prove authenticity, because the receiver could then pretend to be the source.
On the other hand, if the major concern is for the receiving device to validate the source and there is no concern about the receiving device imitating the source, it does not matter that the sender and receiver both know how to treat a message to provide authenticity. An example of authenticity versus nonrepudiation is a data exchange between two computers of the same company versus a data exchange between a customer and an e-commerce website. The two computers within the organization that exchange data do not have to prove to the other which of them sent a message. The only thing that must be proven is that whatever was received by one was sent by the other. In this instance, the two computers can share the same way of transforming their messages.
This practice is not acceptable in business applications, such as when purchasing items online through a web shop. If the web shop knows how a customer transforms messages to prove authenticity of the source, the web shop could easily fake "authentic" orders. In such a scenario, the sender must be the only party having the knowledge of how to transform messages. The web shop can prove to others that the order was, in fact, sent by the customer, and the customer cannot argue that the order is invalid.
Integrity
Data integrity ensures that messages are not altered in transit. With data integrity, the receiver can verify that the received message is identical to the sent message and that no manipulation occurred.
European nobility ensured the data integrity of documents by creating a wax seal to close an envelope. The seal was often created using a signet ring. These bore the family crest, initials, a portrait, or a personal symbol or motto of the owner of the signet ring. An unbroken seal on an envelope guaranteed the integrity of its contents. It also guaranteed authenticity based on the unique signet ring impression.
Confidentiality
Data confidentiality ensures privacy so that only the receiver can read the message. Encryption is the process of scrambling data so that it cannot be read by unauthorized parties.
When enabling encryption, readable data is called plaintext, or cleartext, while the encrypted version is called ciphertext. The plaintext readable message is converted to ciphertext, which is the unreadable, disguised message. Decryption reverses the process. A key is required to encrypt and decrypt a message. The key is the link between the plaintext and ciphertext.
Historically, various encryption algorithms and methods have been used. Julius Caesar is said to have secured messages by putting two sets of the alphabet side by side and then shifting one of them by a specific number of places. The number of places in the shift serves as the key. He converted plaintext into ciphertext using this key, and only his generals, who also had the key, knew how to decipher the messages. This method is now known as the Caesar cipher.
Using a hash function is another way to ensure data confidentiality. A hash function transforms a string of characters into a usually shorter, fixed-length value or key that represents the original string. The difference between hashing and encryption is in how the data is stored. With encrypted text, the data can be decrypted with a key. With the hash function, after the data is entered and converted using the hash function, the plaintext is gone. The hashed data is simply there for comparison. For example, when a user enters a password, the password is hashed and then compared to the stored hashed value. If the user forgets the password, it is impossible to decrypt the stored value, and the password must be reset.
The purpose of encryption and hashing is to guarantee confidentiality so that only authorized entities can read the message.
Authentication, integrity, and confidentiality are components of cryptography. Cryptography is both the practice and the study of hiding information.
Cryptographic services are the foundation for many security implementations and are used to ensure the protection of data when that data might be exposed to untrusted parties. Understanding the basic functions of cryptography and how encryption provides confidentiality and integrity is important in creating a successful security policy. It is also important to understand the issues that are involved in managing the encryption key.
The history of cryptography starts in diplomatic circles thousands of years ago. Messengers from a king's court took encrypted messages to other courts. Occasionally, other courts not involved in the communication attempted to steal any message sent to a kingdom that they considered an adversary. Not long after, military commanders started using encryption to secure messages.
Various cipher methods, physical devices, and aids have been used to encrypt and decrypt text:
Each of these encryption methods use a specific algorithm, called a cipher, to encrypt and decrypt messages. A cipher is a series of well-defined steps that can be followed as a procedure when encrypting and decrypting messages.
There are several methods of creating cipher text:
In transposition ciphers, no letters are replaced; they are simply rearranged. An example of this type of cipher is taking the message FLANK EAST ATTACK AT DAWN and transposing it to read NWAD TAKCATTA TSAE KNALF. In this example, the key is to reverse the letters.
Another example of a transposition cipher is known as the rail fence cipher. In this transposition, the words are spelled out as if they were a rail fence, meaning some in front and some in back across several parallel lines. For example, a rail fence cipher that uses a key of three specifies that three lines are required when creating the encrypted code. To read the message, read diagonally up and down, following the rail fence.
F...K...T...A...T...N.
.L.N.E.S.A.T.C.A.D.W..
..A...A...T...K...A...
Modern encryption algorithms, such as the Data Encryption Standard (DES) and the Triple Data Encryption Standard (3DES), still use transposition as part of the algorithm.
Substitution ciphers substitute one letter for another. In their simplest form, substitution ciphers retain the letter frequency of the original message.
The Caesar cipher was a simple substitution cipher. Every day there was a different key to use for adjusting the alphabet. For example, if the key for the day was 3, the letter A was moved three spaces to the right, resulting in an encoded message that used the letter D in place of the letter A. The letter E would be the substitute for the letter B, and so on. If the key for the day was 8, A becomes I, B becomes J, and so on.
Because the entire message relied on the same single key shift, the Caesar cipher is referred to as a monoalphabetic substitution cipher. It is also fairly easy to crack. For this reason, polyalphabetic ciphers, such as the Vigenere cipher, were invented. The method was originally described by Giovan Battista Bellaso in 1553, but the scheme was later misattributed to the French diplomat and cryptographer, Blaise de Vigenere.
The Vigenere cipher is based on the Caesar cipher, except that it encrypts text by using a different polyalphabetic key shift for every plaintext letter. The different key shift is identified using a shared key between sender and receiver. The plaintext message can be encrypted and decrypted using the Vigenere Cipher Table.
To illustrate how the Vigenere Cipher Table works, suppose that a sender and receiver have a shared secret key composed of these letters: SECRETKEY. The sender uses this secret key to encode the plaintext FLANK EAST ATTACK AT DAWN:
The process continues until the entire text message FLANK EAST ATTACK AT DAWN is encrypted. The process can also be reversed. For instance, the F is still the cipher letter X if encoded by looking at the intersection of row F (FLANK) and the column starting with S (SECRETKEY).
When using the Vigenere cipher and the message is longer than the key, the key is repeated. For example, SECRETKEYSECRETKEYSEC is required to encode FLANK EAST ATTACK AT DAWN:
Secret key: SECRE TKEY SECRET KE YSEC
Plaintext: FLANK EAST ATTACK AT DAWN
Cipher text: XPCEO XKUR SXVRGD KX BSAP
Although the Vigenere cipher uses a longer key, it can still be cracked. For this reason, a better cipher method was required.
Gilbert Vernam was an AT&T Bell Labs engineer who, in 1917, invented and patented the stream cipher and later co-invented the one-time pad cipher. Vernam proposed a teletype cipher in which a prepared key consisting of an arbitrarily long, non-repeating sequence of numbers was kept on paper tape. It was then combined character by character with the plaintext message to produce the ciphertext. To decipher the ciphertext, the same paper tape key was again combined character by character, producing the plaintext. Each tape was used only once, hence the name one-time pad. As long as the key tape does not repeat or is not reused, this type of cipher is immune to cryptanalytic attack because the available ciphertext does not display the pattern of the key.
Several difficulties are inherent in using one-time pads in the real world. One difficulty is the challenge of creating random data. Computers, because they have a mathematical foundation, are incapable of creating true random data. Additionally, if the key is used more than once, it is easy to break. RC4 is an example of this type of cipher that is widely used on the Internet. Again, because the key is generated by a computer, it is not truly random. In addition to these issues, key distribution is also challenging with this type of cipher.
As long as there has been cryptography, there has been cryptanalysis. Cryptanalysis is the practice and study of determining the meaning of encrypted information (cracking the code), without access to the shared secret key.
A variety of methods are used in cryptanalysis.
Brute-Force Attack
In a brute-force attack, an attacker tries every possible key with the decryption algorithm knowing that eventually one of them will work. All encryption algorithms are vulnerable to this attack. On average, a brute-force attack succeeds about 50 percent of the way through the keyspace, which is the set of all possible keys. The objective of modern cryptographers is to have a keyspace large enough that it takes too much money and too much time to accomplish a brute-force attack.
Recently, a DES cracking machine was used to recover a 56-bit DES key in 22 hours using brute force. It is estimated that on the same equipment it would take 149 trillion years to crack Advanced Encryption Standard (AES) using the same method.
Ciphertext-Only Attack
In a ciphertext-only attack, the attacker has the ciphertext of several messages, all of which have been encrypted using the same encryption algorithm, but the attacker has no knowledge of the underlying plaintext. The job of the attacker is to recover the ciphertext of as many messages as possible. Even better for the attacker is to deduce the key or keys used to encrypt the messages to decrypt other messages encrypted with the same keys. The attacker could use statistical analysis to deduce the key. These kinds of attacks are no longer practical, because modern algorithms produce pseudorandom output that is resistant to statistical analysis.
Known-Plaintext Attack
In a known-plaintext attack, the attacker has access to the ciphertext of several messages, but also knows something about the plaintext underlying that ciphertext. With knowledge of the underlying protocol, file type, or some characteristic strings that appear in the plaintext, the attacker uses a brute-force attack to try keys until decryption with the correct key produces a meaningful result. This attack might be the most practical attack, because attackers can usually assume some features of the underlying plaintext if they can only capture the ciphertext. Modern algorithms with enormous keyspaces make it unlikely for this attack to succeed because, on average, an attacker must search through at least half of the keyspace to be successful.
Chosen-Plaintext Attack
In a chosen-plaintext attack, the attacker chooses which data the encryption device encrypts and observes the ciphertext output. A chosen-plaintext attack is more powerful than a known-plaintext attack because the chosen plaintext might yield more information about the key. This attack is not very practical because, unless the trusted network has been breached and the attacker already has access to confidential information, it is often difficult or impossible to capture both the ciphertext and plaintext.
Chosen-Ciphertext Attack
In a chosen-ciphertext attack, the attacker can choose different ciphertext to be decrypted and has access to the decrypted plaintext. With the pair, the attacker can search through the keyspace and determine which key decrypts the chosen ciphertext in the captured plaintext. For example, the attacker has access to a tamperproof encryption device with an embedded key. The attacker must deduce the embedded key by sending data through the device. This attack is analogous to the chosen-plaintext attack. Like the chosen-plaintext attack, this attack is not very practical. Unless the trusted network has been breached, and the attacker already has access to confidential information, it is difficult or impossible for the attacker to capture both the ciphertext and plaintext.
Meet-in-the-Middle
The meet-in-the-middle attack is a known plaintext attack. The attacker knows a portion of the plaintext and the corresponding ciphertext. The plaintext is encrypted with every possible key, and the results are stored. The ciphertext is then decrypted using every key, until one of the results matches one of the stored values.
As an example of how to choose the cryptanalysis method, consider the Caesar cipher encrypted code. The best way to crack the code is to use brute force. Because there are only 25 possible rotations, it is not a big effort to try all possible rotations and see which one returns something that makes sense.
A more scientific approach is to use the fact that some characters in the English alphabet are used more often than others. This method is called frequency analysis. For example, the letters E, T, and A are the most popular letters used in the English language. The letters J, Q, X, and Z are the least popular. Understanding this pattern can help discover which letters are probably included in the cipher message.
For example, in the Caesar ciphered message IODQN HDVW DWWDFN DW GDZQ, the cipher letter D appears six times, while the cipher letter W appears four times. There is a good possibility that the cipher letters D and W represent either the plaintext E, T, or A. In this case, the D represents the letter A, and the W represents the letter T.
Cryptology is the science of making and breaking secret codes. Cryptology combines the two separate disciplines of cryptography, which is the development and use of codes, and cryptanalysis, which is the breaking of those codes. There is a symbiotic relationship between the two disciplines, because each makes the other one better. National security organizations employ members of both disciplines and put them to work against each other.
There have been times when one of the disciplines has been ahead of the other. For example, during the Hundred Years War between France and England, the cryptanalysts were ahead of the cryptographers. France believed that the Vigenere cipher was unbreakable; however, the British were able to crack it. Some historians believe that World War II largely turned on the fact that the winning side on both fronts was much more successful than the losing side at cracking the encryption of its adversary. Currently, it is believed that cryptographers have the edge.
Cryptanalysis is often used by governments in military and diplomatic surveillance, by enterprises in testing the strength of security procedures, and by malicious hackers in exploiting weaknesses in websites.
While cryptanalysis is often linked to mischievous purposes, it is actually a necessity. It is an ironic fact of cryptography that it is impossible to prove an algorithm secure. It can only be proven that it is not vulnerable to known cryptanalytic attacks. Therefore, there is a need for mathematicians, scholars, and security forensic experts to keep trying to break the encryption methods.
In the world of communications and networking, authentication, integrity, and data confidentiality are implemented in many ways using various protocols and algorithms. The choice of protocol and algorithm varies based on the level of security required to meet the goals in the network security policy.
For example, for message integrity, message-digest 5 (MD5) is faster but less secure than SHA2. Confidentiality can be implemented using DES, 3DES, or the very secure AES. Again, the choice varies depending on the security requirements specified in the network security policy document.
Old encryption algorithms, such as the Caesar cipher or the Enigma machine, were based on the secrecy of the algorithm to achieve confidentiality. With modern technology, where reverse engineering is often simple, public-domain algorithms are often used. With most modern algorithms, successful decryption requires knowledge of the appropriate cryptographic keys. This means that the security of encryption lies in the secrecy of the keys, not the algorithm. How can the keys be kept secret?
A hash function takes binary data, called the message, and produces a condensed representation, called the message digest. Hashing is based on a one-way mathematical function that is relatively easy to compute, but significantly harder to reverse. Grinding coffee is a good example of a one-way function. It is easy to grind coffee beans, but it is almost impossible to put all of the tiny pieces back together to rebuild the original beans.
The cryptographic hashing function is designed to verify and ensure data integrity. It can also be used to verify authentication. The procedure takes a variable block of data and returns a fixed-length bit string called the hash value or message digest.
Hashing is similar to calculating cyclic redundancy check (CRC) checksums, but it is much stronger cryptographically. For instance, given a CRC value, it is easy to generate data with the same CRC. With hash functions, it is computationally infeasible for two different sets of data to come up with the same hash output. Every time the data is changed or altered, the hash value also changes. Because of this, cryptographic hash values are often called digital fingerprints. They can be used to detect duplicate data files, file version changes, and similar applications. These values are used to guard against an accidental or intentional change to the data and accidental data corruption.
The cryptographic hash function is applied in many different situations:
Mathematically, a hash function (H) is a process that takes an input (x) and returns a fixed-size string, which is called the hash value (h). The formula for the calculation is h = H(x).
A cryptographic hash function should have the following properties:
If a hash function is hard to invert, it is considered a one-way hash. Hard to invert means that given a hash value of h, it is computationally infeasible to find some input, (x), such that H(x) = h.
Hash functions are helpful when ensuring data is not changed accidentally, but they cannot ensure that data is not changed deliberately. For instance, the sender wants to ensure that the message is not altered on its way to the receiver. The sending device inputs the message into a hashing algorithm and computes its fixed-length digest or fingerprint. Both the message and the hash are in plaintext. This fingerprint is then attached to the message and sent to the receiver. The receiving device removes the fingerprint from the message and inputs the message into the same hashing algorithm. If the hash that is computed by the receiving device is equal to the one that is attached to the message, the message has not been altered during transit.
When the message traverses the network, a potential attacker could intercept the message, change it, recalculate the hash, and append it to the message. Hashing only prevents the message from being changed accidentally, such as by a communication error. There is nothing unique to the sender in the hashing procedure, so anyone can compute a hash for any data, as long as they have the correct hash function.
These are two well-known hash functions:
The MD5 algorithm is a hashing algorithm that was developed by Ron Rivest and is used in a variety of Internet applications today.
MD5 is a one-way function that makes it easy to compute a hash from the given input data, but makes it unfeasible to compute input data given only a hash value. MD5 is also collision resistant, which means that two messages with the same hash are very unlikely to occur. MD5 is essentially a complex sequence of simple binary operations, such as exclusive OR (XORs) and rotations, that are performed on input data and produce a 128-bit digest.
The main algorithm is based on a compression function, which operates on blocks. The input is a data block plus a feedback of previous blocks. 512-bit blocks are divided into 16 32-bit sub-blocks. These blocks are then rearranged with simple operations in a main loop, which consists of four rounds. The output of the algorithm is a set of four 32-bit blocks, which concatenate to form a single 128-bit hash value. The message length is also encoded into the digest.
MD5 is based on MD4, an earlier algorithm. MD4 has been broken, and MD5 is now considered less secure than SHA-1 by many authorities on cryptography. These authorities consider MD5 less secure because some noncritical weaknesses have been found in one of the MD5 building blocks.
The U.S. National Institute of Standards and Technology (NIST) developed the Secure Hash Algorithm (SHA), the algorithm that is specified in the Secure Hash Standard (SHS). SHA-1, published in 1994, corrected an unpublished flaw in SHA. Its design is very similar to the MD4 and MD5 hash functions that Ron Rivest developed.
The SHA-1 algorithm takes a message of less than 2^64 bits in length and produces a 160-bit message digest. The algorithm is slightly slower than MD5, but the larger message digest makes it more secure against brute-force collision and inversion attacks.
NIST published four additional hash functions in the SHA family, each with longer digests:
These four versions are collectively known as SHA-2, although the term SHA-2 is not standardized. SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 are the secure hash algorithms required by law for use in certain U.S. government applications, including use within other cryptographic algorithms and protocols, for the protection of sensitive unclassified information.
Both MD5 and SHA-1 are based on MD4. This makes MD5 and SHA-1 similar in many ways. SHA-1 and SHA-2 are more resistant to brute-force attacks because their digest is at least 32 bits longer than the MD5 digest.
SHA-1 involves 80 steps, and MD5 involves 64 steps. The SHA-1 algorithm must also process a 160-bit buffer instead of the 128-bit buffer of MD5. Because there are fewer steps, MD5 usually executes more quickly, given the same device.
When choosing a hashing algorithm, SHA-1 or SHA-2 is preferred over MD5. MD5 has not been proven to contain any critical flaws, but its security is questionable today. If performance is an issue, the MD5 algorithm is slightly faster than the algorithm for SHA-1. Keep in mind that MD5 may prove to be substantially less secure than SHA-1.
Are hashes only used to provide data integrity?
In cryptography, a keyed-hash message authentication code (HMAC or KHMAC) is a type of message authentication code (MAC). An HMAC is calculated using a specific algorithm that combines a cryptographic hash function with a secret key. Hash functions are the basis of the protection mechanism of HMACs.
Only the sender and the receiver know the secret key, and the output of the hash function now depends on the input data and the secret key. Only parties who have access to that secret key can compute the digest of an HMAC function. This characteristic defeats man-in-the-middle attacks and provides authentication of the data origin.
If two parties share a secret key and use HMAC functions for authentication, a properly constructed HMAC digest of a message that a party has received indicates that the other party was the originator of the message, because it is the only other entity possessing the secret key.
The cryptographic strength of the HMAC depends on the cryptographic strength of the underlying hash function, on the size and quality of the key, and the size of the hash output length in bits.
Cisco technologies use two well-known HMAC functions:
When an HMAC digest is created, data of an arbitrary length is input into the hash function, together with a secret key. The result is a fixed-length hash that depends on the data and the secret key.
Care must be taken to distribute secret keys only to the parties who are involved because, if the secret key is compromised, the other party can forge and change packets, violating data integrity.
Consider an example where a sender wants to ensure that the message is not altered in transit, and wants to provide a way for the receiver to authenticate the origin of the message.
The sending device inputs data and the secret key into the hashing algorithm and calculates the fixed-length HMAC digest or fingerprint. This authenticated fingerprint is then attached to the message and sent to the receiver.
The receiving device removes the fingerprint from the message and uses the plaintext message with its secret key as input to the same hashing function. If the fingerprint that is calculated by the receiving device is equal to the fingerprint that was sent, the message has not been altered. Additionally, the origin of the message is authenticated, because only the sender possesses a copy of the shared secret key. The HMAC function has ensured the authenticity of the message.
IPsec virtual private networks (VPNs) rely on HMAC functions to authenticate the origin of every packet and provide data integrity checking.
Cisco products use hashing for entity authentication, data integrity, and data authenticity purposes:
Digital signatures are an alternative to HMAC.
Key management is often considered the most difficult part of designing a cryptosystem. Many cryptosystems have failed because of mistakes in their key management, and all modern cryptographic algorithms require key management procedures. In practice, most attacks on cryptographic systems are aimed at the key management level, rather than at the cryptographic algorithm itself. There are several essential characteristics of key management to consider:
Two terms that are used to describe keys are key length and keyspace. The key length is the measure in bits, and the keyspace is the number of possibilities that can be generated by a specific key length. As key lengths increase, the keyspace increases exponentially:
The keyspace of an algorithm is the set of all possible key values. A key that has n bits produces a keyspace that has 2^n possible key values. By adding one bit to the key, the keyspace is effectively doubled. For example, DES with its 56-bit keys has a keyspace of more than 72,000,000,000,000,000 (2^56) possible keys. By adding one bit to the key length, the keyspace doubles, and an attacker needs twice the amount of time to search the keyspace.
Almost every algorithm has some weak keys in its keyspace that enable an attacker to break the encryption via a shortcut. Weak keys show regularities in encryption or poor encryption. For instance, DES has four keys for which encryption is the same as decryption. This means that if one of these weak keys is used to encrypt plaintext, an attacker can use the weak key to encrypt the ciphertext and reveal the plaintext.
The DES weak keys are those that produce 16 identical subkeys. This occurs when the key bits are:
It is very unlikely that such keys would be chosen, but implementations should still verify all keys and prevent weak keys from being used. With manual key generation, take special care to avoid defining weak keys.
Several types of cryptographic keys can be generated:
Regardless of the type of key, all keys share similar issues. Choosing a suitable key length is one issue. If the cryptographic system is trustworthy, the only way to break it is with a brute-force attack. A brute-force attack is a search through the entire keyspace, trying all the possible keys to find a key that decrypts the data. If the keyspace is large enough, the search requires an enormous amount of time, making such an exhaustive effort impractical.
On average, an attacker has to search through half of the keyspace before the correct key is found. The time that is needed to accomplish this search depends on the computer power that is available to the attacker. Current key lengths can easily make any attempt insignificant, because it takes millions or billions of years to complete the search when a sufficiently long key is used. With modern algorithms that are trusted, the strength of protection depends solely on the length of the key. Choose the key length so that it protects data confidentiality or integrity for an adequate period of time. Data that is more sensitive and needs to be kept secret longer must use longer keys.
Performance is another issue that can influence the choice of a key length. An administrator must find a good balance between the speed and protective strength of an algorithm, because some algorithms, such as the Rivest, Shamir, and Adleman (RSA) algorithm, run slowly because of large key sizes. Strive for adequate protection, while enabling unhindered communication over untrusted networks.
The estimated funding of the attacker should also affect the choice of key length. When assessing the risk of someone breaking the encryption algorithm, estimate the resources of the attacker and how long the data must be protected. For example, classic DES can be broken by a $1 million machine in a couple of minutes. If the data that is being protected is worth significantly more than $1 million dollars needed to acquire a cracking device, then, classic DES is a bad choice. It would take an attacker a million years or more to crack 168-bit 3DES or 128-bit RC4, which makes either of these key length choices more than adequate.
Because of the rapid advances in technology and cryptanalytic methods, the key size that is needed for a particular application is constantly increasing. For example, part of the strength of the RSA algorithm is the difficulty of factoring large numbers. If a 1024-bit number is hard to factor, a 2048-bit number is going to be even harder. Even with the fastest computers available today, it would take many lifetimes to factor a 1024-bit number that is a factor of two 512-bit prime numbers. Of course, this advantage is lost if an easy way to factor large numbers is found, but cryptographers consider this possibility unlikely. The rule "the longer the key, the better" is valid, except for possible performance reasons.
Cryptographic encryption can provide confidentiality at several layers of the OSI model by incorporating various tools and protocols:
There are two approaches to ensuring the security of data when using various encryption methods. The first is to protect the algorithm. If the security of an encryption system is based on the secrecy of the algorithm itself, the algorithm code must be heavily guarded. If the algorithm is revealed, every party that is involved must change the algorithm. The second approach is to protect the keys. With modern cryptography, all algorithms are public. The cryptographic keys ensure the secrecy of the data. Cryptographic keys are sequences of bits that are input into an encryption algorithm together with the data to be encrypted.
Two basic classes of encryption algorithms protect the keys: symmetric and asymmetric. Each differs in its use of keys. Symmetric encryption algorithms use the same key, sometimes called a secret key, to encrypt and decrypt data. The key must be pre-shared. A pre-shared key is known by the sender and receiver before any encrypted communications commence. Because both parties are guarding a shared secret, the encryption algorithms used can have shorter key lengths. Shorter key lengths mean faster execution. Symmetric algorithms are generally much less computationally intensive than asymmetric algorithms.
Asymmetric encryption algorithms use different keys to encrypt and decrypt data. Secure messages can be exchanged without having to have a pre-shared key. Because both parties do not have a shared secret, very long key lengths must be used to thwart attackers. These algorithms are resource intensive and slower to execute. In practice, asymmetric algorithms are typically hundreds to thousands times slower than symmetric algorithms.
To help understand the differences between both types of algorithms, consider an example where Alice and Bob live in different locations and want to exchange secret messages to one another through the mail system. In this example, Alice wants to send a secret message to Bob.
Symmetric Algorithm
In the symmetric algorithm example, Alice and Bob have identical keys to a single padlock. These keys were exchanged prior to sending any secret messages. Alice writes a secret message and puts it in a small box that she locks using the padlock with her key. She mails the box to Bob. The message is safely locked inside the box as the box makes its way through the post office system. When Bob receives the box, he uses his key to unlock the padlock and retrieve the message. Bob can use the same box and padlock to send a secret reply back to Alice.
Asymmetric Algorithm
In the asymmetric algorithm example, Bob and Alice do not exchange keys prior to sending secret messages. Instead, Bob and Alice each have a separate padlock with separate corresponding keys. For Alice to send a secret message to Bob, she must first contact him and ask him to send his open padlock to her. Bob sends the padlock but keeps his key. When Alice receives the padlock, she writes her secret message and puts it in a small box. She also puts her open padlock in the box, but keeps her key. She then locks the box with Bob's padlock. When Alice locks the box, she is no longer able to get inside because she does not have a key to that padlock. She mails the box to Bob. As the box is sent through the mail system, no one is able to open the box. When Bob receives the box, he can use his key to unlock the box and retrieve the message from Alice. To send a secure reply, Bob puts his secret message in the box along with his open padlock and locks the box using Alice's padlock. Bob mails the secured box back to Alice.
Symmetric, or secret key, encryption is the most commonly used form of cryptography, because the shorter key length increases the speed of execution. Additionally, symmetric key algorithms are based on simple mathematical operations that can easily be accelerated by hardware. Symmetric encryption is often used for wire-speed encryption in data networks and to provide bulk encryption when data privacy is required, such as to protect a VPN.
With symmetric encryption, key management can be a challenge. The encryption and decryption keys are the same. The sender and the receiver must exchange the symmetric, secret key using a secure channel before any encryption can occur. The security of a symmetric algorithm rests in the secrecy of the symmetric key. By obtaining the key, anyone can encrypt and decrypt messages.
DES, 3DES, AES, Software Encryption Algorithm (SEAL), and the Rivest ciphers (RC) series, which includes RC2, RC4, RC5, and RC6, are all well-known encryption algorithms that use symmetric keys. There are many other encryption algorithms, such as Blowfish, Twofish, Threefish, and Serpent. However, these protocols are either not supported on Cisco platforms or have yet to gain wide acceptance.
The most commonly used techniques in symmetric encryption cryptography are block ciphers and stream ciphers.
Block Ciphers
Block ciphers transform a fixed-length block of plaintext into a common block of ciphertext of 64 or 128 bits. Block size refers to how much data is encrypted at any one time. Currently the block size, also known as the fixed length, for many block ciphers is either 64 bits or 128 bits. The key length refers to the size of the encryption key that is used. This ciphertext is decrypted by applying the reverse transformation to the ciphertext block, using the same secret key.
Block ciphers usually result in output data that is larger than the input data, because the ciphertext must be a multiple of the block size. For example, DES encrypts blocks in 64-bit chunks using a 56-bit key. To accomplish this, the block algorithm takes data one chunk at a time, for example, 8 bytes each chunk, until the entire block size is full. If there is less input data than one full block, the algorithm adds artificial data (blanks) until the full 64 bits are used.
Common block ciphers include DES with a 64-bit block size, AES with a 128-bit block size, and RSA with a variable block size.
Stream Ciphers
Unlike block ciphers, stream ciphers encrypt plaintext one byte or one bit at a time. Stream ciphers can be thought of as a block cipher with a block size of one bit. With a stream cipher, the transformation of these smaller plaintext units varies, depending on when they are encountered during the encryption process. Stream ciphers can be much faster than block ciphers, and generally do not increase the message size, because they can encrypt an arbitrary number of bits.
The Vigenere cipher is an example of a stream cipher. This cipher is periodic, because the key is of finite length, and the key is repeated if it is shorter than the message.
Common stream ciphers include A5, which is used to encrypt GSM cell phone communications, and the RC4 cipher. DES can also be used in stream cipher mode.
Choosing an encryption algorithm is one of the most important decisions a security professional makes when building a cryptosystem. Two main criteria should be considered when selecting an encryption algorithm for an organization:
Other criteria to consider:
Data Encryption Standard (DES) is a symmetric encryption algorithm that usually operates in block mode. It encrypts data in 64-bit blocks. The DES algorithm is essentially a sequence of permutations and substitutions of data bits combined with an encryption key. The same algorithm and key are used for both encryption and decryption.
DES has a fixed key length. The key is 64-bits long, but only 56 bits are used for encryption. The remaining 8 bits are used for parity. The least significant bit of each key byte is used to indicate odd parity.
A DES key is always 56 bits long. When DES is used with a weaker encryption of a 40-bit key, the encryption key is 40 secret bits and 16 known bits, which make the key length 56 bits. In this case, DES has a key strength of 40 bits.
Although DES typically uses block cipher mode, it can also encrypt using stream cipher mode. To encrypt or decrypt more than 64 bits of data, DES uses two standardized block cipher modes, Electronic Code Book (ECB) or Cipher Block Chaining (CBC).
Both cipher modes use the logical operation XOR with the following definition:
1 XOR 1 = 0
1 XOR 0 = 1
0 XOR 1 = 1
0 XOR 0 = 0
Block Cipher Mode
ECB mode serially encrypts each 64-bit plaintext block using the same 56-bit key. If two identical plaintext blocks are encrypted using the same key, their ciphertext blocks are the same. Therefore, an attacker could identify similar or identical traffic flowing through a communications channel. The attacker could then, without even knowing the meaning behind the traffic, build a catalog of messages and replay them later to possibly gain unauthorized entry. For example, an attacker might unknowingly capture a login sequence of someone with administrative privilege whose traffic is protected by DES-ECB and then replay it. That risk is undesirable, so CBC mode was invented to mitigate this risk.
In CBC mode, each 64-bit plaintext block is exclusive ORed (XORed) bitwise with the previous ciphertext block and then is encrypted using the DES key. The encryption of each block depends on previous blocks. Encryption of the same 64-bit plaintext block can result in different ciphertext blocks.
CBC mode can help guard against certain attacks, but it cannot help against sophisticated cryptanalysis or an extended brute-force attack.
Stream Cipher Mode
To encrypt or decrypt more than 64 bits of data, DES uses two common stream cipher modes:
In stream cipher mode, the cipher uses previous ciphertext and the secret key to generate a pseudo-random stream of bits, which only the secret key can generate. To encrypt data, the data is XORed with the pseudo-random stream bit by bit, or sometimes byte by byte, to obtain the ciphertext. The decryption procedure is the same. The receiver generates the same random stream using the secret key, and XORs the ciphertext with the pseudo-random stream to obtain the plaintext.
There are several things to consider when securing DES-encrypted data:
Because of its short key length, DES is considered a good protocol to protect data for a very short time. 3DES is a better choice to protect data. It has an algorithm that is very trusted and has higher security strength.
With advances in computer-processing power, the original 56-bit DES key became too short to withstand attack from those with a medium-sized budget for hacking technology. One way to increase the DES effective key length, without changing the well-analyzed algorithm itself, is to use the same algorithm with different keys several times in a row.
The technique of applying DES three times in a row to a plaintext block is called 3DES. Today, brute-force attacks on 3DES are considered unfeasible because the basic algorithm has been well tested in the field for more than 35 years. It is considered very trustworthy.
The Cisco IPsec implementation uses DES and 3DES in CBC mode.
3DES uses a method called 3DES-Encrypt-Decrypt-Encrypt (3DES-EDE) to encrypt plaintext. First, the message is encrypted using the first 56-bit key, known as K1. Next, the data is decrypted using the second 56-bit key, known as K2. Finally, the data is encrypted again, using the third 56-bit key, known as K3.
The 3DES-EDE procedure is much more effective at increasing security than simply encrypting the data three times with three different keys. Encrypting data three times in a row using different 56-bit keys equals a 58-bit key strength. The 3DES-EDE procedure, on the other hand, provides encryption with an effective key length of 168 bits. If keys K1 and K3 are equal, as in some implementations, a less secure encryption of 112 bits is achieved.
To decrypt the message, the opposite of the 3DES-EDE method is used. First, the ciphertext is decrypted using key K3. Next, the data is encrypted the data using key K2. Finally, the data is decrypted the data using key K1.
Although 3DES is very secure, it is also very resource intensive. For this reason, the AES encryption algorithm was developed. It has proven to be as secure as 3DES, but with much faster results.
For a number of years, it was recognized that DES would eventually reach the end of its usefulness. In 1997, the AES initiative was announced, and the public was invited to propose encryption schemes to replace DES. After a five-year standardization process in which 15 competing designs were presented and evaluated, the U.S. National Institute of Standards and Technology (NIST) selected the Rijndael block cipher as the AES algorithm.
The Rijndael cipher, developed by Joan Daemen and Vincent Rijmen, has a variable block length and key length. Rijndael is an iterated block cipher, which means that the initial input block and cipher key undergo multiple transformation cycles before producing output. The algorithm can operate over a variable-length block using variable-length keys. A 128-, 192-, or 256-bit key can be used to encrypt data blocks that are 128, 192, or 256 bits long, and all nine combinations of key and block length are possible.
The accepted AES implementation of Rijndael contains only some of the capabilities of the Rijndael algorithm. The algorithm is written so that the block length or the key length or both can easily be extended in multiples of 32 bits, and the system is specifically designed for efficient implementation in hardware or software on a range of processors.
The AES algorithm has been analyzed extensively and is now used worldwide. Although it has not been proven in day-to-day use to the degree that 3DES has, AES with the Rijndael cipher is the more efficient algorithm. It can be used in high-throughput, low-latency environments, especially when 3DES cannot handle the throughput or latency requirements. AES is expected to gain trust as time passes and more attacks have been attempted against it.
AES was chosen to replace DES for a number of reasons. The key length of AES makes the key much stronger than DES. AES runs faster than 3DES on comparable hardware. AES is more efficient than DES and 3DES on comparable hardware, usually by a factor of five when it is compared with DES. AES is more suitable for high-throughput, low-latency environments, especially if pure software encryption is used.
Despite these advantages, AES is a relatively young algorithm. The golden rule of cryptography states that a mature algorithm is always more trusted. 3DES is therefore a more trusted choice in terms of strength, because it has been tested and analyzed for 35 years.
AES is available in the following Cisco VPN devices as an encryption transform:
The Software-optimized Encryption Algorithm (SEAL) is an alternative algorithm to software-based DES, 3DES, and AES. Phillip Rogaway and Don Coppersmith designed SEAL in 1993. It is a stream cipher that uses a 160-bit encryption key. Because it is a stream cipher, data to be encrypted is continuously encrypted and, therefore, much faster than block ciphers. However, it has a longer initialization phase during which a large set of tables is created using SHA.
SEAL has a lower impact on the CPU compared to other software-based algorithms. SEAL support was added to Cisco IOS Software Release 12.3(7)T.
SEAL has several restrictions:
The RC algorithms were designed all or in part by Ronald Rivest, who also invented MD5. The RC algorithms are widely deployed in many networking applications because of their favorable speed and variable key-length capabilities.
There are a number of widely used RC algorithms:
Whitfield Diffie and Martin Hellman invented the Diffie-Hellman (DH) algorithm in 1976. The DH algorithm is the basis of most modern automatic key exchange methods and is one of the most common protocols used in networking today. Diffie-Hellman is not an encryption mechanism and is not typically used to encrypt data. Instead, it is a method to securely exchange the keys that encrypt data.
In a symmetric key system, both sides of the communication must have identical keys. Securely exchanging those keys has always been a challenge. Asymmetric key systems address this challenge because they use two keys. One key is called the private key, and the other is the public key. The private key is secret and known only to the user. The public key is openly shared and easily distributed.
DH is a mathematical algorithm that allows two computers to generate an identical shared secret on both systems, without having communicated before. The new shared key is never actually exchanged between the sender and receiver. But because both parties know it, it can be used by an encryption algorithm to encrypt traffic between the two systems. Its security is based on the difficulty of calculating the discrete logarithms of very large numbers.
DH is commonly used when data is exchanged using an IPsec VPN, data is encrypted on the Internet using either SSL or TLS, or when SSH data is exchanged.
Unfortunately, asymmetric key systems are extremely slow for any sort of bulk encryption. This is why it is common to encrypt the bulk of the traffic using a symmetric algorithm such as DES, 3DES, or AES and use the DH algorithm to create keys that will be used by the encryption algorithm.
To help understand how DH is used, consider this example of communication between Alice and Bob.
1. To start a DH exchange, Alice and Bob must agree on two non-secret numbers. The first number, g, is a base number (also called the generator). The second number, p, is a prime number that is used as the modulus. These numbers are usually public and are chosen from a table of known values. Typically, g is a very small number, such as 2, 3, 4, or 5 and p is a larger prime number.
2. Next, Alice generates a secret number Xa, and Bob generates his secret number Xb.
3. Based on g, p, and Alice's X number, Alice calculates a public value (Ya) using the DH algorithm. She sends her public value (Ya) to Bob.
4. Bob also calculates a public value (Yb) using g, p and his secret number. Bob sends his public value (Yb) to Alice. These values are not the same.
5. Alice now performs a second DH algorithm using Bob's public value (Yb) as the new base number.
6. Bob also performs a second DH algorithm using Alice's public value (Ya) as the new base number.
The result is that Alice and Bob both come up with the same result (Z). This new value is now a shared secret between Alice and Bob and can be used by an encryption algorithm as a shared secret key between Alice and Bob.
Anyone listening on the channel cannot compute the secret value, because only g, p, Ya, and Yb are known, and at least one secret value is needed to calculate the shared secret. Unless the attackers can compute the discrete algorithm of the above equation to recover Xa or Xb, they cannot obtain the shared secret.
Although DH is used with symmetric algorithms to create shared keys, it is important to remember that it is actually an asymmetric algorithm.
What other asymmetric algorithms are there and what are they used for?
Asymmetric algorithms, also sometimes called public-key algorithms, are designed so that the key that is used for encryption is different from the key that is used for decryption. The decryption key cannot, in any reasonable amount of time, be calculated from the encryption key and vice versa.
In the example of Alice and Bob, they did not exchange pre-shared keys prior to communication. Instead, they each had separate padlocks and corresponding keys. In this same manner, asymmetric algorithms are used to exchange secret messages without ever having had a shared secret before the exchange.
There are four protocols that use asymmetric key algorithms:
Asymmetric algorithms use two keys: a public key and a private key. Both keys are capable of the encryption process, but the complementary matched key is required for decryption. For example, if a public key encrypts the data, the matching private key decrypts the data. The opposite is also true. If a private key encrypts the data, the corresponding public key decrypts the data.
This process enables asymmetric algorithms to achieve authentication, integrity, and confidentiality.
The confidentiality objective of asymmetric algorithms is achieved when the encryption process is started with the public key. The process can be summarized using the formula:
Public Key (Encrypt) + Private Key (Decrypt) = Confidentiality
When the public key is used to encrypt the data, the private key must be used to decrypt the data. Only one host has the private key, therefore, confidentiality is achieved.
If the private key is compromised, another key pair must be generated to replace the compromised key.
The authentication objective of asymmetric algorithms is achieved when the encryption process is started with the private key. The process can be summarized using the formula:
Private Key (Encrypt) + Public Key (Decrypt) = Authentication
When the private key is used to encrypt the data, the corresponding public key must be used to decrypt the data. Because only one host has the private key, only that host could have encrypted the message, providing authentication of the sender. Typically, no attempt is made to preserve the secrecy of the public key, so any number of hosts can decrypt the message. When a host successfully decrypts a message using a public key, it is trusted that the private key encrypted the message, which verifies who the sender is. This is a form of authentication.
When sending a message that ensures message confidentiality, authentication and integrity, the combination of two encryption phases is necessary.
Phase 1 - Confidentiality
Alice wants to send a message to Bob ensuring message confidentiality (only Bob can read the document in plaintext). Alice uses the public key of Bob to cipher the message. Only Bob can decipher it, using his private key.
Phase 2 - Authentication and Integrity
Alice also wants to ensure message authentication and integrity (Bob is sure that the document was not modified, and was sent by Alice). Alice uses her private key to cipher a hash of the message. In this way, Bob can use the public key of Alice to verify that the message was not modified (the received hash is equal to the locally determined hash based on Alice's public key). Additionally, this verifies that Alice is definitely the sender of the message because nobody else has Alice's private key.
By sending a message that was ciphered using Bob's public key and a ciphered hash that was encrypted using Alice's private key, confidentiality, authenticity and integrity are ensured.
A variety of well-known asymmetric key algorithms are available:
Although the mathematics differ with each algorithm, they all share one trait in that the calculations required are complicated. Their design is based on computational problems, such as factoring extremely large numbers or computing discrete logarithms of extremely large numbers. As a result, computation takes more time for asymmetric algorithms. In fact, asymmetric algorithms can be up to 1,000 times slower than symmetric algorithms. Because they lack speed, asymmetric algorithms are typically used in low-volume cryptographic mechanisms, such as key exchanges that have no inherent key exchange technology, and digital signatures.
The key management of asymmetric algorithms tends to be simpler than that of symmetric algorithms, because usually one of the two encryption or decryption keys can be made public.
Typical key lengths for asymmetric algorithms range from 512 to 4096 bits. Key lengths greater than or equal to 1024 are considered to be trustworthy, while key lengths that are shorter than 1024 bits are considered unreliable for most algorithms.
It is not relevant to compare the key length of asymmetric and symmetric algorithms because the underlying design of the two algorithm families differs greatly. To illustrate this point, it is generally thought that a 2048-bit encryption key of RSA is roughly equivalent to a 128-bit key of RC4 in terms of resistance against brute-force attacks.
Handwritten signatures have long been used as a proof of authorship of the contents of a document. Digital signatures can provide the same functionality as handwritten signatures, and much more. For example, assume a customer sends transaction instructions via an email to a stockbroker, and the transaction turns out badly for the customer. It is conceivable that the customer could claim never to have sent the transaction order or that someone forged the email.
The brokerage could protect itself by requiring the use of digital signatures before accepting instructions via email. In fact, digital signatures are often used in the following situations:
Specifically, digital signatures provide three basic security services:
To better understand nonrepudiation, consider using HMAC functions, which also provide authenticity and integrity guarantees. With HMAC functions, two or more parties share the same authentication key and can compute the HMAC fingerprint. Therefore, taking received data and its HMAC fingerprint to a third party does not prove that the other party sent this data. Other users could have generated the same HMAC fingerprint, because they have a copy of the HMAC authentication key. With digital signatures, each party has a unique, secret signature key, which is not shared with any other party, making nonrepudiation possible.
Digital signatures have specific properties that enable entity authentication and data integrity:
In some countries, including the United States, digital signatures are considered equivalent to handwritten signatures if they meet certain provisions. Some of these provisions include the proper protection of the certificate authority, the trusted signer of all other public keys, and the proper protection of the private keys of the users. In such a scenario, users are responsible for keeping their private keys private, because a stolen private key can be used to steal their identity.
Many Cisco products use digital signatures:
The current signing procedures of digital signatures are not simply implemented by public-key operations. In fact, a modern digital signature is based on a hash function and a public-key algorithm.
There are six steps to the digital signature process:
1. The sending device (signer) creates a hash of the document.
2. The sending device encrypts the hash with the private key of the signer.
3. The encrypted hash, known as the signature, is appended to the document.
4. The receiving device (verifier) accepts the document with the digital signature and obtains the public key of the sending device.
5. The receiving device decrypts the signature using the public key of the sending device. This step unveils the assumed hash value of the sending device.
6. The receiving device makes a hash of the received document, without its signature, and compares this hash to the decrypted signature hash. If the hashes match, the document is authentic; it was signed by the assumed signer and has not changed since it was signed.
Both encryption and digital signatures are required to ensure that the message is private and has not changed.
In addition to ensuring authenticity and integrity of messages, digital signatures are commonly used to provide assurance of the authenticity and integrity of mobile and classic software codes. The executable files, or possibly the entire installation package of a program, are wrapped with a digitally signed envelope, which allows the end user to verify the signature before installing the software.
Digitally signing code provides several assurances about the code:
The digital signature could be forged only if someone obtained the private key of the publisher. The assurance level of digital signatures is extremely high if the private key is protected properly.
The user of the software must also obtain the public key, which is used to verify the signature. The user can obtain the key in a secure fashion. For example, the key could be included with the installation of the operating system or transferred securely over the network.
Protecting the private key is of the highest importance when using digital signatures. If the signature key of an entity is compromised, the attacker can sign data in the name of that entity, and repudiation is not possible. To exchange verification keys in a scalable fashion, a secure but accessible method must be deployed.
Well-known asymmetric algorithms, such as RSA or Digital Signature Algorithm (DSA), are typically used to perform digital signing.
DSA
In 1994, the U.S. NIST selected the DSA as the Digital Signature Standard (DSS). DSA is based on the discrete logarithm problem and can only provide digital signatures.
DSA, however, has had several criticisms. Critics claim that DSA lacks the flexibility of RSA. The verification of signatures is too slow, and the process by which NIST chose DSA was too secretive and arbitrary. In response to these criticisms, the DSS now incorporates two additional algorithm choices: Digital Signature Using Reversible Public Key Cryptography (which uses RSA) and the Elliptic Curve Digital Signature Algorithm (ECDSA).
A network administrator must decide whether RSA or DSA is more appropriate for a given situation. DSA signature generation is faster than DSA signature verification. On the other hand, RSA signature verification is much faster than signature generation.
RSA is one of the most common asymmetric algorithms. Ron Rivest, Adi Shamir, and Len Adleman invented the RSA algorithm in 1977. It was a patented public-key algorithm. The patent expired in September 2000, and the algorithm is now in the public domain. Of all the public-key algorithms that were proposed over the years, RSA is by far the easiest to understand and implement.
The RSA algorithm is very flexible because it has a variable key length, so the key can be shortened for faster processing. There is a tradeoff; the shorter the key, the less secure it is.
The RSA keys are usually 512 to 2048 bits long. RSA has withstood years of extensive cryptanalysis. Although the security of RSA has been neither proved nor disproved, it does suggest a confidence level in the algorithm. The security of RSA is based on the difficulty of factoring very large numbers. If an easy method of factoring these large numbers were discovered, the effectiveness of RSA would be destroyed.
The RSA algorithm is based on a public key and a private key. The public key can be published and given away, but the private key must be kept secret. It is not possible to determine the private key from the public key using any computationally feasible algorithm and vice versa.
RSA keys are long term and are usually changed or renewed after some months or even years. It is currently the most common method for signature generation and is used widely in e-commerce systems and Internet protocols.
RSA is about a hundred times slower than DES in hardware, and about a thousand times slower than DES in software. This performance problem is the main reason that RSA is typically used only to protect small amounts of data.
RSA is mainly used to ensure confidentiality of data by performing encryption, and to perform authentication of data or nonrepudiation of data, or both, by generating digital signatures.
In large organizations, it is impractical for all parties to continually exchange identification documents. With trusted third-party protocols, all individuals agree to accept the word of a neutral third party. Presumably, the third party does an in-depth investigation prior to the issuance of credentials. After this in-depth investigation, the third party issues credentials that are difficult to forge. From that point forward, all individuals who trust the third party simply accept the credentials that the third party issues. Certificate servers are an example of a trusted third party.
As an example, a large organization such as Cisco goes to reasonable lengths to identify employees and contractors, and then issues an ID badge. This badge is relatively difficult to forge. Measures are in place to protect the integrity of the badge and the badge issuance. Because of these measures, all Cisco personnel accept this badge as authoritative of the identity of any individual.
If this method did not exist and 10 individuals needed to validate each other, 90 validations would need to be performed before everyone would have validated everyone else. Adding a single individual to the group would require an additional 20 validations because each one of the original 10 individuals would need to authenticate the new individual, and the new individual would need to authenticate the original 10. This method does not scale well.
For another example, assume that Alice applies for a driver's license. In this process, she submits evidence of her identity and her qualifications to drive. Her application is approved, and a license is issued. Later, Alice needs to cash a check at the bank. Upon presenting the check to the bank teller, the bank teller asks her for ID. The bank, because it trusts the government agency that issued the driver's license, verifies her identity and cashes her check.
Certificate servers function like the driver's license bureau. The driver's license is analogous to a certificate in a Public Key Infrastructure (PKI) or another technology that supports certificates.
How does PKI actually work?
PKI is the service framework that is needed to support large-scale public key-based technologies. A PKI allows for very scalable solutions and is becoming an extremely important authentication solution for VPNs.
PKI is a set of technical, organizational, and legal components that are needed to establish a system that enables large-scale use of public key cryptography to provide authenticity, confidentiality, integrity, and nonrepudiation services. The PKI framework consists of the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates.
Two very important terms must be defined when talking about a PKI: certificates and Certificate authority (CA).
Certificates are used for various purposes in a network. Certificates are public information. They contain the binding between the names and public keys of entities and are usually published in a centralized directory so that other PKI users can easily access them.
The CA is a trusted third-party entity that issues certificates. The certificate of a user is always signed by a CA. Every CA also has a certificate containing its public key, signed by itself. This is called a CA certificate or, more properly, a self-signed CA certificate.
A single CA server can facilitate many applications that require digital certificates for authentication purposes. Using CA servers is a solution that simplifies the management of authentication and provides strong security due to the strength of the cryptographic mechanisms that are used in combination with digital certificates.
PKI is more than just a CA and its users. In addition to implementing the enabling technology, building a large PKI involves a huge amount of organizational and legal work. There are five main components of a PKI:
Many vendors offer CA servers as a managed service or as an end-user product, including VeriSign, Entrust Technologies, RSA, CyberTrust, Microsoft, and Novell. CAs, especially outsourced ones, can issue certificates of a number of classes, which determine how trusted a certificate is. A single outsourcing vendor such as VeriSign might run a single CA, issuing certificates of different classes, and its customers use the CA they need depending on the desired level of trust.
A certificate class is usually identified by a number. The higher the number, the more trusted the certificate. The trust in the certificate is usually determined by how rigorous the procedure was that verified the identity of the holder when the certificate was issued:
For example, a class 1 certificate might require an email reply from the holder to confirm the wish to enroll. This kind of confirmation is a weak authentication of the holder. For a class 3 or 4 certificate, the future holder must prove identity and authenticate the public key by showing up in person with at least two official ID documents.
Some PKIs offer the possibility, or even require the use, of two key pairs per entity. The first public and private key pair is intended only for encryption operations. The public key encrypts, and the private key decrypts. The second public and private key pair is intended for digital signing operations. The private key signs, and the public key verifies the signature.
These keys are sometimes called usage or special keys. They may differ in key length and even in the choice of the public key algorithm. If the PKI requires two key pairs per entity, a user has two certificates. An encryption certificate contains the public key of the user, which encrypts the data, and a signature certificate contains the public key of the user, which verifies the digital signature of the user.
The following scenarios typically employ usage keys:
Standardization and interoperability of different PKI vendors is still an issue when interconnecting PKIs. Interoperability between a PKI and its supporting services, such as Lightweight Directory Access Protocol (LDAP) and X.500 directories, is a concern because many vendors have proposed and implemented proprietary solutions instead of waiting for standards to develop. The state of interoperability is very basic, even after 10 years of PKI software development.
To address this interoperability concern, the IETF formed the Public-Key Infrastructure X.509 (PKIX) workgroup, that is dedicated to promoting and standardizing PKI in the Internet. This workgroup has published a draft set of standards, X.509, detailing common data formats and PKI-related protocols in a network.
X.509 is a well-known standard that defines basic PKI formats such as the certificate and certificate revocation list (CRL) format to enable basic interoperability. The standard has been widely used for years with many Internet applications, such as SSL and IPsec.
The X.509 version 3 (X.509v3) standard defines the format of a digital certificate. Certificates were traditionally used at the Application Layer to provide strong authentication for applications. Each application can have a different implementation of the actual authentication process, but they all use a similar type of certificate in the X.509 format.
This format is already extensively used in the infrastructure of the Internet:
Certificates are also used at the Network Layer or Application Layer by network devices. Cisco routers, Cisco VPN concentrators, and Cisco PIX firewalls can use certificates to authenticate IPsec peers.
Cisco switches can use certificates to authenticate end devices connecting to LAN ports. Authentication uses 802.1X between the adjacent devices. The authentication can be proxied to a central ACS via the Extensible Authentication Protocol with TLS (EAP-TLS).
Cisco routers can also provide TN3270 support that does not include encryption or strong authentication. Cisco routers can now use SSL to establish secure TN3270 sessions.
Another important PKI standard is the Public-Key Cryptography Standards (PKCS). PKCS refers to a group of Public Key Cryptography Standards devised and published by RSA Laboratories. PKCS provides basic interoperability of applications that use public-key cryptography. PKCS defines the low-level formats for the secure exchange of arbitrary data, such as an encrypted piece of data or a signed piece of data.
As the RSA Laboratories website states, "The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide for the purpose of accelerating the deployment of public-key cryptography."
Public key technology is increasingly deployed and becoming the basis for standards-based security, such as the IPsec and IKE protocols. With the use of public key certificates in network security protocols comes the need for a certificate management protocol for PKI clients and CA servers. These clients and servers can support certificate lifecycle operations, such as certificate enrollment and revocation and certificate and CRL access.
For example, an end entity starts an enrollment transaction by creating a certificate request using PKCS #10 (certification request syntax standard) and sends it to the CA that is enveloped using the PKCS #7(cryptographic message syntax standard). After the CA receives the request, it can perform one of three functions:
The end goal is that any network user should be able to request a digital certificate easily and electronically. Previously, these processes required intensive input from network administrators and were not suited to large scale deployments. The IETF designed the Simple Certificate Enrollment Protocol (SCEP) to make issuing and revocation of digital certificates as scalable as possible. The goal of SCEP is to support the secure issuance of certificates to network devices in a scalable manner using existing technology whenever possible.
SCEP is now being referenced by network equipment manufacturers and software companies who are developing simplified means of handling certificates for large-scale implementation to everyday users.
PKIs can form different topologies of trust, including single-root PKI topologies, hierarchical CA topologies, and cross-certified CA topologies.
Single-root PKI Topology
In the single-root PKI model, a single CA, which is also known as the root CA, issues all the certificates to the end users. The benefit is simplicity. There are also disadvantages:
Because of its simplicity, VPNs that are managed by a single organization often use this topology.
Hierarchical CA Topology
Going beyond the single-root CA, more complex topologies involve multiple CAs within the same organization. In the hierarchical CA topology, CAs can issue certificates to end users and to subordinate CAs, which in turn issue their certificates to end users, other CAs, or both. In this way, a tree of CAs and end users is built in which every CA can issue certificates to lower level CAs and end users.
The main benefits of a hierarchical PKI topology are increased scalability and manageability. Trust decisions can now be hierarchically distributed to smaller branches. This distribution works well in most large organizations. For example, a large company might have a root CA, which issues certificates to level-2 CAs. These level-2 CAs issue the certificates to the end users. Because the root-signing key is seldom used after the subordinate CA certificates are issued, the root-signing key is less exposed and therefore much more trusted. Additionally, if a subordinate CA has its private key stolen, only a branch of the PKI is rendered untrusted.
One issue with hierarchical PKI topologies lies in finding the certification path for a certificate. It can be difficult to determine the chain of the signing process. This task increases in difficulty as more CAs are placed between the root CA and the end user.
Cross-certified CA Topology
Another approach to hierarchical PKIs is called a cross-certified CA or cross-certifying. In this approach, multiple, flat, single-root CAs establish trust relationships horizontally by cross-certifying their own CA certificates.
As PKIs are hierarchical in nature, the issuing certificate authority may be a root CA (the top-level CA in the hierarchy) or a subordinate CA. The PKI might employ additional hosts, called registration authorities (RAs) to accept requests for enrollment in the PKI. RAs are employed to reduce the burden on CAs in an environment that supports a large number of certificate transactions or where the CA is offline.
In a more complex environment, the RA might be tasked with verifying user identity, establishing passwords for certificate management transactions, submitting enrollment requests along with appropriate organizational attributes or other information to the CA, and handling assorted tasks such as certificate revocation and re-enrollment.
Usually, these tasks are offloaded to the RA:
It is important to note that the RA only has the power to accept registration requests and forward them to the CA. It is not allowed to issue certificates or publish CRLs. The CA is responsible for these functions.
How are certificates retrieved, enrolled, and used in authentication?
In the CA authentication procedure, the first step of the user when contacting the PKI is to securely obtain a copy of the public key of the CA. The public key verifies all the certificates issued by the CA and is vital for the proper operation of the PKI.
The public key, called the self-signed certificate, is also distributed in the form of a certificate issued by the CA itself. Only a root CA issues self-signed certificates.
To explain how CA certificates are retrieved, consider this example:
1. Alice and Bob request the CA certificate that contains the CA public key.
2. Upon receipt of the CA certificate, each requesting system verifies the validity of the certificate using public key cryptography.
3. Alice and Bob follow up the technical verification done by their system by telephoning the CA administrator and verifying the public key and serial number of the certificate.
CA certificates are retrieved in-band over a network, and the authentication is done out-of-band using the telephone.
After retrieving the CA certificate, Alice and Bob submit certificate requests to the CA:
1. Both systems forward a certificate request that includes their public key along with some identifying information. All of this information is encrypted using the public key of the CA.
2. Upon the receipt of the certificate requests on the CA server, the CA administrator telephones Alice and Bob to confirm their submittal and the public key. The CA administrator issues the certificate by adding some additional data to the certificate request and digitally signing it all.
3. Either the end user manually retrieves the certificate or SCEP automatically retrieves the certificate, and the certificate is installed onto the system.
Having installed certificates signed by the same CA, Bob and Alice are now ready to authenticate each other:
1. Bob and Alice exchange certificates. The CA is no longer involved.
2. Each party verifies the digital signature on the certificate by hashing the plaintext portion of the certificate, decrypting the digital signature using the CA public key, and comparing the results. If the results match, the certificate is verified as being signed by a trusted third party, and the verification by the CA that Bob is Bob and Alice is Alice is accepted.
Authentication no longer requires the presence of the CA server, and each user exchanges their certificates containing public keys.
PKI as an authentication mechanism has several characteristics:
The disadvantages of using trusted third parties relate to key management:
Which type of PKI to implement varies depending on the needs of the organization. Administrators might need to combine public-key authentication with another authentication mechanism to increase the level of security and provide more authorization options. For example, IPsec using certificates for authentication and Extended Authentication (XAUTH) with one-time password hardware tokens is a superior authentication scheme when compared to certificates alone.
Whatever choice the administrator makes, the PKI implementation must be based on the requirements specified in the network security policy.