1 / 30

Analysis of Security Protocols (IV)

Analysis of Security Protocols (IV). John C. Mitchell Stanford University. Mur  [Dill et al.]. Describe finite-state system Startstate declaration Transition rules Correctness conditions Scalable: choose system size parameters

adeck
Télécharger la présentation

Analysis of Security Protocols (IV)

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 (IV) John C. Mitchell Stanford University

  2. Mur [Dill et al.] • Describe finite-state system • Startstate declaration • Transition rules • Correctness conditions • Scalable: choose system size parameters • Automatic exhaustive testing space limit: hash table to avoid repeated states

  3. Murfor security protocols • Formulate protocol • Add adversary • Control over “network” (shared variables) • Possible actions • Intercept any message • Remember parts of messages • Generate new messages, using observed data and initial knowledge (e.g. public keys) • Identify correctness conditions

  4. Needham-Schroeder in Mur(1) const NumInitiators: 1; -- number of initiators NumResponders: 1; -- number of responders NumIntruders: 1; -- number of intruders NetworkSize: 1; -- max. outstanding msgs in network MaxKnowledge: 10; -- number msgs intruder can remember type InitiatorId: scalarset (NumInitiators); ResponderId: scalarset (NumResponders); IntruderId: scalarset (NumIntruders); AgentId: union {InitiatorId, ResponderId, IntruderId};

  5. Needham-Schroeder in Mur(2) MessageType : enum { -- types of messages M_NonceAddress, -- {Na, A}Kb nonce and addr M_NonceNonce, -- {Na,Nb}Ka two nonces M_Nonce -- {Nb}Kbone nonce }; Message : record source: AgentId; -- source of message dest: AgentId; -- intended destination of msg key: AgentId; -- key used for encryption mType: MessageType; -- type of message nonce1: AgentId; -- nonce1 nonce2: AgentId; -- nonce2 OR sender id OR empty end;

  6. Needham-Schroeder in Mur(3) -- intruder i sends recorded message ruleset i: IntruderId do -- arbitrary choice of choose j: int[i].messages do -- recorded message ruleset k: AgentId do -- destination rule "intruder sends recorded message" !ismember(k, IntruderId) & -- not to intruders multisetcount (l:net, true) < NetworkSize ==> var outM: Message; begin outM := int[i].messages[j]; outM.source := i; outM.dest := k; multisetadd (outM,net); end; end; end; end;

  7. Adversary Model • Formalize “knowledge” • initial data • observed message fields • results of simple computations • Optimization • only generate messages that others read • time-consuming to hand simplify • Future goal: automatic generation

  8. Run of Needham-Schroeder • Find error after 1.7 seconds exploration • Output: trace leading to error state • Mur  times after correcting error:

  9. State Reduction on N-S Protocol

  10. Limitations • System size with current methods • 2-6 participants Kerberos: 2 clients, 2 servers, 1 KDC, 1 TGS • 3-6 steps in protocol • May need to optimize adversary • Adversary model • Cannot model randomized attack • Do not model adversary running time

  11. Analysis Results • Analyze common protocols • Needham-Schroeder • Kerberos • Found bug in documented algorithm (not in RFC) • one client, two servers • TMN cellular phone protocol • Found all known bugs automatically • Model algebraic properties of encryption function • Largest case study: SSL protocol

  12. A initiates and B sends session key Several bugs: replay step 3 for chosen Na’ I S : I, {Nb}Ks TMN Protocol S B, {N } A a K s B {N } A {N } A B b b N K a s

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

  14. TMN Replay with “Blinding” B, {Na}Ks A A S B B, {Nb}Na A, {Nb}Ks D, {Nc}Ks C C S D D, {i*Nb}Nc C, i*{Nb}Ks REPLAY

  15. Modeling Challenge • Avoid repeated keys by storing list • Do not allow new session with old key • But RSA allows “blinding”: • Adversary sends multiple of old key • Divides later message by multiplier • Need to model multiplication in Murj • Model message by pair: datum, blinding bit

  16. Secure Socket Layer (SSL) • De facto standard for Internet security Goal: “...provide privacy and reliability between two communicating applications” • Handshake Protocol Use public-key cryptography to establish shared secret key • Record Layer Transmit data using negotiated key

  17. Handshake Protocol (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

  18. Rational Reconstruction of SSL • Begin with simple, intuitive protocol • Client sends id, version, crypto preference • Server sends version, crypto pref, public key • Client sends encrypted random secret • Model check and find bug • Intruder can modify server public key, obtain client secret, then sent to complete protocol • Fix bug and repeat, to produce full SSL

  19. SSL Handshake Protocol • Negotiate version, crypto suite • Possible “version rollback attack” • Authenticate client and server • Appeal to “certificate authority” • Use public key to establish shared secret Several underlying primitives: public key, signature, hash function, private key

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

  21. Rational Reconstruction of SSL • Begin with simple, intuitive protocol • Model check and find bug • Add a piece of SSL to fix bug and repeat VersionC, SuiteC VersionS, SuiteS, Key KS { SecretC } C S KS

  22. Summary of Reconstruction • A = Basic protocol • C = A + certificates for public keys • Authentication for client and server • E = C + verification (Finished) messages • Prevention of version and crypto suite attacks • F = E + nonces • Prevention of replay attacks • Z = “Correct” subset of SSL

  23. Anomaly (Protocol F) … SuiteC … … SuiteS … … C S Switch to negotiated cipher Finished Finished data data

  24. Anomaly (Protocol F) Modify … SuiteC … … SuiteS … Modify … C S Switch to negotiated cipher X X Finished Finished data data

  25. Protocol Resumption SessionId, VerC= 3.0, NC, ... VerS= 3.0, NS, ... C S Finished Finished data data

  26. Version Rollback Attack SessionId, VerC= 2.0, NC, ... VerS= 2.0, NS, ... X X C S Finished Finished { NS } SecretKey { NC } SecretKey data data

  27. Protocol Analysis • Protocol Specification Abstract notions of message, key, nonce, cryptographic functions • ProtocolAnalysis High-level models for crypto primitives • Protocol Implementation Specific key length, random number generator, encryption and decryption functions

  28. What Do We Learn? • Find an error • Error in Murj model implies error in protocol • Can confirm error in impl by testing • Do not find error • Not a proof of correctness • Idealized adversary, communication models • Bound on number of participants • Implementation may not be faithful to specification • Correct impl safe against certain attacks

  29. Conclusions • Murj is useful tool for complex protocols • Rational reconstruction of protocol • Understand protocol • Ensure “completeness” of analysis • Protocol spec simpler, more precise than RFC • Uncover problem areas in SSL • SSL 2.0 errors identified • “Gray” areas in the resumption protocol

More Related