Storing Secrets on continually leaky devices

1. Daniel Wichs Storing Secrets on continually leaky devices Joint work with: YevgeniyDodis, Allison Lewko, Brent Waters FOCS 2011

2. Cryptography (on paper) Cryptographic Algorithm secret state input output

3. Cryptography (reality) • Side-Channel Attacks: Observable physical properties can reveal information about internal secrets. • Major obstacle to using crypto in the real world! secret state input output

4. Security against Side-Channel Attacks • 1: Better hardware implementations that reduce side-channel leakage. • 2: New cryptosystems that maintain security despite partial leakage.

5. Modeling 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. state Attacker

6. 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 periodicallyrefreshes its state. • Attacker learn L bits per time period. No restrictions on type of questions! state

7. Encryption in Continual Leakage Model Refresh FIXED sk pk EVOLVING …

8. Encryption in Continual Leakage Model Attacker can’t recover valid sk or learn anything useful about future ciphertexts. pk

9. 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

10. 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?

11. Storing Data on Leaky Devices • Impossible to keep data hidden in bounded/continual leakage model. • Need to relax the model! state = { 1st bit of }

12. Storing Data on Leaky Devices • Distributed Model: Two separate components operate and leak individuallyin continual leakage model. 2 1 state state Studied by [DP08, Pie09] for stream ciphers, [AGH11] for encryption. Strengthens “only comp leaks”[MR04].

13. Leakage Resilient Sharing • Bounded Leakage Model.Attacker can leak L bits from each share individually. • Information theoretic solution using two-source extractors [DDV10]. 2 1 share share

14. Continual Leakage Resilient Sharing • Each component can refresh its share individually. (no interaction, synchronization) • Security:Data stays hidden even if: • Attacker schedules refreshing. • LeaksL bits from each component in each time period. 2 1 share share

15. CLR Sharing: Randomized refresh • Refresh must be randomized. • Else can leak some future share in full. • Allow attacker to leak on randomness. 2 1 share share

16. CLR Sharing: Additional Motivation 2 Lots of work on constructing general leakage-resilient computation. [JV10,GR10,FRR+10] So faronly have incomplete results relying on leak-free hardware. Need storageas a first step. 1 share share

17. CLR Sharing: Information Theoretic? • 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 interactfor refreshing? 2 1 share share

18. 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. 2 1 share share

19. 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).

20. 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.

21. 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?

22. 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!

23. 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 =) =.

24. 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.

25. Proving Leakage Resilience Share1 Round 1: Round 1: share1 share2 Round 2: Round 2: Round 3: Round 3: Round 4: Round 4: … … • Attacker cannot distinguish if we share 0 or 1 (whether are orthogonal or random).

26. 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.

27. Computational Step Share1 Round 1: Round 1: share1 share2 Round 2: Round 2: Round 3: Round 3: Round 4: Round 4: … … Computationally indistinguishable as long as span() and span() are orthogonal.

28. Information Theoretic Step Share1 Round 1: Round 1: share1 share2 Round 2: Round 2: Round 3: Round 3: Round 4: Round 4: … … Choose and independently of each other. (still orthogonal to , orthogonal to )

29. Information Theoretic Step Share1 Round 1: Round 1: share1 share2 Round 2: Round 2: Round 3: Round 3: Round 4: 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.

30. 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?

31. QUESTIONS