Storing Secrets on continually leaky devices
-
Upload
baker-diaz -
Category
Documents
-
view
16 -
download
0
description
Transcript of Storing Secrets on continually leaky devices
STORING SECRETS ON CONTINUALLY LEAKY DEVICES
FOCS 2011
Daniel Wichs
Joint work with: Yevgeniy Dodis, Allison Lewko, Brent Waters
input output
secret
state
Cryptographic Algorithm
Cryptography (on paper)
Side-Channel Attacks: Observable physical properties can reveal information about internal secrets.
Major obstacle to using crypto in the real world!
input output
secret
state
Cryptography (reality)
Security against Side-Channel Attacks
1: Better hardware implementations that reduce side-channel leakage.
2: New cryptosystems that maintain security despite partial leakage.
Attacker chooses what to learn! Pick “leakage-questions” . Learns
How to model partial leakage? Bound number of leaked bits. Restrict type of allowed questions.
Many such models.
Modeling Leakage
𝑓
𝑓 (𝑠𝑡𝑎𝑡𝑒)
state
Attacker
Modeling Leakage
Bounded Leakage Model [Akavia-Goldwasser-Vaikuntanathan09]:
Bounds amount of leakage. L bits over lifetime. L =
“leakage bound”.
Continual Leakage Model [Brakeski-Kalai-Katz-Vaikuntanathan10] [Dodis-Haralembiev-Lopez-W10]:
Bounds rate of leakage. Device periodically refreshes its
state. Attacker learn L bits per time
period.
𝑓
𝑓 (𝑠𝑡𝑎𝑡𝑒)
state
No restrictions ontype of questions!
Encryption in Continual Leakage Model
sk
pk
…
𝑓
𝑓 (𝑠𝑘)
FIXED
EVOLVING
Refresh
Encryption in Continual Leakage Model
pk
Attacker can’t recover valid sk orlearn anything useful about future ciphertexts.
Leakage-Resilient Cryptosystems
Signatures/Encryption(IBE, ID, AKA)
[AGV09, ADW09, NS09,KV09, DHLW10, ADNSWW10, BG10, CRW10, HL11, BSW11]
[DHLW10, BKKV10, LRW11, BSW11, LLW11, DLWW11]
Bounded
Continual
Leakage-Resilient Cryptosystems
Prior Works: After leaking on secret keys, some capability of a cryptosystem remain “hidden”.
Question:Can we store some data privately on a leaky device?
Storing Data on Leaky Devices
𝑓
= { 1st bit of }
state
Impossible to keep data hidden in bounded/continual leakage model.
Need to relax the model!
𝑓 (𝑠𝑡𝑎𝑡𝑒)
state
Storing Data on Leaky Devices
Distributed Model: Two separate components operate and leak individually in continual leakage model.
state 2
1
Studied by [DP08, Pie09] for stream ciphers, [AGH11] for encryption.
Strengthens “only comp leaks” [MR04].
𝑓 (𝑠𝑡𝑎𝑡𝑒1) 𝑔 (𝑠𝑡𝑎𝑡𝑒2)𝑓 𝑔
Leakage Resilient Sharing
Bounded Leakage Model. Attacker can leak L bits from each share individually. Information theoretic solution
using two-source extractors [DDV10].
share
share 2
1
𝑓 ( h𝑠 𝑎𝑟𝑒1) 𝑔 ( h𝑠 𝑎𝑟𝑒2)𝑓 𝑔
Continual Leakage Resilient Sharing
Each component can refresh its share individually. (no interaction, synchronization)
Security: Data stays hidden even if: Attacker schedules refreshing. Leaks L bits from each component
in each time period.
share
share 2
1
𝑓 ( h𝑠 𝑎𝑟𝑒1) 𝑔 ( h𝑠 𝑎𝑟𝑒2)𝑓 𝑔
CLR Sharing: Randomized refresh
Refresh must be randomized. Else can leak some future share
in full. Allow attacker to leak on
randomness.
share
share 2
1
𝑓 ( h𝑠 𝑎𝑟𝑒1) 𝑔 ( h𝑠 𝑎𝑟𝑒2)𝑓 𝑔
CLR Sharing: Additional Motivation
share
share 2
1
𝑓 ( h𝑠 𝑎𝑟𝑒1) 𝑔 ( h𝑠 𝑎𝑟𝑒2)𝑓 𝑔
Lots of work on constructing general leakage-resilient computation. [JV10,GR10,FRR+10]
So far only have incomplete results relying on leak-free hardware.
Need storage as a first step.
Can we achieve CLR Sharing information-theoretically?
No. (Even 1 bit/period, leak-free refresh). Leakage function
enumerates the space of all shares reachable by continual refreshing.
Show how to consistently leak on a “unique representative”.
Open Q: Is IT sec possible if components interact for refreshing?
CLR Sharing: Information Theoretic?
share
share 2
1
𝑓 ( h𝑠 𝑎𝑟𝑒1) 𝑔 ( h𝑠 𝑎𝑟𝑒2)𝑓 𝑔
CLR Sharing via Encryption
CLR Sharing via encryption:
Have encryption schemes in the continual-leakage model! [BKKV10, LRW11, LLW11]
Not enough: Only refresh (not
ciphertext) Only allow continual leakage
on before seeing ciphertext.
share
share 2
1
𝑓 ( h𝑠 𝑎𝑟𝑒1) 𝑔 ( h𝑠 𝑎𝑟𝑒2)𝑓 𝑔
CLR Sharing: Results
Construct new leakage-resilient public-key encryption that can be used to instantiate CLR Sharing. Can update ciphertexts. Secure after continually leaking on keys and
ciphertexts. Security under DLIN assumption in prime order
bilinear groups.
Get a new simplified construction of CLR PKE that allows “leakage on update randomness”. [LLW11] Simpler assumption, more modular proof. More efficient (encrypt multi-bit messages).
CLR Sharing Construction: Toy Scheme
For this talk:
The “refreshing” process is leak-free. Only leak on the shares in between refreshing.
Scheme does not go through public-key encryption.
CLR Sharing Construction: Toy Scheme
Start with “bounded-leakage” sharing [DDV10]. Shares are two vectors:
Share1 := Share2 :=
To share the bit 0, choose random orthogonal vectors. To share the bit 1, choose truly random.
Security follows information-theoretically from inner-product being a good two-source extractor.
How to refresh shares to allow continual leakage?
CLR Sharing Construction: Toy Scheme
Idea: refresh “on the same line”. Refresh(share = ) = .
Correctness: refresh preserves orhogonality.
Not secure! Given arbitrary vectors , can easily find a unique “canonical vector” on the same line as (e.g. one whose first non-zero entry is a 1). Leak the canonical vector bit by bit.
Indeed, recall that we need computational assumptions!
CLR Sharing Construction: Toy Scheme
Idea: do everything “in the exponent” of a bilinear group (similar to [BKKV10]): Share1 := Share2 :=
Use bilinear map to test if exponent vectors are orthogonal and recover shared bit.
Refresh in the exponent: Refresh(share = ) =.
CLR Sharing Construction: Toy Scheme
Idea: do everything “in the exponent” of a bilinear group (similar to [BKKV10]): Share1 := Share2 :=
Security? It is computationally difficult to test if two
vectors in exponent are on same line. Can’t efficiently find a “canonical representative”.
Proof under DDH assumption in (asymmetric) bilinear groups.
Proving Leakage Resilience
share1
share2
𝑓 (𝑠𝑘) 𝑔 (𝑐𝑡)𝑓 𝑔
Round 1:
Round 2:
Round 3:
Round 4:
Share2
… …
Share1
𝑔𝑟1 ∙ �⃑�
𝑔𝑟3 ∙ �⃑�
𝑔𝑟 4 ∙𝑣
h𝑠1 ∙𝑤
h𝑠3 ∙ �⃑�
h𝑠4 ∙ �⃑�
Attacker cannot distinguish if we share 0 or 1 (whether are orthogonal or random).
Round 1:
Round 2:
Round 3:
Round 4:
Proof Strategy for Toy Scheme
Proof is a careful hybrid argument consisting of two types of steps:
“Computational steps”. Use computational assumption, can even assume full leakage. Must maintain orhtogonality of all share-pairs.
“Leakage Steps”. Information theoretic. Use the fact that leakage is bounded (per period). May change orthogonality if bounded
leakage.
Computational Step
share1
share2
𝑓 (𝑠𝑘) 𝑔 (𝑐𝑡)𝑓 𝑔
Round 1:
Round 2:
Round 3:
Round 4:
Share2
… …
Share1
𝑔𝑟1 ∙ �⃑�+ �⃑�
𝑔𝑟3 ∙ �⃑�
𝑔𝑟 4 ∙𝑣
h𝑠1 ∙𝑤+𝑦
h𝑠3 ∙ �⃑�
h𝑠4 ∙ �⃑�
Round 1:
Round 2:
Round 3:
Round 4:
Computationally indistinguishable as long as span() and span() are orthogonal.
Information Theoretic Step
share1
share2
𝑓 (𝑠𝑘) 𝑔 (𝑐𝑡)𝑓 𝑔
Round 1:
Round 2:
Round 3:
Round 4:
Share2
… …
Share1
𝑔𝑟1 ∙ �⃑�+ �⃑�
𝑔𝑟3 ∙ �⃑�
𝑔𝑟 4 ∙𝑣
h𝑠1 ∙𝑤+𝑦
h𝑠3 ∙ �⃑�
h𝑠4 ∙ �⃑�
Round 1:
Round 2:
Round 3:
Round 4:
Choose and independently of each other.(still orthogonal to , orthogonal to )
Information Theoretic Step
share1
share2
𝑓 (𝑠𝑘) 𝑔 (𝑐𝑡)𝑓 𝑔
Round 1:
Round 2:
Round 3:
Round 4:
Share2
… …
Share1
𝑔𝑟1 ∙ �⃑�+ �⃑�
𝑔𝑟3 ∙ �⃑�
𝑔𝑟 4 ∙𝑣
h𝑠1 ∙𝑤+𝑦
h𝑠3 ∙ �⃑�
h𝑠4 ∙ �⃑�
Round 1:
Round 2:
Round 3:
Round 4:
Notice: In round 1, the pair (share1, share2 ) is a sharing the bit 1.
Can do a careful hybrid argument to modify all rounds.
Conclusions
Achieve Continual Leakage Resilient Sharing. Can be used to store data secretly on 2 components leaking individually.
Extension to sharing over general access structures. Some components can be compromised completely while others continually leak.
Many questions: IT security with interactive refreshing? General leakage-resilient computation? Other assumptions?
QUESTIONS