1. Leakage- Resilient Cryptography: Recent Advances
Research Exam
Petros Mol
May 20, 2010

2. Cryptography in the ideal world
KeyGen()
sk $ SK
pk  f
return pk
Encrypt(m) r
c  …
return c
Decrypt($%^#)
m  f ($%^#)
return m
Primitives as mathematical objects
Restricted interaction between primitive and user/attacker
Secret information completely hidden from the adversary
primitives are black-box
Interaction depends on the security notion
hidden
visible

3. Cryptography in the ideal world
> 30 years of extensive research
Primitives and notions for all tastes…
CPA/CCA encryption, UFCMA signature schemes
Collision resistant hash functions
NIZK protocols with honest but curious verifiers etc.
fully homomorphic encryption
… and from many hardness assumptions
Number theoretic: Factoring, DLP, DDH,QR,...
Lattice based: GapSVP, uSVP,…

4. Ideal world: State of the art
(comp/nal) hardness assumptions
primitives
reductions
Provable Security: Any (efficient) adversary that “breaks” primitive Π, implies an efficient algorithm against a problem considered to be hard
Central Concept: Provable security
Unless a major algorithmic breakthrough happens,
things look good

5. Cryptography in the real world
Protocols are executed in actual physical devices
Adversary can attack the implementation of a protocol
Interaction between adversary and primitive much less restricted
secret information no longer perfectly hidden from the adversary

6. Real World situation Systems vulnerable to such attacks
Smart cards
General/specific purpose hardware
Software implementations
Primitives vulnerable to such attacks
All primitives actually implemented on a physical device
Present motivation in a better way

7. Side-Channel Attacks …from Side Channel Attacks Database
definition: an attack based on extra information gained by the physical implementation of a protocol
…from Side Channel Attacks Database
The decade
over 600 publications
over 50 patents
19 PhD theses

8. Side-Channel Attacks (from computation)
Timing Attacks:
secret key information leaked as a result of
of measuring execution time
Power Analysis:
power consumption measurements reveal
sequence of instructions executed
power analysis: If the execution path depends on processed data (secret key etc)
Common feature: side-channel info is leaked as a result of computation
Fault Induction:
secret information revealed as a result of
execution of erroneous operation

9. Cold-boot (memory) attacks
[HSH+, USENIX Security 08]
standard DRAM cells refresh interval: ~ms
in practice cells retain content for much longer
~ 30o C : complete loss only after tens of seconds
At low temperatures (-50o C) contents might be retained for minutes or hours

10. Memory (cold-boot) attacks
- bits decay to known “ground states” following predictable patterns
5 sec
30 sec
5 min
1 min

11. A (very partial) list of attacks
Type of Attack
Protocol/software attacked
Timing
RSA, El Gamal, DSA,
AES, DES, RC5
Power Analysis
RSA, DES, AES
Fault Induction
RSA, ECC, DES, RC5,
Blowfish, identification schemes
Memory Attacks
AES, DES, RSA,
FileVault, TrueCrypt, BitLocker
RC5 is a block cipher
Other types of SC attacks; Electromagnetic radiation, heat, sound, cache

12. HW/Implementation-level countermeasures
“Obfuscate” computation by decreasing the Signal-to-Noise Ratio
Perform random operations
Randomize the execution sequence
Decorrelate input from intermediate values
Consistency checks
Run (parts of the) algorithm twice and check if results coincide
Reduce information leaked about the key
Encrypt key in memory
Avoid storing redundant info about the key
Timing & Power analysis
Fault
Induction
Cold boot
attacks

13. HW/Implementation-level countermeasures
Ad-hoc: target specific side channel attacks
Expensive:
hardware level masking very costly
train programmers to write and maintain code that minimizes leakage
incur significant slowdowns in the running time
Insufficient: Can only decrease the efficiency of the attack but not completely eliminate it

14. Design process in practice
1st const.
2nd const.
nth const.
fix
fix
. . .
fix
Side-chan.
attack 2
Side-chan.
attack 1

15. Idealizing the Real world
assumptions
primitives
reductions
Central Concept: Provable security
Q: Can we construct primitives that are provable secure in the presence of side-channel information ?

16. Rest of talk Leakage Resilient Cryptography Modeling Leakage Formally
Continuous Leakage
Bounded (Memory) Leakage
Auxiliary Input
Security Definitions / Overview of techniques
Example 1: LR stream cipher
Example 2: LR password authentication
 Conclusions
Has the picture changed ?
Future Directions

17. Leakage-Resilient Cryptography (LRC)
Approach: It is impossible to
prevent side-channel attacks
predict all possible ways side-channel information can be collected by an attacker
Face the truth: Devices are not black-boxes
No restriction on how the adversary obtains side-channel information
only on what information he can obtain.
Ultimate Goal: Develop Cryptography that is secure against wide classes of leakage

18. Modeling Side-Channel information
[Micali, Reyzin 04: Physically Observable Cryptography]
separation of functionality and implementation
Physically implemented
primitive Π
Abstract functionality
Associated leakage
We don’t care about how the information is collected (we don’t care about the specific side-channel attack)
This allows to model any side-channel information abstractly (the leakage)
Here we present a relaxation of the Micali Reyzin model
Leakage is hardware/implementation specific
A: implementation independent
L: HW / implementation specific
Π= (A, L)

19. Modeling Side-Channel information
leakage oracle
Adversary has access to a leakage oracle that models all sources of side channel information

20. Micali- Reyzin model (somewhat relaxed)
at i-th execution round
Randomness (environmental noise)
Adversarially chosen (measurement)
Secret (internal) state of the protocol
Compactly (randomized f, Mi encoded in f)
** For stateless primitives Si might simply the secret key**

21. Modeling Leakage for Cryptography
Universal Requirement 1
[MR04, Axiom 5]
Leaked information is efficiently computable
Universal Requirement 2
Given
it shouldn’t be trivial to recover Si
[MR04, Fundamental Physical Assumption]
physical implementations of primitives s.t. leakage does not reveal the entire secret state

22. (Partial) Taxonomy of Derived Models
Type (family) of f
restricted
arbitrary
This talk
Domain (effective input) of f
entire secret state
active state
[MR04, Axiom 1]
Only Computation leaks Information
Range of f ( )
bounded :
unbounded :

23. (Partial) Taxonomy of Derived Models
Domain
Range
Additional restrictions
Practical Scenario
continuous
leakage
accessed state
unbound.
bounded per invocation (round)
leakage from computation
Memory Leakage
entire sk
bounded
cold-boot attacks
Auxiliary Input
comp/ly hard to find sk, given f(sk)
both
Each model might or might not be appropriate depending on the actual practical setting

24. Leakage Models: Comparison/Discussion
continuous leakage
fails to capture memory attacks
proofs rely on the fact that parts of the key don’t participate in the computation
bounded (memory) leakage
captures scenarios where attacker has one-shot
are not very realistic in settings where many computations take place
auxiliary input
somehow combines best of both worlds
requires exponential hardness of the leakage function  hard to interpret what that means in practice

25. Outline Leakage Resilient Cryptography Modeling Leakage Formally
Continuous Leakage
Bounded (Memory) Leakage
Auxiliary Input
Security Definitions / Overview of techniques
Example 1: LR stream cipher
Example 2: LR password authentication
 Conclusions
Has the picture changed ?
Future Directions

26. New Security Definitions
Pseudorandom Functions (PRFs) (without leakage)
REAL
IDEAL
PRFs are central primitive in cryptography
building block for more advanced primitives
Security of PRFs:
Given pairs (for x’s of his choice) no efficient adversary can tell which world he interacts with.

27. New Security Definitions
Pseudorandom Functions (PRFs) (with leakage)
REAL
IDEAL
PRFs are central primitive in cryptography
building block for more advanced primitives
Trivial Attack (single query, 1 bit of leakage)
Adversary encodes x in f
If output “REAL” else “IDEAL”

28. Security in the presence of leakage
Weak PRFs
REAL
IDEAL
Security of weak PRFs:
Given pairs (for random x’s) no efficient adversary can tell which world he interacts with.
PRFs are central primitive in cryptography
building block for more advanced primitives
Q: Can we prove leakage resilience of wPRFs?
A: Yes (but security degrades exponentially in the leakage)

29. Weak PRFs are leakage resilient.
[Pietrzak 09: A Leakage-Resilient Mode of Operation]
Define
F: ε-wPRF: for all PPT adversaries A
Theorem (informal) [Pietrzak 09]
Assume such that . If ε-wPRF for uniform keys, then δ-wPRF for keys K drawn according to , where

30. Towards constructing a LR- stream cipher
Why ``only computation leaks information” ?
Π: stateful primitive
State update (round i):
Upper bound on |Si| : M
Leakage function takes the whole state as input
Attack (1 bit of leakage per round)
At round i: adversary queries leakage function
After M queries, adversary gets SM
scheme completely broken!!

31. Stream Cipher in the continuous leakage model
F: weak PRF
Init ; ;
Update uses part of the state
State
Computation

32. Stream Cipher in the continuous leakage model
F: weak PRF
State
Update uses part of the state
Computation

33. Leakage-resilient Stream Cipher
Update rule:
K2i , K2i+1 evolve “independently”
Intuition: If F is instantiated with a weak PRF and K, X have high min-entropy, then the output F(K,X) has high (pseudo-)entropy, even given the leakage f(K ,X)

34. Outline Leakage Resilient Cryptography Modeling Leakage Formally
Continuous Leakage
Bounded (Memory) Leakage
Auxiliary Input
Security Definitions / Overview of techniques
Example 1: LR stream cipher
Example 2: LR password authentication
 Conclusions
Has the picture changed ?
Future Directions

35. Bounded leakage model (toy example)
Password Authentication (w/o leakage)
secure channel
client
server
(g, y=g(x))
(sk=x)
insecure storage
secure storage
Problem: Client wants to authenticate itself to the server
Solution: Use One-Way Functions (OWF) . g is OWF
easy to compute
hard to invert
for all efficient A

36. Password Authentication (with leakage)
server
secure channel
client
(g, y=g(x))
(sk=x)
f(x)
insecure storage
Problem: Attacker gets in addition l bits of leakage
Solution: Use l-Leakage-Resilient-OWF . g is l-LR-OWF
- … hard to invert. For all efficient A
leakage

37. Password Authentication (with leakage)
Observation: OWFs imply l-LR-OWFs with exponential (in l) loss in security
Proof Idea
Inverter (I) with Leakage
Advantage: ε
Inverter
Input: (g,y=g(x)) x’

38. Password Authentication (with leakage)
server
secure channel
client
(g, y=g(x))
(sk=x)
f(x)
insecure storage
Using OWF g, the authentication protocol can resist l bits of leakage assuming g is hard to invert.
Q: Can we avoid this exponential loss in security?

39. Password Authentication (with leakage)
Workaround: Second Preimage Resistant Functions
is SPRF if:
easy to compute
given x, h hard to find such that h(x’)=h(x)
Known constructions of SPRFs from number-theoretic assumptions

40. Password Authentication (with leakage)
[Theorem (informal)]: If SPRF with then h is l-LR-OWF with
Proof Idea
Inverter (I) with Leakage
Advantage: ε A
Input: (x, h)
Output: x’ if x’

41. Password Authentication (with leakage)
Inverter (I) with Leakage
Advantage: ε A
Input: (x, h)
Output: x’ if x’
But and
Even given y= h(x) AND leakage = f(x) there exist on average preimages for y

42. Security definitions for PKE
Standard ind/lity under chosen plaintext attacks
(IND-CPA)
1.(sk,pk)  KeyGen
2.(m0,m1,state)  A1(pk)
3.c* Enc(pk,mb)
4.b’ A2(c*,state)
5.if (b’=b) return 1, else return 0

43. Security definitions for PKE
ind/lity under chosen plaintext attacks with leakage
(l-leakage-CPA)
1.(sk,pk)  KeyGen
2.(m0,m1,state)  A1(pk,f(sk,pk))
3.c* Enc(pk,mb)
4.b’ A2(c*,state)
5.if (b’=b) return 1, else return 0
Adversary can query any (PT) leakage function f
No leakage allowed after the creation of the challenge c*

44. LRC: Primitives (overview)
LR PKE
(gen. mod)
LR- Stream
Cipher
Simplified
LR- SC
Continuous Leakage
LR st/ful
sig/res
2008
2009
2010 I I I
CPA/CCA SKE
sign/res
gen. const.
CPA-PKE,
IBE
Bounded Leakage
& Auxiliary Input
CPA PKE
CPA / CCA-PKE,
generic constructions
improved leakage

45. Outline Leakage Resilient Cryptography Modeling Leakage Formally
Continuous Leakage
Bounded (Memory) Leakage
Auxiliary Input
Security Definitions / Overview of techniques
Example 1: LR stream cipher
Example 2: LR password authentication
 Conclusions
Has the picture changed ?
Future Directions

46. LRC in designing process
1st const.
Side-chan.
attack 1
fix
2nd const.
attack 2
. . .
nth const.
Before
Consider classes of leakage functions that are as rich as possible (and for which there is a proof)
Construct primitives that are provably leakage resilient with respect to
Design hardware/ Write code whose leakage is faithfully modeled by
Now

47. LRC in designing process
1st const.
Side-chan.
attack 1
fix
2nd const.
attack 2
. . .
nth const.
Before
Consider classes of leakage functions that are as rich as possible (and for which there is a proof)
Construct primitives that are provably leakage resilient with respect to
Design hardware/ Write code whose leakage is faithfully modeled by
Now

48. How LRC changed the picture ?
Cons
Modeling gaps (more on that in the next slide)
constructions and models more tailored to proof techniques rather than to practical needs.
some models unintuitive and hard to interpret in practice.
Performance implications:
for same level of security size of secret keys might get much longer  more storage, slower operations
Pros
Brought Side-Channel attacks (closer) to theoreticians’ attention and improved their understanding on the subject.
Set basis for formal treatment of a serious practical problem
Can potentially bring Cryptography closer to hardware designers : clearer engineering goals (though not easy ones)

49. More on Modeling Gaps
What does it mean in practice for a smart card, to leak at most k bits per encryption?
Modeling leakage as an uninvertible function makes proofs go through but doesn’t make engineers’ life any easier.
Adversary has no access to leakage oracle once given the challenge. Does this make sense?
(byproduct of considering arbitrary leakage functions)

50. Outline Leakage Resilient Cryptography Modeling Leakage Formally
Continuous Leakage
Bounded (Memory) Leakage
Auxiliary Input
Security Definitions / Overview of techniques
Example 1: LR stream cipher
Example 2: LR password authentication
 Conclusions
Has the picture changed ?
Future Directions

51. Look to the future
Construct more Leakage Resilient primitives
… that resist more leakage
… from more hardness assumptions
Flexible LR constructions:
Design independent of leakage
Security degrades with leakage but in the absence of leakage primitive as secure as a leakage-free ones
rob/ness of assumptions vs rob/ness of costructions
[Goldwasser, Kalai, Peikert, Vaikuntanathan 10: Robustness of LWE
Allowing (restricted) access to the leakage oracle after the creation of the challenge.
- How does this affect security guarantees?