Upload
hope-beere
View
214
Download
3
Tags:
Embed Size (px)
Citation preview
Leakage- Resilient Cryptography: Recent Advances
Research Exam
May 20, 2010
Petros Mol
1
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
2
hidden
visible
• > 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,…
Cryptography in the ideal world
3
• Provable Security: Any (efficient) adversary that “breaks” primitive Π, implies an efficient algorithm against a problem considered to be hard
4
Ideal world: State of the art
primitives
(comp/nal) hardness
assumptions
reductions
Unless a major algorithmic breakthrough happens,
things look good
Cryptography in the real world
5
• 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
Real World situation • Systems vulnerable to such attacks
– Smart cards– General/specific purpose hardware– Software implementations
6
• Primitives vulnerable to such attacks– All primitives actually implemented on a physical device
Side-Channel Attacks
definition: an attack based on extra information gained by the physical implementation of a protocol
…from Side Channel Attacks Database
7
The decade 1999-2008• over 600 publications• over 50 patents• 19 PhD theses
Side-Channel Attacks (from computation)
• Timing Attacks: secret key information leaked as a result of
of measuring execution time
8
• Power Analysis:
power consumption measurements reveal
sequence of instructions executed
• Fault Induction:
secret information revealed as a result of
execution of erroneous operation
Cold-boot (memory) attacks
•standard DRAM cells refresh interval: ~ms
•in practice cells retain content for much longer
•~ 30o C : complete loss only after tens of seconds
9
At low temperatures (-50o C) contents might be retained for minutes or hours
[HSH+, USENIX Security 08]
10
Memory (cold-boot) attacks- bits decay to known “ground states” following predictable patterns
5 sec 30 sec 5 min1 min
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
11
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
12
Timing & Power analysis
FaultInduction
Cold bootattacks
• Ad-hoc: target specific side channel attacks
13
HW/Implementation-level countermeasures
• 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
Design process in practice
1st const.
Side-chan.attack 1
fix2nd const.
Side-chan.attack 2
fix
14
. . . nth const.fix
Q: Can we construct primitives that are provable secure in the presence of side-channel information ?
15
Idealizing the Real world
primitives assumptionsreductions
Rest of talk• Leakage Resilient Cryptography
o Modeling Leakage Formallyo Continuous Leakage
o Bounded (Memory) Leakage
o Auxiliary Input
o Security Definitions / Overview of techniqueso Example 1: LR stream cipher
o Example 2: LR password authentication
• Conclusions
o Has the picture changed ?
o Future Directions16
• Approach: It is impossible to– prevent side-channel attacks– predict all possible ways side-channel information can
be collected by an attacker
17
Leakage-Resilient Cryptography (LRC)
• 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
Modeling Side-Channel information
18
[Micali, Reyzin 04: Physically Observable Cryptography]
separation of functionality and implementation
Physically implementedprimitive Π
Associated leakage
Abstract functionalit
y
Π= (A, L) A: implementation independentL: HW / implementation specific
19
• Adversary has access to a leakage oracle that models all sources of side channel information
Modeling Side-Channel information
leakage oracle
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
[MR04, Axiom 5]
Leaked information is efficiently computable
[MR04, Fundamental Physical Assumption]
physical implementations of primitives s.t. leakage does not reveal the entire secret state
Universal Requirement 1
Universal Requirement 2Given
it shouldn’t be trivial to recover Si
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
Model Domain Range Additional restrictions
Practical Scenario
continuousleakage
accessed state
unbound.bounded per invocation (round)
leakage from computation
Memory Leakage
entire sk boundedcold-boot attacks
Auxiliary Input
entire sk unbound.comp/ly hard to find sk, given f(sk)
both
(Partial) Taxonomy of Derived Models
Each model might or might not be appropriate depending on the actual practical setting
• 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 practice24
Leakage Models: Comparison/Discussion
Outline• Leakage Resilient Cryptography
o Modeling Leakage Formallyo Continuous Leakage
o Bounded (Memory) Leakage
o Auxiliary Input
o Security Definitions / Overview of techniqueso Example 1: LR stream cipher
o Example 2: LR password authentication
• Conclusions
o Has the picture changed ?
o Future Directions25
• Security of PRFs:
Given pairs (for x’s of his choice) no
efficient adversary can tell which world he interacts with.
26
New Security DefinitionsPseudorandom Functions (PRFs) (without leakage)
REAL
IDEAL
• Trivial Attack (single query, 1 bit of leakage)
Adversary encodes x in f
If output “REAL” else “IDEAL”
27
New Security Definitions
Pseudorandom Functions (PRFs) (with leakage)
REAL
IDEAL
• Security of weak PRFs:
Given pairs (for random x’s) no efficient adversary can tell
which world he interacts with.
28
Security in the presence of leakage
REAL
IDEAL
Weak PRFs
Q: Can we prove leakage resilience of wPRFs?
A: Yes (but security degrades exponentially in the leakage)
• Define
• F: ε-wPRF: for all PPT adversaries A
29
[Pietrzak 09: A Leakage-Resilient Mode of Operation]
Weak PRFs are leakage resilient.
Theorem (informal) [Pietrzak 09]
Assume such that . If ε-wPRF for uniform keys, then δ-wPRF for keys K drawn according to , where
• Why ``only computation leaks information” ?
30
Towards constructing a LR- stream cipher
• Π: stateful primitive
• State update (round i):
• Upper bound on |Si| : M
Attack (1 bit of leakage per round)
At round i: adversary queries leakage function
After M queries, adversary gets SM scheme completely broken!!
Leakage function takes the whole state as input
32
Stream Cipher in the continuous leakage model
State
Computation
F: weak PRF
Update uses part of the state
33
Leakage-resilient Stream Cipher
• 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)
Update rule:
Outline• Leakage Resilient Cryptography
o Modeling Leakage Formallyo Continuous Leakage
o Bounded (Memory) Leakage
o Auxiliary Input
o Security Definitions / Overview of techniqueso Example 1: LR stream cipher
o Example 2: LR password authentication
• Conclusions
o Has the picture changed ?
o Future Directions34
35
Bounded leakage model (toy example)Password Authentication (w/o leakage)
secure channel clientserver
insecure storage
Problem: Client wants to authenticate itself to the server
(g, y=g(x)) (sk=x)
• Solution: Use One-Way Functions (OWF) . g is OWF- easy to compute - hard to invert
for all efficient A
secure storage
36
Password Authentication (with leakage)
secure channel clientserver
Problem: Attacker gets in addition l bits of leakage
(g, y=g(x)) (sk=x)
• Solution: Use l-Leakage-Resilient-OWF . g is l-LR-OWF
- … hard to invert. For all efficient A
insecure storagef(x)
leakage
• Observation: OWFs imply l-LR-OWFs with exponential (in l) loss in security
37
Password Authentication (with leakage)
Inverter
Input: (g,y=g(x)) Inverter (I) with Leakage
Advantage: ε
Proof Idea
x’
38
Password Authentication (with leakage)
secure channel clientserver
(g, y=g(x)) (sk=x)
insecure storagef(x)
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
• [Theorem (informal)]: If SPRF with then h is l-LR-OWF with
40
AInput: (x, h) Inverter (I)
with Leakage
Advantage: ε
Proof Idea
x’Output: x’ if
Password Authentication (with leakage)
41
AInput: (x, h)
Inverter (I) with
Leakage
Advantage: εx’
Output: x’ if
Password Authentication (with leakage)
Even given y= h(x) AND leakage = f(x) there exist on average preimages for y
But and
Security definitions for PKE
• Standard ind/lity under chosen plaintext attacks
(IND-CPA)
1.(sk,pk) KeyGen2.(m0,m1,state) A1(pk)
3.c* Enc(pk,mb)
4.b’ A2(c*,state)5.if (b’=b) return 1, else return 0
42
• ind/lity under chosen plaintext attacks with leakage
(l-leakage-CPA)
1.(sk,pk) KeyGen2.(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
43
Adversary can query any (PT) leakage function f
No leakage allowed after the creation of the challenge c*
Security definitions for PKE
LRC: Primitives (overview)
44
Con
tinuo
us
Leak
age
Bou
nded
Lea
kage
& A
uxili
ary
Inpu
t
2009 20102008I I I
LR- StreamCipher
SimplifiedLR- SC
LR st/fulsig/res
CPA-PKE,IBE
CPA / CCA-PKE,generic constructionsimproved leakage
CPA/CCA SKE
sign/resgen. const.
CPA PKE
LR PKE(gen. mod)
Outline• Leakage Resilient Cryptography
o Modeling Leakage Formallyo Continuous Leakage
o Bounded (Memory) Leakage
o Auxiliary Input
o Security Definitions / Overview of techniqueso Example 1: LR stream cipher
o Example 2: LR password authentication
• Conclusions
o Has the picture changed ?
o Future Directions45
46
LRC in designing process
1st const.
Side-chan.attack 1
fix 2nd const.
Side-chan.attack 2
fix . . . nth const.fix
Before
Now
1. Consider classes of leakage functions that are as rich as possible (and for which there is a proof)
2. Construct primitives that are provably leakage resilient with respect to
3. Design hardware/ Write code whose leakage is faithfully modeled by
47
LRC in designing process
1st const.
Side-chan.attack 1
fix 2nd const.
Side-chan.attack 2
fix . . . nth const.fix
Before
Now
1. Consider classes of leakage functions that are as rich as possible (and for which there is a proof)
2. Construct primitives that are provably leakage resilient with respect to
3. Design hardware/ Write code whose leakage is faithfully modeled by
How LRC changed the picture ?
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)48
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
More on Modeling Gaps
• What does it mean in practice for a smart card, to leak at most k bits per encryption?
49
• 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)
Outline• Leakage Resilient Cryptography
o Modeling Leakage Formallyo Continuous Leakage
o Bounded (Memory) Leakage
o Auxiliary Input
o Security Definitions / Overview of techniqueso Example 1: LR stream cipher
o Example 2: LR password authentication
• Conclusions
o Has the picture changed ?
o Future Directions50
Look to the future
51
• 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
[Goldwasser, Kalai, Peikert, Vaikuntanathan 10: Robustness of LWE
rob/ness of assumptions vs rob/ness of costructions
• Allowing (restricted) access to the leakage oracle after the creation of the challenge.
- How does this affect security guarantees?