Basic Protocols

1. Basic Protocols Schneier Ch. Three

2. Key Exchange w/ Symmetric Crypto • Desire A and B on network, sharing secret key with KDC. How??? • A request session key from T to talk to B. • T generates sess. Key, encrypts once with A’s key and once with B’s, sends both to A. • A decrypts her copy and sends B his copy. • B decrypts his copy • A and B use key to communicatte • Trent is a bottleneck and attack target.

3. Key Exchange with PK Crypto • A gets B’s key from KDC • A generates session key, encrypts with Bob’s public key, sends to B. • B decrypts w/ his private key • A and B have session key for comms.

4. Man in Middle Attack • A sends B her public key. Mallory intercepts it and sends B his key in place of A’s. • Likewise, mutatis mutandis, with B. • A sends msg to B. M intercepts, reads with his private key and encrypts with B’s public key and sends to B. • Likewise, mutatis mutandis, with A.

5. Interlock Protocol to Foil Man in the Middle • A, B swap public keys • A encrypts her msg, sends half to B • B does same thing, sends half a msg to A • A sends other half, B assembles, decrypts. • Likewise B to A. • Can send 1st half, every other byte, etc., or a “half” could be hash fn of message, next half the msg itself. • M can’t decrypt 1/2 msg, thus can’t send it on.

6. Key Exchange w/ Digital Signatures • Foils man in middle. • Trent signs A and B’s PKs, including cert. Of ownership. • A and B get keys, verify T’s signature. • M can’t impersonate A, B -- doesn’t know their private keys. He can’t substitute his PK since it’s signed by T as belonging to M. • If M gets T’s key he can create phony keys but can’t decrypt sess. Keys or read msgs. • If can intercept and msgs and impersonate T, can do man in middle

7. Key And Message Transmission • Familiar Hybrid system, very common (PGP) • A generates random session key K, encrypts M with it • A gets B’s PK from database, encrypts K with it. • A sends encrypted M and K to B, can sign if she’s worried about men in middle. • B decrypts K with his PK and M using K.

9. Authentication • How does computer know who you are? PINs, passwords…but want to protect passwords. • Computer doesn’t need to know pw, just that it’s valid. • Calls for one-way hash, or one-way fn in general. Host stores hashes, compares with hashing the input password.

10. Dictionary Attacks and Salt • Unix’s one-way function is public. • Generate valid pws, encrypt, see if they match one in database = Dictionary Attack. • “Salt” is string concatenated to pw before one-way fn. It is stored with one-way fn result. (like initialization vector). • M then has to try each user’s salt value with each possible pw in his dictionary to get a match.

11. Dictionary Attack and Salt Continued • So M can’t just bash his encrypted dict against the database of encrypted pws. He has to do a dict search per user, not per database. • However, despite everything, dict. Atttacks on Unix are surprisingly successful. • Salt protects the system, not an individual user.

12. SKEY Motivation • Used at UR…why work thru it backwards? • Problem: sending password in clear over phone line. Partial answer: system must authenticate you before allowing you to try to login over phone. Your pw could still be lost.

13. SKEY • Sys admin enters random R, computer produces f(R ), f(f( R)), etc (list = x1, x2, … x100). System stores x101 with your name. • You (user) keep this list. To log in, give name and x100; computer calculates f(x100), which should = x101. If so, you’re authenticated: system stores newly-entered x100 opposite your name. • Computer can ask for number it wants by subscript number. Actually use 4-letter words • Each no. only used once, database no help.

14. Authentication with PK: Motivation • Problem: sending password over phone in clear, or even having it in computer, however briefly, in clear (eg before encryption). • So, host keeps file of public keys, user keeps private key as usual. Two protocols follow.

15. Weak PK Authentication • Host sends A a random string • A encrypts with her PK, sends back along with her name. • Host looks up PK by her name, decrypts. • If result is what host sent out, A is authenticated. • Not bad except for step 1. M could pretend to be host and mount chosen ciphertext attack on A.

16. Better PK Authentication • A performs computation using random numbers and her key, sends result to host. • Host sends A yet a different random no. • A makes more computations on all the random numbers and her key, sends to host. • Host does computations on everything received from A to verify she knows her own private key: if so, A’s authenticated.

17. Mutual Authentication with Interlock • Why believe host is who it says it is? • A and B have pw the other knows, PA and PB. Man in middle defeats this: • A encrypts PA with B’s PK and sends to B • B encrypts PB with A’s PK and sends to A • A, B decrypt, verify correctness. • Mallory can get in, substitute his PK for A’s (to B) and vice-v, learns pws. Interlock can help but attack can be Improved.

18. Authentication and Key Exchange • A and B on network, want to xchg keys, authenticate, communicate despite Mallory • Most protocols assume Trent shares different secret key with each party before protocol starts. • Many commercial systems to do this. Schneier examines nine of them critically. We’ll look at two.

19. Wide Mouth Frog • Simplest, uses T with whom A and B share secret key for key distribution, not encryption. To get session key: • A concats timestamp, B’s name, random session key, encrypts with key she shares with T, sends T the package and her name. • T decrypts, concats new timestamp, A’s name, random key, sends to B encrypted with his key. • Problem: A may be incompetent to create secure session key.

20. Kerberos Motivation • Same assumptions, variant of Needham-Schroeder (see Schneier). Prevents replay attacks (use of old messages). • Kerberos timestamps are to fix bug in N-S involving old session keys.

21. Kerberos Protocol • A sends T her identity and B’s (A,B). • T makes msg with timestamp, lifetime L, random session key K, A’s ID; encrypts with key he shares with Bob, similarly for Alice: EA(T,L,K,B) , EB(T,L,K,A). • A sends EK(A,T), EB(T,L,K,A) to Bob. • B sends EK(T+1) to A. • All clocks must be synched with T’s. If not exact, check for replays in uncertainty interval.

22. Lessons Learned • Many authentication and key-exchange protocols! Lots of examination, testing, critique. • Protocols fail if too clever, try to avoid names, random numbers. • Everything should be explicit. • Performance depends on assumptions (like authenticated time), and underlying comm architecture.(connectivity).

23. Formal Verification • Can prove protocol properties? • Use OS or hdw spec. languages, verification tools. • Use expert systems • Use special logics (most popular: BAN) • Formalize crypto system • AI tools meet system-design tools!

24. Secret Splitting and Sharing • Send different msg parts to diff. People, who must cooperate to read it… • Trent provides random string R same length as msg M. • T XORs M with R to generate S • T gives R to A and S to B. • A and B XOR their pieces to reconstruct M. • Like T has one-time pad, gives cipher to one person and pad to other.

25. Threshold Schemes • With hardware or computer techniques, can fix it so that message is distributed in n pieces, but any m of the n holders can reconstruct it. (m,n) threshold scheme. • See Text for a technical how-to.

26. Protecting Databases with Crypto • How fix database so you can extract the address of someone whose name you know but can’t get at everyone’s address? • Use one-way hash and symm. Encryption. • Store full name and address info encrypted by last name, along with field that is last name hashed. • To find record, search db for hashed name and decrypt what you find using last name.