Basic Protocols Schneier Ch. Three

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

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

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

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

Key Exchange w/ Digital Signatures 1.Foils man in middle. 2.Trent signs A and B’s PKs, including cert. Of ownership. 3.A and B get keys, verify T’s signature. 4.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. 5.If M gets T’s key he can create phony keys but can’t decrypt sess. Keys or read msgs. 6.If can intercept and msgs and impersonate T, can do man in middle

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

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

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

Dictionary Attack and Salt Continued 1.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. 2.However, despite everything, dict. Atttacks on Unix are surprisingly successful. 3.Salt protects the system, not an individual user.

SKEY Motivation 1.Used at UR…why work thru it backwards? 2.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.

SKEY 1.Sys admin enters random R, computer produces f(R ), f(f( R)), etc (list = x1, x2, … x100). System stores x101 with your name. 2.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. 3.Computer can ask for number it wants by subscript number. Actually use 4-letter words 4.Each no. only used once, database no help.

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

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

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

Mutual Authentication with Interlock 1.Why believe host is who it says it is? 2.A and B have pw the other knows, PA and PB. Man in middle defeats this: 3.A encrypts PA with B’s PK and sends to B 4.B encrypts PB with A’s PK and sends to A 5.A, B decrypt, verify correctness. 6.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.

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

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

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

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

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

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

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

Threshold Schemes 1.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. 2.See Text for a technical how-to.

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