1 / 31

Storing Secrets on continually leaky devices

Daniel Wichs. Storing Secrets on continually leaky devices. Joint work with: Yevgeniy Dodis , Allison Lewko , Brent Waters. FOCS 2011. Cryptography (on paper). Cryptographic Algorithm. secret state. input. output. Cryptography (reality).

baker-diaz
Download Presentation

Storing Secrets on continually leaky devices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related