White-Box Security Notions for Symmetric Encryption Schemessac2013.irmacs.sfu.ca/slides/s14.pdf ·...

White-Box Security Notions forSymmetric Encryption Schemes

Cecile Delerablee1 Tancrede Lepoint1,2

Pascal Paillier1 Matthieu Rivain1

CryptoExperts1, Ecole Normale Superieure2

SAC 2013

Outline

1 � What is white-box crypto?

2 � A framework of security notions

3 � Achieving incompressibility

4 � Traceable white-box programs

5 � Conclusion

White-Box Security Notions for Symmetric Encryption Schemes

What is NOT white-box crypto?

General obfuscation

� from any program P, generate an obfuscated program O(P)

� hide any program property π in the code of O(P)

� meaning: the code of O(P) ≡ a black-box oracle that runs P

How realistic is obfuscation?

� very strong requirements on the compiler O

� known impossibility results [BGI+01]


What is white-box crypto?

6= general program obfuscation!

White-box cryptography [CEJO+02]

� considers programs in a restricted class

programs(f ) where f = some keyed function

� hides some program properties π in the code (but not all)

� code ≡ a black-box oracle only in some adversarial contexts

� already provably secure constructions for some f(f = re-encryption [HRSV07,CCV12])

� no impossibility results so far for f = blockcipher

� but no secure construction for e.g. f = AESk(·), k ← $


Our approach

What do we really want from white-box crypto?

1. given k ← $, generate (possibly randomly) P = [AESk(.)]

2. it must be hard to recover k by playing around with P OLD

3. it also must be hard to decrypt under k OLD

4. we may want P to be big and incompressibleNEW

5. we may want to distribute traceableNEW versions P1, . . . ,Pn

This work

� we capture 1-5 into concrete security gamesOLD+NEW

� we build a toy blockcipher that provably satisfies 1-4NEW

� we build a construction that provably achieves 5NEW


Outline





5 � Conclusion


White-box compilers

Let E = (K ,E ,D) be a symmetric encryption scheme.

Definition

A white-box compiler CE takes as input a key k ∈ K and someindex r ∈ R and outputs a program P = CE(k , r) = [E r

k ].

Huge behavioral differences between

function E (·, ·) oracle E (k, ·) program [E rk ]

analytic description oralgorithmic description

remote access,input/output only,might be stateful

word in a language,stateless since rebootable,copiable, transferable,observable, modifiable,system calls simulatable

(specification) (smart card) (executable software)


Attack models

Security notion = adversarial goal + attack model

What are the attack models against white-box programs?

Given the description of CE(·, ·) and P = [E rk ] for unknown k ∈ K

chosen-plaintext attack – CPA can encrypt any plaintext unavoidable

chosen-ciphertext attack – CCA can make decryption queries toan oracle D(k , ·)

recompilation attack – RCA can make recompilation requests toget other programs CE(k , r ′) for unknown r ′ 6= r

combined attack – RCA + CCA most powerful (?)

RCA can be made stronger with known or chosen r ′ ∈ R.

What about adversarial goals?White-Box Security Notions for Symmetric Encryption Schemes

Unbreakability – UBK

A

k ← K(), r$← R

[Erk] = CE(k, r)

[Erk]

kk

?= k

Challenger

D(k, ·)

CE(k,R)

UBK-CCA

UBK-RCA

c′

m′

[Er′k ]

There is no ”semantic security” on k sinceverifying that k = k is easy.

So some information on k always leaks.


One-wayness – OW

A

k ← K(), r$← R

[Erk] = CE(k, r)

m$← M

c = E(k,m)[Er

k], c

mm

?= m

Challenger

D(k, ·)

CE(k,R)

OW-CCA

OW-RCA

c′

m′

[Er′k ]

Again, no semantic security on m sinceverifying that m = m is easy.

Expected since E is a deterministic encryption scheme.


Incompressibility – INC

Given a large program, build an equivalent yet much smaller one

A

Challenger

k ← K(), r$← R

[Erk] = CE(k, r)

[Erk]

P∆(P,E(k, ·))

?6 δ and size (P )

?< λ

D(k, ·)

CE(k,R)

INC-CCA

INC-RCA

c′

m′

[Er′k ]


Traceability – TRAC

CE admits a tracing scheme if there exists an algorithm trace

such that no adversary can win the ”tracing game” TRAC:

� generate a key k$← K and P1 = [E r1

k ], . . . ,Pn = [E rnk ]

� A chooses some T ⊆ [1, n] and is provided with {Pi , i ∈ T}� A returns some rogue program Q ← A({Pi , i ∈ T})� trace a traitor t ← trace(Q, k , r1, . . . , rn)

� A wins if Q is functional enough and t 6∈ T


The big picture

α⇐ β: if β can be broken, α can be broken

INC ⇐ UBK ⇒ TRAC⇓

OW

CCA ⇐ CPA⇓ ⇓

RCA + CCA ⇐ RCA

The weakest security notion is UBK-CPA.We don’t even know how to achieve it with E = AES . . .


Outline





5 � Conclusion


Achieving incompressibility

A toy example. . .

G group of secret order w and e = exponent with large entropy

Hard problems on GGiven desc(G) and e

UBK[G] find the group order w (FACT)

ORD[G] find the order of a group element (≡ FACT)

ROOT[G, e] find the e-th root of a group element (RSA)

GAP[G, e] find the group order w with the help of an e-th root

extractor (FACTRSA def= GAP-RSA)



Key generation: generate k = (desc(G), e,w)

Encryption: E (k,m) = me

Decryption: D(k , c) = c1/e mod w

CE(k , r = ””) just returns [m 7→ me ]

ThenORD[G]⇐ INC-CPA

assuming that the compressed program is algebraic.


ORD[G]⇐ INC-CPA

A

Challenger

k ← K(), r$← R

[Erk] = CE(k, r)

[Erk]

P∆(P,E(k, ·))

?6 δ and size (P )

?< λ

D(k, ·)

CE(k,R)

INC-CCA

INC-RCA

c′

m′

[Er′k ]

Here, [E rk ] = [m 7→ me ] and P is algebraic.

Using extract, we can find an execution of P where P(m) = mα

for a known α. Then

� either α 6= e then e − α ∝ ord(m) and we break ORD[G]� or α = e then size (P) > H(e) and P must be big



Security profile of CE :

⇐ORD[G] UBK[G] ROOT[G, e]⇑ ≡ ≡

INC-CPA ⇐ UBK-CPA ⇒ OW-CPA⇓ ⇓ ⇓

INC-CCA ⇐ UBK-CCA ⇒ OW-CCA≡ ≡ ≡

GAP[G, e] GAP[G, e] trivial

(under standard assumptions)




⇐ORD[G] ≡ UBK[G] ROOT[G, e]⇑ ≡ ≡

INC-CPA ⇐ UBK-CPA ⇒ OW-CPA⇓ ⇓ ⇓







⇐ORD[G] ≡ UBK[G] ROOT[G, e]≡ ≡ ≡

INC-CPA ≡ UBK-CPA ⇒ OW-CPA⇓ ⇓ ⇓









INC-CCA ⇐ UBK-CCA ⇒ OW-CCA⇓ ≡ ≡








INC-CCA ≡ UBK-CCA ⇒ OW-CCA≡ ≡ ≡









GAP[G, e] GAP[G, e] easy



Outline





5 � Conclusion


Traceable white-box programs

Assume we can hide ”functional perturbations” in [Drk ]

� a perturbation ci 7→ m′i means that [Drk ](ci ) returns m′i

instead of the correct plaintext mi = D(k, ci )

� the white-box compiler CE now takes a list of perturbations

(c1 7→ m′1, c2 7→ m′2, . . . , cu 7→ m′u)

as extra input

� assuming perturbations are ”hidden”, we can construct alog-efficient tracing scheme



Setup

User program Specification PerturbationsP1 [D(k , ·)] c1, c2, . . . , cnP2 [D(k , ·)] c2, c3, . . . , cnP3 [D(k , ·)] c3, c4, . . . , cn...

......

Pn−1 [D(k , ·)] cn−1, cnPn [D(k , ·)] cn

Note that

1. when c 6= c1, . . . , cn, all programs decrypt c correctly2. when c = ci , programs P1, . . . ,Pi are incorrect on c but

Pi+1, . . . ,Pn are correct



We get a private-key linear broadcast encryption (PLBE) scheme

With

p(0) = Pr [Q(c) = D(k, c)] for c$← C

p(v) = Pr [Q(cv ) = D(k , cv )] for v = 1, . . . , n

If there is a gap on the curve of p(v) for some v then v is a traitor.



Tracing algorithm on rogue decryption program Q

Estimate p(v) as p(v) and find a gap using dichotomy⇒ takes O(log n) executions of Q

Requires 2 assumptions on ”how well” perturbations are hidden bythe white-box compiler.

See details in the paper.


Outline





5 � Conclusion


Conclusion

New achievements

� framework of proper security notions for white-box compilers

� unbreakability + one-wayness + incompressibility is achievable

� traceability of programs is achievable under assumptions

A lot of issues remain

� are there any other security notions of interest?unforgeability? non-malleability? public verifiability?

� can we achieve any of these notions with a true blockcipher?

� . . . even just UBK-CPA with f = AES?

� can we extend traceability for f = any keyed function?


White-Box Security Notions for Symmetric Encryption Schemessac2013.irmacs.sfu.ca/slides/s14.pdf ·...

Documents

Transcript of White-Box Security Notions for Symmetric Encryption Schemessac2013.irmacs.sfu.ca/slides/s14.pdf ·...