1. CNS2010handout 12 :: crypto protocols1 ELEC5616 computer and network security matt barrie mattb@ee.usyd.edu.au

2. CNS2009handout 12 :: crypto protocols2 man in the middle Problem: (Diffie-Hellman) AliceBob “hello I’m Alice” g x mod p g a mod p Session key = h(g ax mod p) Eve “hello I’m Alice” g b mod p g x mod p Session key = h(g bx mod p) Eve owns the channel!

3. CNS2009handout 12 :: crypto protocols3 man in the middle Problem: (Key Exchange with Public Key Crypto) AliceBob “Alice”, e A e Y (“launch missiles at Eve”) Eve “Bob”, e B “Alice”, e X “Bob”, e Y e B (“disarm missile system”) Eve owns the channel!

4. CNS2009handout 12 :: crypto protocols4 session hijacking Problem: Eve owns the channel! AliceBob “hello I’m Alice” nonce r sign A (r) verify signature pick random r Eve “thanks guys, I’ll take it from here”

5. CNS2009handout 12 :: crypto protocols5 EKE - encrypted key exchange Alice and Bob share a secret key k A (possibly low entropy) shared secret k is used to form a high entropy shared secret h(g xy ) Prevents eavesdropping Prevents an active attack on Diffie-Hellman Forward secrecy What’s the obvious problem? AliceBob “hello” E k [g x mod p] random y random x E k [g y mod p] Session key = h(g xy mod p)

6. CNS2009handout 12 :: crypto protocols6 definitions A protocol is said to have perfect forward secrecy if disclosure of long term keys does not compromise past (short term) session keys. A protocol is vulnerable to a known-key attack if disclosure of past session keys allows an attacker to compromise future session keys (including actively impersonating)

7. CNS2009handout 12 :: crypto protocols7 needham-schroeder protocol (key exchange with TTP) Alice and Bob want to setup a session key for communications. –We will denote encryption of m by key k as {m} k All parties share a key with Trent, a trusted third party. Alice → Trent: “A”, “B”, r A –Alice asks Trent to talk to Bob (r A is a nonce) Trent → Alice: {r A, “B”, K AB, {K AB, “A”} K BT } K AT –Trent sends Alice a session key and ticket to give Bob Alice → Bob: {K AB, “A”} K BT, {r A2 } K AB –Alice sends to Bob the ticket (session key) Bob → Alice: {r A2 -1, r B } K AB –Bob challenges Alice (r B is a nonce) Alice → Bob: {r B - 1} K AB –Alice responds

8. CNS2009handout 12 :: crypto protocols8 needham-schroeder protocol Question: What happens if Eve gets a hold of K AT somehow? Alice → Trent: “A”, “B”, r A Trent → Alice: {r A, “B”, K AB, {K AB, “A”} K BT } K AT Alice → Bob: {K AB, “A”} K BT, {r A2 } K AB Bob → Alice: { r A2 -1, r B } K AB Alice → Bob: {r B - 1} K AB

9. CNS2009handout 12 :: crypto protocols9 needham-schroeder protocol Problem: Bob has no guarantee K AB is fresh (new) –Old session keys are valuable as they do not expire If Eve manages to get K AT she can read all of Alice’s messages and impersonate her to everyone else (e.g Carol). Alice informs everyone she has been issued a key for to revoke it. Since Alice does not know if Eve impersonated her to someone she has never talked to (e.g. Carol), she has to get Trent to tell everyone “stop using all shared keys with Alice” Thus key revocation is a major problem. Needham-Shroeder’s problem is that it assumes all users of the system are good guys and the goal is to keep bad guys from getting in (“eggshell model”) –This is the ‘old school’ model of security. It has been realised today that the most likely threats come from within (knowledgeable insiders).

10. CNS2009handout 12 :: crypto protocols10 kerberos (MIT/windows 2000) Extension of Needham-Schroeder Two trusted servers –Authentication server to which users log on –Ticket granting server issues tickets (timed keys) to resources Allows scalable access management –users managed differently to resource access –e.g. university handles enrolments but departments handle access to facilities Uses timestamps (T) with a lifetime (L) instead of nonces –fixes Needham-Schroeder problem with freshness A and T share key K AT via the authentication server (by password) Alice → Trent: “A”, “B” Trent → Alice: {T T, L, K AB, “B”, {T T, L, K AB, “A”} K BT } K AT Alice → Bob: {T T, L, K AB, “A”} K BT, {“A”, T A } K AB Bob → Alice: {T A +1} K AB

11. CNS2009handout 12 :: crypto protocols11 kerberos Alice and Trent share key K AT via the authentication server –Alice asks Trent for a ticket to talk to Bob Alice → Trent: A, B –Trent gives Alice a ticket (session key K AB with lifetime L from timestamp T T ) and a ticket encrypted for Bob with K BT Trent → Alice: {T T, L, K AB, B, {T T, L, K AB, A} K BT } K AT –Alice gives Bob the encrypted ticket and a challenge Alice → Bob: {T T, L, K AB, A} K BT, {A, T A } K AB –Bob sends back the timestamp incremented by one to indicate he is alive and managed to decrypt the ticket. Bob → Alice: {T A +1} K AB

12. CNS2009handout 12 :: crypto protocols12 problems with kerberos Problems: The key K AT from the authentication server is protected only by a password –we know humans pick these poorly –facilitates a dictionary attack –packet format from authentication server is in a known format makes a dictionary attack easy as we can verify a valid result Alice, Bob and Trent’s clocks need to be synchronised –If the sender’s clock is ahead of receiver’s clock, Eve can intercept a message from the sender and play it later when the timestamp is valid at the receiver (suppress-replay attack) Desynchronisation can be used as part of many attacks (including denial-of-service)

13. CNS2009handout 12 :: crypto protocols13 public key management using certification authorities A public key certificate binds a public key to its owner: –Alice sends her public key to the CA (Trent) –The CA produces a certificate for Alice –Alice sends her public key and certificate to Bob –Bob verifies the certificate using Alice’s public key –Bob sends encrypted messages to Alice using the key sign CA [X.500: name, organisation, address, public key, expires …] Everyone must be able to verify the CA’s public key –shipped with browsers, OS, published in the Australian The CA is a trusted party - it can forge keys / signatures. An example is the X.509 certificate for X.500 directory services certificate

14. CNS2009handout 12 :: crypto protocols14 trust models Symmetric keys –TTP must be online (used every session) –TTP is a juicy target (knows passwords) –No forward secrecy –Fast (e.g. Kerberos) Asymmetric keys –TTP is offline (only used in key generation) –TTP only knows public keys –TTP has forward secrecy –Not as fast (e.g. SSL/TLS, PGP, SET) KDC AliceBob Carol Dave CA Alice Bob Carol Dave

15. CNS2009handout 12 :: crypto protocols15 public key certificate generation Alice generates a public/private key pair Alice sends the public key to the CA The CA challenges Alice to see if she knows the private key The CA generates a certificate and sends it to Alice Note: The CA never learns Alice’s private key –Important for forward secrecy

16. CNS2009handout 12 :: crypto protocols16 certificate revocation Alice’s certificate may need to be revoked –Her private key is stolen –She changes jobs This is a major problem and is done in limited ways: –Through users requiring daily certification-validation information (slow, cumbersome) –Use expiration date field –Use of a certificate revocation list (CRL) which is circulated (like bad credit cards)

17. CNS2009handout 12 :: crypto protocols17 references Handbook of Applied Cryptography –Read § 12 - 12.3.2 (ii) Stallings –§11