Transcript PPT

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
– 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?
• 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
• 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
• 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
1. 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-Schroeder
1. A  B : A.B.{Na.A}PK(B)
2. 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-Schroeder
1. A  B : A.B.{Na.A}PK(B)
2. B  A : B.A.{Na.Nb}PK(A)
3. 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-Schroeder
1. A  B : A.B.{Na.A}PK(B)
2. B  A : B.A.{Na.Nb}PK(A)
3. 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?
• 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 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
• 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
• 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
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
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
• 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
.1
.1
.2
.2
.3
.3
A 
A 
A 
I
: {Na.A}PK(I)
I(A)  B : {Na.A}PK(B)
I(A)  B : {Na.Nb}PK(A)
I
: {Na.Nb}PK(A)
I
: {Nb}PK(I)
I(A)  B : {Nb}PK(B)
Bob now thinks he’s talking to Alice!
Fixing the Protocol
Add Bob’s identity to the second message to prevent
Mallory from replaying it to Alice:
1. A  B : A.B.{Na.A}PK(B)
2. B  A : B.A.{Na.Nb.B}PK(A)
3. A  B : A.B.{Nb}PK(B)
This modified protocol passes the checker.
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
• 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
.1
.1
.2
.2
.3
A  I(B)
I
I
A  I(B)
A  I(B)


B
B
: {Na.A}PK(B)
: {(2*Na).I}PK(B)
: {(2*Na).Nb.B}PK(I)
: {Na.Nb.B}PK(A)
: {Nb}PK(B)
Alice now thinks she’s talking to Bob!
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?
• 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
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