<![CDATA[
# Key Establishment
How can Alice and Bob arrange to share a key k? They run
a *key establishment protocol*. In these protocols,
a *user* is a principal who will use the generated session key
for further communication; other principals might be involved
but won't learn or use the key. A *key transport protocol*
is used to generate a session key by **one** principal then transfer it
to all users. A *key agreement protocol*, on the other hand,
generates a session key as a function of inputs from **all** users
and transfers it to all users.
[Boyd (1993)][boyd93] proved a theorem showing that it is impossible to
establish secure channels between principals who do not already
(i) share a key with each other, or
(ii) separately share a key with a trusted third party, or
(iii) have the means to ascertain a public key for each other.
In other words, you can't get something for nothing.
[boyd93]: http://ieeexplore.ieee.org/document/223872/
## Trusted third party
Let's build a key transport protocol using assumption (ii):
Alice and Bob already share a key with a trusted server who gets
to pick the session key. This seemingly small task turns out
to be remarkably difficult.
**Assume:** A trusted server S with whom A shares long-term key kAS
and B shares long-term key kBS.
**Output:** A new session key kAB generated by S (who can then
immediately forget it)
**Security goals:**
* Goal 1. Only A and B (and S) know kAB. (Confidentiality)
* (more to come...)
**Protocol 1.**
```
1. A -> S: A, B
2. S -> A: kAB
3. A -> B: A, kAB
```
Protocol 1 obviously doesn't satisfy the confidentiality goal.
By *eavesdropping*, the adversary trivially learns kAB.
**Protocol 2.**
As a countermeasure against the eavesdropping attack, we add encryption
to the protocol.
```
1. A -> S: A, B
2. S -> A: Enc(kAB;kAS), Enc(kAB;kBS)
3. A -> B: A, Enc(kAB;kBS)
```
Protocol 2 seems to achieve the confidentiality goal. But consider the following
*man-in-the-middle* (MITM) attack on the protocol by Mallory:
```
1. A -> S: A, B
2. S -> A: Enc(kAB;kAS), Enc(kAB;kBS)
3. A -> M: A, Enc(kAB;kBS)
3'. M -> B: A, Enc(kAB';kBS)
```
In step 3', kAB' is a different key than the one A intended for B
to receive. M might have some influence over that key, perhaps
even knowing some bits of it.
As a countermeasure, we can require the encryption scheme to be
*non-malleable*, meaning that it prevents the adversary from
undetectably transforming one ciphertext into another related ciphertext.
Authenticated encryption is one way to achieve non-malleability.
Henceforth, we assume Enc is non-malleable.
Even with that assumption, here is another MITM attack:
```
1. A -> S: A, B
2. S -> A: Enc(kAB;kAS), Enc(kAB;kBS)
3. A -> M: A, Enc(kAB;kBS)
3'. M -> B: C, Enc(kAB;kBS)
```
In step 3', C is any principal identifier other than A. Now B
believes he shares kAB with C rather than A. That's clearly not
what we intended to have happen.
So let's add a new security goal:
* Goal 2: Users associate the correct shared key with the correct principal
identities. (Integrity)
Here's an even worse MITM attack:
```
1. A -> M: A, B
1'. M -> S: A, M
2. S -> M: Enc(kAM;kAS), Enc(kAM;kMS)
2'. M -> S: Enc(kAM;kAS), Enc(kAM;kMS)
3. A -> M: A, Enc(kAM;kMS)
```
Now M knows the shared key, violating Goal 1, and
A believes the key is shared with B rather than M, violating Goal 2.
**Protocol 3.**
As a countermeasure against those MITM attacks, we add principal's names
to messages.
```
1. A -> S: A, B
2. S -> A: Enc(B,kAB;kAS), Enc(A,kAB;kBS)
3. A -> B: Enc(A,kAB;kBS)
```
Now M cannot change the messages as she did before. But there are still
ways M can abuse the protocol. For example, M could *replay* messages
from old executions of the protocol:
```
1. A -> M: A, B
2. M -> A: Enc(B,old_kAB;kAS), Enc(A,old_kAB;kBS)
3. A -> B: Enc(A,old_kAB;kBS)
```
This attack could result in A and B replaying an old conversation (perhaps
causing A to repeat an order for goods, or repeat a payment, etc.). Maybe
M has even cracked old_kAB in the meantime, thus allowing her to manipulate
the new conversation. Neither of those is desirable. So let's add another
security goal:
* Goal 3: The session key is *fresh*. (Integrity)
We'll achieve that goal by employing nonces as part of a
*challenge–response* protocol.
**Protocol 4.** [Needham and Schroeder 1978]
```
1. A -> S: A, B, nA
2. S -> A: Enc(B, nA, kAB, Enc(A, kAB; kBS); kAS)
3. A -> B: Enc(A, kAB; kBS)
4. B -> A: Enc(nB; kAB)
5. A -> B: Enc(nB-1; kAB)
```
Here, nA and nB are unique nonces chosen by A and B.
This is a well-known protocol that is the grandfather of many others.
One weakness with it is that, if kAB is ever disclosed to M, then
M could use it to start a new conversation with B simply by resuming
the protocol at step 3.
**Protocol 5.** [Bauer et al. 1983]
Another way to defend against the attack on Needham–Schroeder is by
using nonces contributed by both users to the server:
```
1. B -> A: B, nB
2. A -> S: A, B, nA, nB
3. S -> A: Enc(B, nA, kAB; kAS), Enc(A, nB, kAB; kBS)
4. A -> B: Enc(A, nB, kAB; kBS)
```
**Protocol 6.** [Denning and Sacco 1981]
Another way to defend against that attack on Needham–Schroeder is by
assuming synchronized clocks and using timestamps:
```
1. A -> S: A, B
2. S -> A: Enc(B, tS, kAB, Enc(A, tS, kAB; kBS); kAS)
3. A -> B: Enc(A, tS, kAB; kBS)
```
Here, tS is the time at S's local clock when it constructs message 2.
A and B must reject any messages that are not within tS±δ
for some bound δ, which might be on the order of seconds, minutes,
or hours.
**Lessons learned:**
Designing even a simple cryptographic protocol is hard. The attacks aren't
obvious, nor are the security goals. We ended up with a few;
there are many more contemplated in literature.
## Public keys
If A and B already known each other's public key, we can do without the
trusted third party.
**Protocol 7.** [again, Needham and Schroeder 1978]
```
1. A -> B: Enc(A, nA; KB)
2. B -> A: Enc(nA, nB; KA)
3. A -> B: Enc(nB; KB)
```
From nA and nB, a shared key can be derived with a key derivation function.
For example, the shared key might be H(nA, nB).
There is a MITM attack possible on this protocol, assuming that M can
get A to begin a run of the protocol with her:
```
1. A -> M: Enc(A, nA; KM)
1'. M -> B: Enc(A, nA; KB)
2'. B -> M -> A: Enc(nA, nB; KA)
3. A -> M: Enc(nB; KM)
3'. M -> B: Enc(nB; KB)
```
M has successfully impersonated A to B.
It wasn't until 1996 that Gavin Lowe discovered this attack. His defense
has become known as the Needham-Schroeder-Lowe protocol. The defense
is just adding B's name to message 2:
```
1. A -> B: Enc(A, nA; KB)
2. B -> A: Enc(B, nA, nB; KA)
3. A -> B: Enc(nB; KB)
```
## Nothing shared
If A and B don't already share something, they can't create a secure
channel. But they can get something that might be good enough for their
needs. They can create a channel that is secured against an adversary
reading or changing their messages. The catch is, they can't be sure
who's on the other end of the channel. It's like having a secure phone
line to an unknown person. The famous protocol for this is due to Diffie
and Hellman (1976), from the same paper that introduced public-key
cryptography.
## Exercises
1. Read [Boyd and Mathuria][bm], chapter 2, with the objective of being
able to explain Figure 2.1: what are "mutual belief in key", "key confirmation",
"entity authentication", etc.?
2. We were concerned above about replay attacks resulting from the adversary
learning old session keys. But what about if the adversary learns the
long-term shared keys (e.g., kAS) that themselves are used to protect
the session keys? With the protocols above, leakage of the long-term
keys immediately can reveal the session keys. A protocol that offers
*forward secrecy* can defend against such leakage: compromise
of the long-term key does not imply compromise of session keys
with a forward-secret protocol. Here is a protocol that provides forward secrecy:
```
1. A -> B: K, nA, Sign(B, k; kA)
2. B -> A: Enc(kAB; K), Sign(A, nA, h(kAB); kB)
```
The protocol assumes that A and B already share verification keys
KA and KB. Key K is an *ephemeral* public key for which A knows the private
key; it is used only for one run of this protocol then is destroyed.
Explain how this protocol guarantees forward secrecy.
3. Do some research to find out the (quite approachable) number theory
on which Diffie-Hellman is based. Show how Mallory can carry out
a MITM attack in which although Alice and Bob are attempting
to agree on a key, it instead turns out that Alice and Mallory share one
key, Mallory and Bob share a different key, and Alice and Bob have
no idea that anything has gone wrong.
4. After doing exercises 2 and 3, read the original
[Off-the-Record (OTR) Communication][otr] paper.
(Disclaimer: that's the original version of the protocol; it's now in version 3.)
Explain the security goals achieved by the protocol.
Write your own protocol narration for it.
[bm]: https://newcatalog.library.cornell.edu/catalog/9042869
[otr]: https://otr.cypherpunks.ca/otr-wpes.pdf
]]>