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