Public Key Cryptography in the Bounded Retrieval Model Based on joint works with Joël Alwen, Moni Naor, Gil Segev, Shabsi Walfish and Daniel Wichs Crypto.

Slides:



Advertisements
Similar presentations
PROOFS OF RETRIEVABILITY VIA HARDNESS AMPLIFICATION Yevgeniy Dodis, Salil Vadhan and Daniel Wichs.
Advertisements

REDUCTION-RESILIENT CRYPTOGRAPHY: PRIMITIVES THAT RESIST REDUCTIONS FROM ALL STANDARD ASSUMPTIONS Daniel Wichs (Charles River Crypto Day ‘12)
Digital Signatures Good properties of hand-written signatures: 1. Signature is authentic. 2. Signature is unforgeable. 3. Signature is not reusable (it.
Yevgeniy Dodis, Kristiyan Haralambiev, Adriana López-Alt, Daniel Wichs New York University Efficient Public-Key Cryptography in the Presence of Leakage.
Encryption Public-Key, Identity-Based, Attribute-Based.
Digital Signatures and Hash Functions. Digital Signatures.
Foundations of Cryptography Lecture 5 Lecturer: Moni Naor.
1 Introduction CSE 5351: Introduction to cryptography Reading assignment: Chapter 1 of Katz & Lindell.
NON-MALLEABLE EXTRACTORS AND SYMMETRIC KEY CRYPTOGRAPHY FROM WEAK SECRETS Yevgeniy Dodis and Daniel Wichs (NYU) STOC 2009.
RECENT PROGRESS IN LEAKAGE-RESILIENT CRYPTOGRAPHY Daniel Wichs (NYU) (China Theory Week 2010)
On the Composition of Public- Coin Zero-Knowledge Protocols Rafael Pass (Cornell) Wei-Lung Dustin Tseng (Cornell) Douglas Wiktröm (KTH) 1.
Public-Key Encryption in the Bounded-Retrieval Model Joël Alwen, Yevgeniy Dodis, Moni Naor, Gil Segev, Shabsi Walfish, Daniel Wichs Earlier Today: Yevgeniy.
15-1 Last time Internet Application Security and Privacy Public-key encryption Integrity.
Leakage-Resilient Signatures Sebastian Faust KU Leuven Joint work with Eike Kiltz CWI Krzysztof Pietrzak CWI Guy Rothblum Princeton TCC 2010, Zurich, Switzerland.
Session 5 Hash functions and digital signatures. Contents Hash functions – Definition – Requirements – Construction – Security – Applications 2/44.
CS426Fall 2010/Lecture 351 Computer Security CS 426 Lecture 35 Commitment & Zero Knowledge Proofs.
CMSC 414 Computer and Network Security Lecture 6 Jonathan Katz.
CNS2010handout 10 :: digital signatures1 computer and network security matt barrie.
Cryptography in The Presence of Continuous Side-Channel Attacks Ali Juma University of Toronto Yevgeniy Vahlis Columbia University.
Proactive Secure Mobile Digital Signatures Work in progress. Ivan Damgård and Gert Læssøe Mikkelsen University of Aarhus.
CMSC 414 Computer and Network Security Lecture 5 Jonathan Katz.
Asymmetric Cryptography part 1 & 2 Haya Shulman Many thanks to Amir Herzberg who donated some of the slides from
CMSC 414 Computer and Network Security Lecture 9 Jonathan Katz.
CMSC 414 Computer and Network Security Lecture 16 Jonathan Katz.
CMSC 414 Computer and Network Security Lecture 22 Jonathan Katz.
Introduction to Signcryption November 22, /11/2004 Signcryption Public Key (PK) Cryptography Discovering Public Key (PK) cryptography has made.
CMSC 414 Computer and Network Security Lecture 19 Jonathan Katz.
Strongly Secure Certificateless Encryption Alexander W. Dent Information Security Group
1 CPSC156: The Internet Co-Evolution of Technology and Society Lectures 19,20, and 21: April 5, 10, and 12, 2007 Cryptographic Primitives.
CMSC 414 Computer and Network Security Lecture 6 Jonathan Katz.
1 CIS 5371 Cryptography 9. Data Integrity Techniques.
On Everlasting Security in the Hybrid Bounded Storage Model Danny Harnik Moni Naor.
Leakage-Resilient Storage Francesco Davì Stefan Dziembowski Daniele Venturi SCN /09/2010 Sapienza University of Rome.
Foundations of Cryptography Lecture 8 Lecturer: Moni Naor.
CMSC 414 Computer and Network Security Lecture 13 Jonathan Katz.
8. Data Integrity Techniques
Bob can sign a message using a digital signature generation algorithm
CS555Topic 211 Cryptography CS 555 Topic 21: Digital Schemes (1)
Digital Signatures Good properties of hand-written signatures: 1. Signature is authentic. 2. Signature is unforgeable. 3. Signature is not reusable (it.
ON CONTINUAL LEAKAGE OF DISCRETE LOG REPRESENTATIONS Shweta Agrawal IIT, Delhi Joint work with Yevgeniy Dodis, Vinod Vaikuntanathan and Daniel Wichs Several.
Fall 2004/Lecture 201 Cryptography CS 555 Lecture 20-b Zero-Knowledge Proof.
Cryptography Lecture 9 Stefan Dziembowski
Basic Cryptography 1. What is cryptography? Cryptography is a mathematical method of protecting information –Cryptography is part of, but not equal to,
Foundations of Cryptography Lecture 6 Lecturer: Moni Naor.
Password Mistyping in Two-Factor Authenticated Key Exchange Vladimir KolesnikovCharles Rackoff Bell LabsU. Toronto ICALP 2008.
Public Key Encryption with keyword Search Author: Dan Boneh Rafail Ostroversity Giovanni Di Crescenzo Giuseppe Persiano Presenter: 陳昱圻.
On the Communication Complexity of SFE with Long Output Daniel Wichs (Northeastern) joint work with Pavel Hubáček.
Chapter 3 (B) – Key Management; Other Public Key Cryptosystems.
1 Message authentication codes, modes of operation, and indifferentiability Kan Yasuda (NTT, Japan) ASK 2011 Aug. 31, Singapore.
Game-based composition for key exchange Cristina Brzuska, Marc Fischlin (University of Darmstadt) Nigel Smart, Bogdan Warinschi, Steve Williams (University.
Prepared by Dr. Lamiaa Elshenawy
Protocol Analysis. CSCE Farkas 2 Cryptographic Protocols Two or more parties Communication over insecure network Cryptography used to achieve goal.
Based on work with: Sergey Gorbunov and Vinod Vaikuntanathan Homomorphic Commitments & Signatures Daniel Wichs Northeastern University.
Private key
1 Leonid Reyzin Boston University Adam Smith Weizmann  IPAM  Penn State Robust Fuzzy Extractors & Authenticated Key Agreement from Close Secrets Yevgeniy.
1/28 Chosen-Ciphertext Security from Identity- Based Encryption Jonathan Katz U. Maryland Ran Canetti, Shai Halevi IBM.
Jonathan Katz University of Maryland Andrew Lindell Aladdin Knowledge Systems and Bar-Ilan University 04/08/08 CRYP-108 Aggregate Message- Authentication.
Randomness Leakage in the KEM/DEM Framework Hitoshi Namiki (Ricoh) Keisuke Tanaka (Tokyo Inst. of Tech.) Kenji Yasunaga (Tokyo Inst. of Tech.  ISIT) ProvSec.
Does Privacy Require True Randomness? Yevgeniy Dodis New York University Joint work with Carl Bosley.
Cryptography Lecture 10 Arpita Patra © Arpita Patra.
Cryptography Resilient to Continual Memory Leakage Zvika Brakerski Weizmann Institute Yael Tauman Kalai Microsoft Jonathan Katz University of Maryland.
CMSC 414 Computer and Network Security Lecture 2 Jonathan Katz.
Cryptography Lecture 6 Arpita Patra. Quick Recall and Today’s Roadmap >> MAC for fixed-length messages >> Domain Extension for MAC >> Authenticated Encryption:
Cryptographic Hash Function. A hash function H accepts a variable-length block of data as input and produces a fixed-size hash value h = H(M). The principal.
Cryptography and Network Security Chapter 13
Intrusion Resilience via the Bounded-Storage Model Stefan Dziembowski Warsaw University and CNR Pisa.
Topic 14: Random Oracle Model, Hashing Applications
Digital Signature Schemes and the Random Oracle Model
Topic 11: Authenticated Encryption + CCA-Security
Presentation transcript:

Public Key Cryptography in the Bounded Retrieval Model Based on joint works with Joël Alwen, Moni Naor, Gil Segev, Shabsi Walfish and Daniel Wichs Crypto  Clouds Speaker: Yevgeniy Dodis (NYU)

Leakage Attacks  Standard Crypto Assumption: keys stored secretly.  Reality: information leaks  Timing attacks, Power consumption attacks, Freezing attacks, Hackers, Malware, Viruses…  Usual Crypto Response: not our problem.  Better Crypto Response: provably secure primitives that allow leakage.  Assume leakage arbitrary but incomplete.

Modeling Incomplete Leakage  Adversary can learn any efficiently computable function f : {0,1}*  {0,1} L of the secret key. L = Leakage Bound.  Relative leakage […, AGV09, DKL09, NS09, KV09]. Key size dependent on security parameter (e.g bits). Leakage L is dependent on key size (e.g. 50% of key size). Goal: Allow for large percentage of leakage. Problem: in reality, leakage may be large in absolute terms (e.g. L can be on scale of Kbs, Mbs or even Gbs) For example: hackers/malware/virus attacks. Many side-channel attacks.  More robust model: Bounded Retrieval Model

Modeling Incomplete Leakage  Adversary can learn any efficiently computable function f : {0,1}*  {0,1} L of the secret key. L = Leakage Bound. k = Security Parameter  Relative leakage […, AGV09, DKL09, NS09, KV09].  Bounded retrieval model (BRM) [Dzi06,CLW06,DP07,ADW09] Key size |SK| depends on security parameter k AND leakage bound L. (Note: must be more than L) Other efficiency parameters only depend on k. E.g., public key, communication, computation, read-locality. Goal: flexibly accommodate ANY leakage bound L ONLY by increasing |SK| and without impacting other parameters. OK for many applications since storage is extremely cheap.

Only Computation Leaks Information  Incomparable model of leakage [MR04, DP08, P09].  Each OP leaks a shrinking function of accessed data.  Positive: Allows for potentially unbounded overall amount of leakage L.  Doesn’t necessitate increasing secret-key size above L.  Negative:  Does not capture cold-boot attacks, malware, viruses.  Seems to require state and/or key evolution.  This talk: BRM

Crypto Primitives with Leakage  Inherent limitations to leakage-resilient non-interactive primitives.  Encryption Schemes: Leakage can only occur before and not after the adversary sees the ciphertext.  Existentially Unforgeable Signatures: Leakage must be smaller than size of a single signature. Opposite goal for standard signatures, incompatible with BRM.  Can have qualitatively stronger security w./interaction: (Encryption, Authentication, Authen. Key Agreement).  Leakage before and after, but not during, protocol execution.  Perfect forward secrecy: can learn secret keys entirely after the protocol execution.

Full Leakage Private Communication (Encryption) Partial LeakageNo Leakage Non-interactive: Timeline: Partial Leakage Interactive: Timeline: No Leakage Protocol Run (pk Alice, sk Alice ) Prior to CommunicationAfter Communication Prior to CommunicationAfter Communication pk Alice (pk Alice, sk Alice ) Enc(m; pk Alice ) pk Alice

Recent History  Relative Leakage.  Symmetric-Key Authenticated Encryption [DKL09]  Public-Key Encryption [AGV09, NS09, KV09]  Problems: 1) non-BRM, 2) no leakage after ciphertext.  Bounded Retrieval Model [Dzi06,CLW06].  Symmetric-Key Identification [Dzi06]  Symmetric-Key Authenticated Key Agreement [Dzi06,CDD + 07]  Secret Sharing [DP07]  Main Problem: Key distribution (i.e., symmetric-key).  Magnified in the BRM model

Our Results  Efficient (and only) constructions of many public-key primitives in the BRM:  [ADW09]: ID and “Signature” schemes, Interactive Encryption, Authentication and Authenticated Key Agreement (AKA). Based on Okamoto ID/Sigs. |SK| = (1+  ) · L Forward security.  [ADNSWW09]: Encryption schemes, IBE. Based on Gentry IBE. |SK| ≈ 2 · L No forward security  (necessary).

 Leakage bound L. Security parameter k.  Secret key size: O(L), in some cases L(1+   )  Public key size: constant # of group elements  Communication: ID/Sig/AKA: constant # of group elements Enc/IBE: O(k) group elements  Data Accessed: O(k) group elements  Computation: O(k) exponentiations  Relative Leakage: all O(k) become O(1).  Solves open problem of [AGV09] for ID/Sigs Efficiency of Our Results Same as standard constructions!!!

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

Identification Schemes (pk Bob, sk Bob ) pk Bob Prover BobVerifier Alice accept Learning Stage (pk Bob, sk Bob ) pk Bob Impersonation Stage reject!

Leakage-Resilient Identification Learning Stage (pk Bob, sk Bob ) pk Bob Impersonation Stage reject!  Bob’s key can leak !!!  Pre-impersonation leakage: all in learning stage  Anytime leakage: can happen anywhere sk Bob Note: allow adaptive leakage!

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 PK = (G, g 1, g 2, z = g 1 x 1 · g 2 x 2 ), SK = (x 1, x 2 )  Bob → Alice: R = g 1 r 1 · g 2 r 2 for random r 1, r 2  Alice → Bob : random c  Bob → Alice: s 1 = r 1 − c · x 1 and s 2 = r 2 − c · x 2  Alice: accept iff R = g 1 s 1 · g 2 s 2 · z c  Key Properties:  Many possible SK’s (x 1, x 2 ) for fixed PK z  Security proof extracts a valid secret key (x 1 ’, x 2 ’)  WI: proof perfectly hides which (x 1, x 2 ) is used  DL  given one secret key, hard to find another Okamoto’s ID Scheme

 Run Eve with known secret key SK = (x 1, x 2 )  Simulate leakage oracle honestly with (x 1, x 2 )  WI  even computat. unbounded Eve does not know which SK was used in learning stage  Eve’s leakage L < |SK|/2  SK still has min-entropy  Rewind Eve (with a new c’) during impersonation stage to extract a valid SK’ = (x 1 ’, x 2 ’)  Doubles leakage for “anytime leakage” case  If SK’  SK, solve discrete log  Pre-imper. leakage |SK|/2, anytime leakage |SK|/4 Relative Leakage-Resilience

 By using ~ 1 /  generators, can tolerate L learn + 2L imper = (1 −  ) · |SK| :  Pre-impersonation leakage L = (1 −  ) · |SK|  Anytime leakage L = (½ −  ) · |SK|  Efficiency proportional to 1 /   Already solves open problem of [AGV09]  Independently discovered by [Katz09]  Can we extend to BRM? Relative Leakage-Resilience

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 Take any relative-leakage resilient ID scheme X  Choose N independent copies (pk i, sk i ) of X.  N proportional to the leakage parameter L  Set SK = (sk 1,…,sk N ). To run a new ID protocol:  Verifier chooses k random indices (i 1,…,i k )  Run X on the selected k instances  Accept iff all accept  Good: communication/computation complexity ~ k  Is this a proper (secure/efficient) BRM scheme?? Direct Products: Naive Attempt

 Public key is long: PK = (pk 1,…,pk N ).  BRM only allows SK to be long!  Solution: use signatures to authenticate pk i.  Generate “master” signing key (SigKey,VerKey)  Set PK = VerKey (note: PK is short)  Compute certificate s i = Sig((i, pk i ), SigKey)  Store SK = (sk 1,…,sk N ) and Help =(s 1,…,s N ).  Erase SigKey (important!)  Include certificates (s i 1,…,s i k ) with proof Direct Products: Problem 1 Invisible Key Updates! store SigKey “offline” periodically refresh SK = (sk 1,…,sk N ) public key VerKey does not change ! secure as long as < L leakage between refreshes approaches “continuous leakage”, but without assuming “only computation leaks information”

 Add an extra round to send indices (i 1,…,i k )  Destroys “  -protocol structure” of Okamoto  Bad for getting signatures via Fiat-Shamir  Solution: many  -protocols have first flow independent from public key  E.g., R = g 1 r 1 · g 2 r 2 independent from z = g 1 x 1 · g 2 x 2  Have verifier send (i 1,…,i k ) in the second flow, together with challenge c Direct Products: Problem 2

 Seems very hard to prove security generically  Hope. Start with ℓ -leakage resilient scheme X  get L-resilient scheme X’, where L ~ N ℓ  Natural reduction: generate (N-1) keys honestly and set SK = {sk, honest keys}  Simulate leakage f(SK) by hardwiring known keys  But the output length is still L » ℓ. Illegal query!  In fact, can come up with (artificial) counter-examples Direct Products: Problem 3

 Seems very hard to prove security generically  But works for the special case of Okamoto!  Entropy-Preservation Lemma. Assume:  Enc:  N   M is “good” approxim. list-decodable code  X = (x 1,…,x N )   N has “enough” min-entropy Then Y = Enc(X)[ j ] has “enough” min-entropy  Corollary: Apply to direct product code  Enc(x 1,…,x N )[i 1,…,i k ] = (x i 1,…, x i k )  [IJK06]: direct product code is approxim. list-decodable  Thus, “condense” entropy from N  log |  | to k  log |  | Direct Products: Our Solution

 Seems very hard to prove security generically  But works for the special case of Okamoto!  Leakage L  SK = (sk 1,…,sk N ) has entropy  Entropy Lemma  (sk i 1,…,sk i k ) has entropy  Basic Okamoto recovers secret key sk’  k- direct product recovers all k keys ( sk ’ i 1,…, sk ’ i k )  (sk i 1,…,sk i k ) has entropy  likely  j s.t. sk ’ i j  sk ’ i j  Two different secret keys  break DL Direct Products: Our Solution

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 Communication O(k) more than basic Okamoto  Can we “aggregate” k protocols into 1?  Yes, can use entropy lemma again, by “concatenating” the Direct Product and the Reed-Solomon codes  The “aggregate” secret key sk * still has min-entropy  But still need to send k public keys (pk i 1,…,pk i k )   Can aggregate to single pk *, but how to authenticate?  Related to aggregate signatures, but harder…  Solution: use variant of BLS signatures by [SW08]  s[i] = (RO(i)  pk i ) X Compressing Communication

 Pre-impersonation leakage L.  Secret key length |SK| = L · (1+  )  Everything else independent of L.  In particular,  Standard Model: O(k) communication.  RO Model: O(1) communication. Parameters of BRM ID Schemes

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 Standard security: Existential Unforgeability  Requires that leakage L < signature size  Forces large signature, incompatible with BRM  Might be too strong for many applications  More suitable notion: Entropic Unforgeability  Cannot forge signature if message has entropy k  Makes sense in the BRM model ! (call BRM-sig)  Enough for many applications  E.g., interactive encryption, authentication, AKA Leakage-Resilient Signatures

 Apply Fiat-Shamir to any leakage-resilient, 3- round (public-coin) ID scheme:  Resulting signature scheme is:  Leakage-resilient (in RO model), for the same L  Anytime leakage  Existentially Unforgeable  Pre-imperson. leakage  Entropically Unforgeable  Scheme 1  Existent. Unforg. Sig. with L  |SK|/2  Scheme 1  Entropically Unforg. Sig. with L  |SK|  Scheme 3  BRM Signature with L  |SK| From ID to Signatures Same sig size as standard sigs!!!Solves open problem of [AGV09]

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 Example: Interactive Encryption  Sender → Receiver: random r  Receiver → Sender: BRM-Sig(r, enc. key pk)  Sender → Receiver: Enc(m, pk)  Receiver: Decrypt m, erase sk.  Similar trick for interactive authentication, AKA  Punchline: Interactive BRM authentication, encryption, authenticated key agreement with constant communication and forward secrecy Signatures  Interactive Primitives Message has entropy! Forward secrecy!

What does it mean? For example…  An efficient interactive encryption protocol with short public key and 10 GB secret key.  All other efficiency parameters “short” as well  A virus must download at least 5 GB of information to break privacy of messages sent  All messages transmitted prior to infection remain secure, even if virus learns the entire 10 GB key.  Major advantage over encryption [AGV09,NS09,KV09,ADNSWW09].  Almost as efficient as standard protocols.

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap Come to Daniel’s talk [ADNSWW09]. First (non-interactive) BRM encryption & IBE Tools: Gentry IBE (standard model). Entropy-preservation lemma again! Id-based Hash Proof Systems (generalizing [NS09])

 Efficient (and only) constructions of many public-key primitives in the BRM  Encryption, Authentication, IBE, AKA, Sigs  BRM more flexible than relative leakage  Only |SK| depends on L, and storage is cheap  Future Directions:  Leakage of intermediate results “during protocol”  Continuous leakage (ala “invisible updates”)  More BRM tools: improved “entropy-preservation” lemma, leakage amplification, … Conclusions + Open Problems

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap

 Identification Schemes  Scheme 1: Relative Leakage  Scheme 2: “Direct product” extension to BRM  Scheme 3: Compressing Communication  Entropic Signatures  Interactive Encryption, Authentication and AKA  Towards Non-Interactive Primitives:  IBE with Relative Leakage  Public-Key Encryption (and IBE) in the BRM Roadmap