1 / 22

Analysis of Security Protocols (I)

Analysis of Security Protocols (I). John C. Mitchell Stanford University. Computer Security . Protect information Store user passwords in a form that prevents anyone from reading them

shuler
Download Presentation

Analysis of Security Protocols (I)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

  9. 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

  10. 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

  11. 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?

  12. 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?

  13. 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

  14. 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.

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

  16. 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

  17. 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

  18. 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

  19. 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)

  20. 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?

More Related