1 / 24

Model Checking Security Protocols

Model Checking Security Protocols. Joel Winstead 17 Feb 2004. Needham-Schroeder Authentication. Public key authentication protocol that allows Alice to verify that she is talking to Bob and not to Mallory Protocol first published in 1978, with proof of correctness It has become widely used

kristin
Download Presentation

Model Checking Security Protocols

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. Model Checking Security Protocols Joel Winstead 17 Feb 2004

  2. Needham-Schroeder Authentication • Public key authentication protocol that allows Alice to verify that she is talking to Bob and not to Mallory • Protocol first published in 1978, with proof of correctness • It has become widely used • Kerberos is based on a variation on it • Attacks were found ten years later! • There were attack sequences the “proof” did not consider

  3. How can we prevent this? • We want to be confident that our security protocols are secure • We can’t always prove this: there may be attacks that we didn’t consider • It is not unusual to find an attack on a published protocol, even one “proven” correct! • The security of a protocol is not always decidable • Lowe: Use Model Checking • Build a model of the protocol and possible attacks on it • Exhaustively search through the model to find attacks

  4. Lowe: Model Checking • Proving that a program or protocol is correct is hard, and testing is inadequate • Build a model that: • Abstracts away implementation details • Includes all states the system could reach • Includes all transitions from one state to another • Exhaustively search state space to see if it is possible to reach an undesirable state

  5. Modeling Needham-Shroeder • Abstraction: • We assume the encryption primitives are sound and treat them like black boxes • States: • We track what things each participant could know (keys, messages, nonces) at each point in the protocol • Transitions: • Messages sent or received by anyone (Alice, Bob, or Mallory) result in changes in knowledge and thus changes in state

  6. Needham-Schroeder • Alice chooses a secret nonce Na, concatenates it with her identity, encrypts it with Bob’s public key, and sends it to Bob: A  B : A.B.{Na.A}PK(B)

  7. Needham-Schroeder • A  B : A.B.{Na.A}PK(B) • Bob decrypts the message, extracts Na, generates his own nonce Nb, concatenates them together, encrypts them with Alice’s public key, and sends it to her: B  A : B.A.{Na.Nb}PK(A)

  8. Needham-Schroeder • A  B : A.B.{Na.A}PK(B) • B  A : B.A.{Na.Nb}PK(A) • Alice decrypts the message, extracts Bob’s nonce, encrypts it with his public key, and sends it back to him: A  B : A.B.{Nb}PK(B)

  9. Needham-Schroeder • A  B : A.B.{Na.A}PK(B) • B  A : B.A.{Na.Nb}PK(A) • A  B : A.B.{Nb}PK(B) • Alice is confident she’s talking to Bob because Bob repeated her nonce, which should only be known to him • Bob is confident he’s talking to Alice, because Alice repeated his nonce, which should only be known to her

  10. What could an attacker do? • Mallory can intercept and remember messages • Mallory can decrypt messages she has the key for • Mallory can replay messages she has seen before, even if she doesn’t have the key to decrypt them • Mallory can create her own messages using information she already knows • Mallory can engage in the protocol normally using her own key and nonce • Can Mallory stage a man-in-the-middle attack?

  11. Construct a Model of System • Construct models of Alice, Bob, and Mallory using CSP • Specify the result that should be reached from following the protocol • (i.e. Alice is talking to Bob) • Use a model checker to see if there is any sequence of transitions that allows Alice to complete the protocol while failing the specification

  12. Communicating Sequential Processes • Model of concurrency proposed by C.A.R. Hoare in 1978 CACM • Each process is a set of guarded commands: • The guard is a condition which must be true for the command to execute • The command is a transition to a new state • More than one guard condition can be met simultaneously: the result is nondeterminism

  13. The Model • Each message that could be sent by anyone in the system is a command • The knowledge needed to construct the message is the guard • The message changes the state of the system to reflect the knowledge participants could gain from the message

  14. The Initiator INITIATOR(a,na)  user.a?b  I_running.a.b  comm!Msg1.a.b.Encrypt.key(b).na.a  comm.Msg2.b.a.Encrypt.key(a)?n’a.nb if na = n’a then comm!Msg3.a.b.Encrypt.key(b).nb  I_commit.a.b  session.a.b  Skip else Stop

  15. The Intruder I(m1s,m2s,m3s,ns)  intercept.Msg1?a.b.Encrypt.k.n.a’  if k = Ki then I(m1s,m2s,m3s,ns {n}) else I(m1s {Encrypt.k.n.a’},m2s,m3s,ns) ...  fake.Msg1?a.b?m:m1s  I(m1s,m2s,m3s,ns) ...  fake.Msg3?a.b!Encrypt?k?n:ns  I(m1s,m2s,m3s,ns) ...

  16. The Model Checker • FDR (Failures-Divergences Refinement) • Exhaustively tests all sequences of transitions (up to a finite length) that the model allows • Reports any sequences that fail to refine the specification

  17. The Attack .1 A  I : {Na.A}PK(I) .1 I(A)  B : {Na.A}PK(B) .2 I(A)  B : {Na.Nb}PK(A) .2 A  I : {Na.Nb}PK(A) .3 A  I : {Nb}PK(I) .3 I(A)  B : {Nb}PK(B) Bob now thinks he’s talking to Alice!

  18. Fixing the Protocol Add Bob’s identity to the second message to prevent Mallory from replaying it to Alice: • A  B : A.B.{Na.A}PK(B) • B  A : B.A.{Na.Nb.B}PK(A) • A  B : A.B.{Nb}PK(B) This modified protocol passes the checker.

  19. Is passing the checker good enough? • Lowe gives a proof that if there is a flaw in the modified protocol, it must be exploitable in the finite space the model checker examines. • But: are the assumptions correct? • We assumed, when we constructed the model, that we could abstract away implementation details. • The devil’s in the details.

  20. Another Attack • Suppose Mallory chooses an identifier I that is Alice’s identifier shifted left one bit, i.e. I=2*A • Because of a multiplicative ‘feature’ of RSA: {2*m}PK(B) = {m}PK(B) * {2}PK(B) • Thus: {Na.A}PK(B) * {2}PK(B) = {2*(Na.A)}PK(B) = {(2*Na).I}PK(B) • Mallory can engage in the protocol with B, using 2*Na as a nonce, and acquire Nb that way, even under the modified protocol

  21. The Attack Sequence .1 A  I(B) : {Na.A}PK(B) .1 I  B : {(2*Na).I}PK(B) .2 I  B : {(2*Na).Nb.B}PK(I) .2 A  I(B) : {Na.Nb.B}PK(A) .3 A  I(B) : {Nb}PK(B) Alice now thinks she’s talking to Bob!

  22. What can we do now? • The model checker failed because the model treated RSA as a black box and didn’t consider transitions that modify encrypted messages • We can use a secure hash to prevent modification of the messages • But, in general, the model checking approach can fail if the abstraction assumptions are not sound • Model checking can also fail if the finite search isn’t enough to find all attacks • Lowe proved that it is enough for this problem, but the proof doesn’t apply to all problems

  23. What is secure, really? • Security is hard to define: • Secrecy, Confidentiality, Authentication, Anonymity • It can be even harder to prove: • We don’t know if factoring is NP-complete or not • Even if we did, we don’t know that P  NP • Finite-state analysis can find many attacks, but: • It relies on abstraction assumptions that may be false • Infinite-state analysis is undecidable for most interesting problems: • Arbitrary-length attack sequences • Infinite state spaces for nonces, keys, messages

  24. Conclusion Finite-state analysis can be useful: • It can find attacks automatically, thus saving time for protocol designers and analysts • Sometimes we can prove that it applies to the infinite case as well, but the proof isn’t automated • The analysis relies on assumptions that may be false • about the abstraction process • about the cryptographic primitives • It doesn’t eliminate the need to analyze and design protocols carefully

More Related