The Cloud Computations on Encrypted Data and Privacy David Pointcheval CNRS - ENS - INRIA 11th International Conference on Provable Security Xi’an, China - October 23rd, 2017 David Pointcheval Introduction 2 / 26 Anything from Anywhere Security Requirements As from a local hard drive/server, one expects Storage guarantees Privacy guarantees One can store confidentiality of the data Documents to share anonymity of the users Pictures to edit obliviousness of the queries/processing Databases to query and access from everywhere How to proceed? David Pointcheval Introduction 3 / 26 David Pointcheval Introduction 4 / 26
Broadcast Encryption Confidentiality vs Sharing & Computations [Fiat-Naor - Crypto ‘94] Classical Encryption allows to protect data the provider stores them without knowing them nobody can access them either, except the owner/target receiver How to share the data? How to compute on the data? Sharing to a Target Set The sender chooses a target set but No Computations! Users get all-or-nothing about the data David Pointcheval Some Approaches 5 / 26 David Pointcheval Some Approaches 6 / 26 Fully Homomorphic Encryption Fully Homomorphic Encryption [Rivest-Adleman-Dertouzos - FOCS ’78] [Rivest-Adleman-Dertouzos - FOCS ’78] [Gentry - STOC ’09] [Gentry - STOC ’09] FHE allows any computations on encrypted data But the result is encrypted as the inputs! AND ENOT OR EOR EAND NOT Encrypted Encrypted Inputs Circuit Outputs Circuit NOT ENOT Inputs Outputs AND EOR OR EAND Computations But No Controlled Sharing! David Pointcheval Some Approaches 7 / 26 David Pointcheval Some Approaches 7 / 26
Functional Encryption Functional Encryption is Powerful [Boneh-Sahai-Waters - TCC ‘11] Functional Encryption allows access control: with f id ( x || y ) = ( if y = id, then x , else ⊥ ): identity-based encryption with f G ( x || y ) = ( if y ∈ G, then x , else ⊥ ): broadcast encryption Functional Encryption allows computations: any function f : in theory, with iO (Indistinguishable Obfuscation) The authority generates functional decryption keys DK f Result in clear according to functions f concrete functions: inner product for a Specific Function From C = Encrypt ( x ) , Decrypt ( DK f, C ) outputs f ( x ) for Specific Users This allows controlled sharing of data David Pointcheval Functional Encryption 8 / 26 David Pointcheval Functional Encryption 9 / 26 FE: Concrete Case FE: Inner Product [Abdalla-Bourse-De Caro-P. - PKC ’15 - EPrint 2015/017] English CS Math Student → − English CS Math Cells of derived tables are linear combinations Student a i English CS Math Student English CS Math Name Student Written Spoken Theory Practice Algebra Analysis → − Name Written Spoken Theory Practice Algebra Analysis of the grades from the main table: Name Written Spoken Theory Practice Algebra Analysis b Name Written Spoken Theory Practice Algebra Analysis Year 1 Year 1 Year 1 Year 1 a i · − → Year 2 � a i,j b j = − → Year 2 c i = b Year 2 Year 2 Year 3 Year 3 Year 3 Year 3 j − → : vector of the private grades, encrypted in the main table b Class English CS Math Class Total English CS Math Class Total → − : vector of the public coefficients for the cell c i , defines f i Class a i Year 1 Year 1 Written Spoken Theory Practice Algebra Analysis Year 2 Year 2 3Years Total With ElGamal encryption: Year 3 Year 3 For each student: transcript with all the grades computations modulo p Access to partial information for each student if grades, coefficients, and classes small enough: DLog computation And even global grades for the class David Pointcheval Functional Encryption 10 / 26 David Pointcheval Inner-Product Functional Encryption 11 / 26
FE: Limitations IP-FE: Concrete Security? Initial result: selective security [Abdalla-Bourse-De Caro-P. - PKC ’15 - EPrint 2015/017] But improved to adaptive security IP-FE : from c = E ( x ) and dk y , for n -vectors x and y , one gets x . y [Agrawal-Libert-Stehlé - Crypto ’16 - EPrint 2015/608] " Anyway: n different keys reveal x ! one key limits to one function on any vector for the indistinguishability between two sets of vectors, the adversary is not allowed to ask keys that trivially tell them appart a malicious player could ask many functional keys ⇒ if n vectors in the sets, the adversary cannot ask any key! " " too many keys might reveal the plaintexts … " a unique sender only can encrypt all the inputs ! Multi-Input Functional Encryption (MIFE) [Goldwasser-Gordon-Goyal-Jain-Katz-Liu-Sahai-Shi-Zhou - Eurocrypt ’14 - EPrint 2013/727 - EPrint 2013/774] David Pointcheval Inner-Product Functional Encryption 12 / 26 David Pointcheval Inner-Product Functional Encryption 13 / 26 IP-FE: Too Many Messages/Keys? IP-MIFE: Concrete Security? IP-FE with Helper: [Dupont-P. - AsiaCCS ’17] from c = E ( x ) and dk y , for n -vectors x and y , one must ask an helper the helper learns as few as possible about the input IP-MIFE : from c 1 = E ( x 1 ), … , c n = E ( x n ) and dk y , one gets x . y (which ciphertext, which function, which user, etc) if no ordering: one immediately gets n ! linear relations on x " limits the number of answers (according to a bound on the inputs) even with ordering, c 1 = E ( 1, x 1 ), … , c n = E ( n , x n ) learns nothing about the output " if public encryption: only constant-functional keys allowed! " if private encryption: mix-and-match attacks whereas there are additional interactions no much leakage of information to the helper ! more reasonable security model David Pointcheval Interactions 14 / 26 David Pointcheval Multi-User Functional Encryption 15 / 26
Multi-Client Functional Encryption Independent and Untrusted Clients [Chotard-Dufour Sans-Phan-P. - EPrint 2017/989] In addition to the ordering, there is a label (or a time period) Senders ( S i ) i provide sensitive inputs x i (e.g. financial data) Client C i generates c i = E ( i , ! , x i ) for a label ! in an encrypted way under secret encryption keys ek i ⇒ only one ciphertext for each index i and each label ! → c i = E ( ek i , ! , x i ) for a label ! (or every time period) [Goldwasser-Gordon-Goyal-Jain-Katz-Liu-Sahai-Shi-Zhou - Eurocrypt ’14 - EPrint 2013/727 - EPrint 2013/774] For some functions f , an aggregator proposes, as a service, Multi-User Inputs to communicate the aggregation f ( x ) for every label ! , thanks to a functional decryption key dk f Mix-and-match attacks avoided by private encryption The senders want to keep control on f More reasonable security model ! → dk f is generated by the senders " But still a unique authority for the functional key generation David Pointcheval Multi-User Functional Encryption 16 / 26 David Pointcheval Decentralized MCFE 17 / 26 Decentralized MCFE Decentralized MCFE f [Chotard-Dufour Sans-Phan-P. - EPrint 2017/989] [Chotard-Dufour Sans-Phan-P. - EPrint 2017/989] Setup () → secret key sk i and encryption key ek i for each sender S i and mpk, the master public key f Encrypt ( ek i , ! , x i ) → c i = E ( ek i , ! , x i ) for the label ! DKeyGen (( sk i ) i , f ) → dk f f Decrypt ( dk f , ! , C ) → f ( x ) if C = ( c i = E ( ek i , ! , x i )) i Encrypt / Decrypt are non-interactive algorithms Setup / DKeyGen are interactive protocols between the senders f DKeyGen should be a one-round protocol only David Pointcheval Functional Encryption 18 / 26 David Pointcheval Decentralized MCFE 19 / 26
Recommend
More recommend
