IAGO: So will I turn her virtue into pitch,And out of her own goodness make the net That shall enmesh them all. | ||
| --The Tragedy of Othello, II, iii, 361–363. | ||
Cryptographic systems are sensitive to environment. Using cryptosystems over a network introduces many problems. This chapter presents examples of these problems and discusses techniques for dealing with them. First comes a description of stream and block ciphers, followed by a review of the organization of the network layers. We then present several network protocols to show how these techniques are used in practice.
The key point of this chapter is that the strength of a cryptosystem depends in part on how it is used. A mathematically strong cryptosystem is vulnerable when used incorrectly.
The use of a cipher without consideration of the environment in which it is to be used may not provide the security that the user expects. Three examples will make this point clear.
Simmons discusses the use of a “forward search” to decipher messages enciphered for confidentiality using a public key cryptosystem [923]. His approach is to focus on the entropy (uncertainty) in the message. To use an example from Section 10.1 (page 246), Cathy knows that Alice will send one of two messages—BUY or SELL—to Bob. The uncertainty is which one Alice will send. So Cathy enciphers both messages with Bob's public key. When Alice sends the message, Bob intercepts it and compares the ciphertext with the two he computed. From this, he knows which message Alice sent.
Simmons' point is that if the plaintext corresponding to intercepted ciphertext is drawn from a (relatively) small set of possible plaintexts, the cryptanalyst can encipher the set of possible plaintexts and simply search that set for the intercepted ciphertext. Simmons demonstrates that the size of the set of possible plaintexts may not be obvious. As an example, he uses digitized sound. The initial calculations suggest that the number of possible plaintexts for each block is 232. Using forward search on such a set is clearly impractical, but after some analysis of the redundancy in human speech, Simmons reduces the number of potential plaintexts to about 100,000. This number is small enough so that forward searches become a threat.
This attack is similar to attacks to derive the cryptographic key of symmetric ciphers based on chosen plaintext (see, for example, Hellman's time-memory tradeoff attack [465]). However, Simmons' attack is for public key cryptosystems and does not reveal the private key. It only reveals the plaintext message.
Denning [269] points out that in certain cases, parts of a ciphertext message can be deleted, replayed, or reordered.
The independence of parts of ciphertext can give information relating to the structure of the enciphered message, even if the message itself is unintelligible. The regularity arises because each part is enciphered separately, so the same plaintext always produces the same ciphertext. This type of encipherment is called code book mode, because each part is effectively looked up in a list of plaintext-ciphertext pairs.
Despite the use of sophisticated cryptosystems and random keys, cipher systems may provide inadequate security if not used carefully. The protocols directing how these cipher systems are used, and the ancillary information that the protocols add to messages and sessions, overcome these problems. This emphasizes that ciphers and codes are not enough. The methods, or protocols, for their use also affect the security of systems.
Some ciphers divide a message into a sequence of parts, or blocks, and encipher each block with the same key.
Definition 11–1. Let E be an encipherment algorithm, and let Ek(b) be the encipherment of message b with key k. Let a message m = b1b2 …, where each bi is of a fixed length. Then a block cipher is a cipher for which Ek(m) = Ek(b1)Ek(b2) ….
Other ciphers use a nonrepeating stream of key elements to encipher characters of a message.
Definition 11–2. Let E be an encipherment algorithm, and let Ek(b) be the encipherment of message b with key k. Let a message m = b1b2 …, where each bi is of a fixed length, and let k = k1k2 …. Then a stream cipher is a cipher for which Ek(m) = Ek1(b1)Ek2(b2) ….
If the key stream k of a stream cipher repeats itself, it is a periodic cipher.
The one-time pad is a cipher that can be proven secure (see Section 9.2.2.2, “One-Time Pad”). Bit-oriented ciphers implement the one-time pad by exclusive-oring each bit of the key with one bit of the message. For example, if the message is 00101 and the key is 10010, the ciphertext is 0⊕1||0⊕0||1⊕0||0⊕1||1⊕0 or 10111. But how can one generate a random, infinitely long key?
To simulate a random, infinitely long key, synchronous stream ciphers generate bits from a source other than the message itself. The simplest such cipher extracts bits from a register to use as the key. The contents of the register change on the basis of the current contents of the register.
Definition 11–3. An n-stage linear feedback shift register (LFSR) consists of an n-bit register r = r0…rn–1 and an n-bit tap sequence t = t0…tn–1. To obtain a key bit, r0 is used, the register is shifted one bit to the right, and the new bit r0t0⊕…⊕rn–1tn–1 is inserted.
The LFSR method is an attempt to simulate a one-time pad by generating a long key sequence from a little information. As with any such attempt, if the key is shorter than the message, breaking part of the ciphertext gives the cryptanalyst information about other parts of the ciphertext. For an LFSR, a known plaintext attack can reveal parts of the key sequence. If the known plaintext is of length 2n, the tap sequence for an n-stage LFSR can be determined completely.
Nonlinear feedback shift registers do not use tap sequences; instead, the new bit is any function of the current register bits.
Definition 11–4. An n-stage nonlinear feedback shift register (NLFSR) consists of an n-bit register r = r0…rn–1. Whenever a key bit is required, r0 is used, the register is shifted one bit to the right, and the new bit is set to f(r0…rn–1), where f is any function of n inputs.
NLFSRs are not common because there is no body of theory about how to build NLFSRs with long periods. By contrast, it is known how to design n-stage LFSRs with a period of 2n – 1, and that period is maximal.
A second technique for eliminating linearity is called output feedback mode. Let E be an encipherment function. Define k as a cryptographic key, and define r as a register. To obtain a bit for the key, compute Ek(r) and put that value into the register. The rightmost bit of the result is exclusive-or'ed with one bit of the message. The process is repeated until the message is enciphered. The key k and the initial value in r are the keys for this method. This method differs from the NLFSR in that the register is never shifted. It is repeatedly enciphered.
A variant of output feedback mode is called the counter method. Instead of using a register r, simply use a counter that is incremented for every encipherment. The initial value of the counter replaces r as part of the key. This method enables one to generate the ith bit of the key without generating the bits 0…i – 1. If the initial counter value is i0, set the register to i + i0. In output feedback mode, one must generate all the preceding key bits.
Self-synchronous ciphers obtain the key from the message itself. The simplest self-synchronous cipher is called an autokey cipher and uses the message itself for the key.
The problem with this cipher is the selection of the key. Unlike a one-time pad, any statistical regularities in the plaintext show up in the key. For example, the last two letters of the ciphertext associated with the plaintext word THE are always AL, because H is enciphered with the key letter T and E is enciphered with the key letter H. Furthermore, if the analyst can guess any letter of the plaintext, she can determine all successive plaintext letters.
An alternative is to use the ciphertext as the key stream. A good cipher will produce pseudorandom ciphertext, which approximates a random one-time pad better than a message with nonrandom characteristics (such as a meaningful English sentence).
This type of autokey cipher is weak, because plaintext can be deduced from the ciphertext. For example, consider the first two characters of the ciphertext, QX. The X is the ciphertext resulting from enciphering some letter with the key Q. Deciphering, the unknown letter is H. Continuing in this fashion, the analyst can reconstruct all of the plaintext except for the first letter.
A variant of the autokey method, cipher feedback mode, uses a shift register. Let E be an encipherment function. Define k as a cryptographic key and r as a register. To obtain a bit for the key, compute Ek(r). The rightmost bit of the result is exclusive-or'ed with one bit of the message, and the other bits of the result are discarded. The resulting ciphertext is fed back into the leftmost bit of the register, which is right shifted one bit. (See Figure 11-1.)
Figure 11-1. Diagram of cipher feedback mode. The register r is enciphered with key k and algorithm E. The rightmost bit of the result is exclusive-or'ed with one bit of the plaintext mi to produce the ciphertext bit ci. The register r is right shifted one bit, and ci is fed back into the leftmost bit of r.
Cipher feedback mode has a self-healing property. If a bit is corrupted in transmission of the ciphertext, the next n bits will be deciphered incorrectly. But after n uncorrupted bits have been received, the shift register will be reinitialized to the value used for encipherment and the ciphertext will decipher properly from that point on.
As in the counter method, one can decipher parts of messages enciphered in cipher feedback mode without deciphering the entire message. Let the shift register contain n bits. The analyst obtains the previous n bits of ciphertext. This is the value in the shift register before the bit under consideration was enciphered. The decipherment can then continue from that bit on.
Block ciphers encipher and decipher multiple bits at once, rather than one bit at a time. For this reason, software implementations of block ciphers run faster than software implementations of stream ciphers. Errors in transmitting one block generally do not affect other blocks, but as each block is enciphered independently, using the same key, identical plaintext blocks produce identical ciphertext blocks. This allows the analyst to search for data by determining what the encipherment of a specific plaintext block is. For example, if the word INCOME is enciphered as one block, all occurrences of the word produce the same ciphertext.
To prevent this type of attack, some information related to the block's position is inserted into the plaintext block before it is enciphered. The information can be bits from the preceding ciphertext block [343] or a sequence number [561]. The disadvantage is that the effective block size is reduced, because fewer message bits are present in a block.
Cipher block chaining does not require the extra information to occupy bit spaces, so every bit in the block is part of the message. Before a plaintext block is enciphered, that block is exclusive-or'ed with the preceding ciphertext block. In addition to the key, this technique requires an initialization vector with which to exclusive-or the initial plaintext block. Taking Ek to be the encipherment algorithm with key k, and I to be the initialization vector, the cipher block chaining technique is
c0 = Ek(m0 ⊕ I)
ci = Ek(mi ⊕ ci–1) for i > 0
Other approaches involve multiple encryption. Using two keys k and k' to encipher a message as c = Ek' (Ek(m)) looks attractive because it has an effective key length of 2n, whereas the keys to E are of length n. However, Merkle and Hellman [700] have shown that this encryption technique can be broken using 2n+1 encryptions, rather than the expected 22n (see Exercise 3).
Using three encipherments improves the strength of the cipher. There are several ways to do this. Tuchman [1006] suggested using two keys k and k':
c = Ek(Dk' (Ek(m)))
This mode, called Encrypt-Decrypt-Encrypt (EDE) mode, collapses to a single encipherment when k = k'. The DES in EDE mode is widely used in the financial community and is a standard (ANSI X9.17 and ISO 8732). It is not vulnerable to the attack outlined earlier. However, it is vulnerable to a chosen plaintext and a known plaintext attack. If b is the block size in bits, and n is the key length, the chosen plaintext attack takes O(2n) time, O(2n) space, and requires 2n chosen plaintexts. The known plaintext attack requires p known plaintexts, and takes O(2n+b/p) time and O(p) memory.
A second version of triple encipherment is the triple encryption mode [700]. In this mode, three keys are used in a chain of encipherments.
c = Ek(Ek' (Ek'' (m)))
The best attack against this scheme is similar to the attack on double encipherment, but requires O(22n) time and O(2n) memory. If the key length is 56 bits, this attack is computationally infeasible.
Before we discuss Internet protocols, a review of the relevant properties of networks is in order. The ISO/OSI model [990] provides an abstract representation of networks suitable for our purposes. Recall that the ISO/OSI model is composed of a series of layers (see Figure 11-2). Each host, conceptually, has a principal at each layer that communicates with a peer on other hosts. These principals communicate with principals at the same layer on other hosts. Layer 1, 2, and 3 principals interact only with similar principals at neighboring (directly connected) hosts. Principals at layers 4, 5, 6, and 7 interact only with similar principals at the other end of the communication. (For convenience, “host” refers to the appropriate principal in the following discussion.)
Figure 11-2. The ISO/OSI model. The dashed arrows indicate peer-to-peer communication. For example, the transport layers are communicating with each other. The solid arrows indicate the actual flow of bits. For example, the transport layer invokes network layer routines on the local host, which invoke data link layer routines, which put the bits onto the network. The physical layer passes the bits to the next “hop,” or host, on the path. When the message reaches the destination, it is passed up to the appropriate level.
Each host in the network is connected to some set of other hosts. They exchange messages with those hosts. If host nob wants to send a message to host windsor, nob determines which of its immediate neighbors is closest to windsor (using an appropriate routing protocol) and forwards the message to it. That host, baton, determines which of its neighbors is closest to windsor and forwards the message to it. This process continues until a host, sunapee, receives the message and determines that windsor is an immediate neighbor. The message is forwarded to windsor, its endpoint.
Definition 11–5. Let hosts C0, …, Cn be such that Ci and Ci+1 are directly connected, for 0 ≤ i < n. A communications protocol that has C0 and Cn as its endpoints is called an end-to-end protocol. A communications protocol that has Cj and Cj+1 as its endpoints is called a link protocol.
The difference between an end-to-end protocol and a link protocol is that the intermediate hosts play no part in an end-to-end protocol other than forwarding messages. On the other hand, a link protocol describes how each pair of intermediate hosts processes each message.
The protocols involved can be cryptographic protocols. If the cryptographic processing is done only at the source and at the destination, the protocol is an end-to-end protocol. If cryptographic processing occurs at each host along the path from source to destination, the protocol is a link protocol. When encryption is used with either protocol, we use the terms end-to-end encryption and link encryption, respectively.
In link encryption, each host shares a cryptographic key with its neighbor. (If public key cryptography is used, each host has its neighbor's public key. Link encryption based on public keys is rare.) The keys may be set on a per-host basis or a per-host-pair basis. Consider a network with four hosts called windsor, stripe, facer, and seaview. Each host is directly connected to the other three. With keys distributed on a per-host basis, each host has its own key, making four keys in all. Each host has the keys for the other three neighbors, as well as its own. All hosts use the same key to communicate with windsor. With keys distributed on a per-host-pair basis, each host has one key per possible connection, making six keys in all. Unlike the per-host situation, in the per-host-pair case, each host uses a different key to communicate with windsor. The message is deciphered at each intermediate host, reenciphered for the next hop, and forwarded. Attackers monitoring the network medium will not be able to read the messages, but attackers at the intermediate hosts will be able to do so.
In end-to-end encryption, each host shares a cryptographic key with each destination. (Again, if the encryption is based on public key cryptography, each host has—or can obtain—the public key of each destination.) As with link encryption, the keys may be selected on a per-host or per-host-pair basis. The sending host enciphers the message and forwards it to the first intermediate host. The intermediate host forwards it to the next host, and the process continues until the message reaches its destination. The destination host then deciphers it. The message is enciphered throughout its journey. Neither attackers monitoring the network nor attackers on the intermediate hosts can read the message. However, attackers can read the routing information used to forward the message.
These differences affect a form of cryptanalysis known as traffic analysis. A cryptanalyst can sometimes deduce information not from the content of the message but from the sender and recipient. For example, during the Allied invasion of Normandy in World War II, the Germans deduced which vessels were the command ships by observing which ships were sending and receiving the most signals. The content of the signals was not relevant; their source and destination were. Similar deductions can reveal information in the electronic world.
Several widely used Internet protocols illustrate different facets of cryptographic techniques. This section examines three such protocols, each at a different layer. PEM is a privacy-enhanced electronic mail protocol at the applications layer and demonstrates the considerations needed when designing such a protocol. Its techniques are similar to those of PGP, another widely used security-enhanced electronic mail protocol. SSL provides transport layer security. Application layer protocols such as HTTP can use SSL to ensure secure connections. IPsec provides security mechanisms at the network, or IP, layer.
Electronic mail is a widely used mechanism for communication over the Internet. It is also a good example of how practical considerations affect the design of security-related protocols. We begin by describing the state of electronic mail and then show how security services can be added.
Figure 11-3 shows a typical network mail service. The UA (user agent) interacts directly with the sender. When the message is composed, the UA hands it to the MTA (message transport, or transfer, agent). The MTA transfers the message to its destination host, or to another MTA, which in turn transfers the message further. At the destination host, the MTA invokes a user agent to deliver the message.
Figure 11-3. Message handling system. The user composes mail on the UA (user agent). When she sends it, the message is passed to the MTA (message transport, or transfer, agent). The MTA passes the message to other MTAs, until it reaches the MTA associated with the destination host. That host transfers it to the appropriate UA for delivery.
An attacker can read electronic mail at any of the computers on which MTAs handling the message reside, as well as on the network itself. An attacker could also modify the message without the recipient detecting the change. Because authentication mechanisms are minimal and easily evaded, a sender could forge a letter from another and inject it into the message handling system at any MTA, from which it would be forwarded to the destination. Finally, a sender could deny having sent a letter, and the recipient could not prove otherwise to a disinterested party. These four types of attacks (violation of confidentiality, authentication, message integrity, and nonrepudiation) make electronic mail nonsecure.
In 1985, the Internet Research Task Force on Privacy (also called the Privacy Research Group) began studying the problem of enhancing the privacy of electronic mail. The goal of this study was to develop electronic mail protocols that would provide the following services.
Confidentiality, by making the message unreadable except to the sender and recipient(s)
Origin authentication, by identifying the sender precisely
Data integrity, by ensuring that any changes in the message are easy to detect
Nonrepudiation of origin (if possible)
The protocols were christened Privacy-enhanced Electronic Mail (or PEM).
Creating a viable protocol requires the developers to consider several design aspects. Otherwise, acceptance and use of the protocol will be very limited.
Related protocols should not be changed. A protocol is designed to provide specific services (in this case, the privacy enhancements discussed in the preceding section). It should not require alteration of other protocols (such as those that transmit electronic mail). The Privacy Research Group developed new protocols rather than modifying the mail transfer protocols. This also requires development of new software rather than modification of existing software to implement the protocol (although existing software can be modified to support it).
A corollary is compatibility. A general protocol (such as PEM) must be compatible with as many other protocols and programs as possible. The protocols must work with a wide range of software, including software in all environments that connect to the Internet.
Another important principle is independence. The privacy enhancements should be available if desired but should not be mandatory. If a new protocol provides specific services, the user should be able to use the services desired, which may (or may not) be all the ones that the protocol provides. For example, a sender might care about sender authentication but not confidentiality. This also enables some users to send privacy-enhanced electronic mail, and others to send unprotected electronic mail, on the same system. Recipients can also read either type of mail.
Finally, two parties should be able to use the protocol to communicate without prearrangement. Arranging a communications key out of band (such as in person or over the telephone) can be time-consuming and prone to error. Furthermore, callers must authenticate themselves to the recipients. This is difficult and is another error-prone operation.
To summarize, the design goals of PEM were as follows.
Not to redesign existing mail system or protocols
To be compatible with a range of MTAs, UAs, and other computers
To make privacy enhancements available separately, so they are not required
To enable two parties to use the protocol to communicate without prearrangement
PEM defines two types of keys. The message to be sent is enciphered with a data encipherment key (DEK), corresponding to a session key. This key is generated randomly and is used only once. It must be sent to the recipient, so it is enciphered with an interchange key. The interchange keys of the sender and recipient must be obtained in some way other than through the message.
This requires several assumptions. First, the interchange key must be available to the respective parties. If symmetric ciphers are used, the keys must be exchanged out of bands—for example, by telephone or courier. If public keys are used, the sender needs to obtain the certificate of the recipient.
If Alice wants to send a confidential message to Bob, she obtains Bob's interchange key kBob. She generates a random DEK ksession and enciphers the message m. She then enciphers the DEK using the interchange key. She sends both to Bob.
Alice → Bob: { m }ksession{ ksession }kBob
Bob can then decipher the session key and from it obtain the message.
If Alice wants to send an authenticated, integrity-checked message to Bob, she first computes a cryptographic hash h(m) of the message, possibly using a random session key (if the hash function requires one). The value that the hash function computes is called a message integrity check (MIC). She then enciphers the MIC (and the session key, if one was used) with her interchange key kAlice and sends it to Bob:
Alice → Bob: m { h(m) }kAlice
Bob uses Alice's interchange key to decipher the MIC, recomputes it from m, and compares the two. If they do not match, either the message or the value of the hash has been changed. In either case, the message cannot be trusted.
To send an enciphered, authenticated, integrity-checked message, combine the operations discussed above, as follows.
Alice → Bob: { m }ksession{ h(m) }kAlice{ ksession }kBob
The nonrepudiation service comes from the use of public key cryptography. If Alice's interchange key is her private key, a third party can verify that she signed the message by deciphering it with her public key. Alice cannot refute that her private key was used to sign the message. (She can dispute that she signed it by claiming her private key was compromised. Preventing this is beyond the scope of technical protocols. In this context, “nonrepudiation” refers only to the inability to deny that the private key was used to sign the message.)
When the interchange keys are for public key cryptosystems, PEM suggests the use of a certificate-based key management scheme (see Section 14.5, “Naming and Certificates”). However, it is not a requirement.
A major problem is the specification of Internet electronic mail. Among the restrictions placed on it, the requirements that the letter contain only ASCII characters and that the lines be of limited length are the most onerous. Related to this is the difference among character sets. A letter typed on an ASCII-based system will be unreadable on an EBCDIC-based system.
A three-step encoding procedure overcomes these problems.
The local representations of the characters making up the letter are changed into a canonical format. This format satisfies the requirements of RFC 822–compliant mailers (specifically, all characters are seven-bit ASCII characters, lines are less than 1,000 characters long, and lines end with a carriage return followed by a newline [246][1]).
The message integrity check is computed and enciphered with the sender's interchange key. If confidentiality is required, the message is enciphered as described above.
The message is treated as a stream of bits. Every set of six bits is mapped into a character,[2] and after every 64 characters, a newline is inserted.
The resulting ASCII message has PEM headers (indicating algorithms and key) prepended. PEM headers and body are surrounded by lines indicating the start and end of the PEM message.
If the recipient has PEM-compliant software, she can read the message. Otherwise, she cannot. If the message is authenticated and integrity-checked (but not encrypted), she should be able to read the message even if she does not have PEM-compliant software (remember that one of the design components is compatibility with existing mail programs). The special mode MIC-CLEAR handles this case. In this mode, the message check is computed and added, but the message is not transformed into the representation of step 3. On receipt, the authentication and message integrity check may fail because some MTAs add blank lines, change the end-of-line character, or delete terminating white space from lines. Although this does not alter the meaning of the message, it does change the content. Hence, PEM-compliant software will report that the message has been altered in transit. But people can use normal mail reading programs to read the letter. (Whether they should trust it is another matter. Given that the PEM software has reported changes, the recipients should at least verify the contents in some way before trusting the letter.)
PEM demonstrates how system factors influence the use of cryptographic protocols. While central to the design and implementation of PEM systems, the cryptographic protocols require a supporting infrastructure. The need for compatibility guides many design choices for this infrastructure. The environment of development also affects the infrastructure.
Comparing PGP and PEM illustrates this. Both use the same cryptographic protocols, but by default, PGP uses the IDEA cipher instead of the DES. PGP also uses a different, nonhierarchical certificate management scheme described in Sections 10.4.2.2 and 14.5. Finally, PGP handles line termination characters differently. Messages are labeled binary or text. If binary, line terminators are untransformed. If text, they are canonicalized (if enciphering) or mapped into the end-of-line character sequence for the current host (if deciphering).
The Secure Socket Layer (SSL) [375] is a standard developed by Netscape Corporation to provide security in WWW browsers and servers. The current version, SSLv3, is the basis for an Internet standard protocol under development. This protocol, the Transport Layer Security (TLS) protocol [293], is compatible with SSLv3 and has only minor changes. It has not yet been adopted formally, so we will focus on the widely used SSLv3.
SSL works in terms of connections and sessions between clients and servers.
Definition 11–6. An SSL session is an association between two peers. An SSL connection is the set of mechanisms used to transport data in an SSL session.
A single session may have many connections. Two peers may have many sessions active at the same time, but this is not common.
Each party keeps information related to a session with each peer. The data associated with a session includes the following information.
A session identifier that uniquely identifies the session
The peer's X.509v3 certificate (which is empty if no such certificate is needed)
A compression method used to reduce the volume of data
A cipher specification that includes all the relevant parameters for the cipher and for the message authentication code (MAC)[3]
A “master secret” of 48 bits shared with the peer
A connection describes how data is sent to, and received from, the peer. Each party keeps information related to a connection. Each peer has its own parameters. The key with which the client enciphers data is (probably) not the same as the key with which the server enciphers data. The information associated with the connection includes the following.
Random data for the server and client
The server and client write keys, which each uses to encipher data
The server and client write MAC key, which each uses to compute a MAC
The initialization vectors for the ciphers, if needed
The server and client sequence numbers
SSLv3 consists of two layers supported by numerous cryptographic mechanisms. We begin by describing the mechanisms, then the lower layer, and finally the upper layer.
During the setup negotiations, the peers determine a cryptographic mechanism for providing confidentiality and message and origin integrity. Interchange keys are used to establish a session key. Because all parts of SSL use cryptographic mechanisms, we discuss them first.
The initial phase of session setup uses a public key cryptosystem to exchange keys. The messages are enciphered using a classical cipher and are checksummed using a cryptographic checksum.
Initially, the handshake protocol assumes no interchange cipher, no classical cipher, and no checksum. The handshake protocol then negotiates the selection of these mechanisms.
If the interchange cipher is RSA, the server must provide an RSA certificate for key exchange. The server may request that the client provide either an RSA or DSS certificate for signatures. Table 11-1 shows the legal combinations of classical ciphers and MACs.
Table 11-1. RSA, Classical Ciphers, and Checksum Combinations
Interchange cipher | Classical cipher | MAC algorithm |
|---|---|---|
RSA (key at most 512 bits) | None RC4 (40-bit key) RC2 (40-bit key), CBC mode DES (40-bit key), CBC mode | MD5, SHA MD5 MD5 SHA |
RSA | None RC4 (128-bit key) IDEA, CBC mode DES, CBC mode DES, EDE mode, CBC mode | MD5, SHA MD5, SHA SHA SHA SHA |
Three types of Diffie-Hellman ciphers serve as interchange ciphers. “Diffie-Hellman” denotes a cipher system in which the certificate contains the cipher parameters and is signed by an appropriate certification authority. “Ephemeral Diffie-Hellman” refers to a cipher system in which a DSS or RSA certificate is used to sign the parameters to the Diffie-Hellman cipher. This implies that the parameters will not be used again (or else they would have been in a certificate) and so are “ephemeral.” “Anonymous Diffie-Hellman” refers to use of Diffie-Hellman without either party being authenticated. This cipher is vulnerable to attacks, and its use is “strongly discouraged” according to the SSLv3 specification. Table 11-2 summarizes the legal combinations of classical ciphers and MACs.
Table 11-2. Diffie-Hellman, Classical Ciphers, and Checksum Combination
Interchange cipher | Classical cipher | MAC algorithm |
|---|---|---|
Diffie-Hellman, DSS certificate | DES (40-bit key), CBC mode DES, CBC mode DES, EDE mode, CBC mode | SHA SHA SHA |
Diffie-Hellman (key at most 512 bits), RSA certificate | DES (40-bit key), CBC mode DES, CBC mode DES, EDE mode, CBC mode | SHA SHA SHA |
Ephemeral Diffie-Hellman, DSS certificate | DES (40-bit key), CBC mode DES, CBC mode DES, EDE mode, CBC mode | SHA SHA SHA |
Ephemeral Diffie-Hellman (key at most 512 bits), RSA certificate | DES (40-bit key), CBC mode DES, CBC mode DES, EDE mode, CBC mode | SHA SHA SHA |
Anonymous Diffie-Hellman | RC4 (40-bit key) RC4 (128-bit key) DES (40-bit key), CBC mode DES, CBC mode DES, EDE mode, CBC mode | MD5 MD5 SHA SHA SHA |
The third set of ciphers is for the Fortezza cryptographic token [758, 759] used by the U.S. Department of Defense. Table 11-3 summarizes the legal combinations of classical ciphers and MACs.
Table 11-3. Fortezza, Classical Ciphers, and Checksum Combinations
Interchange cipher | Classical cipher | MAC algorithm |
|---|---|---|
Fortezza key exchange | None Fortezza, CBC mode | SHA SHA |
Algorithm | RC4 (128-bit key) | SHA |
An RSA digital signature is computed by concatenating two hashes (the first computed using MD5, the second by computing SHA) and signing them with the appropriate public key. For other ciphers, the SHA hash is signed.
The record layer computes a MAC for each block. In SSLv3, the MAC is
hash(MAC_ws||opad||hash(MAC_ws||ipad||seq||SSL_comp||SSL_len||block))
where hash is the particular hash function used (MD5 or SHA), MAC_ws is the write MAC key of the entity, ipad and opad are the ipad and opad from HMAC (see Section 9.4.1), seq is the sequence number, SSL_comp is the message type (taken from the higher layer protocol), SSL_len is the length of the block, and block is the block itself.
When the record layer (see Section 11.4.2.2) enciphers a block, it uses the cryptosystem negotiated during the initialization of the session. The cryptosystem may be a stream cipher or a block cipher. If it is the former, the blocks are enciphered sequentially, with the state of the stream at the end of one block carrying over to the next block. If it is the latter, the block is padded to the block size by adding bytes after the MAC. The padding is arranged so that the length of the padding is added just before the cipher block boundary.
During the handshake protocol, the client and server each compute a secret from some shared data. SSLv3 uses the following function:
master | = | MD5(pre || SHA('A' || pre || random_1 || random_2)) || MD5(pre || SHA('BB' || pre || random_1 || random_2)) || MD5(pre || SHA('CCC' || pre || random_1 || random_2)) |
where pre is the shared data and random_1 and random_2 are shared random numbers.
The SSL record protocol provides a basis for secure communication. The protocol to be secured runs on top of it. For example, SSL adds security to HTTP by taking HTTP messages and applying the steps listed below to each message. However, the SSL record protocol need not handle retransmissions or unreliable delivery, because it runs on top of TCP. TCP handles the transport layer functions such as retransmissions and reliable delivery.
The SSL record protocol provides both confidentiality and message integrity for the records being sent. It accepts messages from the higher layer. Each message is split, if needed, into multiple parts. The SSL record protocol can transport a block of at most 214 = 16,384 bytes. The following steps are applied to each block, and the blocks are reassembled at the end.
The block is compressed. The MAC of the (compressed) block is computed, and the compressed block and MAC are enciphered. Finally, the SSL record header is prepended. The header contains the message type, the major version number (3 for both SSLv3 and TLS), the minor version number (0 for SSLv3, 1 for TLS), and the length of the block. Figure 11-4 shows these steps.
Figure 11-4. SSL record layer. The message is split into blocks. Each block is compressed, has a MAC added, and is enciphered.
If the MAC and enciphering key have not been selected (which happens when the record layer carries messages for the handshake protocol; see Section 11.4.2.3), the encipherment algorithm is the identity transformation and no MAC is used. (In other words, the record layer does neither encipherment nor computation of the MAC.)
The SSL handshake protocol sets up the parameters for the SSL record protocol. It consists of four rounds that enable the peers to agree on keys, ciphers, and MAC algorithms. The exact sequence depends on the level of security desired. For clarity, in the following discussion we assume that the client and server use RSA as the interchange cryptosystem.
The first round creates the SSL connection between the client C and the server S. If the server initiates the handshake, it sends an empty server_hello message, and the client begins the protocol. The client can initiate the handshake by sending the message without the server's request:
C → S: { version || rand1 || session_id || cipher_list || compression_list }
where version is the version of SSL that the client uses and rand1 is a nonce composed of a timestamp and a set of 28 random bytes. The session_id is either 0 (meaning a new session) or the session identification number of an existing session (meaning that parameters are to be updated). The cipher_list is a list of ciphers that the client understands, in order of preference, and the compression_list identifies the compression algorithms that the client understands, again in order of preference.
The server responds with its own message:
S → C: { version || rand2 || session_id || cipher || compression }
which indicates the selection of the parameters for the connection. Here, version is the highest version of SSL that both the client and server understand, the cipher and compression fields identify the cipher and compression algorithms, session_id identifies the session (if the client sent a 0, this is the identification number of the new session), and rand2 is a nonce (timestamp and 28 random bytes) that the server generated. For this example, assume that the cipher selected is RSA. This ends the first round.
The server authenticates itself in the second round. (If the server is not going to authenticate itself, it sends the final message in this round—message 6—immediately.) First, it sends the client its X.509v3 certificate.[4]
S → C: { server_cert }
The next message sets the parameters. If the RSA certificate is for signatures only, the server sends the public key modulus and exponent used for confidentiality, followed by a hash of the data.
S → C: { mod || exp || { hash(rand1 || rand2 || mod || exp) }kS }
Here, rand1 and rand2 are the random data from the first two messages; this prevents replay. The hash is the concatenation of the MD5 and SHA-1 hashes for the given parameter, digitally signed by enciphering them with the private key kS of the server.[5]
If the server is not anonymous, it may request a certificate from the client:
S → C: { cert_type, good_cert_authorities }
where cert_type identifies the type of certificate requested (by cryptosystem used) and good_cert_authorities identifies certification authorities that the server will accept. The server then sends a message ending the second round.
S → C: { end_round_2 }
Round 3 begins with the client validating the server's certificate (if any) and the parameters (again, if any were sent). If the server requested a certificate, the client obliges or replies with an alert indicating that it has no certificate:
C → S: { client_cert }
The client next sends a message to begin the key exchange. Since our peers are using RSA, the appropriate public key is used to encipher 48 random bytes to produce a “pre master secret” pre. The server and client will use this to generate a shared master secret.[6]
C → S: { pre }
Both parties now compute the master secret from the pre_master_secret, as discussed above. The client closes with a verification message so the server can check that all previous messages were received correctly.
C → S: { hash(mastr || opad || hash(messages || mastr || ipad)) }
Here, mastr is the master secret computed from the pre sent in the previous step, ipad and opad are as defined for the HMAC, and messages is the concatenation of messages 1 through 8.
The fourth round consists of acknowledgments between the server and the client. First, the client tells the server to begin using the cipher specified (using a “change cipher spec” message; see Section 11.4.2.4). The client updates its session and connection information to reflect the cipher it uses. It then sends a “finished” message. As for the preceding message, the client creates this message by hashing the previously sent messages; unlike the preceding one, it includes message 9. The SSL record layer applies the ciphers and MACs to this message.
C → S: { hash(mastr || opad || hash(messages || 0x434C4E54 || mastr || ipad)) }
The server responds with a “change cipher spec” message telling the client to use the ciphers that the server specified, and it updates its session and connection information accordingly. It then sends a “finish” message.
S → C: { hash(mastr || opad || hash(messages || 0x53525652 || mastr || ipad)) }
In both the client's and the server's “finish” message, the quantities are as for message 9, except that messages includes message 9.
At this point, enciphered communications can begin.
The change cipher spec protocol is a single byte. It is sent after new cipher parameters have been negotiated (or renegotiated). The new parameters are considered “pending” because the old parameters are in use. When this protocol message is received, the “pending” parameters become the parameters in use.
The alert protocol signals that an unusual condition exists. A closure alert signals that the sender will not send any more messages over the connection. All pending data is delivered, but any new messages are ignored.
All other alerts are error alerts. Errors are either warnings or fatal errors. In the latter case, as soon as the error is sent or received, the connection is torn down. The cause of the error and its type (warning or fatal) are independent; however, some errors are always fatal. Table 11-4 summarizes the error messages and their levels.
Table 11-4. SSL Alert Protocol Error Messages
Message | Level | Message | Level |
|---|---|---|---|
unexpected_message | fatal | no_certificate | warning, fatal |
bad_record_mac | fatal | bad_certificate | warning, fatal |
decompression_failure | fatal | unsupported_certificate | warning, fatal |
handshake_failure | fatal | certificate_revoked | warning, fatal |
illegal_parameter | fatal | certificate_expired certificate_unknown | warning, fatal warning, fatal |
This protocol simply passes data from the application layer to the SSL Record Protocol layer. The record protocol transports the data to the peer using the current compression and cipher algorithms.
IPsec is a collection of protocols and mechanisms that provide confidentiality, authentication, message integrity, and replay detection at the IP layer. Because cryptography forms the basis for these services, the protocols also include a key management scheme, which we will not discuss here.
Conceptually, think of messages being sent between two hosts as following a path between the hosts. The path also passes through other intermediate hosts. IPsec mechanisms protect all messages sent along a path. If the IPsec mechanisms reside on an intermediate host (for example, a firewall or gateway), that host is called a security gateway.
IPsec has two modes. Transport mode encapsulates the IP packet data area (which is the upper layer packet) in an IPsec envelope, and then uses IP to send the IPsec-wrapped packet. The IP header is not protected. Tunnel mode encapsulates an entire IP packet in an IPsec envelope and then forwards it using IP. Here, the IP header of the encapsulated packet is protected. (Figure 11-5 illustrates these modes.) Transport mode is used when both endpoints support IPsec. Tunnel mode is used when either or both endpoints do not support IPsec but two intermediate hosts do.
Figure 11-5. The packet on the left is in transport mode, because the body of the packet is encrypted but its header is not. The packet on the right is in tunnel mode, because the packet header and the packet body are both encrypted. The unencrypted IP header is used to deliver the encrypted packet to a system on which it can be decrypted and forwarded.
Two protocols provide message security. The authentication header (AH) protocol provides message integrity and origin authentication and can provide antireplay services. The encapsulating security payload (ESP) protocol provides confidentiality and can provide the same services as those provided by the AH protocol. Both protocols are based on cryptography, with key management supplied by the Internet Key Exchange (IKE) protocol (although other key exchange protocols, including manual keying, may be used).
IPsec mechanisms use a security policy database (SPD) to determine how to handle messages. Legal actions are discarding the message, applying security services to the message, and forwarding the message with no change. The action taken depends on information in the IP and transport layer headers.
IPsec mechanisms determine the security services needed on the basis of the SPD and the path that the packet takes.
When a packet arrives, the IPsec mechanism consults the SPD for the relevant network interface. The SPD determines which entry applies on the basis of the attributes of the packet. These attributes include the source and destination port and address, the transport layer protocol involved, and other data.
Entries are checked in order. If one has a different policy for securing electronic mail depending on its destination, the more specific entries are placed where they will be searched first. If no entry matches the incoming packet, it is discarded.
The heart of applying IPsec is the security association.
Definition 11–7. A security association (SA) is an association between peers for security services. The security association is unidirectional.
A security association is a set of security enhancements to a channel along which packets are sent. It is defined uniquely by the destination address, the security protocol (AH or ESP), and a unique 32-bit security parameter index (SPI). It defines the security protocol that is to be applied to packets sent over that association.
Each SA uses either ESP or AH, but not both. If both are required, two SAs are created. Similarly, if IPsec is to provide security between two peers in both directions, two SAs are needed.
When IPsec services are to be applied, the SPD entry identifies one or more security associations and parameters. The parameters describe how to determine which security association(s) to use to process the packet. This leads to the security association database (SAD), which consists of a set of selectors and corresponding security associations.
Each SAD entry contains information about the SA. Key fields are as follows.
The AH algorithm identifier and keys are used when the SA uses the AH protocol.
The ESP encipherment algorithm identifier and keys are used when the SA uses the confidentiality service of the ESP protocol.
The ESP authentication algorithm identifier and keys are used when the SA uses the authentication and data integrity services of the ESP protocol.
The lifetime of the SA is either the time at which the SA must be deleted and a new one formed or a count of the maximum number of bytes allowed over this SA.
The IPsec protocol mode is tunnel mode, transport mode, or a wildcard. If it is a wildcard, either protocol mode is acceptable. Security gateways need to support only tunnel mode, but host implementations must support both modes.
An additional field checks for replay in inbound packets.
The antireplay window field is used to detect replay (see Section 11.4.3.2). If the SA does not use the antireplay feature, this field is not used.
Outbound packets have sequence numbers.
The sequence number counter generates the AH or ESP sequence number.
The sequence counter overflow field stops further traffic over the SA if the sequence counter overflows.
Path Maximum Transmission Unit and aging variables detect time-outs.
When inbound traffic arrives, the destination address, security protocol, and SPI are used to find the associated SA in the SAD. This verifies the properties that the packet should have and enables the replay check (if desired). If the packet is to be forwarded, the SPD determines the relevant services, the appropriate services are supplied, and the packet is forwarded.
In some situations, multiple SAs may protect packets.
Definition 11–8. A security association bundle (SA bundle) is a sequence of security associations that the IPsec mechanisms apply to packets.
Tunnel mode SAs can be nested. This is called iterated tunneling and occurs when multiple hosts build tunnels through which they send traffic. The endpoints may be the same, although support for iterated tunneling is required only when at least one endpoint of the two tunnels is different. The tunnels may be entirely nested.
Iteration of transport mode SAs occurs when both the AH and ESP protocols are used. This is called transport adjacency, and when it is used, application of the ESP protocol should precede application of the AH protocol. The idea is that the ESP protocol protects the higher-layer (transport) protocol and the AH protocol protects the IP packet. Were the AH protocol to be applied first, the ESP protocol would not protect the IP packet headers.
It is instructive to examine the appearance of the packets in the example above. Figure 11-6 shows the packet layout as it travels between the two companies. Notice that the packet generated by frauds is encapsulated in another IP packet with the IPsec services applied to the inner packet. Both headers identify equity as the destination. When the packet arrives at gateway, the original IP header is (probably) not visible to gateway. In this case, the SAD and SPD use a special identifier to indicate that the source is obscured. (See Exercise 8.) The appropriate SA directs the packet to be encapsulated and forwarded to firewall, so the added IP header identifies firewall as the destination IP address. When the packet arrives at firewall, it uses the incoming packet's destination IP address (firewall), security protocol, and SPI to locate the SA. This bundle tells firewall to authenticate and decrypt the contents of the packet. The inner IP packet is then used to look up the appropriate action in the SPD, which (in this case) is to bypass IPsec. The packet is then forwarded to equity, which repeats the processing. The innermost IP packet is then forwarded to equity and processed.
Figure 11-6. An IPsec-protected packet going through nested tunnels. The filled rectangles represent headers. The rightmost IP header and the following data constitute the original packet. The IPsec mechanisms add the ESP, AH, and IP headers of frauds and forward the packet to gateway. This is the first SA and is in tunnel mode. The host gateway adds the ESP, AH, and IP headers shown, putting the packet into the second tunnel mode SA.
We now examine the AH and ESP protocols.
The goal of the authentication header (AH) protocol is to provide origin authentication, message integrity, and protection against replay, if desired. It protects static fields of the IP packet header as well as the contents of the packet.
The important parameters included in the AH header are an indication of the length of the header, the SPI of the SA under which this protocol is applied, a sequence number used to prevent replay, and an Integrity Value Check (IVC)[7] padded to a multiple of 32 bits (for IPv4) or 64 bits (for IPv6).
The AH protocol has two steps. The first checks that replay is not occurring. The second checks the authentication data.
When a packet is sent, the sender assumes that antireplay is used unless it is told otherwise. The sender first checks that the sequence number will not cycle. (If it will, a new SA must be created; see the discussion above.) It adds 1 to the current sequence number. The sender then calculates the IVC of the packet. The IVC includes all fields in the IP header that will not change in transit or that can be predicted (such as the destination field), the AH header (with the authentication data field set to 0 for this computation), and any encapsulated or higher-layer data. Mutable fields in the IP header (such as the type of service, flags, fragment offset, time to live, and header checksum fields) are set to 0 for this computation.
When a packet arrives, the IPsec mechanism determines if the packet contains an authentication header. If so, it uses the SPI and destination address to find the associated SA in the SAD. If no such SA exists, the packet is discarded. Otherwise, the key, IVC algorithm, and antireplay settings are obtained from the SAD entry.
If the antireplay service is desired, a “sliding window” mechanism checks that the packet is new. Think of the SA as operating on a stream of packets. Conceptually, the window contains slots for at least 32 packets. Each slot has the sequence number of the packet for that slot. When a packet arrives, the mechanism checks that the packet's sequence number is at least that of the leftmost slot in the window. If the packet's sequence number is to the left of the window, the packet is discarded. The IVC of the packet is then verified, and if it is incorrect, the packet is discarded. Otherwise, if the packet's sequence number lies within the window, but the slot with that sequence number is occupied, the packet is discarded. If the slot is empty, the packet is inserted into the slot. Finally, if the packet lies to the right of the window, the window is advanced to create a slot for the packet. The packet is then placed in that slot, which is the rightmost slot in the window.
If the antireplay service is not used, the IVC is verified. The IVC is computed in the same way as the sender (that is, appropriate fields are replaced by zeros) and is compared with the IVC in the AH. If the two differ, the packet is discarded.
All implementations of the AH protocol must support HMAC_MD5 and HMAC_SHA-1. They may support others as well.
The goal of the encapsulating security payload (ESP) protocol is to provide confidentiality, origin authentication, message integrity, protection against replay if desired, and a limited form of traffic flow confidentiality. It protects only the transport data or encapsulated IP data; it does not protect the IP header.
The important parameters included in the ESP header are the SPI of the SA under which this protocol is applied, a sequence number used to prevent replay, a generic “payload data” field, padding, the length of the padding, and an optional authentication data field.
The data in the payload data field depends on the ESP services enabled. For example, if an SA needs to resynchronize a cryptographic algorithm used in chaining mode, the sender could include an initialization vector here. As more algorithms for the ESP are defined, they may specify data to be included in this field.
Because the ESP protocol begins enciphering with the payload data field and protects both header fields and data, the IPsec mechanism may need to pad the packet in order to have the number of bits or bytes required by the cryptographic algorithm. The padding field allows for this adjustment. The padding length field contains the number of padding bytes; no more than 255 bytes of padding are allowed.
At least one of the confidentiality and authentication services must be selected. Furthermore, because packets may not arrive in order, any synchronization material must be carried in the payload field. Otherwise, the packets that follow a missing packet may be unintelligible.
When a packet is sent, the sender adds an ESP header, including any required padding, to the payload (either the transport data or an encapsulated IP packet). The sender enciphers the result (except for the SPI and sequence numbers). If authentication is desired, the authentication is computed as for the AH protocol, except that it is over the ESP header and payload. It does not include the IP header that encapsulates the ESP header and payload. The relevant SA dictates the cryptographic keys and algorithms that are used.
When a packet arrives, the IPsec mechanism determines if the packet contains an ESP header. If so, it uses the SPI and destination address to find the associated SA in the SAD. If no such SA exists, the packet is discarded. Otherwise, the SA parameters are obtained from the SAD entry.
If the authentication service is used, the antireplay feature and the MAC verification proceed as for the AH, again except that only the ESP and the payload are used. Because the authentication data is inserted after encipherment, it is not enciphered and so can be used directly.
If the confidentiality service is used, the IPsec mechanisms decipher the enciphered portion of the ESP header. Any padding is processed, and the payload is deciphered. If the SA specifies transport mode, the IP header and payload are treated as the original IP packet. If the SA specifies tunnel mode, the encapsulated IP packet is treated as the original IP packet.
Typical implementations of public key cryptosystems are far slower than implementations of classical cryptosystems. Hence, implementations of ESP assume a classical cryptosystem, although this is not required.
All implementations of ESP must support DES in CBC mode and the NULL encipherment algorithms, as well as the HMAC_MD5, HMAC_SHA-1, and NULL MACs. (The NULL encipherment algorithm and MAC mean that those algorithms are not used. Both should never be NULL at the same time.) Implementations may support other algorithms.
Each of the three protocols adds security to network communications. The “best” protocol to use depends on a variety of factors.
To what do the requisite security services apply? If they are specific to one particular application, such as remote logins, then using a program with application layer security is appropriate. When a program that requires security services is used in an environment that does not supply those services, or that the user does not trust to supply the requisite services, the application should supply its own security.
If more generic services are needed, lower-layer security protocols can supply security services to multiple applications and can do so whether or not the application has its own mechanisms for security services. Transport layer protocols such as SSL are end-to-end security mechanisms. They are appropriate when the intermediate hosts are not trusted, when the end hosts support the transport protocol, and when the application uses a connection-oriented (transport) protocol. Network layer mechanisms such as IPsec may provide security services on either an end-to-end or a link basis. They are appropriate when securing connectionless channels or when the infrastructure supports the network layer security mechanisms.
The application layer security protocol PEM provides security services for electronic mail messages. Consider using SSL for this goal. SSL does not authenticate the message to the recipient; it merely authenticates the transport connection. Specifically, if Alice sends Bob a message, PEM will authenticate that Alice composed the message and that Bob received it unaltered (and possibly that the message was kept confidential). SSL can authenticate that Alice sent the message to Bob, that it arrived as sent, and possibly that it was confidential in transit. SSL does not verify that Alice composed the message or that the message was confidential and unchanged on Alice's system or Bob's system. In other words, SSL secures the connection; PEM secures the electronic mail (the contents of the connection). Similarly, IPsec protects the packets and their contents in transit, but authentication is of the hosts and not of Alice or Bob.
If one uses a cryptosystem without considering the protocols directing its use, the security service that the cryptosystem is to provide can be deficient. Precomputation attacks, assumptions about message sizes, and statistical attacks can all compromise messages.
Stream and block ciphers have different orientations (bits and blocks, respectively) that affect solutions to these problems. Stream ciphers emulate a one-time pad either through an externally keyed source (such as an LFSR, which generates a stream of key bits from an initial seed) or internally (such as the autokey ciphers or through feedback modes). Block ciphers emulate “code books” in which a set of bits maps to a different set of bits. (In practice, the mapping is algorithmic.)
Over a network, cryptographic protocols and cryptosystems are the basis for many security services, including confidentiality, authentication, integrity, and nonrepudiation. These services can be provided at different layers, depending on the assumptions about the network and the needs of the servers and clients.
Cryptographic protocols are the foundation of many security mechanisms and are sensitive to the assumptions inherent in their environments. As with authentication protocols, a critical area of research is to verify that protocols provide the services they claim to provide. Another area is to determine what assumptions are relevant to the protocol. For example, is a trusted server required? How could one modify the protocol so it would work without such a server (or prove that the protocol cannot work)?
Designing protocols for the Internet, or for any large, heterogeneous internet, requires flexibility without sacrificing security. The problem is as much political as technical. When several suitable protocols can solve a particular problem, different sites will try different protocols. During this process, some protocols will prove inadequate, others will need modification, and some will work. The resulting protocols may coexist or may be combined. Determining which protocol is the “best” is an open research topic.
Deriving modes of cryptosystems (such as CFB and OFB), and proving properties related to them, is another open research area.
Seberry and Pieprzyk [897] and Denning [269] discuss the theory of linear feedback shift registers. Schneier [888] presents a variant called Feedback Carry Shift Registers. Beker and Piper [66] discuss stream ciphers. Rueppel analyzes design criteria for stream ciphers [857]. Several papers discuss the RC4 keystream generator's strength [360, 404, 719].
Bellovin [72] discusses security problems in many Internet protocols; Kent [562] provides a different perspective. Two groups use different techniques to analyze the security of SSL [720, 1027]. Oppliger [787], Stallings [960], and Doraswamy and Harkins [309] present overviews of IPsec. Bellovin [74] discusses the cryptographic security of IPsec. Bishop [112] examines the Network Time Protocol NTPv2. Ylönen presents SSH, a protocol for secure remote logins [1065]. Vincenzetti, Taino, and Bolognesi add security mechanisms to Telnet [1015]. Vixie [1018] and Bellovin [73] discuss issues related to the Directory Name Services.
1: | Let the function f for a four-stage NLFSR be f(r0…rn–1) = (r0 and r1) or r3, and let the initial value of the register be 1001. Derive the initial sequence and cycle. |
2: | An n-stage LFSR produces a sequence with a period of length at most 2n – 1, but the register has n bits and thus may assume 2n values. Why can the length of the period never be 2n? Which register value is excluded from the cycle, and why? |
3: | Consider double encryption, where c = Ek'(Ek(m)) and the keys k and k' are each n bits long. Assume that each encipherment takes one time unit. A cryptanalyst will use a known plaintext attack to determine the key from two messages m0 and m1 and their corresponding ciphertexts c0 and c1.
|
4: | A network consists of n hosts. Assuming that cryptographic keys are distributed on a per-host-pair basis, compute how many different keys are required. |
5: | One cryptographic checksum is computed by applying the DES in CBC mode to the message or file and using the last n bits of the final enciphered block as the checksum. (This is a keyed hash; the parties must agree on the key and the initalization vector used.) Analyze this hash function. In particular, how difficult is it to find two different messages that hash to the same value? How difficult is it to generate a second message that produces the same hash value as the first message? |
6: | A variant of the autokey cipher is to pick a well-known book and use its text, starting at some agreed-upon location. For example, the plaintext |
7: | Unlike PEM, PGP requires the user to set a flag to indicate whether the file being protected is text or binary data. Explain why such a flag is necessary. Why does PEM not require such a flag? |
8: | Redraw Figure 11-6 assuming that the SA between frauds and equity is a transport mode SA rather than a tunnel mode SA. |
9: | When the IVC for the AH protocol is computed, why are mutable fields set to 0 rather than omitted? |
10: | Section 11.4.4 discusses the use of SSL to provide confidentiality, authentication, and integrity security services for electronic mail and suggests that PEM is more appropriate. Consider a remote login protocol in the same context. In answering the following questions, please state explicitly any assumptions that you make.
|
[1] The dot stuffing convention (so that a line containing a single “.” is not seen as a message terminator) is not used (see Section 4.3.2.2 of RFC 1421 [634]).
[2] The character set is drawn from parts of the international alphabet IA5 common to most other alphabets.
[3] This is another term for a message integrity check (MIC); we use the SSL protocol specification term here for consistency.
[4] If the client is not using RSA, the server sends a certificate appropriate for the cryptosystem in use.
[5] If DSS is used, the server sends the modulus, generator, and public value. If Fortezza is used, the random number for the key exchange algorithm is sent (and no hash is appended).
[6] If Diffie-Hellman is used, and a Diffie-Hellman certificate was sent, this message is empty; otherwise, it contains the client's public value. If Fortezza is used, this message contains its parameters, including the client's public key.
[7] This is another term for a message integrity check (MIC); we use the AH protocol specification term here for consistency.