White-Box Cryptography & Security Notions for Symmetric Encryption Schemes Cécile Delerablée Tancrède Lepoint Pascal Paillier Matthieu Rivain SDTA – November 5th, 2014
White-Box Cryptography& Security Notions for Symmetric Encryption Schemes
Cécile Delerablée Tancrède Lepoint Pascal Paillier Matthieu Rivain
SDTA – November 5th, 2014
Obfuscation
Transform a readable program P into an unreadable program O(P)
x
4
x
4
2 / 22
Recreational Obfuscation
Apply keyword substitution, use or non-use of whitespaceto create artistic effects, and self-generating or
heavily compressed programs, etc. to a readable program P
x
4
x
_(_,__,___){__<=1?___()}__(_,___){_+1;_3=__||(!_&&__==8)?_:9;}
_>_?__+!:___;_=__++;{_>1&&!_?_()}
43 / 22
General Obfuscation
For any P, generate an obfuscated O(P)code of O(P)≡ black-box oracle that runs P
x
4
x
O(P)
4
4 / 22
General Obfuscation: Known impossibility results [BGI+01]
For any P, generate an obfuscated O(P)code of O(P)≡ black-box oracle that runs P
x
4
x
O(P)
4
5 / 22
What Can We Obfuscate?
What about special purpose obfuscators for some ordinary functions?
É Point functions: OK in the random oracle model
É Possibly some cryptographic schemes?
6 / 22
White-Box Cryptography
6= General Program Obfuscation!
É Programs P = programs(f ) for f = some keyed function
É Hides some program properties π in the code but not all
É code ≡ black-box in some adversarial context
É No impossibility result for f = block cipher
É No secure construction for f =AESk, k← $
7 / 22
Attackers
Black-BoxAttacker
Grey-BoxAttacker
White-BoxAttacker
Worst-case model
8 / 22
Attackers
Black-BoxAttacker
Grey-BoxAttacker
White-BoxAttacker
Worst-case model
8 / 22
Attackers
Black-BoxAttacker
Grey-BoxAttacker
White-BoxAttacker
Worst-case model
8 / 22
Our Approach
What do we really want from white-box crypto?
1. given k← $, generate (possibly random) P = [AESk(·)]2. it must be hard to recover k by playing around with P
3. it must be hard to decrypt under k
4. we may want P to be big and incompressible
5. we may want to distribute traceable versions P1,. . . ,Pn
[DelerableeLepointPaillierRivain, SAC13]
É we capture 1−5 into concrete security gamesÉ we build a toy blockcipher that provably satisfies 2−4
É we build a construction that probably achieves 59 / 22
White-box compilersLet E = (K , E, D) be a symmetric encryption scheme
DefinitionA white box compiler CE takes as input a key k ∈K and some index r ∈R, andoutputs a program P =CE (k; r) = [Er
k].
Huge behavorial differences between
function E(·, ·) oracle E(k, ·) program [Erk]
analytic or algorithmicdescription
remote access, in-put/output only, state-ful?
word in a language,stateless, copiable,transferable, modifi-able, etc.
(specification) (smart card) (executable software)
10 / 22
Security Notion
=
Adversarial goal + attack model
11 / 22
Attack ModelsGiven the decription of CE (·, ·) and P = [Er
k] for unknown k ∈K :
É Chosen Plaintext Attack – CPA: can encrypt any plaintext
É Chosen Ciphertext Attack – CCA: can make decryption queries to anoracle D(k, ·)
É Recompilation Attack – RCA: can make recompilation requests to getother programs [Er′
k ] for unknown r′ 6= r
É Combined Attack – RCA+CCA: most powerful (?)
12 / 22
Unbreakability - UBK
A
k ← K(), r$← R
[Erk] = CE(k, r)
[Erk]
k̂k̂
?= k
Challenger
D(k, ·)
CE(k,R)
UBK-CCA
UBK-RCA
c′
m′
[Er′k ]
No semantic security on k: verifying k̂ = k is easy
13 / 22
One-Wayness - OW
A
k ← K(), r$← R
[Erk] = CE(k, r)
m$← M
c = E(k,m)[Er
k], c
m̂m̂
?= m
Challenger
D(k, ·)
CE(k,R)
OW-CCA
OW-RCA
c′
m′
[Er′k ]
No semantic security on m: verifying m̂=m is easy
14 / 22
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 ]
15 / 22
Traceability - TRAC
CE admits a tracing scheme if there exists an algorithm trace such that noadversary can win the ”tracing game”
A
k ← K(), t← T ()
∀i ∈ ID,∀j ∈ {1, . . . , q}, ri,j $← R∀i ∈ ID,∀j ∈ {1, . . . , q}, [Eri,j
k,t,i] = CE,T (k, t, i, ri,j)
{[E
ri,jk,t,i]
}i∈ID,j∈{1,...,q}
m̂m̂
?∈ S(t, ID)
Challenger
D(k, ·)
CE,T (k, t, ID,R)
TRAC-CCA
TRAC-RCA
c′
m′
[Er′k,t,i′ ]
16 / 22
Big Pictureα⇐β : if β can be broken, α can be broken
INC ⇐ UBK ⇒ TRAC⇓
OW
CCA ⇐ CPA⇓ ⇓
RCA+CCA ⇐ RCA
Weakest notion: UBK-CPA... we don’t even know how to achieve it with E =AES
... but we can achieve notions for specific E
17 / 22
Big Pictureα⇐β : if β can be broken, α can be broken
OKINC ⇐ UBK ⇒ OKTRAC⇓
OK=public keyOW
CCA ⇐ CPA⇓ ⇓
RCA+CCA ⇐ RCA
Weakest notion: UBK-CPA... we don’t even know how to achieve it with E =AES... but we can achieve notions for specific E
17 / 22
Conclusion
Achivements
É framework of proper security notions for white-box compilers
É unbreakability + one-wayness + incompressibility is achievable
É traceability of programs is achievable under assumptions
Open problems
É 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?18 / 22
What CAN be done?
19 / 22
Pay TV & Traitor Tracing
20 / 22
Payment on Mobile
É Secure Element (Hardware)
É Software Implementation?
21 / 22