Analysis of Security Protocols John C Mitchell Stanford

Analysis of Security Protocols John C. Mitchell Stanford University (I)

Computer Security l Protect information w Store user passwords in a form that prevents anyone from reading them w Transmit information like credit card numbers in a way that prevents others from intercepting them l Protect system integrity w Keep others from deleting your files w Keep downloaded code (such as Java applets) from modifying important data w Reject mail messages that contain viruses l Maintain privacy

Correctness vs Security l Program or System Correctness w Program satisfies specification For reasonable input, get reasonable output l Program or System Security w Program resists attack For unreasonable input, output not completely disastrous w Secure system might not be correct l Main technical differences w Active interference from environment w Refinement techniques may fail

Outline of these lectures l Introduction to security protocols w Issues in security, protocol examples and flaws l l Overview of cryptography Formal presentation of protocols and intruder Automated finite-state analysis A probabilistic, poly-time framework

Tractable program analysis Intractable program complexity May be possible complexity of property to verify l l Goal: tools and techniques to solve useful problems Caveat: need to be realistic

Security Protocols l Transmit information across network Keep important information secret Communicate with those you know and trust l Typical handshake protocols l l w 3 -7 steps w 2 -5 parties client, server, key distribution service, … w lead to shared secret key for data transfer

Example: Secure Sockets Layer

Establishing Secure Communication l Parties use SSL protocol to w Choose encryption scheme, e. g. 40 -bit international encryption with 2 40 keys 120 -bit domestic encryption with 2 120 keys choose among versions of specific scheme w Agree on shared secret key Secret key more efficient than public key • Avoid known-plaintext attack Minimize reuse of hard-to-establish public key

Some security objectives l Secrecy l w Info not revealed l Authentication w Know identity of individual or site l Data integrity w Msg not altered l Message Authentication w Know source of msg Receipt w Know msg received l l Access control Revocation Anonymity Non-repudiation

Example Protocols l Challenge response w Mechanism for freshness l Needham-Schroeder Public Key w Use public-key crypto to generate shared secret l Kerberos w Simplified version w/o timestamps or nonces w Idea of sending encrypted “tickets” l l SSL (briefly) Diffie-Hellman key exchange

Timeliness in Communication l l l Assume Alice and Bob share a private encryption key K Alice wants to know if Bob is on network Possible protocol: w Alice Bob: { “Hi Bob. Still there? ” }K w Bob Alice: { “I am here? ” }K l What’s wrong with this?

Challenge-Response l Alice wants to know if Bob is still there w Send “fresh” number n, Bob returns f(n) nonce = number used once w This avoids reply by malicious 3 rd party l Protocol w Alice Bob: { nonce }K w Bob Alice: { nonce+1 }K l Does this work?

Needham-Schroeder Key Exchange { A, Noncea } K A b { Noncea, Nonceb } K { Nonceb} K a B b Result: A and B share two private numbers not known to any observer without Ka-1, Kb -1

Anomaly in Needham-Schroeder [Lowe] { A, Na }K A E { Na, Nb }Ka { Nb }K Evil agent E tricks honest A into revealing private key Nb from B. Evil E can then fool B. e e { A, Na } { N a, N b } Kb Ka B

TMN Cell Phone Protocol S B, {Na } Ks A B {Nb} Na A A {Nb} K s B

TMN Replay Attack A C B, {Na}Ks B, {Nb}Na D, {Nc}Ks D, {Nb}Nc S S A A, {Nb}Ks C C, {Nb}Ks REPLAY B D

Kerberos l Client requests key from KDC w C KDC : C, TGS l KDC returns private key and ticket w KDC C : {Ks 1 }Kc {C, Ks 1 }Ktgs l Client sends name and ticket to TGS w C TGS : {C}Ks 1, {C, Ks 1 }Ktgs, S l TCS returns private key and ticket w TGS C : {Ks 2 }Kc {C, Ks 2 }Ks l Client contacts server w C S : {C}Ks 1, {C, Ks 1 }Ks

Secure Socket Layer (SSL) l Three goals w Negotiate specific encryption scheme Possible “version attack” w Authenticate client and server Appeal to “signature authority” w Use public key to transmit secret key Several underlying primitives: public key, signature scheme, hash function, private key

Handshake Protocol Description Client. Hello C S C, Ver. C, Suite. C, NC Server. Hello S C Ver. S, Suite. S, NS, sign. CA{ S, KS+ } Client. Verify C S sign. CA{C, VC } { Ver. C, Secret. C } K + S sign. C { Hash( Master(NC, NS, Secret. C) + Pad 2 + Hash(Msgs + C + Master(NC, NS, Secret. C) + Pad 1)) } (Change to negotiated cipher) Server. Finished S C { Hash( Master(NC, NS, Secret. C) + Pad 2 + Hash( Msgs + S + Master(NC, NS, Secret. C) + Pad 1)) } Master(N , Secret ) C Client. Finished C S S C { Hash( Master(NC, NS, Secret. C) + Pad 2 + Hash( Msgs + C + Master(NC, NS, Secret. C) + Pad 1)) } Master(N , Secret ) C S C

Diffie-Hellman Key Exchange l Number-theoretic assumption w Given three numbers p, g, ga mod p, no efficient algorithm for computing a w Belief: adversary cannot find a until “too late” l Protocol (assumes public prime p, generator g) w Alice Bob: ga mod p w Bob Alice: gb mod p l Consequence w Alice and Bob know gab mod p, no one else does w Works on telephone, not general network. Why?