Model Checking Security Protocols Joel Winstead 17 Feb

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!Msg 1. a. b. Encrypt. key(b). na. a comm. Msg 2. b. a. Encrypt. key(a)? n’a. nb if na = n’a then comm!Msg 3. a. b. Encrypt. key(b). nb I_commit. a. b session. a. b Skip else Stop

The Intruder I(m 1 s, m 2 s, m 3 s, ns) intercept. Msg 1? a. b. Encrypt. k. n. a’ if k = Ki then I(m 1 s, m 2 s, m 3 s, ns {n}) else I(m 1 s {Encrypt. k. n. a’}, m 2 s, m 3 s, ns). . . fake. Msg 1? a. b? m: m 1 s I(m 1 s, m 2 s, m 3 s, ns). . . fake. Msg 3? a. b!Encrypt? k? n: ns I(m 1 s, m 2 s, m 3 s, 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 . 2 . 3 A A A I : {Na. A}PK(I) I(A) B : {Na. A}PK(B) I(A) B : {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 . 2 . 3 A I(B) I I 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