CS 378 Key Establishment Pitfalls Vitaly Shmatikov slide

CS 378 Key Establishment Pitfalls Vitaly Shmatikov slide 1

Secure Sessions u. Secure sessions are one of the most important applications in network security • Enable us to talk securely on an insecure network u. Goal: secure bi-directional communication channel between two parties • The channel must provide confidentiality – Third party cannot read messages on the channel • The channel must provide authentication – Each party must be sure who the other party is • Other desirable properies: integrity, protection against denial of service, anonymity against eavesdroppers 2

Key Establishment Protocols u. Common implementation of secure sessions: establish a secret key known only to two parties • Can then use block ciphers for confidentiality, HMAC for authentication, and so on u. Challenge: how to establish a secret key using only public information u. Even if the two parties share a long-term secret, a fresh key should be created for each session • Long-term secrets are valuable; want to use them as sparingly as possible to limit exposure and the damage if the key is compromised 3

Key Establishment Techniques u. Use a trusted key distribution center (KDC) • Every party shares a pairwise secret key with KDC • KDC creates a new random session key and then distributes it, encrypted under the pairwise keys – Example: Kerberos u. Use public-key cryptography • Diffie-Hellman authenticated with signatures – Example: IKE (Internet Key Exchange) • One party creates a random key, sends it encrypted under the other party’s public key – Example: TLS (Transport Layer Security) 4

Private-Key Needham-Schroeder KDC Fresh, random nonce Creates fresh random session key KAB (knows secret keys KAlice and KBob) N 1, “I’m Alice, wanna talk to Bob” Encrypt. KAlice(N 1, “Bob”, KAB, Encrypt. KBob(KAB, “Alice”)) ticket Alice ticket, Encrypt. KAB(N 2) Another nonce Encrypt. KAB(N 2 -1, N 3) Yet another nonce Encrypt. KAB(N 3 -1) Bob 5

Weird Reflection Attack u. Suppose symmetric encryption is in ECB mode… • Bad idea in general Replay an old message from Alice’s ticket, Encrypt. KAB(N 2) Encrypt. KAB(N 2 -1, N 3) Can’t decrypt, but in ECB mode can extract Encrypt. KAB(N 3) Open a new session with Bob… Alice’s ticket, Encrypt. KAB(N 3) Extract Encrypt. KAB(N 3 -1) Bob Encrypt. KAB(N 3 -1, N 4) Now successfully authenticate in first session… Encrypt. KAB(N 3 -1) 6

Otway-Rees Protocol KDC Creates fresh random session key KAB (knows secret keys KAlice and KBob) NC, Encrypt. KAlice(NA, KAB), Encrypt. KBob(NB, KAB), This nonce is sent in the clear This nonce is hidden from Bob’s own nonce NC, “Alice”, “Bob”, Encrypt. KAlice(NA, NC, “Alice”, “Bob”) NC, Encrypt. KAlice(NA, KAB) Alice Encrypt. KAlice(NA, NC, “Alice”, “Bob”) Encrypt. KBob(NB, NC, “Alice”, “Bob”) Encrypt. KAB(anything recognizable) Bob 7

Brief Analysis of Otway-Rees KDC (knows secret keys KAlice and KBob) If NC is predictable, attacker can send a bogus message to Bob and fool him into creating Encrypt. KBob(NB, NC, “Alice”, “Bob”). When Alice actually uses N C, attacker will be able to impersonate Bob to KDC. NC, Encrypt. KAlice(NA, KAB), Encrypt. KBob(NB, KAB), Encrypt. KAlice(NA, NC, “Alice”, “Bob”) Encrypt. KBob(NB, NC, “Alice”, “Bob”) NC, “Alice”, “Bob”, Encrypt. KAlice(NA, NC, “Alice”, “Bob”) NC, Encrypt. KAlice(NA, KAB) Alice Match between these values is the only thing that authenticates Bob to KDC Encrypt. KAB(anything recognizable) Bob u Lesson: randomness of nonces is essential 8

Public-Key Needham-Schroeder Alice’s nonce Encrypt. Public. Key(Bob)(“Alice”, NA) Bob’s nonce Encrypt. Public. Key(Alice)(NA, NB) Alice Encrypt. Public. Key(Bob)(NB) Bob Create new key from NA and NB, e. g. , NA NB Alice’s reasoning: • The only person who could know NA is the person who decrypted 1 st message • Only Bob can decrypt message encrypted with Bob’s public key • Therefore, Bob is on the other end of the line Bob is authenticated! Bob’s reasoning: • The only way to learn NB is to decrypt 2 nd message • Only Alice can decrypt 2 nd message • Therefore, Alice is on the other end Alice is authenticated! 9

Attack on Needham-Schroeder [published by Gavin Lowe] Encrypt. Public. Key(Bob)(“Alice”, NA) Alice Encrypt. Public. Key(Alice)(NA, NC) Encrypt. Public. Key(Bob)(NC) Bob can’t decrypt this message, but he can replay it to Alice Evil Bob tricks honest Alice into revealing Charlie’s secret Nc Evil Bob pretends that he is Alice Encrypt. Public. Key(Alice)(NA, NC) Charlie is convinced that he is talking to Alice! Encrypt. Public. Key(Charlie) (“Alice”, NA) Charlie 10

Lessons of Needham-Schroeder u. Yet another example of faulty reasoning • Alice is correct that Bob must have decrypted Encrypt. Public. Key(Bob)(“Alice”, NA), but this does not mean that Encrypt. Public. Key(Alice)(NA, NB) came from Bob u. It is important to realize limitations of protocols • The attack requires that Alice willingly talk to attacker – Attacker uses a legitimate conversation with Alice to impersonate Alice to Charlie • Needham and Schroeder intended this protocol to be used by well-behaved workstations on an insecure network. In their setting, the protocol is correct! 11