Security Protocol Analysis: Ensuring Data Integrity and Confidentiality

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

2. Computer Security • 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 • 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 • Maintain privacy

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

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

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

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

7. Example: Secure Sockets Layer

8. Establishing Secure Communication • 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 40 120

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

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

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

14. Challenge-Response • 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 • Protocol • Alice  Bob: { nonce }K • Bob  Alice: { nonce+1 }K • Does this work?

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

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

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

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

19. Kerberos • Client requests key from KDC • C  KDC : C, TGS • KDC returns private key and ticket • KDC  C : {Ks1 }Kc {C, Ks1 }Ktgs • Client sends name and ticket to TGS • C TGS : {C}Ks1, {C, Ks1 }Ktgs, S • TCS returns private key and ticket • TGS C : {Ks2 }Kc {C, Ks2 }Ks • Client contacts server • C  S : {C}Ks1, {C, Ks1 }Ks

20. Secure Socket Layer (SSL) • 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

21. Handshake Protocol Description ClientHello CS C, VerC, SuiteC, NC ServerHello S  C VerS, SuiteS, NS, signCA{ S, KS+} ClientVerify C  S signCA{C, VC} { VerC, SecretC} + signC {Hash( Master(NC, NS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) } (Change to negotiated cipher) ServerFinished S  C { Hash( Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + S + Master(NC, NS, SecretC) + Pad1)) } ClientFinished C  S { Hash( Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1)) } KS Master(NC, NS, SecretC) Master(NC, NS, SecretC)

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