# 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