# Secure Channel We have learned how to protect individual messages with cryptography. Now we protect entire conversations. **Threat:** A Dolev–Yao attacker. **Harm:** The contents of a conversation can be learned (violating confidentiality) or changed (violating integrity) by the attacker. **Vulnerability:** The conversation is held over a communication channel that is controlled by principals other than the sender and receiver. **Countermeasure:** Cryptography, including encryption, MACs, and hashes, and some new techniques that we will introduce. What is a "secure channel"? As we're using the term, a *channel* is a means for bidirectional communication between two principals, who we'll call Alice and Bob. We think of Alice as the initiator of the conversation, though of course Alice and Bob might well have multiple conversations going in parallel in which either one of them might be the initiator. So "Alice" and "Bob" here are really roles rather than identities. The communication might occur spatially over a network, or temporally over a storage device. In the latter case, a principal might even have a conversation with itself. As for *secure*, we want to achieve these goals: 1. The channel does not reveal anything about messages except for their timing and size. (Confidentiality) 2. If Alice sends a sequence of messages m1, m2, ... then Bob receives a subsequence of that, and furthermore Bob knows which subsequence. And the same for Bob sending to Alice. (Integrity) We do not attempt to achieve any kind of anonymity or availability. Nor do we attempt to defend against *traffic analysis*: leakage of information based on who is communicating with whom and how much. ## Authenticated encryption To protect both confidentiality and integrity, the cryptographic primitive you want is called *authenticated encryption*. There are three generic ways of constructing authenticated encryption out of a standard block cipher and MAC. All three are used in real-world protocols. - **Encrypt and MAC.** Encrypt the message. Separately MAC the message under a different shared key. Send both the ciphertext and the tag. This algorithm is probably the worst of the three, because the tag could reveal information about the plaintext. Secure Shell (ssh) uses this algorithm in a safe way. - **Encrypt then MAC.** Encrypt the message. MAC the resulting ciphertext. Send both the ciphertext and the tag. This is provably the most secure of the three algorithms; IPsec uses it. - **MAC then Encrypt.** MAC the plaintext message. Encrypt the message and the tag together. Send the resulting ciphertext. As long as the MAC algorithm is strong enough (and HMAC is), this algorithm is just as secure as the previous one. SSL uses this algorithm. There are also block cipher modes that are specifically designed to achieve both confidentiality and integrity. *Galois/Counter Mode* (GCM) is a popular choice, because it has high performance and is not encumbered by patents. Let's unify these three constructions with a pair of algorithms: * AuthEnc(m; ke; km): produce an authenticated ciphertext x of message m under encryption key ke and MAC key km. * AuthDec(x; ke; km): recover the plaintext message m from authenticated ciphertext x, and verify that the MAC is valid, using ke and km. Abort if MAC is invalid. ## Message numbers To help ensure the integrity property, we use *message numbers* aka *sequence numbers*. Every message that Alice sends is numbered 1, 2, 3, and so forth. Bob keeps state to remember the last message number he received; he accepts only increasing message numbers. The same goes for Bob sending messages to Alice. So each principal keeps two independent counters: one for messages sent, another for messages received. What happens if Bob detects a gap? e.g. he receives 1, 2, 5, but 3 and 4 are missing. Maybe Mallory deleted messages 3 and 4 from network, or maybe she detectably changed 3 and 4, causing Bob to discard them. In either case, the channel is under active attack. This would be a good time to panic. Bob aborts the protocol, produces appropriate information for later auditing, and shuts down the channel. Note that we assume the underlying network transport protocol (e.g., TCP) is itself guaranteeing in-order message delivery and attempting to retry messages that are dropped. If we wanted to build atop an unreliable transport protocol (e.g., UDP), we'd have to make the secure channel itself more complicated. That would be in tension with Economy of Mechanism. Message numbers are usually implemented as a fixed-size unsigned integer, e.g., 32 or 48 or 64 bits. What if that `int` overflows and wraps back around to 0? The conversation must stop at that point, though of course the principals could start a new conversation. Otherwise, Mallory could begin replaying messages from earlier in the conversation. ## Key derivation Let's assume that Alice and Bob already share a session key k for the purpose of the conversation; we'll address how they get that key later. For now, note that a single key isn't good enough: authenticated encryption will require both an encryption key and a MAC key, and under the principle that every key should have a unique purpose we should even have separate keys for sending from Alice to Bob and for sending from Bob to Alice. So we really need four keys: 1. kea: Encrypt Alice to Bob 2. keb: Encrypt Bob to Alice 3. kma: MAC Alice to Bob 4. kmb: MAC Bob to Alice How can we *derive* new keys from the one we already have? We use a cryptographic hash function H: 1. kea = H(k, "Enc Alice to Bob") 2. keb = H(k, "Enc Bob to Alice") 3. kma = H(k, "MAC Alice to Bob") 4. kmb = H(k, "MAC Bob to Alice") Hashing destroys any structure in its input, producing random looking output, which can be truncated to the appropriate size for whatever Enc or MAC scheme we're using. Because of the collision-resistance property of H, it's unlikely any of the four keys will turn out to be the same. And because of the one-way property of H, even if one of the four keys ever leaks to the adversary, it's hard to invert the hash to recover k and get the other keys. There is an issue, though, with whether the output of H is compatible with the keys that are produced by the Gen algorithms. For most block ciphers and MACs, this turns out not to be a problem: they happily take any uniformly random sequence of bits of the right length as keys. But for (deprecated) DES, it is a problem, because there are *weak keys* that DES's Gen would reject. It's easy to check for those, though. For many asymmetric algorithms, the output of a hash would not work as a key, because the keys must satisfy certain algebraic properties that depend on the number theory involved. ## Protocol Our resulting protocol for a secure channel is as follows. We assume that A and B already share a key k. From it they derive separate keys for encryption and MACing in both directions. After that, they can send messages to one another. For A to send a message to B: ``` 1. A: increment sent_ctr; if sent_ctr overflows then abort; x = AuthEnc(sent_ctr, m; kea; kma) 2. A -> B: x 3. B: i,m = AuthDec(x; kea; kma); increment rcvd_ctr; if i != rcvd_ctr then abort; output m ``` And for B to send a message to A: ``` 1. B: increment sent_ctr; if sent_ctr overflows then abort; x = AuthEnc(sent_ctr, m; keb; kmb) 2. B -> A: x 3. A: i,m = AuthDec(x; keb; kmb); increment rcvd_ctr; if i != rcvd_ctr then abort; output m ``` In the next lecture we'll talk about how A and B can establish a shared key k. ## Exercises 1. Do some research to find out how Counter with CBC-MAC (CCM) mode works. It is a block cipher mode designed for authenticated encryption. It uses only one key, not two, which contradicts the principle we identified about unique key usage. Why is that contradiction believed to be safe for CCM? Also, which of the three ways of combining Enc with MAC does CCM use? 2. Suppose that the message counter were a 32-bit unsigned integer, and that the encryption algorithm used is AES. How many gigabytes could you send before the message counter overflows? How does that compare to the length of a single movie? An entire TV series? What do you conclude about the sufficiency of a 32-bit counter for most applications? 3. Explain the advantages and disadvantages of each of the three ways of combining Enc with MAC for authenticated encryption. Which does [FSK][fsk] recommend, and what is their rationale? 4. The secure channel we built does not have anonymity of the participants as a security goal. In 1981, David Chaum invented a cryptographic primitive called a *mix network* to achieve anonymity. Read his [original paper][chaum81]. Explain how that paper uses layers of encryption to achieve anonymity. [fsk]: https://newcatalog.library.cornell.edu/catalog/9306807 [chaum81]: http://dl.acm.org/citation.cfm?doid=358549.358563