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

My Second Marktoberdorf School l Fun playing volleyball, swimming, hiking l Review German vocabulary  Alt, Pils, Dunkel, Weizen, Dunkel Weizen  wegabschneider (trail-off-cutter) l Seen some ‘96 students at conferences l What else should I remember?

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

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

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

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

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

Example: Secure Sockets Layer

Establishing Secure Communication l Parties use SSL protocol to  Choose encryption scheme, e.g.  40-bit international encryption with 2 keys  120-bit domestic encryption with 2 keys  choose among versions of specific scheme  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  Info not revealed l Authentication  Know identity of individual or site l Data integrity  Msg not altered l Message Authentication  Know source of msg l Receipt  Know msg received l Access control l Revocation l Anonymity l Non-repudiation

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

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

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

Needham-Schroeder Key Exchange { A, Nonce a } { Nonce a, Nonce b } { Nonce b } KaKa KbKb Result: A and B share two private numbers not known to any observer without K a -1, K b -1 AB KbKb

Anomaly in Needham-Schroeder AE B { A, N a } { N a, N b } { N b } KeKe KbKb KaKa KaKa KeKe Evil agent E tricks honest A into revealing private key N b from B. Evil E can then fool B. [Lowe]

TMN Cell Phone Protocol a N a b b K K s s S B A B, {N } A B {N } A {N }

TMN Replay Attack SBA B, {N a } Ks A A, {N b } Ks B, {N b } Na SDC D, {N c } Ks C C, {N b } Ks D, {N b } Nc REPLAY

Kerberos l Client requests key from KDC  C  KDC : C, TGS l KDC returns private key and ticket  KDC  C : {K s1 } Kc {C, K s1 } Ktgs l Client sends name and ticket to TGS  C  TGS : {C} Ks1, {C, K s1 } Ktgs, S l TCS returns private key and ticket  TGS  C : {K s2 } Kc {C, K s2 } Ks l Client contacts server  C  S : {C} Ks1, {C, K s1 } Ks

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

Handshake Protocol Description ClientHello C  S C, Ver C, Suite C, N C S C Ver S, Suite S, N S, S, K S + ServerHello S  C Ver S, Suite S, N S, sign CA { S, K S + } ClientVerify C  S sign CA {C, V C } + { Ver C, Secret C } + N S sign C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash(Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } (Change to negotiated cipher) N S ServerFinished S  C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + S + Master(N C, N S, Secret C ) + Pad 1 )) } N S ClientFinished C  S { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } SKSSKS S Master(N C, N S, Secret C )

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