Upload
sarai
View
24
Download
0
Embed Size (px)
DESCRIPTION
Cryptography against continuous memory attacks. NYU. Yevgeniy Dodis , Kristiyan Haralambiev , Adriana Lopez-Alt and Daniel Wichs. MIT/MSR Reading Group. Motivation: Leakage-Resilient Crypto. Security proofs in crypto require an adversarial attack model . - PowerPoint PPT Presentation
Citation preview
CRYPTOGRAPHY AGAINST CONTINUOUS MEMORY
ATTACKSYevgeniy Dodis, Kristiyan
Haralambiev, Adriana Lopez-Alt and Daniel Wichs
MIT/MSR Reading Group
NYU
Motivation: Leakage-Resilient Crypto
Security proofs in crypto require an adversarial attack model. e.g. adversary sees public-keys but not secret-keys.
Reality: schemes broken using attacks outside of model. Side-channels: timing, power consumption, heat,
acoustics, radiation. The cold-boot attack. Hackers, Malware, Viruses.
Usual Crypto Response: Not our problem. Blame the Engineers…
Leakage-Resilient Crypto: Let’s try to help. Primitives that provably allow some leakage of secret key.
Modeling Leakage
During an attack, adversary can query “leakage-oracle” with “leakage-functions” f : {0,1}* ! {0,1}. Learns f(sk).
Need to restrict leakage so adv. does not learn sk in full. Bound number of queries during various stages of
attack. Restrict type of allowed leakage-functions.
skf
f(sk)
Modeling Leakage
Type: Restricted functions vs. Memory Attacks. Restricted leakage functions f.
Individual bits, AC0 circuits... [Riv97, ISW03, FRR+10, …] “Only computation leaks information” [MR04, DP08]
Memory Attacks [AGV09]: All efficient functions f are legal.
Amount: One-Time vs. Continuous. One-time: Total number of leakage queries is bounded by
L. Continuous:
The secret key of the scheme gets updated periodically. Number of queries is bounded by L in each “period” but not
overall.
Prior Work
OCLI Stream Cipher OCLI Signatures [DP08, Pie09, KKPR10]
General Computation [ISW03, FRRTV10, JRV10].
?All-Or-Nothing-
Transform (AONT)[Riv97, Boy99, CDH+00, DSS01, KZ03]
PKE [AGV09, NS09, ADNS+10, DHLW10]
Signatures [ADW09, KV09, DHLW10]
ID/AKA [ADW09, DHLW10]
Other: [Dzi06, CLW06, ADW09, DKL09, ADNS+10, DGK+10, GKPV10]
Continuous
One time
Restricted Memory
Continuous Leakage + Memory Attacks?
Question: Can we get the best of both worlds?
Continuous Leakage Resilience (CLR)
Secret key can be updated using only local randomness. Public-key stays the same. Other users do not need to know about updates.
Number of leakage queries bounded by L in between updates. No bound on number of queries over the lifetime of the
system.
No restriction on the type of leakage (memory attacks). Adversary cannot predict randomness for future updates. (No leakage during the update).
Efficiency does not degrade with the number of updates.
Model of CLR Security
Initial Steps Towards CLR
[ADW09]: Construct CLR signatures but updates require an “external master key” that never leaks.
[BKKV10]: Construct CLR signatures, but… Requires a non-standard and non-black-box
assumption. Uses PCP theorem, so not practical. (Main results to follow. Stay tuned…)
Our Results
Build the first CLR schemes under standard assumptions (K-Linear in bilinear groups). Signatures, ID schemes, Authenticated-Key-
Agreement
In each period, leak up to ½ of the secret key.
All schemes are efficient/practical.
Main technical result: CLR One-Way Relation.
Main Technical Problem:CLR One-Way Relation
pk
sk
R(pk, sk)=1
(pk, sk) Ã KeyGen()
• KeyGen() generates (pk, sk) pairs. • Relation R tests if (pk, sk) are valid.
Basic One-Wayness: Given pk, can’t find sk* s.t. R(pk, sk*) = 1.
Main Technical Problem:CLR One-Way Relation
pk
sk
• KeyGen() generates (pk, sk) pairs. • Relation R tests if (pk, sk) are valid.• Rerand(sk) refreshes the secret key.• Can refresh arbitrarily many times.
Rerand(sk)
R(pk, sk)=1Rerand Rerand Rerand
…
Main Technical Problem:CLR One-Way Relation
pk
sk Adversary gets pk.
Can ask for up to L bits of information about sk.What’s the 2nd bit of
sk ?What’s the 3rd bit of
SHA-1(sk) ?
Security
Main Technical Problem:CLR One-Way Relation
pk
sk Adversary gets pk.
Can ask for up to L bits of information about sk.
Key is refreshed.
Security
Main Technical Problem:CLR One-Way Relation
pk
Adversary gets pk. Can ask for up to L
bits of information about sk.
Key is refreshed. Wins if R(pk, sk*)
= 1.
Security
sk* =
Difficulty of Constructing CLR-OWR
In a reduction, need to know many valid secret-keys in full.
Nevertheless, need to solve some hard problem given a valid forgery by the adversary.
Hope: forgery of different type then secret-keys we know.
Adversary gets unbounded amount of information in total. Why can’t it “learn” the type?
Outline of Construction
1. General strategy to handle continuous leakage. Reduce “continuous leakage” to “one-time leakage”.
2. Construction from (special) PKE/NIZK.
3. Instantiate components based on DDH/K-Linear.
Strategy for CLR-OWR
For each public-key pk: Valid: { sk : R(pk, sk) = 1}. Good ½ Valid Bad = Valid \ Good
Can sample pk along with: samG : Samples sk 2 Good. samB : Samples sk 2 Bad. dk : isGood(sk, dk) = 0/1.
Re-randomize inside Good. Given pk, samG, sk 2 Good :
Rerand(sk) ¼ Sample(samG)
goodbad
All possible sk
Valid for pk
Strategy for CLR-OWR
Security Hardness of Good Keys:
Given pk, samB, find sk* s.t. isGood(sk*, dk) = 1.
Hardness of Bad Keys: Given pk, samG, find sk* s.t. isGood(sk*, dk)
= 0. L-Leakage-Indistinguishability:
Adv. gets pk, samG, samB. Challenger randomly chooses {good, bad}
key sk. Adv. gets L bits of leakage on sk. Wins if produces sk* in the same category as
sk.
goodbad
Leakage Indistinguishable Re-randomizable Relation (LIRR)
Only “one-time memory attack”.
1. LIRR ) CLR-OWR
Claim: An L-LIRR is a L-CLR-OWR Proof:
Adversary only sees random good keys. Forgery must be a good key by “hardness of bad keys”.
One-by-one, switch good keys for bad keys. Pr[forged key is good] does not decrease by “L-Leakage-
Ind.”. Adversary only sees bad keys. Yet forgery is good.
Contradicts “hardness of good keys”.
Outline of Construction
1. General strategy to handle continuous leakage. Reduce “continuous leakage” to “one-time leakage”.
2. Construction from (special) PKE/NIZK.
3. Instantiate components based on DDH/K-Linear.
Constructing LIRR
Let E1, E2 be two PKE and ¦ be a NIZK argument-system.
The LIRR scheme samples: pk = (CRS, pk1, pk2, c1) where c1 = Encpk1(m;r) for rand m. Secret-keys have form sk = (c2, ¼).
Valid sk: ¼ proves that “(c1, c2) encrypt same message”. Good sk: (c1, c2) actually encrypt the same message.
Sample good keys with samG = (m , r). Sample bad keys with samB = TD (simulation trap-door). Distinguish good/bad with dk = (sk1, sk2)
Constructing LIRR
Re-randomization.
Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability.
Constructing LIRR (Hardness)
Claim: The “hardness of good/bad keys” holds if E1 is “one-way secure” (weaker than semantic-sec) and ¦ is sound.
Proof: Given samG = (m , r), producing a bad key, requires
proving an invalid statement (break soundness). Given samB = TD, producing a good key inverts c1
(break one-wayness of E1).
pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).
samG = (m , r) , samB = TD , dk = (sk1, sk2)
Valid sk: ¼ proves that “(c1, c2) encrypt same message”. Good sk: (c1, c2) actually encrypt same message.
Constructing LIRR
Re-randomization.
Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability.
Constructing LIRR (Re-randomization)
To re-randomize sk = (c2, ¼) need to: Re-randomize the ciphertext c2. (same message,
fresh rand.) Update the NIZK proof ¼ (new statement, fresh
rand).
pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).
Constructing LIRR (Re-randomization)
Assume E1, E2, ¦ are homomorphic over some groups.
Hom. Encryption: Enc(m; r) + Enc(m’; r’) = Enc(m + m’; r + r’).
Hom. Language: x 2 L, x’ 2 L ) x + x’ 2 L.
Hom. NIZK for Hom. Language. If ¼, ¼’ are proofs of x, x’ then ¼ + ¼’ is a proof of x+x’. Notion of re-randomizable/malleable NIZKS defined in [BCC+09].
Language “(c1, c2) encrypt the same message” is homomorphic. Notice (c1 , c2 + Enc(0;r)) = (c1, c2) + (Enc(0;0), Enc(0;r) ).
pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).
Constructing LIRR
Re-randomization. (If E1, E2, ¦ are “homomorphic”)
Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability.
To get leakage indistinguishability, need “something” from E2.
Given L bits of leakage on ctext c, can’t produce related ctext c’. Adversary gets pk. Chooses m0, m1. Challenger chooses b à {0,1}. Sets c = Enc(mb).
Adversary gets L bits of leakage on ciphertext c. Adversary makes 1 decryption query on any c*. Wins if guesses
b. Call this L-“Leakage-of-Ciphertext Non-Malleability” (L-LoC-NM).
Notice: Non-malleable Enc ) |m|-LoC-NM ) CPA. But we need L-LoC-NM + Homomorphic encryption! Is it possible?
Constructing LIRR (Leakage Ind.)
pk = (CRS, pk1, pk2, c1) sk = (c2, ¼).
Constructing LIRR
Re-randomization. (If E1, E2, ¦ are “homomorphic”)
Hardness of Good Keys. Hardness of Bad Keys. L-Leakage-Indistinguishability. (If E2 is
L-LoC-NM)
Outline of Construction
1. General strategy to handle continuous leakage. Reduce “continuous leakage” to “one-time leakage”.
2. Construction from (special) PKE/NIZK.
3. Instantiate components based on DDH/K-Linear.
Homomorphic NIZKs
Groth-Sahai NIZKs are homomorphic for “systems of equations” over prime-order groups (with a pairing).
Secure under K-linear assumption for any K¸ 1. 1-linear = DDH. Can only hold for “asymmetric
pairings” (two base groups are different). 2-linear is a standard assumption for symmetric
and asymmetric pairings. K-linear assumption gets weaker as K grows.
Homomorphic Encryption
For E1, use ElGamal (generalized to K-linear).
For E2, use “Cramer-Shoup-Lite” Encryption (generalized). Full Cramer-Shoup: CCA-2 secure. Not homomorphic.
Enc(m;r) = (gr , hr, (f0)r m, (f1)r (f2)r a ) where a = H(gr , hr)
Cramer-Shoup-Lite: Only CCA-1 secure. Is homomorphic.Enc(m;r) = (gr , hr, (f0)r m, (f1)r )
In general, CCA-1 security does not imply L-LoC-NM. But proof technique extends to show L-LoC-NM for L ¼
¼|c|. Can generalize scheme to get L-LoC-NM for L ¼ (1-²)|c|.
Enc(m;r) = (gr , hr, (f0)r m, (f1)r , (f2)r, (f3)r, …).
Summary of CLR-OWR
Construct L-CLR-OWR based on the K-linear assumption.
Relative leakage L/|sk| > 1/(K+1).
1/2 for DDH , 1/3 for 2-linear.
“Practical Efficiency”: Constant number of group elements, group
operations.
Applications
Build CLR signatures, ID schemes, Authenticated-Key-Agreement (AKA) generically from CLR-OWR, using prior techniques [ADW09, KV09, DHLW10]. Preserve leakage L and “relative leakage” L/|sk|. Can even preserve efficiency!
Extensions
Leakage-of-Randomness of Computation: So far, only assumed that sk leaks. For signatures (and ID/AKA) need to hide “local
randomness”. Can be done. Standard model for ID. RO model for Sigs/AKA.
Bounded-Retrieval Model (BRM): Allow “huge” amount of leakage, by increasing secret-
key size. Does not effect efficiency (pk size, signature size,
computation).
(More extensions in the paper.)
Follow-up Results of [BKKV10]
Show how to do CLR Public-Key Encryption, IBE. Under 2-linear assumption. Leads to alternate construction of signatures
(worse leakage).
Show all CLR OWR/Signature/Encryption schemes also allow small (logarithmic) leakage of the update process.
Thank you!
ePrint Report 2010/196