# 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.
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
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
- **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
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:
if sent_ctr overflows then abort;
x = AuthEnc(sent_ctr, m; kea; kma)
2. A -> B: x
i,m = AuthDec(x; kea; kma);
if i != rcvd_ctr then abort;
And for B to send a message to A:
if sent_ctr overflows then abort;
x = AuthEnc(sent_ctr, m; keb; kmb)
2. B -> A: x
i,m = AuthDec(x; keb; kmb);
if i != rcvd_ctr then abort;
In the next lecture we'll talk about how A and B can establish a shared key k.
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.