IP Security in Practice
6.3 Encryption and Authentication Algorithms
Rather than relying on secrecy to protect an encryption or authentication scheme (an approach known as “ security through obscurity ” ), TCP/IP security protocols always specify that cryptographic algorithms be well known and accessible. This is done for several reasons, not the least of which is that as an open protocol suite, TCP/IP protocol specifi cations must be published freely. The most important rea- son, however, is that secrecy is a poor safeguard over security.
Attempting to keep an encryption algorithm secret is almost impossible, partic- ularly if it is being used by anyone other than the person who knows the secret. Attackers have many cryptanalysis tools at their disposal for breaking codes, and they need only have access to ciphertexts to break them. Having access to the software used to encrypt and/or decrypt data with the secret algorithm makes the task much easier: the attacker must only determine what the software does to the data to fi gure out how to reverse the operation.
The greatest advantage that published algorithms provide is the benefi t of scrutiny by researchers and others seeking to fi nd ways to further improve or break the algorithms. The more trained experts examine an algorithm, the less likely they are to overlook an “ obvious ” attack.
Security algorithms and protocols are hard to design because there are so many different ways to attack them—and designers can’t always imagine them all. Although national security organizations as well as corporations may have their own top-secret codes, secrets are hard to keep. Spies and other criminals are well known for their skill at motivating (through bribery, extortion, or other means) people who know secrets to share them.
6.3 Encryption and Authentication Algorithms
CH06-P374463.indd 155
156 CHAPTER 6 IP Security in Practice
The prevailing wisdom in security holds that a good encryption or authenti- cation algorithm should be secure even if an attacker knows what algorithm is being used. This is particularly important for Internet security, since an attacker with a sniffer will often be able to determine exactly what kind of algorithm is being used by listening as systems negotiate their connections.
In this section we’ll cover fi ve types of important cryptographic functions.
■ Symmetric encryption
■ Public key encryption
■ Key exchange
■ Secure hashes (message digests)
■ Digital signature
6.3.1 Symmetric Encryption
Most people are familiar with symmetric encryption , if only at a visceral, intui- tive level: Plaintexts are encrypted with a secret key and some set of procedures, and they are decrypted with the same key and the same set of procedures. If you have the key, you can decrypt all data that has been encrypted with that key.
Sometimes known as secret key encryption , symmetric encryption is computa-
tionally effi cient and it is the most frequent type of encryption for network trans- mission of volumes of data.
In October 2000, the National Institute of Standards and Technology (NIST) announced that the Rijndael 2 data encryption algorithm had been selected for the
Advanced Encryption Standard ( AES ), replacing the outdated Data Encryption Standard ( DES ) algorithm originally developed during the 1970s by IBM. DES uses 56-bit keys, although a variation called triple DES encrypts data three times with the DES algorithm, providing improved security.
Using a secure encryption requires using suffi ciently long keys. Shorter keys are vulnerable to brute-force attacks, in which an attacker uses a computer to try all the different possible keys. Key lengths on the order of 40 bits, for example, are considered insecure because they can be broken by brute-force attacks in very short order by relatively inexpensive computers. Single-DES has been brute-forced as well; in general, 128-bit and longer keys are likely to be secure against such attacks for the immediate future.
Symmetric encryption algorithms can be vulnerable to other types of attacks. Most applications that use symmetric encryption for Internet communications use session keys, meaning that the key is used for only a single-session data transmission (sometimes several keys are used in one session). Loss of a session key thus com- promises only the data that was sent during that session or portion of a session.
2 According to an FAQ at the NIST Web site, “ The algorithm’s developers have suggested the fol-
lowing pronunciation alternatives: ‘ Reign Dahl, ’ ‘ Rain Doll, ’ and ‘ Rhine Dahl. ’ ” The AES home page is http://csrc.nist.gov/encryption/aes/ .
CH06-P374463.indd 156
157
These are some of the other symmetric encryption algorithms that have been or are currently being used for Internet applications.
RC2/RC4 These commercial symmetric encryption algorithms were devel- oped and marketed by the cryptography fi rm RSA.
CAST Developed in Canada and used by Nortel’s Entrust products, CAST sup-
ports up to 128-bit keys.
IDEA The International Data Encryption Algorithm supports 128-bit keys. It
was patented by Swiss fi rm Ascom, which granted permission for IDEA to be used for free noncommercial use in the seminal and open source encryp- tion program Pretty Good Privacy (PGP), written by Philip Zimmermann and published for a time by Network Associates, Inc.
GOST This algorithm was reportedly developed by a Soviet security agency.
Blowfi sh This algorithm was developed by Bruce Schneier and released to the public domain.
Twofi sh This was Bruce Schneier’s submission to the AES competition.
Skipjack This algorithm was developed by the National Security Agency for use with the Clipper chip’s escrowed key system.
6.3.2 Public Key Encryption
Public key encryption, also called asymmetric encryption , uses pairs of keys:
One, the public key , is associated with the other, the secret key . The public key is intended to be made public. Any data encrypted with the public key can only be decrypted with the secret key and any data encrypted with the secret key can be decrypted with the public key.
Anyone can get a public key and encrypt some data with it. That data can be decrypted only by the holder of the secret key. As long as an entity can keep its secret key a secret, other entities can be sure that any data encrypted with the pub- lic key will be accessible only to the holder of the associated secret key. The holder of the secret key can encrypt something using that secret key and make it available to another entity. That entity can verify the fi rst entity as holding the secret key of a particular public key pair by decrypting the data with the public key.
Public key encryption tends to be computationally intensive and is most often used to encrypt session keys for network transmissions as well as for digital signatures.
The most commonly used type of public key encryption is the RSA algorithm
developed by Ron Rivest, Adi Shamir, and Len Adleman. RSA defi nes a mechanism for choosing and generating the secret/public key pairs, as well as for the actual mathematical function to be used for encryption.
6.3 Encryption and Authentication Algorithms
CH06-P374463.indd 157
158 CHAPTER 6 IP Security in Practice
6.3.3 Key Management
One of the most complex issues facing Internet security professionals is how to manage keys. This includes not only the actual distribution of keys through a key exchange protocol but also the negotiation of key length, lifetime, and crypto- graphic algorithms between communicating systems.
An open channel (an open communication medium over which transmissions can be overheard) like the global Internet complicates the process of sharing a secret. This process is necessary when two entities need to share a key to be used for encryption. Some of the most important cryptographic algorithms relate to the process of sharing a key over an open channel securely, in a way that keeps the secret from anyone but the intended recipients.
Diffi e-Hellman key exchange is an algorithm that allows entities to exchange enough information to derive a session encryption key. Alice (the customary entity name for the fi rst participant in a cryptographic protocol) calculates a value using Bob’s public value and her own secret value (Bob is the second participant in cryptographic protocols). Bob calculates his own value and sends it to Alice; they each then use their secret values to calculate their shared key. The math- ematics are relatively simple (but outside the scope of this book); the bottom line is that Bob and Alice can send each other enough information to calculate their shared key but not enough for an attacker to be able to fi gure it out.
Diffi e-Hellman is often called a public key algorithm, but it is not a public key
encryption algorithm. Diffi e-Hellman is used to calculate a key, but that key must be used with some other encryption algorithm. Diffi e-Hellman can be used for authentication, though, and is also used by PGP.
Key exchange is integral to any Internet security architecture, and candidates for the IPsec security architecture include the Internet Key Exchange ( IKE )
protocol and the Internet Security Association and Key Management Protocol
(ISAKMP).
ISAKMP is an application protocol, using UDP as its transport, which defi nes dif- ferent types of messages that systems send to each other to negotiate the exchange of keys. The mechanisms and algorithms for doing the actual exchanges, however, are not defi ned in ISAKMP—it is a framework to be used by the specifi c mecha- nisms. The mechanisms, often based on Diffi e-Hellman key exchange, have been defi ned in a number of different proposals over the years. These are some of them.
Photuris Based on Diffi e-Hellman, Photuris adds the requirement that the
requesting node send a cookie , a random number that is used as a sort of
session identifi er. The cookie is sent fi rst, and the server acknowledges the request by returning the cookie. This reduces the risk from denial of service attacks made by attackers forging their source addresses. Photuris also requires all parties to sign their negotiated key to reduce the risk of a man-in-the-middle attack (in which an attacker pretends to be Bob to one system’s Alice, while pretending to be Alice to the other system’s Bob).
CH06-P374463.indd 158
159
SKIP Sun Microsystems ’ Simple Key-management for Internet Protocols
( SKIP ) is also based on Diffi e-Hellman key exchange, but rather than requir- ing parties to use random values to calculate their keys, SKIP calls for the use of a secret table that remains static. The parties look up secret values in this table and then transmit calculated values based on some secret value from the table.
OAKLEY Although this mechanism shares some features with Photuris, it pro- vides different modes of key exchange for situations where denial of service attacks are not a concern.
By defi ning a separate protocol, ISAKMP, for the generalized formats required to do key and Security Association exchanges, it can be used as a base to build specifi c key exchange protocols. The foundation protocol can be used for any security protocol, and it does not have to be replaced if an existing key exchange protocol is replaced.
It should be noted that manual key management is an important option and in many cases is the only option. This approach requires individuals to personally deliver keys and confi gure network devices to use them. Even after open stan- dards have been fi rmly determined and implemented, particularly as commercial products, manual key management will continue to be an important choice.
As more research is done with IPsec, work on an IKE successor protocol (sometimes called Son-of-IKE ) is ongoing, with IKEv2 one candidate protocol that (as of 2002) is a work in progress.
6.3.4 Secure Hashes
A hash is a digital summary of a chunk of data of any size. Simple types of hashes include check digits; secure hashes produce longer results (often 128 bits or lon- ger). Good secure hashes are extremely diffi cult for attackers to reverse-engineer or subvert in other ways. Secure hashes can be used with keys or without, but their purpose is to provide a digital summary of a message that can be used to verify whether some data that has been received is the same as the data sent. The sender calculates the hash and includes that value with the data; the recipient cal- culates the hash on the data received. If the results match the attached hash value, the recipient can be confi dent in the data’s integrity.
Commonly used hashes include the MD2, MD4, and MD5 message digest func-
tions published by Network Associates. The Secure Hash Algorithm ( SHA ) is a
digest function developed as a standard by NIST. Hashes may be used on their own or as part of digital signatures.
6.3.5 Digital Signature
Public key encryption, as noted previously, relies on key pairs. Digital signatures rely on the property of public key encryption that allows data encrypted with
6.3 Encryption and Authentication Algorithms
CH06-P374463.indd 159
160 CHAPTER 6 IP Security in Practice
an entity’s secret key to be decrypted with the public key of the pair. The sender calculates a secure hash on the data to be signed and then encrypts the result using a secret key. The recipient calculates the same hash and then decrypts the encrypted value attached by the sender. If the two values match, the recipient knows that the owner of the public key was the entity that signed the message and that the message was not modifi ed during transmission.
The RSA public key encryption algorithm can be used for digital signatures: The signing entity creates a hash of the data to be signed and then encrypts that hash with its own secret key. The certifying entity then calculates the same hash on the data being received, decrypts the signature using the signing entity’s pub- lic key, and compares the two values. If the hash is the same as the decrypted sig- nature, then the data is certifi ed.
Digital signatures carry with them several implications.
■ A signature that can be certifi ed indicates that the message was received without any alteration from the time it was signed to the time it was received.
■ If a signature cannot be certifi ed, then the message was corrupted or tam- pered with in transit, the signature was calculated incorrectly, or the signa- ture was corrupted or tampered with in transit. In any case, an uncertifi able signature does not necessarily imply any wrongdoing but does require that the message be resigned and resent in order to be accepted.
■ If a signature is certifi ed, it means that the entity associated with the public key was the only entity that could have signed it. In other words, the entity associated with the public key cannot deny having signed the message. This is called nonrepudiation and is an important feature of digital signatures. There are other mechanisms for doing digital signatures, but RSA is probably the most widely used one and is implemented in the most popular Internet products.