model checking security protocols l.
Skip this Video
Loading SlideShow in 5 Seconds..
Model Checking Security Protocols PowerPoint Presentation
Download Presentation
Model Checking Security Protocols

Loading in 2 Seconds...

play fullscreen
1 / 24

Model Checking Security Protocols - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Model Checking Security Protocols' - kristin

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
model checking security protocols

Model Checking Security Protocols

Joel Winstead

17 Feb 2004

needham schroeder authentication
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
how can we prevent this
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
lowe model checking
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
modeling needham shroeder
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
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)

needham schroeder7
  • 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)

needham schroeder8
  • 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)

needham schroeder9
  • 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
what could an attacker do
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?
construct a model of system
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
communicating sequential processes
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
the model
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
the initiator
The Initiator


user.a?b  I_running.a.b 

comm!Msg1.a.b.Encrypt.key(b).na.a 


if na = n’a

then comm!Msg3.a.b.Encrypt.key(b).nb 

I_commit.a.b  session.a.b  Skip

else Stop

the intruder
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)


the model checker
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
the attack
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!

fixing the protocol
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.

is passing the checker good enough
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.
another attack
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
the attack sequence
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!

what can we do now
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
what is secure really
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

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