Backward Compatible Identity-Based Encryption

Abstract

In this paper, we present a new identity-based encryption (IBE) system that is named Backward Compatible Identity-based Encryption (BC-IBE). Our BC-IBE is proposed to solve the problem caused by the out-of-synchronization between users’ private keys and ciphertexts. Encryption systems such as revocable IBE or revocable Attribute-based Encryption (ABE) often require updating private keys to revoke users after a certain time period. However, in those schemes, an updated key can be used to decrypt the ciphertexts created only during the current time period. Once the key is updated and the previous keys are removed, the user, the owner of the updated key, will lose access to the past ciphertexts. In our paper, we propose BC-IBE that supports backward compatibility, to solve this problem. In our proposed system, user’s private keys and ciphertexts can be updated periodically with time tags, and these processes can be used to revoke users who do not receive an updated key as the other revocable encryption does. However, in our proposed system, a private key newly issued to a user is backward compatible. This means that it decrypts not only the ciphertexts at the present time period but also all past ciphertexts. This implies that our proposed scheme guarantees the decryption of all encrypted data even if they are not synchronized. Compared to the existing revocable identity-based encryption system, our proposed BC-IBE has the advantage of simplifying key management and securely delegating ciphertext updates. Our proposed scheme only requires a single backward-compatible private key to decrypt all past ciphertexts created. Moreover, the ciphertext update process in our proposed scheme does not require any special privileges and does not require decryption. This means that this process can be securely delegated to a third-party server, such as a cloud server, and it prevents the potential leakage of secrets. For those reasons, BC-IBE is suitable for a system where users are more dynamic, such as the Internet-of-Things (IoT) network, or a system that regularly updates the data, like cloud data storage. In this paper, we provide the construction of BC-IBE and prove its formal security.

1. Introduction

The Internet of Things (IoT) network is a network where a number of heterogeneous devices are connected to each other and exchange various types of data. As the data in an IoT network is often private, the security of the transmitted data in the IoT network is considered important. Public key encryption is the most widely used cryptographic system to control access to the IoT network in security protocols like Transport Layer Security (TLS), Datagram TLS, and Constraint Application Protocol (CoAP) because it does not require any pre-shared secret.

In such public key encryption systems, the authentication of devices is essential because the devices must check the identities of the corresponding party before encrypting a secret using its public key. Otherwise, the adversary can easily disguise as the other and hijack the data in the middle via an attack like Man-in-the-middle (MITM) attack [1,2]. Particularly, in a public key encryption system, a public key is transmitted through a non-secure channel. Therefore, a sender needs to check if the recipient’s public key is matched with its identity so that it is truly from the same recipient who the sender intends to communicate with.

Public Key Infrastructure (PKI) is a widely used system for authentication and preventing this type of attack. A PKI system enables devices to authenticate if the recipient’s identity and public key are matched before the sender sends any private data to the receiver. This conventional system implements the authentication process by issuing and maintaining certificates. Each certificate consists of identity, public keys and digital signatures so that it can be used to verify if the public key in the certificate belongs to the certificate owner via digital signatures. Unfortunately, maintaining certificates causes a significant burden to the system. It requires verifying multiple signatures for authentication and having to exchange large-sized certificates in addition to the cost of maintaining the certificate chain. Those are considered too large for the resource-constrained network such as IoT systems.

Identity-based encryption (IBE) [3,4,5] was introduced to manage access control based on the user’s identity. In IBE, a sender encrypts a message with a public key that is associated with a receiver’s identity. Furthermore, the receiver can decrypt ciphertexts with its private key that corresponds to the public key. The recipient’s public key is not needed to be authenticated as it is already associated with its identity. Therefore, it reduces the burden of managing certificates that the IoT system wants to avoid due to its cost. Although an IBE system can bring a huge benefit to access control in an IoT system where a complex authentication scheme is needed due to its heterogeneity and scale, there are other properties that should be considered in an authentication. One of the properties that must be considered is dynamic access control.

In an IoT system, a user can join and be revoked from the system while the system is operating. One of the key features of IoT networks is sharing resources. A user can use multiple devices to share storage, as each individual device has relatively little storage. Cloud storage services such as Microsoft Onedrive and Google Drive are often used to share users’ data across multiple devices, from desktop PCs to mobile phones or tablet PCs. However, those mobile devices can easily be lost and also out-of-synchronized by the carelessness of the user. This will put users’ privacy at significant risk as those incidents will make a user’s private key and data leak or become inaccessible from time to time.

In a traditional PKI system, a user (or its public key associated with the compromised private key) can be removed from its certificate chain by adding its certificate to a revocation list. However, in the IBE system, which does not use any certificates, the revocation is not straightforward. To support the revocation in IBE systems, Revocable IBE (RIBE) [6,7,8,9,10] was introduced to revoke a user when its private key is compromised.

RIBE uses a key-update mechanism. In RIBE, for a specific time slot, a user’s long-term private key, for which the associated identity does not belong to the revocation list, can be used to compute the decryption key that can be used to decrypt the ciphertext encrypted in that time slot. Therefore, in the RIBE, one who does not have the decryption key in a specific time slot $\mathcal{T}$ is revoked. In RIBE, the decryption key cannot be used for the other time slots, particularly ciphertexts for the previous time slots. This may cause some compatibility problems in a practical system. For example, in the heterogeneous IoT network, some nodes are not synchronized properly and encrypt the data using the just previous time slot. The receiver cannot decrypt the data as it has already updated its key. Moreover, in cloud storage, the data is normally synchronized but not always. Some data, for example, stored in local storage, may not be synchronized properly. In this scenario, the data that are encrypted cannot be decrypted after the key update.

In this paper, we solve this problem, which we called the backward compatibility problem, by providing a new encryption system based on IBE that is named Backward Compatible IBE (BC-IBE). Trivial solutions for this problem are (1) keeping all previous decryption keys for backward compatibility or (2) decrypting and re-encrypting all ciphertexts created in the past time slots. However, the former requires more resources in secure memory, which is considered expensive. The latter requires a large overhead and the potential leakage of the secret as it causes decryption and re-encryption.

In our solution, BC-IBE allows a user to keep only a single key for the present time slot, but this key can be used to decrypt not only the ciphertexts created for the present time slot where the current key is issued but also all past ciphertexts previously created. Moreover, at the same time, in our proposed BC-IBE, ciphertexts can be updated for a new time slot without decryption, so that it reduces the overhead caused by decryption and re-encryption.

1.1. Our Contribution

In this paper, we propose a new IBE encryption system, which is named backward compatible identity-based encryption (BC-IBE). Our proposed scheme provides the revocation of an expired private key via the update of ciphertexts and the backward compatibility of an updated private key. The details are as follows:

• Backward compatibility: In our proposed scheme, a private key updated for time $\mathcal{T}$ can decrypt all the ciphertexts created at the time $\mathcal{T}$ and all the previous ciphertexts created before the time $\mathcal{T}$. One of the most trivial ways to achieve this is to keep all previous keys in secure storage. However, in that system, the user needs to maintain multiple keys to decrypt all past ciphertexts, which consumes large amounts of secure memory space. In our proposed scheme, the user only needs to maintain a single key at all times, but this key can be used to decrypt all past ciphertexts that were encrypted at previous time slots. At the same time, the same key can decrypt the ciphertext generated for the present time slot, too.
• Revocation: In our proposed scheme, a private key is efficiently revoked by updating ciphertexts in the past time slots. That means that for all ciphertexts of the time $\mathcal{T}$, all previous keys issued before the time $\mathcal{T}$ cannot be used to decrypt the ciphertexts at time $\mathcal{T}$. Therefore, all past keys are revoked in the system.
• Updating ciphertexts: In our BC-IBE, ciphertexts can be updated to revoke the past keys without decryption or re-encryption. Hence, the data owner does not need to download all ciphertexts and decrypt and re-encrypt them for the update. Moreover, this process does not involve any secret parameters. It can be easily delegated to a third party, such as a cloud service provider. Our scheme allows the updating of ciphertexts. This will be helpful for the overall scheme as (1) the scheme does not leak any information to the server while there is no secret involved in updating ciphertexts, (2) the server does not maintain the secret key for the ciphertext update and does not need any connection to be maintained to receive it.

We compare the above three properties of our BC-IBE scheme to the other encryption systems: identity-based encryption (IBE), revocable identity-based encryption (RIBE) and aggregate identity based encryption (AIBE) using

Table 1. Comparison of BC-IBE to the other encryption systems.

	Backward Compatibility	Revocation	Re-Encryption w/o Decryption
IBE [3,4,5,11,12]	N/A	No	No
RIBE [7,9,10,13,14]	No	Yes	No
AIBE [15]	Maybe	No	No
BC-IBE (Ours)	Yes	Yes	Yes

. The plain IBE schemes [3,4,5,11,12] do not support revocation. As there are no states or separated time periods, backward compatibility is not applicable in the plain IBE. Due to the same reason, plain IBE does not support re-encrypting ciphertexts. RIBE [7,9,10,13,14] is a scheme for revoking invalid users only at a specific time slot. All ciphertexts in the past time slot cannot be decrypted using the decryption key at the present time slot, as each decryption key is a short-term key only for the current time slot. Therefore, it does not support the backward compatibility of a private key. The ciphertexts of the past time periods are accessible via decryption and re-encryption for the current time period.

AIBE [15] may be a suitable scheme for backward compatibility, as it can aggregate all past keys and the current key into a single one. However, it is not a scheme for revocation. Therefore, it does not provide revocation and re-encryption.

To summarize, our proposed scheme has the following contribution:

• We define the backward compatibility property of identity-based encryption and construct the first scheme that satisfies the backward compatibility property.
• Together with the backward compatibility property, our scheme supports the update of the ciphertexts. In our scheme, previous ciphertexts can be updated for the newly updated key without decryption, and they cannot be decrypted by all previously issued keys.
• As the encryption system we proposed is new, we newly develop the definition of BC-IBE, suggest its security model, and provide the security proof of the proposed scheme.

1.2. Paper Organization

The rest of this paper is organized as follows: in Section 1, we provide the introduction and contribution to explaining the motivation of our research. Section 2 and Section 3 are for related work and preliminary explanations of the important literature for our work, respectively. In Section 4, the detailed method and the technical overview of our BC-IBE are explained. In Section 5, we present our construction and its formal security analysis. In Section 6. We discuss a potential threat and conclude our paper.

2. Related Works

The concept of identity-based encryption was proposed by Shamir [3]. It enables users to encrypt a message using their identities, such as e-mail, mobile numbers, and account numbers. Therefore, it reduces a lot of the burden needed to authenticate the receivers. The first practical IBE scheme was proposed by Boneh and Franklin [4] in a bilinear pairing group. Furthermore, it became an active research topic in public-key cryptography. Multiple IBE schemes [5,11,12] which improved security, were introduced, including adaptive security.

Revocable identity-based encryption (RIBE) is a system that improves an IBE scheme to support efficient revocation. As a user’s private key can be compromised by an adversary, revocation is practically needed. The first practical RIBE scheme were introduced by Boldyreva et al. [13] using the complete subtree (CS) method, which achieves logarithm revocation complexity. Their scheme revokes a user’s access by broadcasting an update key. The revoked users cannot compute a decryption key from the key update, so they are revoked. More schemes that achieve better security [14,16] or are based on different revocation methods [17] (e.g., the subset difference method) were introduced. Some RIBE systems are resistant to decryption key leakage. They are called decryption key exposure resistance (DKER) RIBE schemes [7,9,10]. Moreover, the generic constructions for RIBE from IBE was introduced by [6,8]. A few RIBE schemes also [18,19,20] use a third-party server to update the ciphertexts, similar to our scheme but without supporting backwards compatibility, and it also needs a key for the server to revoke users.

RIBE revokes users by updating decryption keys, but our scheme basically revokes users using the ciphertext and the status. This approach is more widely used in revocable attribute-based encryption (RABE) [21,22,23], in which each user has a private key that is associated with its attributes, and the decryption is allowed when its attributes satisfy a specific function (e.g., Boolean function). In those schemes, ciphertexts are re-encrypted or updated to revoke attributes to supporting dynamic credentials. The decryption key in RIBE can be used to decrypt the ciphertexts created within the same time slots. That is the main difference from our BC-IBE. In RIBE, the past ciphertexts can be updated only via decryption using the old keys, then it needs to be re-encrypted for the present time slot.

Improving the efficiency of those RIBE is still an ongoing problem. Lee et al. [24] and Yinxia et al. [25] presented RIBE schemes with a short key and a short ciphertext. More recently, Keita et al. [26] proposed a RIBE scheme that reduces the size of public keys. However, those schemes focus on reducing the keys in the current time period and do not support backward compatibility. This means their scheme still needs a list of private keys for backward compatibility.

3. Preliminaries

3.1. Bilinear Pairing

Let’s set $\mathcal{G}$ as a group generator that takes a security parameter $\mathit{\lambda }$ as input and outputs a description of a bilinear group $\mathcal{G}$. For our purposes, we will have $\mathcal{G}$ output (p, $\mathbb{G}$, ${\mathbb{G}}_T$, e) where p is a prime, $\mathbb{G}$ and ${\mathbb{G}}_T$ are cyclic groups of order p, and $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$ is an efficiently computable non-degenerate bilinear map. We assume that the group operations in $\mathbb{G}$ and ${\mathbb{G}}_T$ as well as the bilinear map e are efficiently computable in polynomial time with respect to $\mathit{\lambda }$ and that the group descriptions of $\mathbb{G}$ and ${\mathbb{G}}_T$ include generators of the respective cyclic groups.

3.2. Assumption

Assumption 1.

The q Decision Bilinear Diffie-Hellman Inversion (q-DBDHI) Assumption [15]. Let $\mathbb{G}$ and ${\mathbb{G}}_T$ be groups of order p with a bilinear map $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$, and let g be a generator for $\mathbb{G}$. Set $\alpha \stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{*}$ and $b\stackrel{R}{\leftarrow }\{0,1\}$. If $b=0$, set $T\leftarrow e{(g,g)}^{1/\alpha }$; otherwise, set $T\stackrel{R}{\leftarrow }{\mathbb{G}}_T$. Output $\{g^{{\alpha }^i}:i\in \left[q\right]\}\mathrm{and}T$. The problem is to guess b.

We define the advantage of the adversary of $\mathcal{A}$ to guess b correctly as follows:

$$Ad{v}_{\mathcal{A},m}^{q-DBDHI}\left(\mathit{\lambda }\right)=|Pr[b=b^{\prime }]-\frac{1}{2}|.$$

3.3. Definitions

We write the formal definition of IBE using the syntax of [15].

Definition 1

(Identity-Based Encryption (IBE)). The identity-based encryption for a set of identity spaces $\mathcal{I}={\left\{{\{0,1\}}^n\right\}}_{n\in \mathbb{N}}$ and a message space $\mathcal{M}$ consists of the following PPT algorithm (Setup, KeyGen, Enc, Dec):

• Setup (1${}^{\mathit{\lambda }}$, 1${}^n$) $\to (\mathsf{pk},\mathsf{msk})$: takes as input the security parameter λ, the identity length n. It outputs the public parameters pk and the master secret key msk.
• KeyGen($\mathsf{msk}$, $\mathsf{id}$) $\to \left({\mathsf{sk}}_{\mathsf{id}}\right)$: takes as input the master secret key $\mathsf{msk}$ and the identity $\mathsf{id}\in \mathcal{I}$. It outputs a private key ${\mathsf{sk}}_{\mathsf{id}}$.
• Enc(m, $\mathsf{id}$, $\mathsf{pk}$) $\to \left({\mathsf{ct}}_{\mathsf{id}}\right)$: takes as input a message $m\in \mathcal{M}$, an identity $\mathsf{id}\in \mathcal{I}$, and the public parameters pk. It outputs a ciphertext ${\mathsf{ct}}_{\mathsf{id}}$.
• Dec(${\mathsf{sk}}_{\mathsf{id}},{\mathsf{ct}}_{\mathsf{id}}$) $\to (m/\perp )$: takes as input a private key ${\mathsf{sk}}_{\mathsf{id}}$, a ciphertext ${\mathsf{ct}}_{\mathsf{id}}$. It outputs a message m or aborts.

• Correctness. An IBE scheme is correct if the following holds: for all $\mathit{\lambda },n\in \mathbb{N},$ let $(\mathsf{pk},\mathsf{msk})\leftarrow \mathsf{Setup}(1^{\mathit{\lambda }},1^n),{\mathsf{sk}}_{\mathsf{id}}\leftarrow \mathsf{KeyGen}(\mathsf{msk},\mathsf{id})$ for $\mathsf{id}\in {\{0,1\}}^n$, and ${\mathsf{ct}}_{\mathsf{id}}\leftarrow \mathsf{Enc}(m,\mathsf{mpk},\mathsf{id})$ for $m\in \mathcal{M}$. Furthermore, $m\leftarrow \mathsf{Dec}({\mathsf{sk}}_{\mathsf{id}},{\mathsf{ct}}_{\mathsf{id}})$.

The aggregating secret keys property, introduced in ref. [15], allows aggregating multiple private keys in an identity-based encryption scheme into a single compact key. They provide the definition of Aggregate Identity-Based Encryption(AIBE) by adding two extra algorithms to the definition of IBE as described in the following definition:

Definition 2

(Aggregate Identity-Based Encryption (AIBE)). In addition to the algorithms (Setup, KeyGen, Enc, Dec) that forms an IBE scheme, the aggregating secret keys property requires the following two PPT algorithms (KeyAgg, AggDec) to support secret key aggregation in AIBE.

• KeyAgg(sk${}_1,\dots {\mathsf{sk}}_{\ell }$) $\to (\widehat{\mathsf{sk}}$) takes as input a sequence of secret keys $\left\{{\mathsf{sk}}_i\right\}$ for $i\in [\ell ]$ (for some $\ell >1$). It outputs an aggregated $\widehat{\mathsf{sk}}$.
• AggDec($\widehat{\mathsf{sk}},({\mathsf{id}}_1,\dots {\mathsf{id}}_{\ell }$),ct, j) $\to (m/\perp )$ takes as input an aggregated private key $\widehat{\mathsf{sk}}$, a list of identities $\left\{{\mathsf{id}}_i\right|i\in [\ell ]\}$, a ciphertext ct and the index $j\in [\ell ]$ that denotes the identity utilized to create ct. It outputs a message m or aborts.

• Correctness. An IBE scheme with aggregating secret keys is correct if the following holds: for all $\mathit{\lambda },n\in \mathbb{N},$ let $(\mathsf{pk},\mathsf{msk})\leftarrow \mathsf{Setup}(1^{\mathit{\lambda }},1^n),$ identities ${\mathsf{id}}_i\in {\{0,1\}}^n$ for $i\in [\ell ],$ every secret key ${\mathsf{sk}}_i\leftarrow \mathsf{KeyGen}(\mathsf{msk},{\mathsf{id}}_i)$ for $i\in [\ell ],$ an aggregated secret key $\widehat{\mathsf{sk}}\leftarrow \mathsf{KeyAgg}({\mathsf{sk}}_1,\dots ,{\mathsf{sk}}_{\ell })$ and a ciphertext ct $\leftarrow \mathsf{Enc}(\mathsf{mpk},{\mathsf{id}}_i,m)$. Furthermore, $m\leftarrow \mathsf{AggDec}(\widehat{\mathsf{sk}},({\mathsf{id}}_1,\dots ,{\mathsf{id}}_{\ell }),\mathsf{ct},j)$ for all $j\in [\ell ]$, every message $m\leftarrow \mathcal{M}$.

Definition 3

(Security of IBE [15]). The security of IBE scheme is defined as follows:

• Setup: The challenger runs Setup($1^{\mathit{\lambda }}$, $1^n$) to obtain a public key $\mathsf{pk}$. It gives $\mathcal{A}$ the public key pk.
• Phase I: The adversary $\mathcal{A}$ requests ${\mathsf{sk}}_{{\mathsf{id}}_i}$ for $i\in \{1,\dots ,q_1\}$.
• Challenge: If Phase I is over, the adversary$\mathcal{A}$ sends messages $m_0$ and $m_1$ with the challenge identity $\mathsf{id}*$ to the challenger where $\mathsf{id}*$ was not queried in Phase I. Furthermore, the challenger chooses a random binary β and runs Enc algorithm to calculate ${\mathsf{ct}}_{\mathsf{id}*}$ = Enc($m_{\beta }$, $\mathsf{id}*$, pk) and returns (${\mathsf{ct}}_{\mathsf{id}*}$) to $\mathcal{A}$.
• Phase II: The adversary $\mathcal{A}$ continues to requests private keys ${\mathsf{sk}}_{{\mathsf{id}}_i}$ for $i\in \left[q\right]\backslash \left[q_1\right]$. For every pair ${\mathsf{id}}_i$ such that ${\mathsf{id}}_i\ne \mathsf{id}*$, it returns ${\mathsf{sk}}_{{\mathsf{id}}_i}$ to the adversary.
• Guess: Finally, the adversary $\mathcal{A}$ outputs a guess $b^{\prime }\in \{0,1\}$ and wins the game if $b=b^{\prime }$.

We define the advantage of the adversary $\mathcal{A}$ to win in the game as following:

$${\mathit{AdvIBE}}_{\mathcal{A},n}\left(\mathit{\lambda }\right)=|Pr[b=b^{\prime }]-\frac{1}{2}|.$$

Static security is a weaker notion of security. In static security, the adversary lets the challenger know all the identities to be queried and the challenge identity $\mathsf{id}*$ before Setup. We use AdvIBE${}_{\mathcal{A},n}^{Static}\left(\mathit{\lambda }\right)$ to denote the static security of IBE.

4. Our Method

The objective of our scheme is to build a more practical revocation system that supports ciphertext update and backward compatibility of the private key. Figure 1 depicts the backward compatibility that our scheme pursues. In the figure, tag${}_i$ implies a tag allocated for the ith time slot. The private key sk${}_{\mathsf{id},i}$ of an identity $\mathsf{id}$ for the time slot i can decrypt the ciphertext for the current time slot, ct${}_{\mathsf{id},i}$ and all past ciphertexts, ct${}_{\mathsf{id},j}$ for $j<i$. However, it cannot decrypt ciphertexts for future time slots.

Our scheme is using a polynomial function to control access. Using a polynomial function is more popular for the variant of IBE, which is Identity-Based Broadcast Encryption (IBBE) [27,28,29]. IBBE is designed to share a single ciphertext for multiple users for broadcasting. As multiple identities are engaged in the encryption and decryption processes, it uses a polynomial function to handle this. In particular, in those schemes, the roots of a polynomial function are identities so it can be used to implement OR gates in the scheme.

In our scheme, a polynomial function is used differently. It has as its roots the identity of the recipient and tags that are uniquely allocated for time slots. So, one who can cancel out a polynomial function embedded in a ciphertext entirely using its private key that is associated with the identity and the tags can decrypt the ciphertext. It means that the polynomial function works in our scheme as AND gates.

For example, let a, $t_1$ and $t_2$ be the identity and the tags used for Alice, respectively. The ciphertext is constructed by using a polynomial function $P(a,t_1,t_2)=(x-a)(x-t_1)(x-t_2)$ (e.g., $g^{r·P(a,t_1,t_2)}$ where g is a group generator and r is a randomization parameter.) and Alice has a private key computed based on $1/P(a,t_1,t_2)$ (e.g., $g^{1/P(a,t_1,t_2)}$) at the second time slot. Therefore, Alice can decrypt the ciphertext using a pairing computation (e.g., $e(g^{r·P(a,t_1,t_2)},g^{1/P(a,t_1,t_2)})=e{(g,g)}^r$) using her key. Therefore, decryption is possible only for one who has a private key based on the inverse of the polynomial function given in the ciphertext.

For the revocation, we observed that, although a polynomial function is set in a ciphertext, it can be updated to become more restrictive. Using the previous example, if the following is given

$$(C=m·e{(g,g)}^r,C_2=g^{r·P(a,t_1,t_2)x^2},C_1=g^{r·P(a,t_1,t_2)x},C_0=g^{r·P(a,t_1,t_2)}).$$

To update the ciphertext with $t_3$, the tag for the third time slot is given, and one can update the ciphertext as

$$C^{\prime }=m·e{(g,g)}^r,C_2^{\prime }=R,C_1^{\prime }=C_2·C_1^{-t_3}=g^{r·P(a,t_1,t_2)(x-t_3)x}=g^{r·P(a,t_1,t_2,t_3)x},$$

$$C_0^{\prime }=C_1·C_0^{-t_3}=g^{rP(a,t_1,t_2)(x-t_3)}=g^{r·P(a,t_1,t_2,t_3)}$$

where R is a random value and $P(a,t_1,t_2,t_3)=(x-a)(x-t_1)(x-t_2)(x-t_3)$. This can be completed without any other secret parameter and does not need decryption. Moreover, once the new ciphertext is updated successfully, it cannot go back.

For the updated ciphertext, all previous keys such as $g^{1/P(a,t_1,t_2)}$ are no longer valid as they cannot completely divide the polynomial function given in the ciphertext due to $(x-t_3)$. Therefore, they are revoked. However, the newly generated key at the time $t_3$ can be used for all previous ciphertexts by executing the update process locally. Therefore, this method can be used to guarantee backward compatibility.

To prove the security of our scheme, we utilize aggregate identity-based encryption (AIBE). AIBE was introduced by Goyal and Vaikuntanathan [15]. Their scheme is used for a system that maintains multiple private keys. It uses the key accumulate algorithm, called DPP, from Delerablée, Paillier and Pointcheval [30,31] to aggregate multiple keys such as ${\{g^{1/(x-a_i)},a_i\}}_{i\in [\ell ]}$ into a single key $g^{1/(x-a_1)(x-a_2)\cdots (x-a_{\ell })}$. Our scheme does not need key aggregation as a private key can be updated directly by a key-update key. However, it is still useful to prove the security of BC-IBE, as we can query the private keys and use them to form a key-update key without knowing the master secret.

Before we present our main construction, we provide the formal definitions of our BC-IBE and its security models in the following subsections.

4.1. Definition of BC-IBE

Using the notion of identity-based encryption, we provide the definition of Backward Compatible Identity-Based Encryption (BC-IBE). Our BC-IBE consists of seven algorithms, Setup, UpdateKeyGen, KeyGen, KeyUpdate, Enc, EncUpdate, and Dec, as defined below:

• Setup($1^{\mathit{\lambda }}$, $1^{n_1}$, $1^{n_2}$, $1^{n_3}$) $\to (\mathsf{pk},\mathsf{msk})$: takes as input the security parameter $\mathit{\lambda }$, the identity length $n_1$, the tag length $n_2$ and the maximum number of updates $n_3$. It outputs a public key $\mathsf{pk}$ and a master secret key $\mathsf{msk}$.
• UpdateKeyGen($({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_{\ell }),\mathsf{id},\mathsf{msk})\to \left({\mathsf{usk}}_{\mathsf{id},\ell }\right)$: takes as input a sequence of tags ${\mathsf{tag}}_i\in {\{0,1\}}^{n_2}$ for $i\in [\ell ]$, an identity id $\in {\{0,1\}}^{n_1}$ and the secret key msk. It outputs a key-update key usk${}_{\mathsf{id},\ell }$.
• KeyGen($\mathsf{id}$, msk) $\to {\mathsf{sk}}_{\mathsf{id},0}$: takes as input an identity $\mathsf{id}$ and the master secret key $\mathsf{msk}$. It outputs a private key ${\mathsf{sk}}_{\mathsf{id},0}$.
• KeyUpdate(${\mathsf{sk}}_{\mathsf{id},j-1}$, usk${}_{\mathsf{id},j})\to {\mathsf{sk}}_{\mathsf{id},j}$: takes as input the private key ${\mathsf{sk}}_{\mathsf{id},j-1}$ and the update key ${\mathsf{usk}}_{\mathsf{id},j}$ for $j\le n_3$. It outputs a private key ${\mathsf{sk}}_{\mathsf{id},j}$.
• Enc(m, $\mathsf{id}$, pk) $\to {\mathsf{ct}}_0$: takes as input a message $m\in \mathcal{M}$, an identity $\mathsf{id}\in {\{0,1\}}^{n_2}$, and a public key pk. It outputs a ciphertext ${\mathsf{ct}}_0$.
• EncUpdate(pk, ${\mathsf{ct}}_{\mathsf{id},j-1}$, $\mathsf{id},({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_j$)) $\to {\mathsf{ct}}_{\mathsf{id},j}$: takes as input the ciphertext ${\mathsf{ct}}_{\mathsf{id},j-1}$, an identity $\mathsf{id}$, a sequence of tags $({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_j)$. The algorithm outputs the updated ciphertext ${\mathsf{ct}}_{\mathsf{id},j}$.
• Dec(${\mathsf{sk}}_{\mathsf{id},i},{\mathsf{ct}}_{\mathsf{id},j}$) $\to m/\perp$: takes as input a private key ${\mathsf{sk}}_{\mathsf{id},i}$, a ciphertext ${\mathsf{ct}}_{\mathsf{id},j}$. It outputs the message m or aborts.

• Correctness. For the correctness of a BC-IBE scheme, the following property must be satisfied: for all $\mathit{\lambda },n_1,n_2,n_3\in \mathbb{N}$, let $(\mathsf{pk},\mathsf{msk})\leftarrow \mathsf{Setup}(1^{\mathit{\lambda }},1^{n_1},1^{n_2},1^{n_3})$, ${\mathsf{sk}}_{\mathsf{id},0}\leftarrow \mathsf{KeyGen}(\mathsf{id},\mathsf{msk})$ for every identity $\mathsf{id}\in {\{0,1\}}^{n_1}$ and ${\mathsf{ct}}_{\mathsf{id},0}\leftarrow \mathsf{Enc}(m,\mathsf{id},\mathsf{pk})$. $m\leftarrow \mathsf{Dec}({\mathsf{sk}}_{\mathsf{id},0},{\mathsf{ct}}_{\mathsf{id},0}$) for every message m.
• Correctness for updated ciphertexts and keys. For correctness for updated ciphertexts and keys of a BC-IBE scheme, the following property must be satisfied: for all $\mathit{\lambda },n_1,n_2,n_3\in \mathbb{N}$, let $(\mathsf{pk},\mathsf{msk})\leftarrow \mathsf{Setup}(1^{\mathit{\lambda }},1^{n_1},1^{n_2},1^{n_3})$, ${\mathsf{sk}}_{\mathsf{id},0}\leftarrow \mathsf{KeyGen}(\mathsf{id},\mathsf{msk})$ for every identity $\mathsf{id}\in {\{0,1\}}^{n_1}$. For the update keys, let ${\mathsf{usk}}_{\mathsf{id},i}\leftarrow \mathsf{Update\; KeyGen}(({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_i),\mathsf{id},\mathsf{msk})$ with tags ${\mathsf{tag}}_1,\dots {\mathsf{tag}}_i\in {\{0,1\}}^{n_2}$ for any $i\le n_3$ and sk${}_{\mathsf{id},i}\leftarrow \mathsf{KeyUpdate}({\mathsf{sk}}_{\mathsf{id},i-1},{\mathsf{usk}}_{\mathsf{id},i})$ that is repeatedly computed. Furthermore, let ${\mathsf{ct}}_{\mathsf{id},0}\leftarrow \mathsf{Enc}(m,\mathsf{id},\mathsf{pk})$ and ${\mathsf{ct}}_{\mathsf{id},j}\leftarrow \mathsf{EncUpdate}(\mathsf{pk},{\mathsf{ct}}_{\mathsf{id},j-1},\mathsf{id},({\mathsf{tag}}_1,$$...,{\mathsf{tag}}_j\left)\right)$ for $j\le n_3$. Furthemore, $m\leftarrow \mathsf{Dec}({\mathsf{sk}}_{\mathsf{id},i},{\mathsf{ct}}_{\mathsf{id},j}$) for all $j\le i$ for every message m.

4.2. Security of BC-IBBE

We define the security of our BC-IBE scheme as follows:

• Setup: The challenger runs Setup($1^{\mathit{\lambda }}$, $1^{n_1}$, $1^{n_2}$, $1^{n_3}$) to obtain a public key $\mathsf{pk}$. It gives $\mathcal{A}$ the public key pk.
• Phase I: The adversary $\mathcal{A}$ issues the following queries to the challenger:
  • For $i\in \left[q_1\right]$, it requests ${\mathsf{sk}}_{{\mathsf{id}}_i,0}$.
  • For $i\in \left[q_1\right]$, the challenger sets ${\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_k\in {\{0,1\}}^{n_2}$ for $k\in \left[n_3\right]$ and it requests ${\mathsf{usk}}_{{\mathsf{id}}_i,k}$ for $({\mathsf{id}}_i,{\left\{{\mathsf{tag}}_j\right\}}_{j\in \left[k\right]})$.
  For each query, the challenger returns the resulting key to the adversary.
• Challenge: When Phase I is over, the adversary $\mathcal{A}$ sends messages $m_0$ and $m_1$ with a challenge of identity id$*$ and tags, $({\mathsf{tag}}_1^{*},\dots ,{\mathsf{tag}}_{\ell }^{*})$ in that the pair $(\mathsf{id}*,{\mathsf{tag}}_{\ell }^{*})$ has never been queried together in Phase I to the challenger. The challenger chooses a random binary $\beta$ and runs the Enc algorithm to compute ${\mathsf{ct}}_{\mathsf{id}*,0}$ = Enc($m_{\beta }$, $\mathsf{id}*$, pk), and then it updates the ciphertext ${\mathsf{ct}}_{\mathsf{id}*,0}$ to the ciphertext ${\mathsf{ct}}_{\mathsf{id}*,j}$ using EncUpdate by executing consecutively EncUpdate$(\mathsf{pk},{\mathsf{ct}}_{\mathsf{id}*,i-1},\mathsf{id}*,({\mathsf{tag}}_1^{*},\dots ,{\mathsf{tag}}_i^{*}))$ for $i\in [\ell ]$. The challenger returns (${\mathsf{ct}}_{\mathsf{id}*,\ell }$) to $\mathcal{A}$.
• Phase II: The adversary $\mathcal{A}$ continues to issue the following queries:
  • For $i\in \left[q\right]\backslash \left[q_1\right]$, it requests ${\mathsf{sk}}_{{\mathsf{id}}_i,0}$.
  • For $i\in \left[q\right]\backslash \left[q_1\right]$, the challenger sets ${\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_k\in {\{0,1\}}^{n_2}$ such that $k\in \left[n_3\right]$ and it requests ${\mathsf{usk}}_{{\mathsf{id}}_i,k}$ for $({\mathsf{id}}_i,{\left\{{\mathsf{tag}}_j\right\}}_{j\in \left[k\right]})$ with the restriction that the challenge pair $(\mathsf{id}*,{\mathsf{tag}}_{\ell }^{*})$ cannot be queried.
  For each query, the challenger forwards the resulting key to the adversary.
• Guess: Finally, the adversary $\mathcal{A}$ outputs a guess $b^{\prime }\in \{0,1\}$ and wins the game if $b=b^{\prime }$.

We define the advantage of the adversary $\mathcal{A}$ to win in the game as follows:

$$\mathit{AdvBC}-{\mathit{IBE}}_{\mathcal{A},n}\left(\mathit{\lambda }\right)=|Pr[b=b^{\prime }]-\frac{1}{2}|.$$

Static security is the weaker security notion of BC-IBE by adding the step that the adversary lets the challenger know all identities and tags to be queried before Setup (i.e., before requesting any parameters from the challenger). We use AdvBC-IBE${}_{\mathcal{A},n}^{Static}\left(\mathit{\lambda }\right)$ to denote the advantage of the adversary in the static security model.

5. Our Result

5.1. Our Construction

Let $\mathcal{G}(\mathit{\lambda }$) be an algorithm that outputs bilinear group parameters $\langle \mathbb{G},{\mathbb{G}}_T,e\rangle$, where $\mathbb{G}$ and ${\mathbb{G}}_T$ are of order p, and $e:\mathbb{G}\times \mathbb{G}\to {\mathbb{G}}_T$. Let g and $e(g,g)$ be generators of $\mathbb{G}$ and ${\mathbb{G}}_T$, respectively. With a collision-resistant hash algorithm $H:{\{0,1\}}^{n_1}\times {\{0,1\}}^{n_2}\to {\mathbb{Z}}_p$ where $n_1$ and $n_2$ are the lengths of identities and tags, respectively. Furthermore, $n_3$ is the maximum number of updates. The construction of our BC-IBE scheme is as follows:

• Setup$(1^{\mathit{\lambda }},1^{n_1},1^{n_2},1^{n_3})\to (\mathsf{pk},\mathsf{msk})$ takes the security parameter $\mathit{\lambda }$ as input and the sizes of identities ($n_1$) and tags ($n_2$) together with the maximum number of the key updates ($n_3$). Furthermore, the algorithm generates the bilinear group $\langle p,\mathbb{G},{\mathbb{G}}_T,g,e\rangle \leftarrow \mathcal{G}\left(1^{\mathit{\lambda }}\right)$. It randomly chooses parameters $\alpha$ and $\beta$ in ${\mathbb{Z}}_p$ and hk $\leftarrow \mathsf{HGen}\left(1^{\mathit{\lambda }}\right)$ where hk is a parameter for the identity hash algorithm. It sets a public key pk $:=(\mathsf{hk},g,{\left\{g^{{\beta }^i}\right\}}_{i\in \left[n_3\right]},g^{\alpha })$ and a private key msk $:=(\mathsf{hk},\alpha ,\beta )$.
• UpdateKeyGen($({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_{\ell }),\mathsf{id},\mathsf{msk})\to \left({\mathsf{usk}}_{\mathsf{id},\ell }\right)$: takes the set of tags $({\mathsf{tag}}_1,\dots {\mathsf{tag}}_{\ell })$ as inputs, an identity $\mathsf{id}$ and the master secret key msk. It sets $h_{\mathsf{id},i}=H(\mathsf{hk},\mathsf{id},{\mathsf{tag}}_i)$ for $i\in [\ell ]$. It sets ${\mathsf{usk}}_{\mathsf{id},\ell }=g^{\alpha /((\beta +h_{\mathsf{id},0})\cdots (\beta +h_{\mathsf{id},\ell }))-\alpha /((\beta +h_{\mathsf{id},0})\cdots (\beta +h_{\mathsf{id},\ell -1}))}$ where $h_{\mathsf{id},0}=H(\mathsf{hk},\mathsf{id},0)$ for $1\le \ell$. It outputs ${\mathsf{usk}}_{\mathsf{id},\ell }$.
• KeyGen(id, msk) $\to {\mathsf{sk}}_{\mathsf{id},0}$: The key generation algorithm takes the identity id and the master secret key msk. It then outputs ${\mathsf{sk}}_{\mathsf{id},0}=g^{\alpha /(\beta +h_{\mathsf{id},0})}$ where $h_{\mathsf{id},0}=H(\mathsf{hk},\mathsf{id},0)$.
• KeyUpdate(${\mathsf{sk}}_{\mathsf{id},\ell -1}$, ${\mathsf{usk}}_{\mathsf{id},\ell }$) $\to {\mathsf{sk}}_{\mathsf{id},\ell }$: The key generation algorithm takes the latest updated key ${\mathsf{usk}}_{\mathsf{id},\ell }$ and the secret key ${\mathsf{sk}}_{\mathsf{id},\ell -1}$ for $1\le \ell$. It updates the secret key

  $${\mathsf{sk}}_{\mathsf{id},\ell }={\mathsf{sk}}_{\mathsf{id},\ell -1}·{\mathsf{usk}}_{\mathsf{id},\ell }.$$
  It should be noted that the above equation results in ${\mathsf{sk}}_{\mathsf{id},\ell }=g^{\alpha /{\prod }_{i=0}^{\ell }(\beta +h_{\mathsf{id},\ell })}$. It returns ${\mathsf{sk}}_{\mathsf{id},\ell }$.
• Enc$(m,\mathsf{pk},\mathsf{id})\to {\mathsf{ct}}_{\mathsf{id},0}$: The encryption algorithm takes a message m, a public key $\mathsf{p}\mathsf{k}$ and an identity $\mathsf{id}$. It randomly selects a random value $r\in {\mathbb{Z}}_p$ and computes $h_{\mathsf{id},0}=H(\mathsf{hk},\mathsf{id},0)$. It, then, sets the following as the ciphertext ct:

  $$C_i:=g^{r(\beta +h_{\mathsf{id},0}){\beta }^i},C_T:=m·e{(g,g)}^{\alpha ·r}$$
  It outputs $\mathsf{ct}:=({\left\{C_i\right\}}_{i=0}^{n_3},C_T)$.
• EncUpdate$(\mathsf{pk},{\mathsf{ct}}_{\mathsf{id},\ell -1},\ell ,\mathsf{id},({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_{\ell }))\to \left({\mathsf{ct}}_{\mathsf{id},\ell }\right)$: The re-encryption algorithm takes a public key $\mathsf{pk}$ and a ciphertext ${\mathsf{ct}}_{\mathsf{id},\ell -1}$ and the identity id and a sequence of the tags $({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_{\ell })$. It randomly selects a random value $r^{\prime }\in {\mathbb{Z}}_p$ and computes $(h_{\mathsf{id},0},h_{\mathsf{id},1},\dots ,h_{\mathsf{id},\ell })=(H(\mathsf{hk},\mathsf{id},\mathsf{0}),H(\mathsf{hk},\mathsf{id},{\mathsf{tag}}_1)$$,\dots ,H(\mathsf{hk},\mathsf{id},{\mathsf{tag}}_{\ell }))$. It computes $(a_0,a_1,\dots ,a_{\ell +1})$ where $a_j$ is the coefficient of $x^j$ in the polynomial function $(x+h_{\mathsf{id},0})(x+h_{\mathsf{id},1})(x+h_{\mathsf{id},2})\cdots (x+h_{\mathsf{id},\ell })$. It computes $C_i^{″}={\left\{g^{{\sum }_{j=0}^{\ell +1}{a}_j·{\beta }^{i+j}}\right\}}_{i=0}^{n_3-\ell }$.
  It sets $C_T^{\prime }:=C_T·e{(g,g)}^{\alpha r^{\prime }}$. For all $i\in [n_3-\ell ]$,

  $$C_i^{\prime }:=C_{i+1}·{C_i}^{h_{\mathsf{id},i}}·C_i^{″}$$
  For all i such that $n_3-\ell <i\le n_3$, it randomly selects $R_i\in \mathbb{G}$ also sets $C_i^{\prime }:=C_i·R_i$. It outputs the updated ciphertext:

  $${\mathsf{ct}}_{\mathsf{id},\ell }=:({\left\{C_i^{\prime }\right\}}_{i=0}^{n_3},C_T^{\prime })$$
• Dec(${\mathsf{sk}}_{\mathsf{id},\ell },{\mathsf{ct}}_{\mathsf{id},j},({\mathsf{tag}}_1,\dots ,{\mathsf{tag}}_{\ell }),j,\mathsf{hk})\to \left(m\right)$: The decryption algorithm takes the secret key ${\mathsf{sk}}_{\mathsf{id},\ell }$ and the ciphertext ${\mathsf{ct}}_{\mathsf{id},j}$ of $\mathsf{id}$ and the tags $\{{\mathsf{tag}}_1,\dots {\mathsf{tag}}_{\ell }\}$. Furthermore, we set coefficient $a_i$ as follows:

  –

  If $j=\ell$, $a_0=1$.

  –

  If $j<\ell$, for all $i\in \{0,\dots ,\ell -j\}$, $a_i$ is the coefficients of $x^i$ of the polynomial $(x+h_{\mathsf{id},j+1})\cdots (x+h_{\mathsf{id},\ell })$ where $h_{\mathsf{id},j}=H(\mathsf{hk},\mathsf{id},{\mathsf{tag}}_j)$.

  It, then, parses ${\mathsf{ct}}_{\mathsf{id},j}$ to $C_0\dots C_{n_3}$ and $C_T$ and computes

  $$m=C_T·e{(\prod _{i=0}^{\ell -j}{C_i}^{a_i},{\mathsf{sk}}_{\mathsf{id},\ell })}^{-1}.$$

• Correctness. By the definition, $C_0=g^{r(\beta +h_{\mathsf{id},0})}$, $s{k}_{\mathsf{id},0}=g^{\alpha /(\beta +h_{\mathsf{id},0})}$ and $C_T=m·e{(g,g)}^{\alpha r}$. Therefore,

  $$\begin{array}{cc}\hfill C_T·e{(C_0,{\mathsf{sk}}_{\mathsf{id},0})}^{-1}& =m·e{(g,g)}^{\alpha r}·e{(g^{r·(\beta +h_{\mathsf{id},0})},g^{\alpha /(\beta +h_{\mathsf{id},0})})}^{-1}\hfill \\ \hfill & =m·e{(g,g)}^{\alpha ·r}·e{(g,g)}^{-\alpha ·r}\hfill \\ \hfill & =m\hfill \end{array}$$
• Correctness for updated ciphertexts and keys. For $j\le \ell$, by the definition, $C_j=g^{\widehat{r}{\prod }_{i=0}^j(\beta +h_{\mathsf{id},i})}$, $s{k}_{\mathsf{id},\ell }=g^{\alpha /{\prod }_{i=1}^{\ell }(\beta +h_{\mathsf{id},i})}$ and $C_T^{\prime }=m·e{(g,g)}^{\alpha ·\widehat{r}}$. First, we compute $a_i$ that is the coefficient of $x^i$ of the polynomial $(x+h_{\mathsf{id},j+1})\cdots (x+h_{\mathsf{id},\ell })$ for all $i\in \{0,\dots ,\ell -j\}$. Therefore,

  $$\begin{array}{cc}\hfill C_T^{\prime }·e{(\prod _{i=0}^{\ell -j}{C_i}^{a_i},{\mathsf{sk}}_{\mathsf{id},\ell })}^{-1}& =m·e{(g,g)}^{\alpha \widehat{r}}·e{(\prod _{i=0}^{\ell -j}{C}_i^{a_i},{\mathsf{sk}}_{\mathsf{id},\ell })}^{-1}\hfill \\ \hfill & =m·e{(g,g)}^{\alpha ·\widehat{r}}·e(g^{\widehat{r}·({\prod }_{i=0}^j(\beta +h_{\mathsf{id},i}))({\sum }_{i=0}^{\ell -j}{a}_i·{\beta }^i)},g^{\alpha /{\prod }_{i=0}^{\ell }(\beta +h_{\mathsf{id},i})})\hfill \\ \hfill & =m·e{(g,g)}^{\alpha ·\widehat{r}}·e(g^{\widehat{r}·({\prod }_{i=0}^{\ell }(\beta +h_{\mathsf{id},i}))},g^{\alpha /{\prod }_{i=0}^{\ell }(\beta +h_{\mathsf{id},i})})\hfill \\ \hfill & =m·e{(g,g)}^{\alpha ·\widehat{r}}·e{(g,g)}^{-\alpha ·\widehat{r}}\hfill \\ \hfill & =m\hfill \end{array}$$

Theorem 1.

Our BC-IBE is static secure under (q-DBDHI) assumption.

Proof. 

We will show the security of our BC-IBE using Lemma 1 in our security analysis. It will be proven to be secure by showing the oracles simulating the security of the AIBE from Goyal and Vaikuntanathan are invariant. Therefore, it will have the same security that AIBE has. □

5.2. Security Analysis

We utilize Goyal and Vaikuntanathan’s AIBE (see Appendix A) to prove our scheme. Their AIBE scheme is static secure and its static security is proven under q-DBDHI assumption in a random oracle model. In our scheme, we also show that our scheme is secure via the security of the AIBE scheme.

To use the AIBE scheme for the security proof of BC-IBE, we define two indistinguishable oracles $\mathcal{O}$${}_{\mathit{AIBE}}^0$ and $\mathcal{O}$${}_{\mathit{AIBE}}^1$ that simulate the static security of AIBE. First, we define $\mathcal{O}$${}_{\mathit{AIBE}}^0$ as follows:

• Setup(1${}^{\mathit{\lambda }}$, 1${}^n$, id$*$) $\to \left(\mathsf{mpk}\right)$: takes as input the security parameter $\mathit{\lambda }$, the identity length n. It returns the public parameters $\mathsf{mpk}=(\mathsf{hk},{\{g^{{\beta }^i}\}}_{i\in \left[n\right]})$ where hk  $\leftarrow \mathsf{HGen}\left(1^{\mathit{\lambda }}\right)$ is a parameter for the hash algorithm for identities H (i.e., $H(\mathsf{hk},\mathsf{id})=h_{\mathsf{id}})\in {\mathbb{Z}}_p$).
• Query($\mathsf{id}\in {\{0,1\}}^n\backslash \{\mathsf{id}*\}$) $\to \left({\mathsf{sk}}_{\mathsf{id}}\right)$: When a secret key sk${}_{\mathsf{id}}$ for the identity $\mathsf{id}\in {\{0,1\}}^n$ is requested, it returns a private key ${\mathsf{sk}}_{\mathsf{id}}=g^{{(\beta +h_{\mathsf{id}})}^{-1}}$ where $h_{\mathsf{id}}=H(\mathsf{hk},\mathsf{id})$.
• Challenge$(m_0,m_1,\mathsf{id}*,\mathsf{mpk}$) $\to \left({\mathsf{ct}}_{\mathsf{id}*}\right)$ takes as input messages $m_0,m_1\in \mathcal{M}$, an identity $\mathsf{id}*\in \{0,1\}$, and the public parameters $\mathsf{mpk}$. It randomly selects $b\in \{0,1\}$ and outputs the challenge ciphertext

  $${\mathsf{ct}}_{\mathsf{id}*}=({\{g^{r(\beta +h_{\mathsf{id}*}){\beta }^i}\}}_{i=0}^n,m_b·e{(g,g)}^r)$$

  where r is a randomly selected value in ${\mathbb{Z}}_p$.

The oracle $\mathcal{O}$${}_{\mathit{AIBE}}^1$ is defined identically except that $m_b$ in ct${}_{\mathsf{id}*}$ is replaced by a random message in $\mathcal{M}$. It should be noted that the oracles $\mathcal{O}$${}_{\mathit{AIBE}}^0$ and $\mathcal{O}$${}_{\mathit{AIBE}}^1$ are indistinguishable under $q-DBDHI$ assumption in the random oracle model by the static security of Aggregate IBE in [15].

Lemma 1.

Suppose there is a PPT algorithm $\mathcal{A}$ that breaks the static security of BC-IBE with non-negligible probability ϵ. Furthermore, we can build an algorithm $\mathcal{B}$ that distinguishes between $\mathcal{O}$${}_{\mathit{AIBE}}^0$ and $\mathcal{O}$${}_{\mathit{AIBE}}^1$ using $\mathcal{A}$ with ϵ.

Proof. 

We are going to prove the static security of our BC-IBE scheme using the indistinguishability between $\mathcal{O}$${}_{\mathit{AIBE}}^0$ and $\mathcal{O}$${}_{\mathit{AIBE}}^1$ as follows:

• Before Setup, for the initialization, the challenger sets the identities to be queried and the maximum number of updates $n_3$. It also chooses the identity to be challenged, $\mathsf{id}*$ and the number of updates to be challenged for $\mathsf{id}*$, which is ${\mathsf{tag}}_{\ell }^{*}$. The algorithm $\mathcal{B}$ sets a new identity space that is defined as

  $$\left\{\right\{{\mathsf{id}}_i\left|\right|{\mathsf{tag}}_{i,j}{\}}_{i\in \left[q\right],j\in \left[n_3\right]},\{\mathsf{id}*\left|\right|{\mathsf{tag}}_j{\}}_{j\in \left[n_3\right]}\}$$

  and the challenge identity $\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell }^{*}$. $\mathcal{B}$ sends them to the oracle (either $\mathcal{O}$${}_{\mathit{AIBE}}^0$ or $\mathcal{O}$${}_{\mathit{AIBE}}^1$) that it works with. The oracle uses this for the initialization by creating $n_1+n_2$ sized identity space (i.e., ${\{0,1\}}^{n_1+n_2}$ where $n_1$ and $n_2$ are the sizes of the identity and tag spaces, respectively. Through this process, $\mathcal{B}$ will break the static security of AIBE by distinguishing between $\mathcal{O}$${}_{\mathit{AIBE}}^0$ and $\mathcal{O}$${}_{\mathit{AIBE}}^1$ using $\mathcal{A}$.
• Setup: To create pk for $\mathcal{B}$. $\mathcal{B}$ requests a public key to the oracle, it works with. The oracle sends $(\mathsf{hk},{\{g^{{\beta }^i}\}}_{i\in \left[n\right]})$ back to $\mathcal{B}$. Furthermore, $\mathcal{B}$ randomly selects $\alpha$ and sends $(H,{\{g^{{\beta }^i}\}}_{i\in \left[n\right]},g^{\alpha })$ as pk where H is a random oracle hashing identities with hk $\leftarrow \mathsf{HGen}\left(1^{\mathit{\lambda }}\right)$ by concatenating an identity and a tag and taking it as input together with hk. (i.e., H(hk, id$\left|\right|$ tag)).
• Phase I/II: In this stage, $\mathcal{A}$ can query three types of queries and $\mathcal{B}$ responds it as follows:

• When $\mathcal{A}$ requests ${\mathrm{sk}}_{{\mathsf{id}}_i,0}$ for $i\in \left[q\right]$, $\mathcal{B}$ requests the private key for ${\mathrm{id}}_i\left|\right|0$ to the oracle. $\mathcal{B}$ receives ${\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|0}$ from the oracle. Furthermore, it sets ${\mathsf{sk}}_{{\mathsf{id}}_i,0}$ = ${({\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|0})}^{\alpha }$ and returns it to $\mathcal{A}$.
• When $\mathcal{A}$ requests usk${}_{{\mathsf{id}}_i,j}$ for ${\mathrm{id}}_i\left|\right|{\mathsf{tag}}_{i,j}$ for $i\in \left[q\right],j\in \left[n_3\right]$, $\mathcal{B}$ requests the a private key for ${\mathrm{id}}_i\left|\right|{\mathsf{tag}}_{i,j}$ to the oracle. $\mathcal{B}$ receives ${\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|{\mathsf{tag}}_{i,j}}$ from the oracle it works with. Furthermore, it computes $d_1=\mathsf{DPP}({\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|0},{\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|{\mathsf{tag}}_{i,1}},\dots ,{\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|{\mathsf{tag}}_{i,j-1}})$ and $d_2=\mathsf{DPP}({\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|0},{\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|{\mathsf{tag}}_{i,1}},\dots ,{\widehat{\mathsf{sk}}}_{{\mathsf{id}}_i\left|\right|{\mathsf{tag}}_{i,j}})$. It sets usk${}_{{\mathsf{id}}_i,j}={\left(d_2\right)}^{\alpha }-{\left(d_1\right)}^{\alpha }$ and returns it to $\mathcal{A}$ where the function DPP [30,31] is an aggregate algorithm that can aggregate multiple keys such as ${\{g^{1/(x+a_i)},a_i\}}_{i\in [\ell ]}$ into a single key $g^{1/(x+a_1)(x+a_2)\cdots (x+a_{\ell })}$.
• $\mathcal{A}$ also can request sk${}_{\mathsf{id}*\left|\right|\mathsf{0}}$ and usk${}_{\mathsf{id}*\left|\right|{\mathsf{tag}}_i^{*}}$ for $i\in [\ell -1]$ and also $\mathcal{B}$ can respond in the same way it responds above. They cannot query usk${}_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell }^{*}}$.

• Challege: When $\mathcal{A}$ requests the challenge ciphertext for $\mathsf{id}*$, $({\mathsf{tag}}_1^{*},\dots ,{\mathsf{tag}}_{\ell }^{*})$, $\mathcal{B}$ requests the challenge ciphertext of $\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell }^{*}$ to the oracle that it works with. The oracle will send the challenge ciphertext that is either a ciphertext for $m_b$ or a random message following:

  $$\mathsf{ct}=({\{g^{r(\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell }^{*}}){\beta }^i}\}}_{i=0}^{n_3},T)$$

  where T is either $m_b·e{(g,g)}^r$ or a random value $R\in {\mathbb{G}}_T$ according to the definition of the oracles. To create the challenge cipherttext for $\mathcal{A}$, $\mathcal{B}$ requests $(h_{\mathsf{id}*\left|\right|\mathsf{0}},h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_1^{*}},\dots ,h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell -1}^{*}})$ to the oracle it works with. It then, computes $a_0,\dots ,a_{\ell }$ where $a_i$ is a coefficient of $x^i$ of $(x+h_{\mathsf{id}*\left|\right|0})(x+h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_1^{*}})\cdots (x+h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell -1}^{*}})$.

  $$\begin{array}{cc}\hfill \mathsf{ct}& =(\{R_1,\dots ,R_{\ell },{\{g^{r(\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell }^{*}})(a_{\ell }{\beta }^{\ell }+\dots +a_1{\beta }^1+a_0){\beta }^i}\}}_{i=0}^{n_3-\ell }\},T)\hfill \\ \hfill & =(\{R_1,\dots ,R_{\ell },{\{g^{r(\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell }^{*}})(\beta +h_{\mathsf{id}*\left|\right|0})(\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_1^{*}})\cdots (\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell -1}^{*}}){\beta }^i}\}}_{i=0}^{n_3-\ell }\},T)\hfill \end{array}$$

  where $R_1,\dots ,R_{\ell }$ are random values in ${\mathbb{Z}}_p$ It, then, returns the challenge chiphertext to $\mathcal{A}$. The last equality of the above equation because, for all $i=\{0,1,\dots ,\ell \}$, $a_i$ is also the coefficient of ${\beta }^i$ of $(\beta +h_{\mathsf{id}*\left|\right|0})(\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_1^{*}})\cdots (\beta +h_{\mathsf{id}*\left|\right|{\mathsf{tag}}_{\ell -1}^{*}})$ by its definition.
• Guess: When $\mathcal{B}$ receives the answer from $\mathcal{A}$, it sends back the result to the oracle it works with. As $\mathcal{A}$ distinguishes if T encrypts a random message or $m_b$ with the non-negligible advantage $ϵ$, $\mathcal{B}$ also can use this advantage to distinguish between $\mathcal{O}$${}_{\mathit{AIBE}}^0$ and $\mathcal{O}$${}_{\mathit{AIBE}}^1$. □

5.3. Performance Evaluation

In this section, we compare the performance of our scheme with the other revocable identity-based encryption schemes in

Table 2. Efficiency Comparison with RIBE-parameter sizes. (n is the maximum number of backward-compatible ciphertexts. ℓ is the maximum number of users.)

	pk	sk with BC	ct
SE [9]	$(6+|ID\left|\right)|{\mathbb{G}}_p|$	$2n(log\ell )|{\mathbb{G}}_p|$	$3|{\mathbb{G}}_p|+|{\mathbb{G}}_T|$
LLP [17]	$6|{\mathbb{G}}_N|$ + $|{\mathbb{G}}_T|$	$n(lo{g}^{1.5}\ell )\left|{\mathbb{G}}_N\right|$	$4|{\mathbb{G}}_N|$
ESW [26]	$7|{\mathbb{G}}_1|$ + $11|{\mathbb{G}}_2|$ + $|{\mathbb{Z}}_p|$	$n(5log\ell )|{\mathbb{G}}_2|$	$4|{\mathbb{G}}_1|$ + $|{\mathbb{G}}_T|$ + $|{\mathbb{Z}}_p|$
Ours	$(n+2)|{\mathbb{G}}_p|$ + $|{\mathbb{Z}}_p|$	$|{\mathbb{G}}_p|$	$(n+1)|{\mathbb{G}}_p|$ + $|{\mathbb{G}}_T|$

and

Table 3. Efficiency Comparison with RIBE - Updating keys and # of pairing in Decryption (r is the number of revoked users. ℓ is the maximum number of users.

	Update Key	Decryption Key	# of Pairing in Dec
SE [9]	$\left(2rlog(\ell /r)\right)|{\mathbb{G}}_p|$	$3|{\mathbb{G}}_p|$	3 Pairings
LLP [17]	$4r|{\mathbb{G}}_N|$	$3|{\mathbb{G}}_N|$	3 Pairings + 10 Exp.
ESW [26]	$3rlog(\ell /r)\left)\right|{\mathbb{G}}_2|$	$6|{\mathbb{G}}_2|$	3 Pairings + 2 Exp.
Ours	$r|{\mathbb{G}}_p|$	$|{\mathbb{G}}_p|$	1 Pairing + r Exp.

. In revocable identity-based encryption schemes [9,17,26], backward compatibility is not supported. Therefore, we assume that they keep all previous keys for backward compatibility for n time periods.

As shown in those tables, our scheme has a very short private key (sk) even though it supports backward compatibility. In the existing scheme, the size of those keys increases in not only the number of keys it keeps for backward compatibility, (n) but also the total number of users (ℓ). Moreover, our key update processes are simple, it always needs a single key for each time period and sk is directly used as a decryption key. In all other schemes, the size of updating keys increases in the total number of users (ℓ).

Our scheme has relatively longer ciphertexts as it increases in the maximum number of updates and also the decryption needs n exponentiation computations although it only needs one pairing. However, the other RIBE does not support the updates. It needs decryption and re-encryption to update existing ciphertexts. This difference makes the size of the ciphertext larger but we believe that this is the cost of the functional enhancement. In addition, one may consider guaranteeing backward compatibility within reasonable time periods. With a smaller n, our scheme outperforms the other RIBE schemes in terms of decryption overhead.

Moreover, the size of the secret keys is often considered an expensive resource as it needs secure memory and is an extra burden for the management. Therefore, our proposed scheme can be used where the restriction of secure memory is severe.

6. Discussion and Conclusions

6.1. Discussion on Threats on Updating Ciphertexts

In our proposed scheme, the ciphertext update can be conducted by any third party without giving any private key. However, our update only makes the access policy applied to ciphertexts more restrictive because it always needs a newly established update key to be aggregated to a decryption key in addition to the keys already aggregated to the decryption key. Due to this, even one who has a malicious purpose cannot compromise the ciphertext through the update. The other potential threat is one makes ciphertexts inaccessible by updating them to an arbitrary identity. However, this means that the adversary has a writing privilege for the ciphertext because the update process needs to overwrite the previous ciphertext to the updated one. If the adversary already has the writing privilege, the adversary can compromise the availability of ciphertext anyway even without using the update algorithm. For example, it can overwrite ciphertext to any random elements using its privilege. Due to the reasons we explain above, we argue that the threats on updating ciphertext are reasonable and do not increase the attacker’s capability significantly.

6.2. Conclusions

In this paper, we introduce a new encryption system, which supports the backward compatibility property. Our proposed scheme allows for a user to keep a single key allocated for the present time slot and this key can decrypt all ciphertexts created at past and present time slots. So, it is backward compatible. In addition, in our proposed scheme, ciphertexts can be updated for the new time slots without decryption. After it is updated, it cannot be decrypted using the past keys. Therefore, it naturally supports revocation. The ciphertext update process does not require any secret parameters in our scheme so that it can be delegated to a third party. We believe that this is helpful for cloud storage and server-aided IoT network where the synchronization of the data in a system matters.

We present our idea by setting a new definition of backward compatible identity-based encryption (BC-IBE) and its security model. Furthermore, we construct an efficient scheme that satisfies the backward compatibility property we previously described. We prove its security using the aggregate identity-based encryption scheme introduced by Goyal and Vaikuntanathan.

We provide an efficient scheme as the size of the private key is constant, but the length of the ciphertext of the proposed scheme increases linearly over the maximum number of updates. It would be interesting to reduce the size of ciphertexts for future work.