# Computer-aided cryptographic proofs

(1)

Gilles Barthe

March 24, 2014

(2)

## The two views of cryptography

Computational cryptography

Strong ties with complexity theory

Feasible adversary breaks scheme with small probability

Design of secure and efficient primitives and protocols

Complex and manual proofs

(3)

## The two views of cryptography

Computational cryptography

Strong ties with complexity theory

Feasible adversary breaks scheme with small probability

Design of secure and efficient primitives and protocols

Complex and manual proofs

Symbolic cryptography(Dolev and Yao, 1983)

Assume perfect cryptography

Discovery of logical bugs in protocols

Strong ties with verification

Automated proofs

(4)

## Reconciling the two views

Computational soundness

Security in symbolic model implies computational security

. . . under non-standard assumptions on primitives

Symbolic tools deliver asymptotic guarantees

. . . but no concrete guarantees

Applicable to many settings

. . . but some impossibility results

(5)

## Computational proof systems

Prove security

directly in the computational model

under standard assumptions

Indistinguishability logics

CryptoVerif (game-playing approach for appliedπ-calculus)

EasyCrypt (code-based game-playing approach)

Domain-specific logics

(6)

## Why bother?

In our opinion, many proofs in cryptography have become essentially unverifiable. Our field may be approaching a crisis of rigor. Bellare and Rogaway, 2004-2006

Do we have a problem with cryptographic proofs? Yes, we do [...] We generate more proofs than we carefully verify (and as a consequence some of our published proofs are incorrect). Halevi, 2005

(7)

EncryptionEOAEP(pk)(m) : r ← {\$ 0,1}k0;

s←G(r)⊕(mk0k1);

t ←H(s)⊕r; return fpk(skt)

DecryptionDOAEP(sk)(c) : (s,t)←f−1sk(c);

r ←t⊕H(s);

if([s⊕G(r)]k1=0k1) then{m←[s⊕G(r)]k;} else{m← ⊥;}

returnm

PrIND-CCA(A)[b =b]−12

PrPDOW(I)[y ∈Y] +3qDqG+qD2+4qD+qG

2k0 + 2qD

2k1

and

tI ≤tA+qD qG qH Tf

(8)

## OAEP: provable security

1994 Bellare and Rogaway

2001 Shoup

Fujisaki, Okamoto, Pointcheval, Stern 2004 Pointcheval

2009 Bellare, Hofheinz, Kiltz

2011 BGLZ

1994 Purported proof of chosen-ciphertext security

2001 1994 proof gives weaker security; desired security holds

for a modified scheme under stronger assumptions 2004 Filled gaps in 2001 proof

2009 Security definition needs to be clarified 2011 Fills gaps in 2004 proof

(9)

## Computer-aided cryptographic proofs

provable security

=

deductive verification of parametrized probabilistic programs

☞ same proof techniques

☞ same guarantees

☞ same level of abstraction

leverage existing verification techniques and tools

☞ program logics, VC generation, invariant generation

☞ SMT solvers, theorem provers, proof assistants

☞ symbolic cryptography

(10)

## A language for cryptographic games

C ::= skip skip

| V ← E assignment

| V ← D\$ random sampling

| C; C sequence

| ifE thenC elseC conditional

| whileE doC while loop

| V ← P(E, . . . ,E) procedure call

E: (higher-order) expressions

D: discrete sub-distributions

P: procedures

user extensible

. oracles: concrete procedures

(11)

Probabilistic Hoare Logic

{P}c{Q} ⋄δ

Probabilistic Relational Hoare logic

{P} c1 ∼ c2 {Q}

Ambient logic

(12)

## Selected rules

{P} c1 c2 {Q} {Q} c1 c2 {R}

{P} c1;c1 c2;c2 {R}

{Peh1i} c1 c {Q} {P∧ ¬eh1i} c2 c {Q}

{P} ifethenc1elsec2 c {Q}

Peh1i=eh2i

{Peh1i} c1 c1 {Q} {P∧ ¬eh1i} c2 c2 {Q}

{P} ifethenc1elsec2 ife thenc1 elsec2 {Q}

f is 1-1

{∀v,Q[xh1i:=f v,xh2i:=v]} x \$ A x \$ A {Q}

(13)

## Applications

Allows deriving judgments of the form Prc

1,m1[A1]≤Prc

2,m2[A2] or

|Prc

1,m1[A1]−Prc

2,m2[A2]| ≤Prc

2,m2[F]

Benefits

Application of rules directed by syntax (mostly)

Can be automated

Generate verification conditions

VCs can be discharged by SMT solvers

Building on 40 years of research in program verification!

(14)

## Example: Bellare and Rogaway 1993 encryption

GameIND-CPA(A) : (sk,pk)← K( );

(m0,m1)← A1(pk);

b ← {\$ 0,1};

c ← Epk(mb);

b ← A2(c);

return(b =b)

EncryptionEpk(m) : r ← {\$ 0,1};

s←H(r)⊕m;

y ←fpk(r)ks;

returny

For every IND-CPA adversaryA, there exists an inverterI st

PrIND-CPA(A)

b =b

−1

2 ≤PrOW(I)

y =y

(15)

## Proof

Game hopping technique

GameINDCPA: (sk,pk)← K();

(m0,m1)← A1(pk);

b← {0,\$ 1};

c← Epk(mb);

b← A2(c);

return(b=b) EncryptionEpk(m) :

r← {0,\$ 1}; hH(r);

shm;

cfpk(r)ks;

returnc

Game G: (sk,pk)← K();

(m0,m1)← A1(pk);

b← {0,\$ 1};

c← Epk(mb);

b← A2(c);

return(b=b) EncryptionEpk(m) :

r← {0,\$ 1}; h← {0,\$ 1}k; shm;

cfpk(r)ks;

returnc

Game G: (sk,pk)← K();

(m0,m1)← A1(pk);

b← {0,\$ 1};

c← Epk(mb);

b← A2(c);

return(b=b) EncryptionEpk(m) :

r← {0,\$ 1}; s← {0,\$ 1}k; hsm;

cfpk(r)ks;

returnc

GameOW: (sk,pk)← K();

y← {0,\$ 1}; y← I(fpk(y));

(m0,m1)← A1(pk);

s← {0,\$ 1}k; cxks;

b← A2(c);

y[z∈LAH|fpk(z)=x];

returny

1. For each hop

prove validity of pRHL judgment

derive probability claims

(possibly) resolve some probability expressions using pHL 2. Obtain security bound by combining claims

3. Check execution time of constructed adversary

(16)

## Conditional equivalence

Epk(m) : r ← {\$ 0,1}; h←H(r);

s←h⊕m;

c ←fpk(r)ks;

returnc

Epk(m) : r ← {\$ 0,1}; h← {\$ 0,1}k; s←h⊕m;

c ←fpk(r)ks;

returnc

{⊤} IND-CPA ∼ G n

(¬r ∈LAH)h2i →=b,b

o

PrIND-CPA

b=b

−PrG

b=b

≤PrG h

r ∈LAHi

(17)

## Equivalence

Epk(m) : r ← {\$ 0,1}; h← {\$ 0,1}k; s←h⊕m;

c ←fpk(r)ks;

returnc

Epk(m) : r ← {\$ 0,1}; s← {\$ 0,1}k; h←s⊕m;

c ←fpk(r)ks;

returnc

{⊤} GG n

=b,b,r,LAH o

PrG

hr ∈LAHi

=Pr

G

hr ∈LAHi

PrG[b=b] =Pr

G[b=b] = 12

(18)

## Equivalence

Epk(m) : r ← {\$ 0,1}; h← {\$ 0,1}k; s←h⊕m;

c ←fpk(r)ks;

returnc

Epk(m) : r ← {\$ 0,1}; s← {\$ 0,1}k; h←s⊕m;

c ←fpk(r)ks;

returnc

{⊤} GG n

=b,b,r,LAH o

PrIND-CPA[b =b]−12 ≤Pr

G

hr ∈LAHi

(19)

## Reduction

GameINDCPA: (sk,pk)← K();

(m0,m1)← A1(pk);

b← {0,\$ 1};

c← Epk(mb);

b← A2(c);

return(b=b) EncryptionEpk(m) :

r ← {0,\$ 1}; s← {\$ 0,1}k; cfpk(r)ks;

returnc

GameOW: (sk,pk)← K();

y← {0,\$ 1}; y← I(fpk(y));

(m0,m1)← A1(pk);

b← {0,\$ 1};

s← {0,\$ 1}k; cxks;

b← A2(c);

y[zLAH |fpk(z) =x];

returny

{⊤} G ∼ OW n

(r ∈LAH)h1i →(y =y)h2io

PrG h

r ∈LAHi

≤PrOW(I)[y =y]

(20)

## Reduction

GameINDCPA: (sk,pk)← K();

(m0,m1)← A1(pk);

b← {\$ 0,1};

c← Epk(mb);

b← A2(c);

return(b=b) EncryptionEpk(m) :

r ← {0,\$ 1}; s← {0,\$ 1}k; cfpk(r)ks;

returnc

GameOW: (sk,pk)← K();

y← {\$ 0,1}; y← I(fpk(y));

(m0,m1)← A1(pk);

b← {0,\$ 1};

s← {0,\$ 1}k; cxks;

b← A2(c);

y[zLAH |fpk(z) =x];

returny

{⊤} G ∼ OW n

(r ∈LAH)h1i →(y =y)h2io

PrIND-CPA(A)[b=b]− 12 ≤Pr

OW(I)[y=y]

(21)

## Case studies

Public-key encryption

Signatures

Hash designs

Block ciphers

Zero-knowledge protocols

Differential privacy Based on

CertiCrypt (2006-2011): Coq based

EasyCrypt (2009-): SMT based

(22)

## Limitations

Abstraction and composition

Implementation

Optimization

(23)

## Abstraction and composition

The need

pRHL can captureinstances ofgeneric proof steps

Repeated proof effort; requires ability to reason in pRHL

Does not scale to complex proofs

Gap between formal proofs and cryptographic practice Two mechanisms

Module system

☞ ML-like module system, with negative constraints

☞ Allows hybrid arguments

☞ Quantification over modules

Type classes

(24)

## Modules at work

module typeScheme = { funkg () : skeypkey

funenc(pk:pkey, m:plaintext) : ciphertext fundec(sk:skey, c:ciphertext) : plaintext }.

funchoose (pk:pkey) : msgmsg funguess (c:cipher) :bool }.

moduleCPA (S:Scheme, A:ADV) = { funmain () :bool= {

varpk,sk,m0,m1,b,b’,challenge;

(pk,sk) = S.kg();

(m0,m1) = A.choose(pk);

b\$ {0,1};

challenge = S.enc(pk, b?m1:m0);

b’ = A.guess(challenge);

return b’ = b;

} }.

Reduction argument:

(A <: Adv),(I <: Inverter), Pr[CPA(A) : res]1/2≤Pr[OW(I) : res].

Existential quantification over modules would require support for complexity claims

(25)

## Implementation

Painful gap between provable security and real world

Standards constrain implementations

Attackers target executable code

Real-world crypto is breakable; is in fact being broken; is one of many ongoing disaster areas in security. Bernstein, 2013

C-mode

Use CompCert as a backend

Account for side-channel countermeasures

(26)

## OAEP: real-world security

1994 1996 Kocher

1998

Bleichenbacher 2001 Manger

2010

Strenzke

2013 ABBD

RSA implementations are vulnerable to timing attacks

PKCS1.5 vulnerable to padding oracle attacks

RSA is a permutation only on strict subset of 0..2k

: careless conversion leads to timing attacks

(27)

## Implementation of OAEP

DecryptionDOAEP(sk)(c) : (s,t)←f−1sk(c);

r ←t⊕H(s);

if([s⊕G(r)]k1=0k1) then{m←[s⊕G(r)]k;} else{m← ⊥;}

returnm

DecryptionDPKCS-C(sk)(res,c) : if(c MsgSpace(sk))then {(b0,s,t)fsk1(c);

hMGF(s,hL); i 0;

while(i <hLen+1)

{s[i]t[i]h[i]; ii+1; } gMGF(r,dbL); i 0;

while(i <dbLen)

{ p[i]s[i]g[i]; ii+1; } l payload_length(p);

if(b0=08[p]hLenl =0..01∧

[p]hLen =LHash) then

{rcSuccess;

memcpy(res,0,p,dbLenl,l);} else{rcDecryptionError;} } else{rcCiphertextTooLong;} returnrc;

(28)

## Provable security of C and executable code

C-mode for EasyCrypt

Prove PKCS using C-mode for EasyCrypt: arrays are base-offset representation and match subset of C arrays (no aliasing or overlap possible, pointer arithmetic only within an array)

Carry proof from C-like code to x86 executable Reduction proof

FOR ALLadversary that breaks the executable code, THERE EXISTSan adversary that breaks the source code

Account for some side-channels Certified compilers

Reduction proof rests on semantic preservation. Use CompCert

(29)

## CompCert (Leroy, 2006)

Optimizing C compiler implemented in Coq

Formal proof of semantic preservation

(30)

## Application to OAEP

Baseline security

idealized operations moved to the environment

☞ random sampling of bitstrings

☞ hash function (random oracle)

“trusted-lib” mechanism for arithmetic libraries PC security

annotation mechanism is used to track control flow

ASM analyser checks that compiler does not add branches

“trusted-lib” must also verify leakage assumptions

(31)

## Implementations and performance

Carefully craft C code to avoid hidden branching (operations on bitstrings or booleans)

Compile with CompCert

Check no new branch was introduced

Links generated code with LIP (secure in PC model)

(32)

## Cache-based side-channel attacks

A recipe for security disaster

Array accesses with high indices

AES, BlowFish, DES, RC4, Snow. . .

Alternative: constant-time crypto Protection mechanism

alias and information flow analysis (CompCert assembly)

tag arrays accessed with secret indices as “stealth”

typable programs w/o “stealth” address are constant-time

typable programs execute securely on stealth memory (provided stealth addresses are mapped correctly)

(33)

AES 744 5 4

DES 836 10 2

Blowfish 279 1 4

RC4 164 1 0.25

Snow 757 6 6

Salsa20 1077 0 0

TEA 70 0 0

SHA256 419 0 0

(34)

## Automated synthesis of cryptosystems

Do the cryptosystems reflect [...] the situations that are being catered for? Or are they accidents of history and personal background that may be obscuring fruitful developments? [...] We must systematize their design so that a new cryptosystem is a point chosen from a well-mapped space, rather than a laboriously devised construction.

(Adapted from Landin, 1966. The next 700 programming languages)

(35)

## An algebraic view of padding-based schemes

Encryption algorithms are modelled as algebraic expressions E ::= m input message

| 0 zero bitstring

| R uniform random bitstring

| E ⊕ E xor

| E || E concatenation

| [E]ss projection

| H(E) hash

| f(E) trapdoor permutation Decryption algorithms are modelled in a mild extension

(36)

## Semantics

Left-to-right evaluation with sharing, yields a pWHILEprocedure Example

f((G(r)⊕(mk0))kH(G(r)⊕(mk0))⊕r) interpreted as:

r ← {\$ 0,1}k; g ←G(r);

s ←g⊕(mk0);

h←H(s);

returnfpk(sk(h⊕r))

(37)

(38)

## Attack finding

Based on standard symbolic tools

☞ deducibility and static equivalence

For efficiency, first apply simple filters, eg

☞ is decryption possible without a key? m||f(r)

☞ is encryption randomized? f(m)

☞ is randomness extractable without a key? r ||f(m⊕r) ee1 ee2

ee1ke2 [Conc] ee1 ee2 ee1e2 [Xor]

ee

e[e]n[Proj] ee1 e1 .

=e2

ee2 [Conv]

ee

eH(e)[H] ee

ef(e)[F] ee

ef1(e)[Finv]

(39)

## Chosen-plaintext security: principles

Failure event ReplaceH(e)by freshr

Optimistic sampling Replacee⊕r, wherer is fresh, byr Probability Compute probability ofb=b ore∈L Reduction Find inverter and apply one-wayness

(40)

## Chosen-plaintext security: formalism

Judgment

c:pϕ

Concrete probability can be computed

☞ on the fly

☞ a posteriori (judgments use onlyp=0,12)

Side-conditions are discharged by symbolic methods

☞ what is the entropy ofe?

☞ can I computeefrome?

(41)

## Chosen-plaintext security: proof rules

m6∈c c:1

2 Guess[Indep]

e~r ~r∩ R(c) =

c:0eLAH [Indom]

c:pϕ r fresh (c:pϕ){er/r}[Opt]

eA~r f(~r)kr~0kmAc ~rr~0= c:0eLAH [OW]

(42)

## Evaluation

Proof Attack Unknown CPA 116433 901929 12627

CCA 28001 182730 66332

Remarks:

16185 out of 66332 CCA unknown non-redundant

CPA unknown seem secure

Proving completeness seems very hard

Found (by inspection) one new and interesting scheme f(r ||m⊕G(r))

Missing methods for mining the database

(43)

## Some ongoing projects

Foundations and automation

Case studies: AKE, MPC, faults, verifiable computation

Synthesis of dlog and pairing-based encryption

Verified batch verifiers

Automated analysis in (multi-linear) generic groups

(44)

## Conclusion

Solid foundation for cryptographic proofs

Formal verification of emblematic case studies

Narrowing the gap between proofs and code

Automated analysis and synthesis of crypto schemes http://www.easycrypt.info

(45)

## EasyCrypt toolchain

ZooCrypt AutoBatch ...

EasyCrypt

User Why3

CertiCrypt CompCert

StealthCert

Updating...

## Références

Sujets connexes :