Download Functional Encryption: Definitions and Challenges and more Lecture notes Cryptography and System Security in PDF only on Docsity!
Functional Encryption: Definitions and Challenges
Dan Boneh?, Amit Sahai, and Brent Waters ?? (^1) Stanford University (^2) University of California at Los Angeles (^3) University of Texas at Austin
Abstract. We initiate the formal study of functional encryption by giving precise definitions of the concept and its security. Roughly speaking, functional encryp- tion supports restricted secret keys that enable a key holder to learn a specific function of encrypted data, but learn nothing else about the data. For example, given an encrypted program the secret key may enable the key holder to learn the output of the program on a specific input without learning anything else about the program. We show that defining security for functional encryption is non-trivial. First, we show that a natural game-based definition is inadequate for some functionalities. We then present a natural simulation-based definition and show that it (provably) cannot be satisfied in the standard model, but can be satisfied in the random oracle model. We show how to map many existing concepts to our formalization of functional encryption and conclude with several interesting open problems in this young area.
1 Introduction
Encryption is a method for a user to securely share data over an insecure network or storage site. Before the advent of public key cryptography, a widely held view was that for two users to communicate data confidentially they would need to a priori es- tablish a mutually held secret key k. While this might be acceptable for some small or tightly knit organizations, such a solution was clearly infeasible for larger networks such as today’s Internet consisting of billions of users. Over thirty years ago, Diffie and Hellman [DH76a,DH76b] put forth a radically new idea in the concept of public key cryptography, where two parties can securely communicate with each other without having an a prior mutual secret — radically challenging the conventional wisdom of the time. Today public key encryption is an invaluable tool and its use is ubiquitous in build- ing tools from secure web communication (e.g., SSH, SSL), to disk encryption, and secure software patch distribution. However, there is an ingrained view that: (1) En- cryption is a method to send a message or data to a single entity holding a secret key, ? (^) Supported by NSF, MURI, and the Packard foundation. ?? (^) Supported by NSF CNS-0716199, CNS-0915361, and CNS-0952692, Air Force Office of Sci-
entific Research (AFO SR) under the MURI award for “Collaborative policies and assured information sharing” (Project PRESIDIO), Department of Homeland Security Grant 2006- CS-001-000001-02 (subaward 641), and the Alfred P. Sloan Foundation.
and (2) Access to the encrypted data is all or nothing – one can either decrypt and read the entire plaintext or one learns nothing at all about the plaintext other than its length. For many emerging applications such as “cloud” services this notion of public-key encryption is insufficient. For example, there is often a need to specify a decryption policy in the ciphertext and only individuals who satisfy the policy can decrypt. More generally, we may want to only give access to a function of the plaintext, depending on the decryptor’s authorization. As a concrete example, consider a cloud service stor- ing encrypted images. Law enforcement may require the cloud to search for images containing a particular face. Thus, the cloud needs a restricted secret key that decrypts images that contain the target face, but reveals nothing about other images. More gen- erally, the secret key may only reveal a function of the plaintext image, for example an image that is blurred everywhere except for the target face. Traditional public-key cryptography cannot help with such tasks. We believe that it is time to adopt a new broad vision of encryption systems. To this end, we explore the concept of functional encryption. In a functional encryption system, a decryption key allows a user to learn a function of the encrypted data. Briefly, in a functional encryption system for functionality F (·, ·) (modeled as a Turing Ma- chine) an authority holding a master secret key can generate a key skk that enables the computation of the function F (k, ·) on encrypted data. More precisely, using skk the decryptor can compute F (k, x) from an encryption of x. Intuitively, the security of the system guarantees that one cannot learn anything more about x, but as we shall see, capturing this rigorously is quite challenging. We can now see the power of functional encryption. Let us consider what can be achieved if we could realize functional encryption for any polynomial-time Turing Ma- chine F (·, ·). In applications of access control, one could let x = (ind, m) encode a message m as well as an arbitrarily complex access control program ind that will act over the description of a user’s credentials. The functionality F would interpret the program ind over k and output the message m if and only if ind accepts on input k. Moreover, the program ind would be hidden and thus one would not necessarily know why decryption was successful or what other keys would satisfy ind. We give many more examples in Section 3.
Our Contributions. Recently, there have been multiple systems that suggest moving beyond the traditional boundaries of encryption. Some examples include Identity-Based Encryption [Sha84,BF03,Coc01], searchable encryption [BCOP04] and Attribute-Based Encryption [SW05]. These and other related works such as [BW07,KSW08] propose specific new systems for problems ranging from expressive access control to searching on encrypted data. In the last few years, the term “functional encryption^4 ” was adopted to describe this new area [LOS+10,OT10,AL10]. While these results contain special cases of functional encryption, the general con- cept has never been formally defined or studied. In this paper we put forth a formal treatment of the subject and discuss many of the remaining challenges. We begin with
(^4) We note that both the term “functional encryption” and its underlying concept were introduced by the authors of this paper. This term was first publicly used to describe the line of work start- ing with [SW05] in a talk “Functional Encryption: Beyond Public Key Cryptography” [Wat08] in 2008, given by one of the authors of this paper.
(pp, mk) ← setup(1λ) (generate a public and master secret key pair) sk ← keygen(mk, k) (generate secret key for k) c ← enc(pp, x) (encrypt message x) y ← dec(sk, c) (use sk to compute F (k, x) from c)
then we require that y = F (k, x) with probability 1.
We define security of a functional encryption scheme in Section 4. For now, we briefly show that standard public-key encryption is a simple example of functional en- cryption. Let K := { 1 , } and consider the following functionality F defined over (K, X) for some plaintext space X:
F (k, x) :=
x if k = 1 len(x) if k =
A secret key for k = 1 fully decrypts valid ciphertexts, while the empty key k = simply returns the bit length of the plaintext. Hence, this functionality syntactically defines standard public-key encryption.
The empty key : The special key in K captures all the information about the plaintext that intentionally leaks from the ciphertext, such as the length of the encrypted plaintext. The secret key for is empty and also denoted by . Thus, anyone can run dec(, c) on a ciphertext c R ← enc(pp, x) and obtain all the information about x that intentionally leaks from c.
Further parametrization. In some cases the key space K and plaintext space X are further parametrized by quantities generated by the setup algorithm. For example, setup may output an RSA modulus N in which case the sets K and X and the functionality F are defined as tuples over ZN. More generally, we allow setup to output a third parameter π and we denote the key and plaintext space by Kπ and Xπ. The functionality F is the defined as
Fπ : Kπ × Xπ → { 0 , 1 }∗^.
When π is clear from context, we avoid writing it as an explicit subscript.
2.1 Sub-classes of functional encryption
So far we defined the most general syntax for a functional encryption scheme. For the applications we have in mind it is convenient to define two sub-classes of functional encryption where the plaintext space X has additional structure.
Predicate encryption [BW07,KSW08]. In many applications a plaintext x ∈ X is itself a pair (ind, m) ∈ I × M where ind is called an index and m is called the payload message. For example, in an email system the index might be the sender’s name while the payload is the email contents.
In this context, an FE scheme is defined in terms of a polynomial-time predicate P : K × I → { 0 , 1 } where K is the key space. More precisely, the FE functionality over ( K ∪ {}, (I × M ) ) is defined as
F
k ∈ K, (ind, m) ∈ X
m if P (k, ind) = 1, and ⊥ if P (k, ind) = 0
Consequently, let c be an encryption of (ind, m) and let skk be a secret key for k ∈ K. Then dec(skk, c) reveals the payload in c when P (k, ind) = 1 and reveals nothing new about m otherwise.
Predicate encryption with public index. A sub-class of predicate encryption makes the plaintext index easily readable from the ciphertext. In particular, in this type of FE the empty key explicitly reveals the index ind, namely
F
, (ind, m)
= (ind, len(m) )
Hence, dec(, c) gives anyone the index component of the plaintext as well as the bit length of m.
3 Capturing Cryptosystems in the Context of Functional
Encryption
Many recent encryption concepts and constructions can be viewed as special cases of Functional Encryption. In this section we give a few examples to show how functional encryption captures these encryption concepts. Security of these schemes is captured by the general security definitions of functional encryption in the next section.
3.1 Predicate encryption systems with public index
The first class of systems that we consider are Predicate encryption schemes with public index.^5 We begin our study with the simplest interesting case of Identity-Based Encryp- tion and then advance to more expressive methods of access formulas. We will describe these systems using the notation for predicate encryption defined in Subsection 2.1. 6
Identity-Based Encryption. In Identity-Based Encryption (IBE) [Sha84] ciphertexts and private keys are associated with strings (a.k.a identities) and a key can decrypt a ciphertext if the two strings are equal. IBE represents the first functionality that is not directly realizable from public key encryption [BPR+08]. IBE is formally described as a Predicate Encryption scheme where:
- The key space K is K := { 0 , 1 }∗^ ∪ {}. (^5) This class has also been informally referred to as “payload hiding” [BW07,KSW08] in the literature. (^6) Recall that for all predicate encryption schemes with public index we have that F
( , (ind, m)
) = (ind, len(m) ).
key are essentially reversed. A Ciphertext-Policy ABE system over n variables can be described as predicate encryption scheme (with public index) for the predicate Pn : K × I → { 0 , 1 } where:
- The key space K := { 0 , 1 }n^ is the set of all n bit strings representing n boolean variables z = (z 1 ,... , zn) ∈ { 0 , 1 }n.
- The plaintext is a pair (ind = φ, m) where the index space I is the set of all poly-sized boolean formulas φ over n variables.
- The predicate Pn on K × I is defined as
Pn
z ∈ K r {}, ind = φ ∈ I
1 if φ(z) = 1, and 0 otherwise
CP-ABE systems are constructed in [BSW07,GJPS08,Wat11]. Most constructions of ABE (both Ciphertext-Policy and Key-Policy) were proven secure in a weaker selective model of security. Recently Lewko et. al. [LOS+10] showed how to give fully secure realizations meeting our security definition.
3.2 Predicate Encryption Systems
While the previous systems described allow for expressive forms of access control, they are limited in two ways. First, the policy ind is given in the clear as part of the empty functionality — often this in itself can be considered sensitive. Second, it does not allow for computation on the encrypted data, which might include such applications as search. Here we describe current Predicate Encryption systems that do not leak the index ind.
Anonymous Identity-Based Encryption. The problem of Anonymous Identity-Based Encryption was first proposed by Boneh et. al. [BCOP04] and later formalized by Ab- dalla et. al. [ABC+08]. Other constructions include [BW06,Gen06,CHKP10,ABB10]. The functionality of Anonymous IBE is similar to IBE except that the string repre- senting the ciphertext identity is hidden and one can only determine it if they have the corresponding private key. Therefore, we can describe Anonymous IBE in the exact same manner as above, except we have that F
, (ind, m)
= len(m). The empty functionality only gives the message length, but ind stays hidden.
Hidden Vector Encryption. Boneh and Waters [BW07] proposed what they called a hidden vector encryption system. In such a system a ciphertext contains a vector of n elements in { 0 , 1 }∗^ and a private key contains of a vector of n elements in {∗} ∪ { 0 , 1 }∗ where we refer to ∗ as a wildcard character. More precisely,
- The key space K is all (v 1 ,... vn) where each vi ∈ {∗} ∪ { 0 , 1 }∗.
- The plaintext is a pair (ind = (w 1 ,... , wn), m) where each wi ∈ { 0 , 1 }∗. The index space in I := ({ 0 , 1 }∗)n.
- The predicate Pn on K × I is defined as
Pn
(v 1 ,... , vn) ∈ K r {}, ind = (w 1 ,... , wn)
1 if vi = wi whenever vi 6 = ∗, and 0 otherwise
Applications of the predicate include conjunctive and range searches. Independently, Shi et. al. [SBC+07] proposed a related system in a weaker security model. Again we note that F
, (ind, m)
= len(m) so that ciphertexts do not reveal ind.
Inner Product Predicate. The previous system was limited to conjunctive searches. Katz, Sahai and Waters [KSW08] proposed a system for testing if a dot product oper- ation over the ring ZN is equal to 0, where N is the product of three random primes chosen by the setup algorithm. This enabled more complex evaluations on disjunctions, polynomials, and CNF/DNF formulae. Subsequently, Okamoto and Takashima [OT09] and Lewko et. al. [LOS+10] gave constructions over the field Fp. We describe this predicate for vectors of length n.
- The setup algorithm defines a randomly chosen prime p of length κ, where κ is the security parameter.
- The key space K is all v = (v 1 ,... vn) where each vi ∈ Fp.
- The plaintext is a pair (ind = (w 1 ,... , wn), m) where each wi ∈ Fp. The index space is I := (Fp)n.
- The predicate Pn,p on K × I is defined as
Pn,p
(v 1 ,... , vn) ∈ K r {}, ind = (w 1 ,... , wn)
1 if
i=1,...,n vi^ ·^ wi^ = 0 0 otherwise
3.3 Other systems and combinations
Different researchers have realized different combinations of the above core systems. Examples of these include combinations of: Attribute-Based Encryption and Broadcast Encryption [AI09], Identity-Based Broadcast Encryption [Del07,DPP07,SF07,GW09], broadcast HIBE [BH08], and Inner-Product Encryption and ABE [OT10]. All are cap- tured as special cases of functional encryption.
4 Security definitions
Given the syntactic definitions of Functional Encryption (FE) from Section 2 we now turn to defining security of an FE scheme. In this section we give game based defini- tions. In Section 5 we discuss simulation-based definitions. Let E be an FE scheme for functionality F defined over (K, X). Our goal is to define security against an adaptive adversary that repeatedly asks for secret keys skk for keys k ∈ K of the attacker’s choice. As we shall see, defining security against such attackers is more delicate than one might first expect. The problem is how to define the challenge ciphertext in a semantic security game. As usual, once the attacker obtains all the secret keys he desires, he outputs two challenge messages m 0 , m 1 ∈ X and expects to get back an encryption c of m 0 or m 1 chosen at random by the challenger. Clearly,
F (, x), E
pp 1 , F (ki, x)
,... , E
pps, F (ks, x)
- dec(ski, c): output c 0 if ski = , and output D(ski, ci) otherwise.
Clearly, a ciphertext c leaks the bit lengths of F (ki, x) for i = 1,... , s. Therefore, for this construction to be secure we must assume that this information is already leaked by the empty functionality F (, ·), namely that |F (ki, x)| for i = 1,... , s is contained in F (, x). If so then we say that F reveals functional bit lengths.
Theorem 1 Let F be a functionality that reveals functional bit lengths. If (G, E, D) is a semantically secure public-key encryption scheme then the brute force FE system implementing F is secure.
Proof (Proof Sketch). The proof is by a standard hybrid argument across the s compo- nents of the challenge ciphertext.
4.2 Insufficiency of the game-based security definition
We will now show that for certain complex functionalities Definition 3 is too weak. For these functionalities we construct systems that are secure under Definition 3, but should not be considered secure. Nevertheless, for functionalities such as predicate encryption with public index we show in Section 5 that Definition 3 is adequate. We give a simple example of a functionality for which the game-based Definition 3 is insufficient. Let π be a one-way permutation and consider the functionality F that only admits the trivial key , defined as follows:
F (, x) = π(x)
It is clear that the “right” way to achieve functional encryption for this very simple functionality is to have the functional encryption algorithm itself simply output π(x) on input x, namely enc(pp, x) = π(x). This scheme would also clearly achieve the simulation-based definition of security presented in Section 5. However, consider an “incorrect” realization of this functionality where the func- tional encryption algorithm outputs x on input x, namely enc(pp, x) = x. Clearly this system leaks more information about the plaintext than needed. Nevertheless, it is easy to verify that this construction satisfies the game-based definition from Section 4. This is because for any two values x and y, it is the case that F (, x) = F (, y) if and only if x = y and therefore the attacker can only issue challenge messages m 0 , m 1 where m 0 = m 1. This problematic system, however, would clearly not achieve the simulation-based definition of security presented in Section 5, since if x is chosen at random, the real-life adversary would be able to recover x always, while the simulator would not be able to recover x without breaking the one-wayness of the permutation π. While the simple example above may seem to be “abusing” the role of the trivial key , it is easy to modify the functionality example F above so that there is exactly one non-trivial key k ∈ K that outputs π(x). The only difference to the construction above would be that the functional encryption algorithm would output a public-key
encryption^8 of either π(x) (in the “correct” implementation) or x (in the “incorrect” implementation), and the secret key for key k would be the secret key of the public-key encryption scheme. Again, it is easy to verify that the incorrect implementation satisfies the game-based definition.
Discussion. What does this separation show? While this is a subjective question, our view is that it shows that if the output of the functionality is supposed to have some computational hiding properties – that is, security of your application is not only based on the information-theoretic properties of the function, but also on the computational properties of the function – then there is a real problem with the game-based formulation of security. The game-based formulation essentially ignores any computational hiding properties of the function, and therefore offers no security guarantees that could be meaningfully combined with such computational considerations.
5 Simulation based definitions
In this section, we explore security definitions for functional encryption that arise from the simulation paradigm [GM84,GMR85,GMW86] that has served us so well, espe- cially in the closely related context of secure computation protocols. We begin by considering a simulation-based definition^9 of security for functional encryption that captures the most basic intuition we have: That getting the secret key skk corresponding to the key k ∈ K should only reveal F (k, x) when given an encryption of x. It turns out that we can achieve this simulation-based definition for natural func- tionalities in the random oracle model, where in the ideal model the random oracle would also be simulated. We argue that in fact this (very strong) random oracle model seems necessary for a meaningful simulation-based definition of security for functional encryption: we show that even in the non-programmable random oracle model (where the simulator, too, only has oracle access to the same random oracle that is provided to the distinguisher), simulation-secure functional encryption (for a seemingly “minimal” formulation of simulation-security) even just for the IBE functionality is impossible to achieve. At a high level, this is because any simulation-based definition that allows the adversary to query for secret keys after seeing the challenge ciphertext must achieve something very similar in spirit to non-interactive non-committing encryption, where exactly these kinds of impossibility and possibility results are known [Nie02]. In our main definition below (that we will achieve in our positive results), we will use some non-standard syntax for representing a stateful oracle^10. When we write AB(·)[[x]], we mean that the algorithm A can issue a query q to its oracle, at which point
(^8) The public-key encryption would need to be non-committing to achieve the simulation-based definition of security for the good case. (^9) We note that there are several natural variants possible for such a definition. We have chosen a definition that is strong in the sense that it requires a universal black-box simulator. We will later discuss some weaker formulations. (^10) The more standard way to formalize this communication structure would be through interactive Turing Machines, but we find this notation to be simpler to parse.
Definition 5 An FE scheme E is weakly simulation-secure if for any (oracle) PPT al- gorithms M essage and Adv, there exists an (oracle) PPT algorithm Sim such that we have that the following two distribution ensembles (over the security parameter λ) are computationally indistinguishable:
Real Distribution:
- (pp, mk) ← setup(1λ)
- (x, τ ) ← M essage(1λ)
- c ← enc(pp, x)
- α ← Advkeygen(mk,·)(pp, c, τ )
- Let y 1 ,... , y` be the queries to keygen made by Adv in the previous steps.
- Output (x, τ, α, y 1 ,... , y`) Ideal Distribution:
- (x, τ ) ← M essage(1λ)
- α ← SimF^ (·,x)(1λ, τ, F (, x))
- Let y 1 ,... , y` be the queries to F made by Sim in the previous step.
- Output (x, τ, α, y 1 ,... , y
) We note another weakening of the definition above would be to have the distribu- tions output the queries y 1 ,... , y as an unordered set, instead of an ordered tuple. Our impossibility proof can be extended to this weakening as well. We now sketch the proof of the following theorem.
Theorem 2 Let F be the functionality for IBE. There does not exist any weakly simulation- secure FE scheme for F in the non-programmable random oracle model.
Proof (Brief Proof Sketch). The overall idea of this proof is almost identical to the im- possibility proof of Nielsen [Nie02] for non-interactive non-committing encryption. Let H represent the random oracle. Consider the following concrete adversary algorithms: M essage(1λ) works as follows: Let lensk be the maximum bit length produced by the keygen algorithm for the key 0 for security parameter λ. Then the vector x consists of the following elements: for i = 1,... , lensk + λ, the element (ri, 0) where ri is a randomly and independently chosen bit for each i. The value τ is empty. Advkeygen(mk,·)(pp, c, τ ) works as follows: Call the random oracle H on the input (pp, c) to obtain a string w of length λ. Now request the secret key for the identity (w) first, and then for the identity 0. Use the key for identity 0 to decrypt the entire ciphertext. Output a full transcript of the entire computation done by Adv, including all calls to the random oracle and the interaction with the keygen oracle. Now consider what Sim must do in order to output a distribution indistinguishable from the real interaction. Because Adv only makes a single key query of the form (w), it is the case that Sim must make exactly one query – its first query – to F of this form as well. Furthermore, the distinguisher can check if this w is the output of H applied to some string of the form (pp, c). Thus, the simulator must perform this query to H before making any queries to F. The simulator at this point has no information whatsoever about the plaintexts ri (which is only revealed when the simulator queries F for identity 0 afterwards). Thus, this fixed string z = (pp, c) has the (impossible) property that after receiving only lensk bits of information, it can deterministically “decode” z to be a an arbitrary string of length lensk + λ.
We remark that the proof above made use of the fact that the simulator’s queries to F are recorded in order. However, we note that the same impossibility result would hold even if the security definition only recorded the unordered set of queries to F , but using a slightly more involved adversary and message distribution. Roughly speaking, the only identities in the system would be of the form (i, 0) and (i, 1) for i = 1,... , λ, and the messages to be encrypted would be random long messages for each identity. The adversary would apply the random oracle to (pp, c) to obtain a single string w of length λ exactly as above, but it would now use this string to obtain keys (i, wi) for i = 1,... , λ. The argument would now proceed by looking at the point when the simulator has made at least λ/ 2 queries to F. By now with overwhelming probability, a single query (pp, c) to H would be compatible with these queries, and that could be used to define the “impossible string” needed above.
5.2 A simulation-based brute force scheme
We now consider FE schemes that are simulation-secure in the random oracle model (where the scheme algorithms and the M essage and Adv algorithms all have oracle access to a random oracle, but the simulator algorithms can emulate the random oracle itself). We note that this is the standard formulation of the random oracle model, more recently called the “full” or “programmable” random oracle model.
The modified “brute-force” construction. We first consider the following slight mod- ification of the brute-force construction given earlier. The modification just uses the random oracle to randomly mask the output values of the function. We will make use of a random oracle H : { 0 , 1 }∗^ → { 0 , 1 }. Note that we will abuse notation and also write H(x) to produce strings of arbitrary length (which will be clear from context). This can be accomplished by interpreting H(x) to mean the concatenation of H((x, 1)),... , H((x, )) to produce strings of length. Recall that we write s = |K| − 1 and K = {, k 1 ,... , ks}. The brute force FE scheme realizing F uses a semantically secure public-key encryption scheme (G, E, D), and works as follows:
- setup(1λ): for i = 1,... , s run (ppi, mki) ← G(1λ).
output: pp := (pp 1 ,... , pps) and mk := (mk 1 ,... , mks)
- keygen(mk, ki): output ski := mki.
- enc(pp, x): choose random values r 1 ,... , rs ∈R { 0 , 1 }λ. output
c :=
F (, x), E
pp 1 , r 1
, H(r 1 ) ⊕ F (k 1 , x),... ,
E
pps, rs
, H(rs) ⊕ F (ks, x)
- dec(ski, c): output c 0 if ski = , and output H
D(ski, c 2 i− 1 )
⊕ c 2 i otherwise.
A proof sketch of the following theorem is given in the full version of the paper [BSW10].
- For each key k in the list κ of keys already queried, the simulator does the following: (1) it invokes the F oracle and obtains F (k, x) = (z 1 ,... , zn), (2) for i = 1,... , n if zi 6 = ⊥ it adds the pair (ri, Ri ⊕ zi) to the list O. If any of these ri values were already in the list O, the simulation aborts.
- Then it invokes Adv(pp, c, τ ) using this “fake” ciphertext vector c created above.
- It now monitors which random oracle queries and keygen queries the adversary Adv makes. It responds to these queries as follows: - Random Oracle Queries: On query q, the simulator first checks to see if a pair (q, y) already exists in the list O. If so, it provides y as the response to the adversary’s query. If not, the simulator chooses a fresh random string y, adds the pair (q, y) to the list O, and provides y as the response to the adversary’s query. - Key Queries: If the adversary asks for the key k, then the simulator in- vokes the F oracle and obtains F (k, x) = (z 1 ,... , zn). For i = 1,... , n if zi 6 = ⊥ it adds the pair (ri, Ri ⊕ zi) to the list O. If for any i there is already a pair (ri, R) in the list O with R 6 = Ri ⊕ zi then the simu- lation aborts. Finally, it sends the secret key sk ← keygen(mk, k) to the adversary. It is easy to confirm that the decryption procedure will work as it should after we have modified the random oracle as detailed above.
- When the adversary terminates and outputs α, then the simulator outputs this α as well, finishing the simulation.
The same argument as in the proof of Theorem 3 shows that the simulator aborts with negligible probability and that the distribution generated by these simulators is statistically close to the real distribution. In particular, the negligible probability of abort follows from the game-based security of E, since game-based security implies one-way security for encrypting random values, which implies that the adversary is extremely unlikely to query the random oracle on the ri values prior to obtaining a secret key that can open the i’th ciphertext.
Other Simulation-Secure Functional Encryption Schemes. Since the above equiva- lence only applies to public index schemes, an interesting question is whether we can achieve simulation security for more general systems. Intuitively this is more challeng- ing, since it goes beyond just hiding a payload, to “hiding a computation” and is ar- guably closer to our counter example of Section 4.2.
In the full version of the paper [BSW10] we prove the simulation security of the Boneh-Franklin construction for the anonymous IBE functionality. An interesting di- rection is to prove simulation security for systems with more functionality. One chal- lenge is that it is not completely clear how to apply the random oracle heuristic to these systems, as the correctness of such schemes typically relies on structure that a hash function might break.
6 Extending Functional Encryption
In this work, we focus on the “core” case of functional encryption. However, there are multiple ways to extend the concept. We briefly outline these here. We hope future work will develop these extensions and give precise definitions of security and constructions.
Delegation. Delegation is the ability of an algorithm to transform a key k in a func- tional encryption system to another key k′. For example, one might want to share the ability to decrypt all messages of a certain subject to another user. Typically, we think of the resulting key k′^ as being more restricted than the source key k. We observe that the set of allowed delegations must respect the security definition of the system. Delegation in functional encryption systems is typically associated with Hierarchical Identity-Based Encryption [HL02,GS02], but was also considered in Attribute-Based Encryption [GPSW06] and other predicate encryption systems [SW08].
Encryption over Multiple Parameters and Multiple Systems. Our functional encryp- tion systems allow for functionalities F : K × X → { 0 , 1 }∗^ that take in a single key and plaintext as inputs. However, we could extend our system to allows for functionali- ties that take in multiple keys F : (K 1 ,... , Kn) × X → { 0 , 1 }∗. This can be useful in applications where we want users to combine their capabilities in a specified manner or when one of the keys can represent an event such as a certain time period arriving, or publication of a revocation list [BGK08].Another interesting direction is to allow for a functional encryption system that operates over multiple ciphertexts. Taking things further we could consider an encryption system where encryption takes in multiple public parameters each from different authorities and where the func- tionality is evaluated over private keys generated by different master secret keys. One notable application of this is Attribute-Based Encryption where multiple authorities are used [Cha07,CC09].
Hiding Information about capabilities of the key. One consistent feature of all sys- tems is that there do not exist any security notions about the attacker’s inability to distinguish what type of key k he is given a secret key for. A natural reason for this is that in a public key system, he can distinguish whether he has the capability for k 0 , k 1 by simply encrypting an x ∈ X such that F (k 0 , x) 6 = F (k 1 , x). However, one might try to consider such a problem when encryption is not public key [SSW09,BIP10].
7 Future directions in functional encryption
The results to date scratch the surface of functional encryption and only implement rel- atively simple functionalities. Here we list a few fascinating open problems that remain.
- The grand challenge is to construct a secure functional encryption scheme for all polynomial-time functionalities. A more modest goal is to do the same for predi- cate encryption for all polynomial-time predicates. Currently, the best we can do is predicates defined by inner products [KSW08]. The inner product construction uses bilinear maps and our inability to move beyond inner products is due to the “bi” in bilinear maps. Other tools, perhaps borrowing from fully homomorphic en- cryption [Gen09], may lead to a more general class of predicates.
[BW07] Dan Boneh and Brent Waters. Conjunctive, subset, and range queries on encrypted data. In TCC, pages 535–554, 2007. [CC09] Melissa Chase and Sherman S. M. Chow. Improving privacy and security in multi- authority attribute-based encryption. In ACM Conference on Computer and Commu- nications Security, pages 121–130, 2009. [CFGN96] Ran Canetti, Uriel Feige, Oded Goldreich, and Moni Naor. Adaptively secure multi- party computation. In STOC 1996, pages 639–648, 1996. [Cha07] Melissa Chase. Multi-authority attribute based encryption. In TCC, pages 515–534,
[CHK03] Ran Canetti, Shai Halevi, and Jonathan Katz. A forward-secure public-key encryption scheme. In EUROCRYPT, pages 255–271, 2003. [CHKP10] David Cash, Dennis Hofheinz, Eike Kiltz, and Chris Peikert. Bonsai trees, or how to delegate a lattice basis. In EUROCRYPT, pages 523–552, 2010. [Coc01] Clifford Cocks. An identity based encryption scheme based on quadratic residues. In IMA Int. Conf., pages 360–363, 2001. [Del07] C´ecile Delerabl´ee. Identity-based broadcast encryption with constant size ciphertexts and private keys. In ASIACRYPT, pages 200–215, 2007. [DH76a] Whitfield Diffie and Martin E. Hellman. Multiuser cryptographic techniques. In AFIPS National Computer Conference, pages 109–112, 1976. [DH76b] Whitfield Diffie and Martin E. Hellman. New directions in cryptography. IEEE Trans- actions on Information Theory, IT-22(6):644–654, 1976. [DPP07] C´ecile Delerabl´ee, Pascal Paillier, and David Pointcheval. Fully collusion secure dy- namic broadcast encryption with constant-size ciphertexts or decryption keys. In Pair- ing, pages 39–59, 2007. [Gen06] Craig Gentry. Practical identity-based encryption without random oracles. In EURO- CRYPT, pages 445–464, 2006. [Gen09] Craig Gentry. A fully homomorphic encryption scheme. PhD thesis, Stanford Univer- sity, 2009. crypto.stanford.edu/craig. [GJPS08] Vipul Goyal, Abhishek Jain, Omkant Pandey, and Amit Sahai. Bounded ciphertext policy attribute based encryption. In ICALP (2), pages 579–591, 2008. [GM84] S. Goldwasser and S. Micali. Probabilistic encryption. Jour. of Computer and System Science, 28(2):270–299, 1984. [GMR85] Shafi Goldwasser, Silvio Micali, and Charles Rackoff. The knowledge complexity of interactive proof-systems. In STOC, pages 291–304, 1985. [GMW86] Oded Goldreich, Silvio Micali, and Avi Wigderson. Proofs that yield nothing but their validity and a methodology of cryptographic protocol design. In FOCS, pages 174–187, 1986. [GPSW06] Vipul Goyal, Omkant Pandey, Amit Sahai, and Brent Waters. Attribute-based en- cryption for fine-grained access control of encrypted data. In ACM Conference on Computer and Communications Security, pages 89–98, 2006. [GPV08] Craig Gentry, Chris Peikert, and Vinod Vaikuntanathan. Trapdoors for hard lattices and new cryptographic constructions. In STOC, pages 197–206, 2008. [GS02] Craig Gentry and Alice Silverberg. Hierarchical id-based cryptography. In ASI- ACRYPT, pages 548–566, 2002. [GW09] Craig Gentry and Brent Waters. Adaptive security in broadcast encryption systems (with short ciphertexts). In EUROCRYPT, pages 171–188, 2009. [HL02] Jeremy Horwitz and Ben Lynn. Toward hierarchical identity-based encryption. In EUROCRYPT, pages 466–481, 2002. [KSW08] Jonathan Katz, Amit Sahai, and Brent Waters. Predicate encryption supporting dis- junctions, polynomial equations, and inner products. In EUROCRYPT, pages 146– 162, 2008.
[LOS+10] Allison B. Lewko, Tatsuaki Okamoto, Amit Sahai, Katsuyuki Takashima, and Brent Waters. Fully secure functional encryption: Attribute-based encryption and (hierar- chical) inner product encryption. In EUROCRYPT, pages 62–91, 2010. [Nie02] Jesper Buus Nielsen. Separating random oracle proofs from complexity theoretic proofs: The non-committing encryption case. In Proc. of CRYPTO 2002, pages 111– 126, 2002. [O’N10] Adam O’Neill. Definitional issues in functional encryption. Cryptology ePrint Archive, Report 2010/556, 2010. http://eprint.iacr.org/2010/556. [OSW07] Rafail Ostrovsky, Amit Sahai, and Brent Waters. Attribute-based encryption with non- monotonic access structures. In ACM Conference on Computer and Communications Security, pages 195–203, 2007. [OT09] Tatsuaki Okamoto and Katsuyuki Takashima. Hierarchical predicate encryption for inner-products. In ASIACRYPT, pages 214–231, 2009. [OT10] Tatsuaki Okamoto and Katsuyuki Takashima. Fully secure functional encryption with general relations from the decisional linear assumption. In CRYPTO, pages 191–208,
[SBC+07] Elaine Shi, John Bethencourt, Hubert T.-H. Chan, Dawn Xiaodong Song, and Adrian Perrig. Multi-dimensional range query over encrypted data. In IEEE Symposium on Security and Privacy, pages 350–364, 2007. [SF07] Ryuichi Sakai and Jun Furukawa. Identity-based broadcast encryption. Cryptology ePrint Archive, Report 2007/217, 2007. http://eprint.iacr.org/. [Sha84] Adi Shamir. Identity-based cryptosystems and signature schemes. In CRYPTO, pages 47–53, 1984. [SSW09] Emily Shen, Elaine Shi, and Brent Waters. Predicate privacy in encryption systems. In TCC, pages 457–473, 2009. [SW05] Amit Sahai and Brent Waters. Fuzzy identity-based encryption. In EUROCRYPT, pages 457–473, 2005. [SW08] Elaine Shi and Brent Waters. Delegating capabilities in predicate encryption systems. In ICALP (2), pages 560–578, 2008. [Wat05] Brent Waters. Efficient identity-based encryption without random oracles. In EURO- CRYPT, pages 114–127, 2005. [Wat08] Brent Waters. Functional encryption:beyond public key cryptography. Power Point Presentation, 2008. http://userweb.cs.utexas.edu/˜bwaters/ presentations/files/functional.ppt. [Wat11] Brent Waters. Ciphertext-policy attribute-based encryption: An expressive, efficient, and provably secure realization. PKC, 2011.
