1. Key Management

2. Shared Key Exchange Problem How do Alice and Bob exchange a shared secret? Offline – Doesn’t scale Using public key cryptography (possible) Using specially crafted messages (Diffie Hellman) Using a trusted third party (KDC) – Secrets should never be sent in clear – We should prevent replay attacks – We should prevent reuse of old keys

3. Exchange a secret with someone you never met while shouting in a room full of people Alice and Bob agree on g and large n Alice chooses random a, sends Bob chooses random b, sends Alice takes Bob’s message and calculates Bob does the same; now they both know shared secret Diffie Hellman Key Exchange

4. Building up to Needham Schroeder/Kerberos User sends req. to KDC (key distrib. center) KDC generates a shared key: K c,s Keys K KDC,C and K KDC,S are preconfigured No keys ever traverse net in the clear Why are identities in tickets? KDC Based Key Distribution C C KDC S S 3. EK KDC,S {C, K c,s } 2. EK KDC,C {S, K c,s } 1. C, S ticket

5. KDC does not have to talk both to C and S Messages 2 or 3 can be replayed by M – Force C and S to use same secret for a long time – Cause S to have an old ticket, break comm. w C KDC Based Key Distribution C C KDC S S ticket S = EK KDC,S {C, K c,s } 2. EK KDC,C {S, K c,s }, ticket S 1. C, S 3. ticket S

6. Use nonces to prevent replay attacks Needham-Shroeder Key Exchange C C KDC S S ticket S = EK KDC,S {C, K c,s } 2. EK KDC,C {N 1, S, K c,s, ticket S } 1. N 1, C, S 3. EK C,S {N 2 }, ticket S 4. EK C,S {N 2 -1, N 3 } 5. EK C,S {N 3 -1}

7. Why N 1 ? Why N 2 ? Why N 3 ? Why encrypt ticket S Whys …

8. What happens if attacker gets session key? – Can reuse old session key to answer challenge- response, generate new requests, etc – Need timestamps to ensure freshness = tickets expire after some time Problem

9. Public Key Exchange Problem How do we verify an identity: – Alice sends to Bob her public key Pub(A) – Bob sends to Alice his public key Pub(B) – How do we ensure that those keys really belong to Alice and Bob? Need a trusted third party

10. Man-in-the-Middle Attack On Key Exchange Alice sends to Bob her public key Pub(A) Mallory captures this and sends to Bob Pub(M) Bob sends to Alice his public key Pub(B) Mallory captures this and sends to Alice Pub(M) Now Alice and Bob correspond through Mallory who can read/change all their messages

11. Public key is public but … – How does either side know who and what the key is for? Does this solve key distribution problem? – No – while confidentiality is not required, integrity is Still need trusted third party – Digital certificates – certificate authority (CA) signs identity+public key tuple with its private key – Problem is finding a CA that both client and server trust Public Key Exchange

12. Digital Certificates Everyone has Trent’s public key Trent signs both Alice’s and Bob’s public keys – he generates public-key certificate When they receive keys, verify the signature Mallory cannot impersonate Alice or Bob because her key is signed as Mallory’s Certificate usually contains more than the public key – Name, network address, organization Trent is known as Certificate Authority (CA)

13. Authentication steps – Alice provides nonce, or a timestamp is used instead, along with her certificate. – Bob selects session key and sends it to Alice with nonce, encrypted with Alice’s public key, and signed with Bob’s private key. He sends his certificate too – Alice validates certificate – it is really Bob’s key inside – Alice checks signature and nonce – Bob really generated the message and it is fresh Certificate-Based Key Exchange

14. Pretty Good Privacy – “Web of Trust” – Public key, identity association is signed by many entities – Receiver hopefully can locate several signatures that he can trust – Like an endorsement scheme PGP

15. User keys installed on server out of band – User logs in with a password – Copies her public key onto server Weak assurance of server keys – User machine remembers server keys on first contact – Checks if this is still the same host on subsequent contact – But no check on first contact SSH

16. Revocation lists (CRL’s) – Long lists – Hard to propagate Lifetime / Expiration – Short life allows assurance of validity at time of issue Real time validation – Receiver of a certificate asks the CA who signed it if corresponding private key was compromised – Can cache replies Recovery From Stolen Private Keys

17. Authentication and Identity Management

18. Ideally – Who you are Practically – Something you know (e.g., password) – Something you have (e.g., badge) – Something about you (e.g., fingerprint) Basis for Authentication

19. Password Authentication Alice inputs her password, computer verifies this against list of passwords If computer is broken into, hackers can learn everybody’s passwords – Use one-way functions, store the result for every valid password – Perform one-way function on input, compare result against the list

20. Password Authentication Hackers can compile a list of frequently used passwords, apply one-way function to each and store them in a table – dictionary attack Host adds random salt to password, applies one-way function to that and stores result and salt value – Randomly generated, unique and long enough

21. Password Authentication Someone sniffing on the network can learn the password Lamport hash or S-KEY – time-varying password – To set-up the system, Alice enters random number R – Host calculates x 0= h(R), x 1= h(h(R)), x 2= h(h(h(R))),..., x 100 – Alice keeps this list, host sets her password to x 101 – Alice logs on with x 100, host verifies h(x 100 )=x 101, resets password to x 100 – Next time Alice logs on with x 99

22. Password Authentication Someone sniffing on the network can learn the password – Host keeps a file of every user’s public key – Users keep their private keys – When Alice attempts to log on, host sends her a random number R – Alice encrypts R with her private key and sends to host – Host can now verify her identity by decrypting the message and retrieving R

23. Goal is single sign-on – Solves problem of weak or repeated user/pass combinations Implemented via redirections – Users authenticate themselves to a common server, which gives them tickets – Similar flavor to Kerberos but different environment – many organizations Widely deployed by Microsoft – Designed to use existing technologies in servers/browsers (HTTP redirect, SSL, cookies, Javascript) Passport

24. Client (browser), merchant (Web server), Passport login server Passport server maintains authentication info for client – Gives merchant access when permitted by client Divides client data into profile (address) and wallet (credit card) How Passport Works David P. Kormann and Aviel D. Rubin, Risks of the Passport Single Signon Protocol, Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000.

25. How Passport Works David P. Kormann and Aviel D. Rubin, Risks of the Passport Single Signon Protocol, Computer Networks, Elsevier Science Press, volume 33, pages 51-58, 2000. SSL Token = 3DES encrypted authentication info using key merchant shares with passport server Also set cookie at browser (passport)

26. Placed into browser cache by servers to store state about this particular user – Contain any information that server wants to remember about the user as name/value pairs – May contain expiration time – May persist across browser instances Returned to server in clear on new access Only those cookies created for the server’s domain are sent to the server – May not be created by this server Usually used for persistent sign in, shopping cart, user preferences How Cookies Work

27. User logs in using her user/pass – Server sets a cookie with some info – username, password, session ID … – Any future accesses return this info to the server who uses it for authentication (equivalent to user/pass) – Once user signs out the cookie is deleted and the session closed at the server Problems – Cookies can be sniffed, remain on the browser because user did not sign out, be stolen by cross-site scripting or via DNS poisoning Solutions: – Send cookies over SSL, use timed cookies, secure code, bind cookies to IP address of the client, encrypt cookies … Cookies for Authentication Learn more at: http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf

28. Cards – Mag stripe (= password) – Smart card, USB key – Time-varying password Issues – How to validate – How to read (i.e. infrastructure) Something You Have

29. Biometrics – Measures some physical attribute Iris scan Fingerprint Picture Voice Issues – How to prevent spoofing – What if spoofing is possible? No way to obtain new credentials Something About You

30. Require at least two of the classes we mentioned, e.g. – Smart card plus PIN – RSA SecurID plus password – Biometric and password Multi-factor Authentication