Part 2: Finding Protocol Flaws with Symbolic Analysis The - - PowerPoint PPT Presentation

Part 2: Finding Protocol Flaws with Symbolic Analysis

2

The Needham-Schroeder problem

A B The Needham-Schroeder public-key authentication protocol (CACM 1978) S {| msg3(A,NA) |}KB {| msg6(NA,NB) |}KA {| msg7(NB) |}KB A,B {| B,KB |}KS-1 B,A {| A,KB |}KS-1

Principal A initiates a session with principal B S is a trusted server returning public-key certificates eg {| A,KA |}KS-1 NA,NB serve as nonces to prove freshness of messages 6 and 7

In “Using encryption for authentication in large networks

• f computers” (CACM 1978), Needham and Schroeder didn’t

just initiate a field that led to widely deployed protocols like Kerberos, SSL, SSH, IPSec, etc. They threw down a gauntlet. “Protocols such as those developed here are prone to extremely subtle errors that are unlikely to be detected in normal operation. The need for techniques to verify the correctness of such protocols is great, and we encourage those interested in such problems to consider this area.”

3

Informal Methods

The Explicitness Principle Robust security is about explicitness. A cryptographic protocol should make any necessary naming, typing and freshness information explicit in its messages; designers must also be explicit about their starting assumptions and goals, as well as any algorithm properties which could be used in an attack.

Anderson and Needham Programming Satan’s Computer 1995

Informal lists of prudent practices attempt to discern common patterns in the extensive record of flawed protocols, and to formulate positive advice for avoiding each pattern. (e.g. Abadi and Needham 1994, Anderson and Needham 1995)

4

Formal Methods

n Dolev&Yao first formalize N&S model in early 80s

n Symmetric key decryption: { {M}K }K-1 = M n Public key decryption: {| {| M |}KA |}KA-1 = M

n In 1987, Burrows, Abadi and Needham (BAN) propose a

systematic rule-based logic for reasoning about protocols

n Neither sound nor complete, but useful and influential n Logical rules for protocol analysis easy to automate

5

Automated Tools

n Circa 2000, formal protocol analysis tools start to appear

n 2001: Blanchet develops ProVerif in 2001 n 2005: Vigano develops AVISPA in 2005 n 2006: Cremers develops Scyther in 2006 n 2012: Schmidt et al. develop Tamarin in 2012

n By 2017, formal methods are applied to many protocols

n Classic protocols: TLS 1.0, Kerberos, SSH, IKE, JFK, … n Modern protocols: TLS 1.3, ACME, OAuth 2.0, … n They find sophisticated multi-session attacks,

by analysing corner cases of complex protocols

6

Formal Methods vs. Crypto Proofs

n An attack in a formal model usually implies an

attack in the standard cryptographic model

n Proofs in the formal model do not usually

imply a crypto proof

n Computational soundness results allow some formal

proofs to be converted to cryptographic proofs, but they only work for restricted protocol models.

n Formal methods are easier to automate, and

are useful tools for finding attacks

n Once these attacks are fixed, we can use tools like

CryptoVerif and EasyCrypt to build crypto proofs

Finding Attacks with Symbolic Analysis

The ProVerif Tool Karthikeyan Bhargavan

INRIA karthikeyan.bhargavan@inria.fr http://prosecco.inria.fr/personal/karthik

February 2018 (Based on slides by Stéphanie Delaune, Bruno Blanchet, and others)

Reading Material and Tools

ProVerif tool and manual: http://proverif.inria.fr Modeling and Verifying Security Protocols with the Applied Pi Calculus and ProVerif. Foundations and Trends in Privacy and Security, 2016. The Applied Pi Calculus: Mobile Values, New Names, and Secure Communication. Journal of the ACM, 2017. Verified models and reference implementations for the TLS 1.3 standard candidate. IEEE S&P 2017.

Symbolic Threat Model: the network is the attacker

Protocol Principals: A (alice), B (bob), . . . Attacker Principals: E (eve), M (mallory), O (opponent), . . . Each message is sent over an insecure network: A ! B : m

Symbolic Threat Model: the network is the attacker

Protocol Principals: A (alice), B (bob), . . . Attacker Principals: E (eve), M (mallory), O (opponent), . . . Each message is sent over an insecure network: A ! B : m Interception: The attacker can steal protocol messages: A ! O(B) : m

Symbolic Threat Model: the network is the attacker

Protocol Principals: A (alice), B (bob), . . . Attacker Principals: E (eve), M (mallory), O (opponent), . . . Each message is sent over an insecure network: A ! B : m Interception: The attacker can steal protocol messages: A ! O(B) : m Injection: The attacker can send protocol messages: O(A) ! B : m

Symbolic Threat Model: the network is the attacker

Protocol Principals: A (alice), B (bob), . . . Attacker Principals: E (eve), M (mallory), O (opponent), . . . Each message is sent over an insecure network: A ! B : m Interception: The attacker can steal protocol messages: A ! O(B) : m Injection: The attacker can send protocol messages: O(A) ! B : m Compromise: The attacker may directly play one of the protocol roles: A ! O : m

Symbolic Threat Model: the network is the attacker

Protocol Principals: A (alice), B (bob), . . . Attacker Principals: E (eve), M (mallory), O (opponent), . . . Each message is sent over an insecure network: A ! B : m Interception: The attacker can steal protocol messages: A ! O(B) : m Injection: The attacker can send protocol messages: O(A) ! B : m Compromise: The attacker may directly play one of the protocol roles: A ! O : m These capabilities are enough for the adversary to:

Steal sensitive data Tamper with sensitive data Impersonate principals

To protect against such attacks, protocols rely on cryptography

Symbolic Cryptography: symmetric encryption

Shared Keys: K, KAB, . . . Symmetric Encryption: enc(m, k) (written {m}n) Symmetric Decryption: dec(m, k)

Defined by the equation: dec({m}K, K) = m

Security Property: Plaintext confidentiality and integrity

A ciphertext cannot be decrypted without knowing the key Encryption is a perfect black-box (no probability of attack) We can weaken guarantee to only cover confidentiality, not integrity

Symbolic Cryptography: asymmetric encryption

Private Keys: sk(A) (for principal A) Public Keys: pk(A) (for principal A)

Public key infrastructure (PKI): Assume that the public keys of all principals are known

Asymmetric Encryption: penc(m, pk(A)) (written {m}pk(A)) Asymmetric Decryption: pdec(m, sk(A))

Defined by the equation: pdec({m}pk(A), sk(A)) = m

Security Property: Plaintext confidentiality and non-malleability

A message encrypted with pk(A) cannot be decrypted without knowing sk(A) Encryption is a perfect black-box (no probability of attack) We can weaken guarantee to allow malleability

Symbolic Cryptography: signature

Signature: sig{m}sk(A) Verification: verify(m, n, pk(A))

Defined by the equation: verify(m, sig{m}sk(A), pk(A)) = true

Security Property: Plaintext Unforgeability

A signature that successfully verifies using pk(A) cannot be created without knowing sk(A) Signature is a perfect one-way function, does not leak its arguments We can add an equation that allows the message to be extracted We can weaken guarantee to allow key compromise with repeated nonces

Protocol Security Goals

Confidentiality: Can the attacker O learn a secret that is meant to be known only to A and B? Integrity: Can O modify a message from A and get it accepted by B? Authentication: Can O convince B that it is talking to A?

Protocol Security Goals

Confidentiality: Can the attacker O learn a secret that is meant to be known only to A and B? Integrity: Can O modify a message from A and get it accepted by B? Authentication: Can O convince B that it is talking to A? Anonymity: If A wishes to be anonymous, can O discover its identity? Non-Repudiation: If A sends a message to B, can it later deny that it sent the message? Can B deny that it received the message? . . .

Example: Symbolic Attacks on Secure RPC

Alice (A) wishes to perform an online transaction with her bank (B): A ! B : request B ! A : response Security Goals:

Confidentiality of request and response; Integrity of request and response; Authentication of A and B

Secure RPC Protocol: Encrypt-Then-Sign

Encrypt messages with recipient’s public key Sign the ciphertexts with the sender’s private key A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) Does this ensure message integrity? sender authentication?

Secure RPC Protocol: Replay Attacks

A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) What if request = “Transfer 1000EUR to O”? O(A) ! B : {request}pk(B), sig{{request}pk(B)}sk(A) O(A) ! B : {request}pk(B), sig{{request}pk(B)}sk(A) O(A) ! B : {request}pk(B), sig{{request}pk(B)}sk(A) We can prevent such replays by incorporating a challenge-response nonce, or a timestamp, or both.

Secure RPC Protocol: Response confidentiality

Suppose request contains the login/password for A’s account Suppose response is A’s current bank statement Does protocol 2 keep response confidential? A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B)

Secure RPC Protocol: Response confidentiality

Suppose request contains the login/password for A’s account Suppose response is A’s current bank statement Does protocol 2 keep response confidential? A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) No! We show a man-in-the-middle attack

Protocol 2: Man-in-the-middle Attack

Does protocol 2 keep response confidential? A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) Suppose O intercepts A’s request to B A ! O(B) : {request}pk(B), sig{{request}pk(B)}sk(A)

Protocol 2: Man-in-the-middle Attack

Does protocol 2 keep response confidential? A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) Suppose O intercepts A’s request to B A ! O(B) : {request}pk(B), sig{{request}pk(B)}sk(A) Then O replaces the signature with its own and forwards it O ! B : {request}pk(B), sig{{request}pk(B)}sk(O)

Protocol 2: Man-in-the-middle Attack

Does protocol 2 keep response confidential? A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) Suppose O intercepts A’s request to B A ! O(B) : {request}pk(B), sig{{request}pk(B)}sk(A) Then O replaces the signature with its own and forwards it O ! B : {request}pk(B), sig{{request}pk(B)}sk(O) B thinks that this request came from O and responds with: B ! O : {response}pk(O), sig{{response}pk(O)}sk(B)

Protocol 2: Man-in-the-middle Attack

Does protocol 2 keep response confidential? A ! B : {request}pk(B), sig{{request}pk(B)}sk(A) B ! A : {response}pk(A), sig{{response}pk(A)}sk(B) Suppose O intercepts A’s request to B A ! O(B) : {request}pk(B), sig{{request}pk(B)}sk(A) Then O replaces the signature with its own and forwards it O ! B : {request}pk(B), sig{{request}pk(B)}sk(O) B thinks that this request came from O and responds with: B ! O : {response}pk(O), sig{{response}pk(O)}sk(B) Hence O obtains the secret response (bank statement of A) Exercise: Fix the protocol to protect response confidentiality

Finding Attacks Systematically

Both attacks above are symbolic attacks that exploit logical flaws. How can we be confident that there are no other logical flaws? Can we formally prove that the protocol satisfies its security goals against all symbolic attackers? To precisely state and prove such security theorems about cryptographic protocols, we need to move to a more formal setting.

What does A ! B : m mean? It specifies the message but now what A and B must do How do we specify security goals? How do we encode the threat model?

Formal Syntax and Semantics of ProVerif

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000]

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels)

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation in(c, x).P message input (continue as P)

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation in(c, x).P message input (continue as P)

• ut(c, M).P

message output (continue as P)

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation in(c, x).P message input (continue as P)

• ut(c, M).P

message output (continue as P) let x = g(M1, . . . , Mn) in P else Q destructor application

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation in(c, x).P message input (continue as P)

• ut(c, M).P

message output (continue as P) let x = g(M1, . . . , Mn) in P else Q destructor application if M = N then P else Q conditional

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation in(c, x).P message input (continue as P)

• ut(c, M).P

message output (continue as P) let x = g(M1, . . . , Mn) in P else Q destructor application if M = N then P else Q conditional P|Q parallel composition

ProVerif Syntax: a process calculus

Simplified version of the applied pi calculus [Abadi, Fournet, 2000] Names: a, b, c, . . . (used for keys, nonces, channels) Messages: M, N, . . . M, N, O ::= Messages x, y, z variables a, b, c names f (M1, . . . , Mn) constructor application Processes: P, Q, R, . . . P, Q, R ::= Processes null process new a.P fresh name generation in(c, x).P message input (continue as P)

• ut(c, M).P

message output (continue as P) let x = g(M1, . . . , Mn) in P else Q destructor application if M = N then P else Q conditional P|Q parallel composition !P replication

Constructors and destructors

Two kinds of operations: Constructors f are used to build terms f (M1, . . . , Mn) Destructors g manipulate terms let x = g(M1, . . . , Mn) in P else Q Destructors are defined by rewrite rules g(N1, . . . , Nn) ! N.

Examples of constructors and destructors

Shared-key encryption: {M}K; one decrypts with the key K Constructor: Shared-key encryption enc(M, K). Destructor: Decryption dec(M0, K) dec(enc(x, y), y) ! x. Perfect encryption assumption: one can decrypt only if one has the key.

Examples of constructors and destructors (continued)

One-way hash function: Constructor: One-way hash function H(M). Very idealized model of a hash function (essentially corresponds to the random oracle model).

Examples of constructors and destructors (continued)

Tuples: Constructor: tuple (M1, . . . , Mn). Destructors: projections ith(M) ith((x1, . . . , xn)) ! xi Tuples are used to represent all kinds of data structures in protocols.

Example: The Denning-Sacco protocol

Message 1. A ! B : {{k}skA}pkB k fresh Message 2. B ! A : {s}k new skA; new skB; let pkA = pk(skA) in let pkB = pk(skB) in

• ut(c, pkA); .out(c, pkB); .

(A) ! in(c, x_pkB); new k;

• ut(c, penc(sign(k, skA), x_pkB)); .

in(c, x).let s = dec(x, k) in 0 (B) | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pkA) in out(c, enc(s, k));

Exercise: The Needham-Schroeder public-key protocol

Exercise

Model the following protocol: Message 1. A ! B {Na, A}pkB Na fresh Message 2. B ! A {Na, Nb}pkA Nb fresh Message 3. A ! B {Nb}pkB

Formal Semantics

Semantic configurations are E, P where E is a set of names P is a multiset of processes Intuitively, E, P where E = {a1, . . . , an} and P = {P1, . . . , Pm} corresponds to new a1; . . . new an; (P1 | . . . | Pm) Initial configuration for P: fn(P), {P}. The semantics is defined by reduction E, P ! E0, P0: the execution of the configuration is modeled by transforming it into another configuration.

Formal Semantics: reduction relation

E, P [ { 0 } ! E, P (Red Nil) E, P [ { !P } ! E, P [ { P, !P } (Red Repl) E, P [ { P | Q } ! E, P [ { P, Q } (Red Par) E, P [ { new a; P } ! E [ {a0}, P [ { P{a0/a} } (Red Res) where a0 / 2 E. E, P [ { out(N, M); .Q, in(N, x).P } ! E, P [ { Q, P{M/x} } (Red I/O) E, P [ { let x = g(M1, . . . , Mn) in P else Q } ! E, P [ { P{M0/x} } if g(M1, . . . , Mn) ! M0 (Red Destr 1) E, P [ { let x = g(M1, . . . , Mn) in P else Q } ! E, P [ { Q } if there exists no M0 such that g(M1, . . . , Mn) ! M0 (Red Destr 2)

Example: Denning-Sacco Execution with Adversary

{c}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); | new skA; new skB; let pkA = pk(skA) in let pkB = pk(skB) in

• ut(c, pkA); .out(c, pkB); .

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pkA) in out(c, enc(s, k)); )} A benign adversary (the first process) reads the public keys of A and B and sends a message on c to initiate a new session from A to B.

Example (2): generate keys

! {c}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); , new skA; new skB;let pkA = pk(skA) in let pkB = pk(skB) in

• ut(c, pkA); .out(c, pkB); .

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pkA) in out(c, enc(s, k)); )}

Example (2): generate keys

! {c}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); , new skA; new skB;let pkA = pk(skA) in let pkB = pk(skB) in

• ut(c, pkA); .out(c, pkB); .

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pkA) in out(c, enc(s, k)); )}

Example (3): generate keys

!⇤ {c, skA,skB}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); , let pkA = pk(skA) in let pkB = pk(skB) in out(c, pkA); .out(c, pk ( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pkA) in out(c, enc(s, k)); )}

Example (3): generate keys

!⇤ {c, skA,skB}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); , let pkA = pk(skA) in let pkB = pk(skB) in out(c, pkA); .out(c, pk ( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pkA) in out(c, enc(s, k)); )}

Example (4)

!⇤ {c, skA,skB}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); ,

• ut(c, pk(skA)); .out(c, pk(skB));.

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (4)

!⇤ {c, skA,skB}, { in(c, xpkA).in(c, xpkB).out(c, xpkB); ,

• ut(c, pk(skA)); .out(c, pk(skB));.

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (5)

!⇤ {c, skA,skB}, {

• ut(c, pk(skB)); ,

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (5)

!⇤ {c, skA,skB}, {

• ut(c, pk(skB)); ,

( ! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0 | ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (6)

! {c, skA,skB}, {

• ut(c, pk(skB)); ,

! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0, ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (6)

! {c, skA,skB}, {

• ut(c, pk(skB)); ,

! in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0, ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (7)

! {c, skA,skB}, {

• ut(c, pk(skB));,

in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0, ! in(c, x_pkB). . . . , ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (7)

! {c, skA,skB}, {

• ut(c, pk(skB));,

in(c, x_pkB).new k; out(c, penc(sign(k, skA), x_pkB)); . in(c, x).let s = dec(x, k) in 0, ! in(c, x_pkB). . . . , ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (8)

! {c, skA,skB}, { new k;out(c, penc(sign(k, skA), pk(skB))); . in(c, x).let s = dec(x, k) in 0, ! in(c, x_pkB). . . . , ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (8)

! {c, skA,skB}, { new k;out(c, penc(sign(k, skA), pk(skB))); . in(c, x).let s = dec(x, k) in 0, ! in(c, x_pkB). . . . , ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (9)

! {c, skA,skB, k0}, {

• ut(c, penc(sign(k0, skA), pk(skB)));.

in(c, x).let s = dec(x, k0) in 0, ! in(c, x_pkB). . . . , ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (9)

! {c, skA,skB, k0}, {

• ut(c, penc(sign(k0, skA), pk(skB)));.

in(c, x).let s = dec(x, k0) in 0, ! in(c, x_pkB). . . . , ! in(c, y).let y0 = pdec(y, skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); )}

Example (10)

!⇤ {c, skA,skB, k0}, { in(c, x).let s = dec(x, k0) in 0, ! in(c, x_pkB). . . . , let y0 = pdec(penc(sign(k0, skA), pk(skB)), skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); ) ! in(c, y). . . .}

Example (10)

!⇤ {c, skA,skB, k0}, { in(c, x).let s = dec(x, k0) in 0, ! in(c, x_pkB). . . . , let y0 = pdec(penc(sign(k0, skA), pk(skB)), skB) in let k = checksign(y0, pk(skA)) in out(c, enc(s, k)); ) ! in(c, y). . . .}

Example (11)

!⇤ {c, skA,skB, k0}, { in(c, x).let s = dec(x, k0) in 0, ! in(c, x_pkB). . . . ,

• ut(c, enc(s, k0));)

! in(c, y). . . .}

Example (11)

!⇤ {c, skA,skB, k0}, { in(c, x).let s = dec(x, k0) in 0, ! in(c, x_pkB). . . . ,

• ut(c, enc(s, k0));)

! in(c, y). . . .}

Example (12)

! {c, skA,skB, k0}, { let s = dec(enc(s, k0), k0) in 0, ! in(c, x_pkB). . . . , ! in(c, y). . . .}

Example (12)

! {c, skA,skB, k0}, { let s = dec(enc(s, k0), k0) in 0, ! in(c, x_pkB). . . . , ! in(c, y). . . .}

Symbolic Adversary

The protocol is executed in parallel with an adversary. The adversary can be any process. S = finite set of names (initial knowledge of the adversary).

Definition

The closed process Q is an S-adversary , fn(Q) ✓ S.

Symbolic Secrecy

Intuitive definition

The secret M cannot be output on a public channel

Definition

A trace T = E0, P0 !⇤ E0, P0 outputs M if and only if T contains a reduction E, P [ { out(c, M); .Q, in(c, x).P } ! E, P [ { Q, P{M/x} } for some E, P, x, P, Q, and c 2 S.

Definition

The closed process P preserves the secrecy of M from S , 8S-adversary Q, 8T = fn(P) [ S, {P, Q} !⇤ E0, P0, T does not output M.

Verification with ProVerif

Verifying protocols in the symbolic model

Compute the set of all terms that the attacker can obtain. This set is infinite:

The attacker can generate messages of unbounded size. The number of sessions of the protocol is unbounded.

Verification Complexity

Bounded messages and number of sessions

) finite state Model checking: FDR [Lowe, TACAS’96]

Bounded number of sessions but unbounded messages

) insecurity is typically NP-complete Constraint solving: Cl-AtSe, integrated in AVISPA Extensions of model checking: OFMC, integrated in AVISPA

Unbounded messages and number of sessions

) the problem is undecidable

Solutions to undecidability

Rely on user interaction

Interactive theorem proving, Isabelle [Paulson, JCS’98]

Use approximations

Abstract interpretation [Monniaux, SCP’03], TA4SP integrated in AVISPA Typing [Abadi, JACM’99], [Gordon, Jeffrey, CSFW’02] (Sometimes also relies on type annotations by the user.)

Allow non-termination ProVerif uses approximations and allows non-termination.

ProVerif

ProVerif is a verifier for cryptographic protocols Fully automatic For an unbounded number of sessions and an unbounded message size

Undecidable problem ) need for abstractions

Handles a wide range of cryptographic primitives, defined by rewrite rules or equations Proves various security properties: secrecy, correspondences, some equivalences Does not always terminate and is not complete. In practice:

Efficient: small examples verified in less than 0.1 s; complex ones in a few minutes. Very precise: no false attack in our tests for secrecy and authentication.

How ProVerif Works

Two ideas (extending [Weidenbach, CADE’99]): a simple abstract representation of protocols, by a set of Horn clauses; an efficient resolution algorithm to find which facts can be derived from these clauses. Using these ideas, we can prove secrecy properties of protocols,

• r exhibit attacks showing why a message is not secret.

Protocol representation as horn clauses

Messages terms M ::= x | f (M1, . . . , Mn) | k[M1, . . . , Mn] penc(c0, pk(skA)). Properties facts F ::= attacker(M). Protocol, attacker Horn clauses F1 ^ . . . ^ Fn ) F attacker(m) ^ attacker(pk) ) attacker(penc(m, pk)).

Example - Cryptographic primitives

Public-key encryption: Encryption penc(m, pk). attacker(m) ^ attacker(pk) ) attacker(penc(m, pk)) Public key generation pk(sk). (builds a public key from a secret key) attacker(sk) ) attacker(pk(sk)) Decryption pdec(penc(m, pk(sk)), sk) ! m. attacker(penc(m, pk(sk))) ^ attacker(sk) ) attacker(m)

Initial knowledge

Clauses that represent the initial knowledge of the adversary: attacker(M) if the adversary knows M.

Example

For the Denning-Sacco protocol: attacker(pk(skA)) attacker(pk(skB))

Names

Normally, fresh names are created each time the protocol is run. Here, we only distinguish two names when they are created after receiving different messages. Each name k becomes a function of the messages previously received: k[M1, . . . , Mn]. (Skolemisation) These functions can only be applied by the principal that creates the name, not by the attacker. The attacker can create his own fresh names: attacker(b[ ]).

Denning-Sacco protocol

A ! B : {{k}skA}pkB k fresh A talks to any principal represented by its public key pk(x). A sends to it the message {{k}skA}pk(x). attacker(pk(x)) ) attacker(penc(sign(k[pk(x)], skA[ ]), pk(x))). B ! A : {s}k B has received a message {{y}skA}pkB. B sends {s}y. attacker(penc(sign(y, skA[ ]), pk(skB[ ]))) ) attacker(enc(s, y)).

General coding of a protocol

If a principal A has received the messages M1, . . . , Mn and sends the message M, attacker(M1) ^ . . . ^ attacker(Mn) ) attacker(M).

Exercise

Give Horn clauses for the Needham-Schroeder public key protocol: Message 1. A ! B {Na, A}pkB Na fresh Message 2. B ! A {Na, Nb}pkA Nb fresh Message 3. A ! B {Nb}pkB

Approximations

The freshness of nonces is partially modeled. The number of times a message appears is ignored,

• nly the fact that is has appeared is taken into account.

The state of the principals is not fully modeled. These approximations are keys for an efficient verification. Solve the state space explosion problem. No limit on the number of runs of the protocols. ) essential for the certification of protocols.

Secrecy

Secrecy criterion

If attacker(M) cannot be derived from the clauses, then M is secret. The term M cannot be built by an attacker. The resolution algorithm will determine whether a given fact can be derived from the clauses.

Authenticity

Authenticity means: if A thinks he talks to B then he really talks to B. Authenticity can be defined by correspondence assertions [Woo and Lam, Oakland’93]: If A executes eA(B) (A thinks he talks to B), then B must have executed eB(A) (B has started a run with A).

Correspondences: events

Events record that some program point has been reached, with certain values of the variables. Syntax: P, Q ::= processes . . . event(M).P event Semantics: E, {event(M).P} [ P ! E, {P} [ P (Red Event) An S-adversary does not contain events.

Definition

A trace T = E0, P0 !⇤ E0, P0 executes event(M) if and only if T contains a reduction E, P [ { event(M).P } ! E, P [ { P } for some E, P, P.

Correspondences

Intuitive definition

If event(M) has been executed then event(M1), . . . event(Mn) have been executed

Definition

The closed process P0 satisfies the correspondence event(M)

l

^

k=1

event(Mk) with respect to S-adversaries if and only if, for any S-adversary Q, for any E0 containing fn(P0) [ S [ fn(M) [ S

k fn(Mk),

for any substitution σ, for any trace T = E0, {P0, Q} !⇤ E0, P0, if T executes σevent(M), then there exists σ0 such that σ0M = σM and, for all k 2 {1, . . . , l}, T executes event(σ0Mk) as well.

Analyzing TLS 1.3 with ProVerif

Transport Layer Security (TLS) 1.3

Next version of the most popular secure channel protocol.

Completely redesigned from TLS 1.2 After 20 drafts, on the verge of standardization

Why did we need a new protocol?

Security: remove broken legacy crypto constructions Efficiency: reduce handshake roundtrip latency

0-RTT when the client and server have a pre-shared key 0.5-RTT

Transport Layer Security (TLS) 1.3

Next version of the most popular secure channel protocol.

Completely redesigned from TLS 1.2 After 20 drafts, on the verge of standardization

Why did we need a new protocol?

Security: remove broken legacy crypto constructions Efficiency: reduce handshake roundtrip latency

0-RTT when the client and server have a pre-shared key 0.5-RTT

These are potentially contradictory goals

Needs extensive security analysis before deployment!

The IETF called for academics to formally analyze the protocol drafts.

Symbolic analysis to find downgrade (and other) attacks

Recent attacks on legacy crypto in TLS: RC4 Keystream biases [Mar’13] Lucky13 MAC-Encode-Encrypt CBC [Mar’13] POODLE SSLv3 MAC-Encode-Encrypt [Dec’14] FREAK Export-grade 512-bit RSA [Mar’15] LOGJAM Export-grade 512-bit DH [May’15] SLOTH RSA-MD5 signatures [Jan’16] DROWN SSLv2 PSA-PKCS#1v1.5 Enc [Mar’16] Legacy crypto remains in TLS libraries for backwards compatibility. Is TLS 1.3 secure, if it is deployed alongside older versions of TLS? Can a man-in-the-middle downgrade TLS 1.3 peers to use legacy crypto?

Modeling weak crypto in ProVerif

Classic symbolic (Dolev-Yao) protocol models idealize crypto

Perfect black-boxes that cannot be opened without relevant key

We model agile crypto primitives parameterized by algorithm

Given a strong algorithm, the primitive behaves ideally Given a weak algorithm, the primitive completely breaks

Modeling weak crypto in ProVerif

Classic symbolic (Dolev-Yao) protocol models idealize crypto

Perfect black-boxes that cannot be opened without relevant key

We model agile crypto primitives parameterized by algorithm

Given a strong algorithm, the primitive behaves ideally Given a weak algorithm, the primitive completely breaks e.g. a weak Diffie-Hellman group behaves like a trivial 1-element group

fun dh_ideal ( element , b i t s t r i n g ) : element . equation f o r a l l x : b i t s t r i n g , y : b i t s t r i n g ; dh_ideal ( dh_ideal (G, x ) , y ) = dh_ideal ( dh_ideal (G, y ) , x ) . fun dh_exp ( group , element , b i t s t r i n g ) : element reduc f o r a l l g : group , e : element , x : b i t s t r i n g ; dh_exp (WeakDH, e , x ) = BadElement

• therwise

f o r a l l g : group , e : element , x : b i t s t r i n g ; dh_exp ( StrongDH , BadElement , x ) = BadElement

• therwise

f o r a l l g : group , e : element , x : b i t s t r i n g ; dh_exp ( StrongDH , e , x ) = dh_ideal ( e , x ) .

Modeling weak crypto in ProVerif

Classic symbolic (Dolev-Yao) protocol models idealize crypto

Perfect black-boxes that cannot be opened without relevant key

We model agile crypto primitives parameterized by algorithm

Given a strong algorithm, the primitive behaves ideally Given a weak algorithm, the primitive completely breaks e.g. a weak Diffie-Hellman group behaves like a trivial 1-element group Similarly, we model strong and weak authenticated encryption, hash functions, MACs, RSA encryption and signatures.

Our model is overly conservative, it may not indicate real exploits

Our goal is to verify TLS 1.3 against future attacks on legacy crypto

Modeling TLS 1.3 in ProVerif

TLS 1.3 1-RTT handshake 12 messages in 3 flights, 16 derived keys, then data exchange + PSK-based 0-RTT + TLS 1.2 Agile Crypto: ⇠400 lines TLS models: ⇠500 lines Modeling is easy, verification takes effort

Writing and verifying security goals

We state security queries for data sent between honest users

Secrecy: messages between honest peers are unknown to an adversary Authenticity: messages between honest peers cannot be tampered Replay prevention: messages between honest peers cannot be replayed Forward secrecy: secrecy holds even if the peers’ long-term keys are leaked after the session is complete

Secrecy query for msg(conn, S) sent from anonymous C to server S query attacker(msg(conn, S)) = ) false

Refining security queries

QUERY: is msg(conn, S) secret? query attacker(msg(conn, S)) = ) false FALSE: ProVerif finds a counterexample if S’s private key is compromised.

Refining security queries

QUERY: is msg(conn, S) secret as long as S is uncompromised? query attacker(msg(conn, S)) = ) event(WeakOrCompromisedKey(S)) FALSE: ProVerif finds a counterexample if the AE algorithm is weak.

Refining security queries

QUERY: Strongest secrecy query that can be proved in our model query attacker(msg(conn, S)) = ) event(WeakOrCompromisedKey(S)) _ event(ServerChoosesAE(conn, S, WeakAE)) _ event(ServerChoosesKEX(conn, S, WeakDH)) _ event(ServerChoosesKEX(conn0, S, WeakRSADecryption)) _ event(ServerChoosesHash(conn0, S, WeakHash)) TRUE: ProVerif finds no counterexample

Conclusion: Downgrade security for TLS 1.2 + TLS 1.3

Messages on a TLS 1.3 connection between honest peers are secret:

if the connection does not use a weak AE algorithm,

the connection does not use a weak DH group,

the server never uses a weak hash algorithm for signing, and

the server never participates in a TLS 1.2 RSA key exchange.

Analysis confirms preconditions for downgrade resilience in TLS 1.3

identifies weak algorithms in TLS 1.2 that can harm TLS 1.3 security

Conclusion: ProVerif

ProVerif is an efficient verifier that can handle complex real-world cryptographic protocols like TLS, SSH, IKE etc. It can handle a wide range of assumptions on cryptographic primitives, specified by flexible rewrite rules or by equations. It can automatically find attacks that break various secrecy and authentication properties. However, ProVerif only looks for symbolic attacks. The absence of attack does not imply a cryptographic proof