Blind Functional Encryption

Abstract

Functional encryption (FE) gives the power to retain control of sensitive information and is particularly suitable in several practical real-world use cases. Using this primitive, anyone having a specific functional decryption key (derived from some master secret key) could only obtain the evaluation of an authorized function f over a message m, given its encryption. For many scenarios, the data owner is always different from the functionality owner, such that a classical implementation of functional encryption naturally implies an interactive key generation protocol between an entity owning the function f and another one managing the master secret key. We focus on this particular phase and consider the case where the function needs to be secret.

In this paper, we introduce the new notion of blind functional encryption in which, during an interactive key generation protocol, the master secret key owner does not learn anything about the function f. Our new notion can be seen as a generalisation of the existing concepts of blind IBE/ABE. After a deep study of this new property and its relation with other security notions, we show how to obtain a generic blind FE from any non-blind FE, using homomorphic encryption and zero-knowledge proofs of knowledge. We finally illustrate such construction by giving an efficient instantiation in the case of the inner product functionality.

Appendices

A Message-Privacy for IFE

Oracles. In traditional FE, the adversary has access to a $\mathsf {KeyGen}(\mathsf {msk},\cdot )$ oracle which extracts a functional key when the adversary requests it for a chosen input function f. We here adapt the definition of message-privacy to our interactive setting. The main difference relies in the fact that some information could leak during the interactive key generation. We introduce an interactive oracle $\mathsf {IKeyGen}(\mathcal {O}(\mathsf {msk}),\cdot )$: when calling this oracle, the adversary, on input $f \in F$, participates in an interactive protocol with the oracle playing the role of an honest authority. The adversary finally gets the output functional key $sk_f$. For any bit $b\in \{0,1\}$, we define $\mathsf {Enc}_b(\mathsf {mpk},\cdot ,\cdot )$ to be an oracle which takes as inputs $x_0$ and $x_1$ and returns $\mathsf {Enc}(\mathsf {mpk},x_b)$. The next definition extends known definitions  [8] to the interactive setting and could be well adapted for private-key $\mathsf {FE}$.

Definition 8

(Message-privacy). Let $\mathsf {IFE} = (\mathsf {Setup},\mathsf {IKeyGen},\mathsf {Enc},\mathsf {Dec})$ over a message space M and a function space F. We say that $\mathsf {IFE}$ is message-private (MP) if for any PPT adversary $\mathcal {A}$, there exists a negligible function $\mathsf{negl}(\lambda )$ such that the quantity, called the advantage of $\mathcal {A}$, $\mathsf {Adv}_{\mathcal {A},\texttt {MP-IFE}}(1^\lambda ):= \left| \mathsf {Pr}\left[ \mathsf {Exp}_{\mathcal {A}}^{(0),\mathsf {mp}}(\lambda )= 1 \right] - \mathsf {Pr}\left[ \mathsf {Exp}_{\mathcal {A}}^{(1),\mathsf {mp}}(\lambda )= 1 \right] \right| \le \mathsf{negl}(\lambda )$, where $\mathsf {Exp}_{\mathcal {A}}^{(b),\mathsf {mp}}(\lambda )$ is

1. $(\mathsf {mpk},\mathsf {msk}) \leftarrow \mathsf {Setup}(1^\lambda )$	2. $b' \leftarrow \mathcal {A}^{\mathsf {IKeyGen}(\mathcal {O}(\mathsf {msk}),\cdot ), \mathsf {Enc}_b (\mathsf {mpk},\cdot ,\cdot )}(1^\lambda ,\mathsf {mpk})$
3. output $b' =b$

We required that for all $f \in F$ and $(m_0,m_1)$ coming from $\mathcal {A}$’s calls to the oracles $\mathsf {KeyGen}$ and $\mathsf {Enc}_b$ respectively, it holds that $f(m_0) = f(m_1)$.

B Leak-Freeness

We provide a generalization of the Leak-Freeness property of [24].

Definition 9

(Leak-Freeness). An $\mathsf {IKeyGen}$ protocol corresponding to $\mathsf {KeyGen}$ algorithm of any FE scheme is leak-free w.r.t. $\mathsf {KeyGen}$ if, for all efficient adversaries $\mathcal {A}$, there exists an efficient simulator $\mathcal {S}$ such that for all value $\lambda$, no distinguisher $\mathcal {D}$ can determine whether it is playing $\mathsf {GameReal}$ or $\mathsf {Game Ideal}$ where

• $\mathsf {GameReal}$: Run $\mathsf {Setup}(1^{\lambda })$. As many times as $\mathcal {D}$ wants, $\mathcal {A}$ chooses a function f and executes the $\mathsf {IKeyGen}(\mathcal {AUT},\cdot )$ protocol input f with an honest authority $\mathcal {AUT}$. $\mathcal {A}$ returns the resulting view to $\mathcal {D}$ which returns a bit.

• $\mathsf {Game Ideal}$: Run $\mathsf {Setup}(1^{\lambda })$. As many times as $\mathcal {D}$ wants, $\mathcal {S}$ chooses a function f and asks $\mathsf {Trivial}.\mathsf {IKeyGen}(\mathsf {msk},\cdot )$ to obtain a functional key $sk_f$ on input f. $\mathcal {S}$ returns then the resulting view to $\mathcal {D}$ which returns a bit.

The quantity $\mathsf {Adv}_{\mathcal {D},\mathsf {leak-free}}(1^\lambda ) := |\mathsf {Pr}[\mathcal {D}^\mathsf {GameReal} (1^\lambda ) = 1] - \mathsf {Pr}[\mathcal {D}^\mathsf {Game Ideal}(1^\lambda ) = 1]|$ is the advantage of $\mathcal {D}$ and $\mathsf {IKeyGen}$ is leak-free w.r.t $\mathsf {KeyGen}$ if it is negligible.

We discuss in the following some remarks about the definition.

• A secure two-party protocol realizing the $\mathsf {KeyGen}$ functionality of a classical $\mathsf {FE}$ ensures the message-privacy since it preserves each party for learning the other party’s input. The main difference in our consideration is that we require the use of a known $\mathsf {FE}$ scheme with some specific $\mathsf {KeyGen}$ algorithm in addition to the existence of a simulator (which interacts with a specific oracle $\mathsf {Trivial.IKeyGen}$). This simulator is then asked to produce a consistent view to any distinguisher. As mentioned in previous sections, a two-party protocol wouldn’t offer the blindness property for free. In Example 2.1, $\mathsf {Trivial.\mathsf {IKeyGen}}$ is by definition leak-free w.r.t $\mathsf {KeyGen}$ but not blind.

• The adversary in $\mathsf {GameIdeal}$ does not appear in the definition. As pointed in [24], the leak-freeness definition implies that the function (for the key being extracted) is extractable from the $\mathsf {IKeyGen}$ protocol (with all but negligible probability), since for every adversary it must exist a simulator $\mathcal {S}$ that should be able to interact with $\mathcal {A}$, in order to learn which functions to submit to the $\mathsf {Trivial}.\mathsf {IKeyGen}(\mathsf {msk},\cdot )$ oracle.

• When considering the validity of $sk_f$ (in Sect. 2.1), a $\mathsf {ZKPoK}$ is used in order to verify if a functional key $sk_f$ is well-formed. This is independent from the definition of the leak-freeness property, since the authority is always honest in this context (simulated by an oracle).

C The Castagnos-Laguillaumie Scheme

CL Encryption Scheme. The $\mathsf {Setup}$ phase in the CL scheme consists of the description of a DDH group with an easy DL subgroup $(p,\tilde{s},\mathfrak {g},\mathfrak {f},\mathfrak {g}_p,G,F,G^p)$ where the set $(G,\cdot )$ is a cyclic group of order ps, for an unknown integer s, p is a prime number such that $\gcd (p,s)=1$. The only known information on s is an upper bound $\tilde{s}$ of s. The set $G^p=\{\mathfrak {y}^p, \mathfrak {y} \in G\}$ is the subgroup of (unknown) order s of G, and F is the subgroup of order p of G, so that $G = F \times G^p$. The elements $\mathfrak {f}$, $\mathfrak {g}_p$ and $\mathfrak {g}=\mathfrak {f} \cdot \mathfrak {g}_p$ are respective generators of F, $G^p$ and G. The discrete logarithm problem is easy in F, which means that there exists deterministic polynomial time algorithm a $\mathsf{Solve}$ that solves the discrete logarithm problem in F. The message space of CL is $\mathbb {Z}_p$ and its indistinguishability under chosen plaintext attacks relies on the hard subgroup membership assumption that says that is hard to distinguish the elements of $G_p$ in G. An instantiation of this group is obtained using the class group of a non maximal order of an imaginary quadratic field (we refer the reader to [16, 17] for a more precise description). Roughly, $\mathsf {CL}$ scheme consists of a secret key $\mathsf {sk}$ is an integer $x \leftarrow \{0, \dots , \tilde{s} p-1\}$ and the public key is $\mathsf {pk}= \mathfrak {g}_p^{x}$. The encryption procedure returns a ciphertext $c_m = (c_1,c_2)$ where $c_{1} \leftarrow \mathfrak {g}_p^{r}$ and $c_{2} \leftarrow \mathfrak {f}^{m} \mathfrak {h}^{r}$ for a random r. The decryption algorithm computes $M \leftarrow c_{2} / c_{1}^{x}$ and returns m using the $\mathsf{Solve}$ algorithm on M.