slide 1 Vitaly Shmatikov CS 378 Key Establishment Pitfalls

slide 2 Secure Sessions uSecure sessions are one of the most important applications in network security Enable us to talk securely on an insecure network uGoal: 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

slide 3 Key Establishment Protocols uCommon 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 uChallenge: how to establish a secret key using only public information uEven 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

slide 4 Key Establishment Techniques uUse 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 uUse 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)

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

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

slide 7 Otway-Rees Protocol AliceBob KDC (knows secret keys K Alice and K Bob ) Creates fresh random session key K AB N C, “Alice”, “Bob”, Encrypt K Alice (N A,N C,“Alice”,“Bob”) N C, Encrypt K Alice (N A, K AB ) Encrypt K AB (anything recognizable) This nonce is sent in the clearThis nonce is hidden from Bob Encrypt K Alice (N A,N C,“Alice”,“Bob”) Encrypt K Bob (N B,N C,“Alice”,“Bob”) Bob’s own nonce N C, Encrypt K Alice (N A,K AB ), Encrypt K Bob (N B,K AB ),     

slide 8 Brief Analysis of Otway-Rees AliceBob KDC (knows secret keys K Alice and K Bob ) N C, “Alice”, “Bob”, Encrypt K Alice (N A,N C,“Alice”,“Bob”) N C, Encrypt K Alice (N A, K AB ) Encrypt K AB (anything recognizable) Encrypt K Alice (N A,N C,“Alice”,“Bob”) Encrypt K Bob (N B,N C,“Alice”,“Bob”) N C, Encrypt K Alice (N A,K AB ), Encrypt K Bob (N B,K AB ),      Match between these values is the only thing that authenticates Bob to KDC If N C is predictable, attacker can send a bogus message to Bob and fool him into creating Encrypt K Bob (N B,N C,“Alice”,“Bob”). When Alice actually uses N C, attacker will be able to impersonate Bob to KDC. uLesson: randomness of nonces is essential

slide 9 Public-Key Needham-Schroeder Alice Bob Encrypt PublicKey(Bob) (“Alice”, N A ) Encrypt PublicKey(Alice) (N A, N B ) Encrypt PublicKey(Bob) (N B ) Alice’s nonce Bob’s nonce Create new key from N A and N B, e.g., N A  N B Alice’s reasoning: The only person who could know N A 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 N B is to decrypt 2 nd message Only Alice can decrypt 2 nd message Therefore, Alice is on the other end Alice is authenticated!

slide 10 Encrypt PublicKey(Bob) (“Alice”, N A ) Evil Bob tricks honest Alice into revealing Charlie’s secret N c Charlie is convinced that he is talking to Alice! [published by Gavin Lowe] Attack on Needham-Schroeder Alice Bob Bob can’t decrypt this message, but he can replay it to Alice Encrypt PublicKey(Alice) (N A, N C ) Evil Bob pretends that he is Alice Charlie Encrypt PublicKey(Charlie) (“Alice”, N A ) Encrypt PublicKey(Alice) (N A, N C ) Encrypt PublicKey(Bob) (N C )

slide 11 Lessons of Needham-Schroeder uYet another example of faulty reasoning Alice is correct that Bob must have decrypted Encrypt PublicKey(Bob) (“Alice”, N A ), but this does not mean that Encrypt PublicKey(Alice) (N A, N B ) came from Bob uIt 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!