Summary From the Last Lecture

1. Summary From the Last Lecture • Attacks on cryptography • Cyphertext, known pltext, chosen pltext, MITM, brute-force • Types of ciphers • Mix of substitution and transposition • Monoalphabetic, homophonic, polygram, polyalphabetic • Symmetric (stream, block), asymmetric • RNGs, block cipher modes (ECB, CFC, CFB, OFB) • Public key cryptography • Modular exponentiation for encryption/decryption • One-way hash functions • Collision-free, collision-resistant • MD5, SHA, DES, AES (not on exams)

2. When/How to Encrypt/Hash? • Confidentiality, integrity, non-repudiation • M, E(M), H(M), E(H(M)), H(E(M)) • M + H(M) • M + E(H(M)) • M + H(E(M)) • E(M) + H(M) • E(M) + E(H(M)) • E(M) + H(E(M))

3. First Report Due in Three Weeks • Chosen paper must talk about cryptography, authentication, authorization or policy • Select from venues listed on the class Web page • Email me your chosen paper to verify it fits the topic • Write 2-4 page report • Summary of problem, why is it important and hard, solution summary, evaluation and results, your opinion and your ideas • Originality, clearness, writing style, must have all sections • Proof-read!! • Start now!

4. Key Exchange

5. Shared Key Exchange Problem • How do Alice and Bob exchange a shared secret? • Offline • Doesn’t scale • Need a trusted third party • 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

6. Diffie Hellman Key Exchange • 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

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

8. KDC Based Key Distribution • 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 • ticketS = EKKDC,S{C, Kc,s} • 1. C, S C KDC S • 2. EKKDC,C{S, Kc,s}, ticketS • 3. ticketS

9. Needham-Shroeder Key Exchange • Use nonces to prevent replay attacks • ticketS = EKKDC,S{C, Kc,s} • 1. N1, C, S C S KDC • 2. EKKDC,C{N1, S, Kc,s,ticketS} • 3. EKC,S{N2}, ticketS • 4. EKC,S{N2-1, N3} • 5. EKC,S{N3-1}

10. Whys … • Why N1? • Why N2? • Why N3? • Why encrypt ticketS

11. Problem • 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

12. Solution • Introduce Ticket Granting Server (TGS) • Daily ticket plus session keys • Authentication server (AS) authenticates users • TGS+AS = KDC • This is modified Needham-Schroeder • Basis for Kerberos

13. TGS 3. TGSReq 4. TGSRep C S 5. SReq Kerberos Third-party authentication service • Distributes session keys for authentication, confidentiality, and integrity AS 2. ASRep 1. ASReq

14. Kerberos Kuser = f(passuser) • ASReq= userID, TGS, lifetime1 • TTGS = EKAS,TGS(TGS, C, KTGS,C, timestamp1, lifetime2) • ASRep = EKuser(KTGS,C, TGS, timestamp2, lifetime2), TTGS • TGSReq = TTGS, EKTGS,C(C, timestamp3), S, lifetime3 • TS = EKS,TGS(S, C, KS,C, timestamp4, lifetime4) • TGSRep = TS, EKC,TGS(KS,C, S, timestamp5, lifetime4) • SReq = EKC,S{C, timestamp6}, TS

15. 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

16. Public Key Distribution • 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

17. 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

18. Key Exchange With Interlock Protocol • First four steps are the same • Alice 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) • Alice encrypts a message in Pub(M) but sends half to Bob – Mallory cannot recover this message and duplicate it • This works if Mallory cannot mimic Alice’s and Bob’s messages

19. 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)

20. Certificate-Based Authentication • Authentication steps • Alice provides nonce, or a timestamp is used instead. • Bob selects session key and sends it to Alice with nonce, encrypted with Bob’s private key and Alice’s public key, sends Bob’s certificate too • Alice validates certificate – it is really Bob’s key inside • Alice checks signature on nonce – Bob really generated the message

21. PGP • 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

22. X.509 • Assumes strict hierarchy of certificate authorities • Nodes in the hierarchy can delegate trust to lower levels

23. SSH • 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

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

25. Group Keys • Group key vs. individual key • Proves that one belongs to the group vs. proving an individual identity • E.g., used for multicast messages

26. Group Key Management • Revoking access • Change keys, redistribute • Joining and leaving groups • New members cannot read old messages on join – backward secrecy – use old key to generate new one • How to revoke access – forward secrecy – much harder • Robustness • Coping with network partitioning • Efficiency • Cost of use, verification, exchange

27. Group Key Management • Centralized • Single entity issues keys • Optimization to reduce traffic for large groups • May utilize application specific knowledge • Decentralized • Employs sub managers • Distributed • Members do key generation • May involve group contributions

28. Authentication

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

30. Something You Know • Password or Algorithm • e.g. encryption key derived from password • Issues • Someone else may learn it • Find it, sniff it, trick you into providing it • Other party must know how to check • You must remember it

31. 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

32. 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

33. 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 x0=h(R), x1=h(h(R)), x2=h(h(h(R))),..., x100 • Alice keeps this list, host sets her password to x101 • Alice logs on with x100, host verifies h(x100)=x101, resets password to x100 • Next time Alice logs on with x99

34. 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

35. Public Key Authentication • Key Distribution • Confidentiality not needed for public key • Can be obtained ahead of time • Performance • Slower than conventional cryptography • Implementations used for key distribution, then use conventional crypto for data encryption • Trusted third party still needed • To certify public key • To manage revocation