Keywords

1 Introduction

Though instant messaging systems are increasingly and widely used, email continues to be one of the mainstream methods to deliver information and data. At the same time, the advantages of cloud computing enable more enterprises and organizations to deploy their own cloud email systems over third-party cloud servers in a cheap and scalable way. The Radicati Group [29] reported that, in 2019, the total number of emails sent and received per day will exceed 293 billion, and the worldwide revenue of cloud business email will roughly achieve $35 billion. On the other hand, the contents of emails usually involve some sensitive information, such as personal credit card bills and the enterprise’s business contracts. Thus, ensuring the privacy and security of email messages has become customers’ primary requirement. Worse, in recent years, there have been various reports of massive leakage of email messages [32, 33]. This further aggravates customers’ concerns about email security. To this end, it has been strongly suggested that cloud emails should be sent in the encrypted form, and the cloud email server just needs to provide transportation service of delivering encrypted emails that can only be decrypted by those intended receivers.

OpenPGP [6] and S/MIME [24] are two main standards for encrypting emails with the public key encryption based on public key infrastructures (PKIs). These two protocols have co-existed more than two decades, and numerous efforts have been made to improve them in terms of security and efficiency [13, 19]. However, they still have failed to be widely adopted [1]. As pointed out by Ryan [25], this is mainly because that none of them can simultaneously meet the requirements of practicability and security. The major issue comes from that they both require an additional trusted certificate authority to manage all users’ certificates, e.g., certificate creation, storage and revocation.

The emergence of identity-based encryption (IBE) [27] eliminates the mandatory requirement for PKIs. It allows a user to derive his/her public key from any string, such as telephone number and email address. Consequently, a email sender just needs to maintain registered email addressees, rather than storing and verifying the certificate of the intended receiver. This greatly facilitates the use of encrypted emails, because customers are more accustomed to the idea that the intended email receiver is identified with a string easy to read and remember (e.g., email address), rather than a public key (e.g., certificate). Due to these advantages, IBE is considered to be an attractive solution for securing email communications. There have been some commercial encrypted cloud email systems that are built upon IBE, such as Proofpoint Email Protection [23] and DataMotion SecureEmail [9].

In practice, due to wide and mixed use of multiple mobile devices (e.g, smartphone, tablet and PC), customers’ long-term secret keys are more likely to get revealed than expected. For example, the malware might extract secret keys from mobile devices, customers might be lawfully enforced to submit their secret keys to law enforcement agencies, the cloud server might occasionally backup customers’ secret keys, and so on. Therefore, forward secrecy, which guarantees the security of those previously encrypted emails in the case that customers’ current secret keys are occasionally compromised, is vital for preserving customer confidentiality. It is considered to be an indispensable security property of encrypted email systems [30]. However, none of the above encrypted email systems have provided a mechanism of achieving forward secrecy.

Addressing the above problem is not trivial. Some early works [5, 26] tired to provide forward secrecy of encrypted email systems by periodically issuing short-time public/private key pairs for all users. This manner seriously relies on a highly-available communication channel to issue fresh secret keys, and thus is not robust. On the other hand, there have been some secure email protocols [8, 28] that employ Diffie-Hellman key exchange to capture forward secrecy. But they mandatorily require either the email sender/receiver and the email server or the email sender and receiver to be online simultaneously. This obviously does not match practical email communication scenario of store-and-forward, in which emails are firstly sent to the email server and cached, and then are delivered to the intended receiver when he/she is online.

Forward secure public key encryption [7, 35] enables us to capture the forward secrecy of encrypted email systems without interactions and frequent key distributions. With this kind of encryption scheme, each customer can evolve the secret key unidirectionally and periodically, and uses different secret keys during each time interval, while the public key remains unchanged. As a result, even if the current secret key is disclosed, those previously encrypted emails still remain secure. However, this method also has not been broadly approved. This is mainly because that it sacrifices usability for achieving forward secrecy. More precisely, when a customer’s secret key is updated to next time interval, he/she losses decryption capacity of all those unreceived encrypted emails. But, in practice, it is very common for customers to receive emails that were sent in previous time intervals due to unexpected reasons, such as network failure, whitelist in email and anonymous mixnets. Thus, how to achieve forward secrecy of encrypted cloud email systems without sacrificing practicality is still a challenging problem.

1.1 Our Contribution

In this paper, we focus on forward secure identity-based encryption scheme that can yield encrypted cloud email systems with practical forward secrecy. Specifically, our contribution is as follows:

  • We introduce a new cryptographic primitive named forward-secure puncturable identity-based encryption (fs-PIBE), and define its syntax and security notion. This primitive allows a customer to individually revoke the decryption capacity of those encrypted emails that have been received, while retaining the decryption capacity of those unreceived ones. Therefore, it is more practical than traditional forward secure IBE.

  • We propose a concrete construction of fs-PIBE scheme. Our scheme is proved to be secure under a well-studied complexity assumption in the standard model, and achieves constant size of ciphertext. Furthermore, we introduce a framework of encrypted cloud email systems based on fs-PIBE. It features of practical forward secrecy.

  • We present a theoretical analysis of the proposed fs-PIBE scheme in terms of computation cost and communication overhead. The analysis results indicate that, at the cost of acceptable storage cost, the proposed fs-PIBE construction captures desirable security guarantees without trading off usability.

1.2 Related Work

OpenPGP [6] and S/MIME [24] are the two most widely known encrypted email protocols, and are both built upon PKIs. That is, each customer’s public key is associated with a signed certificate, and customers’ software clients need to maintain and verify certificates of email servers and intended email receivers. It is too complicated for common customers to understand and use them. This is the main reason why they have failed to take off. Nonetheless, some efforts have made to improve their security, such as adding forward secrecy to OpenPGP [5], enhancing certificate transparency [25], fixing security pitfalls of encryption model [22], and so on.

Shamir [27] introduced the notion of IBE to avoid the issue of certificate management. It offers the possibility of using any string that can identify customers’ identities (e.g., email addresses) as their public keys, and was first instantiated by Boneh and Franklin [3]. Since then, a large number of IBE schemes have been proposed to improve its security, efficiency and scalability, such as fully secure IBE [31], tightly secure IBE [16] and hierarchical IBE [2]. Now there have been many commercial softwares [9, 23] that use these IBE schemes to build encrypted cloud email systems without PKIs. In addition, motivated by some specific application requirements of email communication, several new cryptographic primitives have been proposed for encrypted cloud email systems, such as identity-based broadcast proxy re-encryption [34] and public key encryption with keyword search [20].

To achieve the forward secrecy of encrypted email systems, early works focused on designing particular Diffie-Hellman key exchange protocols, and utilized the resulted session key to secure email communications. For example, Sun et al. [28] proposed two secure email protocols providing perfect forward secrecy. Their first protocol essentially is an ephemeral version of traditional Diffie-Hellman key exchange, and the second one was indicated to be flawed [10]. There are some other similar forward secure email protocols [8, 18]. Unfortunately, they either fail against active attacks, or require an interactive message exchange before securely transmitting emails.

In Eurocrypt 2003, Canetti et al. [7] proposed a forward secure public key encryption, and made it possible to achieve the forward secrecy of encrypted emails without interactions. In their scheme, the whole lifetime of the system is divided into multiple discrete time intervals, and each customer him/herself updates the secret key unidirectionally at the end of each time interval, while the public key remains unchanged. Consequently, each customer uses different secret keys during each time interval, and the disclosure of the current secret key does not affect the security of those previously encrypted emails. Their method is widely used to achieve forward secrecy of various other public key cryptographic primitives like forward secure IBE [35] and ring signature [17].

However, Green and Miers [14] recently pointed out that Canetti et al.’s [7] method is relatively blunt and not practical enough. Specifically, by updating the secret key, a customer can revoke the decryption capacity for a given time interval. But this also means that he/she losses access to all emails that were encrypted yet unreceived in this time interval. In other words, their manner fails to achieve revocation of decryption capacity of individual encrypted emails. They further proposed puncture encryption to overcome this problem. In their scheme, after a receiver decrypting a ciphertext, she/she immediately punctures the secret key with tags associated with the ciphertext. As a result, the punctured secret key will no longer be able to decrypt any ciphertext including these tags. By combining with a hierarchical IBE scheme [2], they presented a puncturable forward secure encryption scheme that captures fine-grained forward secrecy. But the ciphertext size of their scheme is linear with the size of attached tags, its security proof was conducted in the random oracle model. Their idea of achieving forward secrecy is quickly used to construct other forward secure cryptographic primitives, including forward secure proxy re-encryption [12], zero round-trip time key exchange with full forward secrecy [11, 15]. These forward secure puncturable encryption schemes naturally yield encrypted cloud email systems with more practical forward secrecy than previous ones, while all of them still require the support of PKIs.

1.3 Organization

The remainder of this paper is structured as follows: Sect. 2 reviews preliminaries. In Sect. 3, we formalize the syntax and security notion of fs-PIBE. Section 4 provides a concrete construction of fs-PIBE, and gives the security and efficiency analysis. In Sect. 5, we introduce a framework of encrypted cloud email systems based on fs-PIBE. Finally, we conclude this paper in Sect. 6.

2 Preliminaries

2.1 Notation

We use bold lowercase letters like \(\varvec{u}\) to represent vectors, and denote by [m] the positive integer set \(\{1,\ldots ,m\}\). For a binary string w, let |w| be its length and w[j] its j-th bit. Given a group \(\mathbb {G}_T\), let \(R\xleftarrow {\$}\mathbb {G}_T\) indicate uniformly sampling an element R from \(\mathbb {G}_T\) at random. PPT standards for probabilistic polynomial time.

2.2 Bilinear Map

Given a security parameter \(\kappa \in \mathbb {N}\), denote by \(\mathbb {G}\) and \(\mathbb {G}_T\) two multiplicative cyclic groups with a large prime order p in size of \(\kappa \). Let g be a random generator of \(\mathbb {G}\). These two groups \(\mathbb {G}\) and \(\mathbb {G}_T\) are said to be bilinear provided that there exists a map \(e:\mathbb {G}\times \mathbb {G}\rightarrow \mathbb {G}_T\) satisfying the following conditions:

  • Bilinearity. For any group elements \(h,w\in \mathbb {G}\) and integers \(x,y\in \mathbb {Z}_p\), it holds that \(e(h^x,w^y)=e(h,w)^{xy}\).

  • Non-degeneracy. It is required that \(e(g,g)\ne 1_{\mathbb {G}_T}\), where \(1_{\mathbb {G}_T}\) is the unit element of \(\mathbb {G}_T\).

  • Computability. Given any group elements \(h,w\in \mathbb {G}\), there exists an algorithm to efficiently compute e(hw).

For convenience of description, denote by \((\mathbb {G},\mathbb {G}_T,e,p,g)\) the bilinear groups defined as above.

2.3 Complexity Assumption

Given bilinear groups \((\mathbb {G},\mathbb {G}_T,e,p,g)\), let as be two integers randomly sampled from \(\mathbb {Z}_p\). The decisional q-BDHE problem defined over \((\mathbb {G},\mathbb {G}_T,e,p,g)\) is stated as follows: given \(\varvec{g}=(g,g^a,\ldots ,g^{a^q},g^{a^{q+2}},\ldots ,g^{a^{2q}},g^s,R)\in \mathbb {G}^{2q+1}\times \mathbb {G}_T\), decide either \(R=e(g,g)^{a^{q+1}s}\) or \(R\xleftarrow {\$} \mathbb {G}_T\). The advantage of an algorithm \(\mathcal {C}\) solving the decisional q-BDHE problem by outputting a bit \(\beta \in \{0,1\}\) is captured as

$$\begin{aligned} \textsf {Adv}_{\mathcal {C}}^{q\text {-BDHE}}(\kappa )&=\Big |\Pr \big [\mathcal {C}(\varvec{g}, R=e(g,g)^{a^{q+1}s})=0\big ] - \Pr \big [\mathcal {C}(\varvec{g},R\xleftarrow {\$} \mathbb {G}_2)=0\big ]\Big |. \end{aligned}$$

Definition 1

(Decisional q-BDHE Assumption [4]). The decisional q-BDHE assumption holds over \((\mathbb {G},\mathbb {G}_T,g,p,e)\) provided that for any PPT algorithm, its advantage of solving the decisional q-BDHE problem is a negligible function \(\mathsf {negl}(\kappa )\) of the security parameter \(\kappa \).

3 Forward-Secure Puncturable Identity-Based Encryption

3.1 Syntax of fs-PIBE

A forward-secure puncturable identity-based encryption scheme is a tuple of the following six PPT algorithms:

  • Setup\((\kappa ,\tau _{max},n)\): On input a security parameter \(\kappa \), the maximum number of time intervals \(\tau _{max}\) and the maximum number of tags allowed to attach to a ciphertext n, this algorithm outputs the public parameter \(\texttt {PP}\) and the master secret key \(\texttt {MSK}\).

  • KeyGen\((\texttt {PP},\texttt {MSK},\texttt {ID})\): On input the public parameter \(\texttt {PP}\), the master secret key \(\texttt {MSK}\) and an identity \(\texttt {ID}\), this algorithm outputs an initial secret key \(\texttt {SK}_{0,\emptyset }\) for \(\texttt {ID}\).

  • Puncture\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i-1}},\hat{t}_i)\): On input the public parameter \(\texttt {PP}\), a punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i-1}}\) on time interval \(\tau \) and a tag \(\hat{t}_i\), this algorithm outputs a new punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\).

  • Update\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\tau ')\): On input the public parameter \(\texttt {PP}\), a punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) on time interval \(\tau \) and a new time interval \(\tau '>\tau \) (\(\tau '\le \tau _{max}\)), this algorithm outputs a new updated secret key \(\texttt {SK}_{\tau ',\mathcal {P}_{i}}\).

  • Encrypt\((\texttt {PP},\texttt {ID},S,M,\tau )\): On input the public parameter \(\texttt {PP}\), a receiver’s identity ID, a tag set \(S=\{t_1,\ldots ,t_d\}\) \((d\le n)\), a message M to encrypt and a time interval \(\tau \), this algorithm outputs a ciphertext \(\texttt {CT}\), which is implicitly associated with S and \(\tau \).

  • Decrypt\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\texttt {CT})\): On input the public parameter \(\texttt {PP}\), a punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) on time interval \(\tau \) and a ciphertext \(\texttt {CT}\), this algorithm outputs the message M or a symbol \(\bot \) indicating a decryption failure.

Correctness. The correctness of fs-PIBE requires that, for any public parameter and master secret key \((\texttt {PP},\texttt {MSK})\leftarrow \textsf {Setup}(\kappa ,\tau _{max},n)\), any secret key \(\texttt {SK}_{0,\emptyset }\leftarrow \textsf {KeyGen}(\texttt {PP},\texttt {MSK},\texttt {ID})\), any tag sets \(S=\{t_1,\ldots ,t_d\}\) and \(\mathcal {P}=\{\hat{t}_1,\ldots ,\hat{t}_i\}\), any time interval \(\tau \), and any message M, it holds that

where \(\texttt {SK}_{\tau ,\emptyset }\leftarrow \textsf {Update}(\texttt {PP},\texttt {SK}_{0,\emptyset },\tau )\), and for each index j belonging to \(\{1,\ldots ,i\}\), \(\texttt {SK}_{\tau ,\mathcal {P}_{j}}\leftarrow \textsf {Puncture}(\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{j-1}},\hat{t}_j)\) and \(\mathcal {P}_j=\{\hat{t}_1,\ldots ,\hat{t}_j\}\).

The above correctness mandates that a non-punctured secret key \(\texttt {SK}_{\tau ,\emptyset }\) can decrypt any correct ciphertext. However, if it was punctured with tags belonging to \(\mathcal {P}_j\), then it cannot decrypt any ciphertext containing any tag in \(\mathcal {P}_j\).

3.2 Security Definition of fs-PIBE

Security for fs-PIBE is defined via the IND-PUN-ID-CPA game played between a challenger \(\mathcal {C}\) and an adversary \(\mathcal {A}\). We consider selective tag security of fs-PIBE, where the adversary \(\mathcal {A}\) is required to specify the challenge tag set before seeing the public parameter. The game has the following six phases.

Initialization. The adversary \(\mathcal {A}\) chooses a challenge tag set \(S^*=\{t_1^*,\ldots ,t_d^*\}\) and submits it to the challenger \(\mathcal {C}\).

Setup. In this phase, on input the security parameter \(\kappa \), a total number of time intervals \(\tau _{max}\) and a maximum number of tags n, the challenger \(\mathcal {C}\) performs the setup algorithm Setup\((\kappa ,\tau _{max},n)\rightarrow (\texttt {PP},\texttt {MSK})\), and forwards the public parameter PP to the adversary \(\mathcal {A}\). In addition, for each identity ID, the challenger \(\mathcal {C}\) maintain a tuple \((\texttt {ID},\texttt {SK}_{\tau ,\mathcal {P}_i},\mathcal {P}_{\texttt {ID}},\tau )\) recording the state of ID’s secret key. That is, the secret key \(\texttt {SK}_{\tau ,\mathcal {P}_i}\) is now on time interval \(\tau \), and has been punctured with tags in \(\mathcal {P}_{\texttt {ID}}\).

Query phase 1. The adversary \(\mathcal {A}\) is allowed to adaptively issue the following queries:

  • \(\mathcal {Q}_{punc}(\texttt {ID},\hat{t})\): Given an identity ID and a tag \(\hat{t}\), the challenger \(\mathcal {C}\) checks if there exists a tuple \((\texttt {ID},\texttt {SK}_{\tau ,\mathcal {P}_{i-1}},\mathcal {P}_{\texttt {ID}},\tau )\). If yes, it directly performs the algorithm Puncture\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i-1}},\hat{t})\rightarrow \texttt {SK}_{\tau ,\mathcal {P}_{i}}\), and replaces the original tuple with \((\texttt {ID},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\mathcal {P}_{\texttt {ID}}\cup \{\hat{t}\},\tau )\). Otherwise, it successively runs the algorithms KeyGen\((\texttt {PP},\texttt {MSK},\texttt {ID})\rightarrow \texttt {SK}_{0,\emptyset }\) and Puncture\((\texttt {PP},\texttt {SK}_{0,\emptyset },\hat{t})\rightarrow \texttt {SK}_{0,\mathcal {P}_{1}}\), and further creates a new tuple \((\texttt {ID},\texttt {SK}_{0,\mathcal {P}_{1}},\{\hat{t}\},0)\).

  • \(\mathcal {Q}_{update}(\texttt {ID},\tau ')\): Given an identity ID and a time interval \(\tau '\), the challenger \(\mathcal {C}\) checks if there exists a tuple \((\texttt {ID},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\mathcal {P}_{\texttt {ID}},\tau )\) (\(\tau <\tau '\)). If yes, it directly runs the algorithm Update\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\tau ')\rightarrow \texttt {SK}_{\tau ',\mathcal {P}_{i}}\), and replaces the original tuple with \((\texttt {ID},\texttt {SK}_{\tau ',\mathcal {P}_{i}},\mathcal {P}_{\texttt {ID}},\tau ')\). Otherwise, it successively runs the algorithms KeyGen\((\texttt {PP},\texttt {MSK},\texttt {ID})\rightarrow \texttt {SK}_{0,\emptyset }\) and Update\((\texttt {PP},\texttt {SK}_{0,\emptyset },\tau )\rightarrow \texttt {SK}_{\tau ,\emptyset }\), and creates a new tuple \((\texttt {ID},\texttt {SK}_{\tau ,\emptyset },\emptyset ,\tau )\).

  • \(\mathcal {Q}_{corrupt}(\texttt {ID})\): Given an identity ID, the challenger \(\mathcal {C}\) checks if there exists a tuple \((\texttt {ID},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\mathcal {P}_{\texttt {ID}},\tau )\). If yes, it directly returns \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) to the adversary \(\mathcal {A}\). Otherwise, it runs the algorithm KeyGen\((\texttt {PP},\texttt {MSK},\texttt {ID})\rightarrow \texttt {SK}_{0,\emptyset }\), and returns \(\texttt {SK}_{0,\emptyset }\) to the adversary \(\mathcal {A}\). In addition, it creates a new tuple \((\texttt {ID},\texttt {SK}_{0,\emptyset },\emptyset ,0)\).

Challenge. The adversary \(\mathcal {A}\) selects two messages \(M_0\) and \(M_1\), a time interval \(\tau ^*\) as well as an identity \(\texttt {ID}^*\), and submits them to the challenger \(\mathcal {C}\). If the adversary \(\mathcal {A}\) has issued a corruption query with respect to \((\texttt {ID}^*,\texttt {SK}_{\tau ,\mathcal {P}_{i}},\mathcal {P}_{\texttt {ID}^*},\tau )\) such that \(\mathcal {P}_{\texttt {ID}^*}\cap S^*= \emptyset \) and \(\tau <\tau ^*\), then the challenger \(\mathcal {C}\) rejects the challenge. Otherwise, it picks a random bit \(\beta \in \{0,1\}\), and returns the challenge ciphertext \(\texttt {CT}^*\leftarrow \textsf {Encrypt}(\texttt {PP},\texttt {ID}^*,S^*,M_\beta ,\tau ^*)\) to the adversary \(\mathcal {A}\).

Query phase 2. This phase is identical to the query phase 1, except that the adversary \(\mathcal {A}\) cannot issue a corruption query with respect to \((\texttt {ID}^*,\texttt {SK}_{\tau ,\mathcal {P}_{i}},\mathcal {P}_{\texttt {ID}^*},\tau )\) such that \(\mathcal {P}_{\texttt {ID}^*}\cap S^*= \emptyset \) and \(\tau <\tau ^*\).

Guess. The adversary \(\mathcal {A}\) outputs a guess bit \(\beta '\in \{0,1\}\). The adversary \(\mathcal {A}\) wins if \(\beta '=\beta \). Its advantage in the IND-PUN-ID-CPA game is defined as

$$\begin{aligned} \textsf {Adv}_{\mathcal {A},\text {fs-PIBE}}^{\texttt {IND-PUN-ID-CPA}}(\kappa )=\Big |\Pr [\beta '=\beta ]-\frac{1}{2}\Big |. \end{aligned}$$

Definition 2

(IND-PUN-ID-CPA Security of fs-PIBE). We say that a forward-secure puncturable identity-based encryption scheme is IND-PUN-ID-CPA secure if for any PPT adversary \(\mathcal {A}\), its advantage in the above game is negligible for sufficiently large security parameter \(\kappa \).

To capture fine-grained forward secrecy of IBE, we allow an adversary \(\mathcal {A}\) to obtain a secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) of the challenge identity \(\texttt {ID}^*\) via a corruption query \(\mathcal {Q}_{corrupt}(\texttt {ID}^*)\). But it is restricted that either \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) has been punctured with a tag \(t_j^*\in S^*\) via a puncture query \(\mathcal {Q}_{punc}(\texttt {ID}^*,t_j^*)\), or \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) has been updated to a time interval \(\tau \) that is larger than \(\tau ^*\) via an update query \(\mathcal {Q}_{update}(\texttt {ID}^*,\tau )\).

4 The fs-PIBE Construction

4.1 High Description

We first describe some notations used below. We use a binary tree \(\mathcal {BT}\) to manage time intervals as in Canetti et al.’s [7] scheme. That is, if the total number of time intervals is \(\tau _{max}\), then we select a binary tree of depth \(\ell \) such that \(\tau _{max}\le 2^{\ell }\). Each time interval \(\tau \) is assigned to a leaf node \(\eta _\tau \) of \(\mathcal {BT}\) in order from left to right. For a node \(\eta \) of \(\mathcal {BT}\), denote by \(w_\eta \) the binary string that represents the path from the root node \(\epsilon \) to \(\eta \), in which 0 implies that the path passes through the left child node and 1 the right child node. In the absence of ambiguity, for each time interval \(\tau \), we directly rewrite \(w_{\eta _\tau }\) with \(w_\tau \) for simpling descriptions. Given a node \(\eta \), let \(\mathcal {R}(\eta )\) be its right child nodeFootnote 1, and \(\textsf {Path}(\eta )\) be the collection of all nodes on the path from \(\epsilon \) to \(\eta \). Then, for each time interval \(\tau \), we define a node set \(\mathcal {N}_\tau =\{\mathcal {R}(\eta )|\eta \in \textsf {Path}(\eta )\}\). Such a definition enjoys the following property: Given two time intervals \(\tau <\tau '\), for each node \(\eta '\in \mathcal {N}_{\tau '}\), there exists a node \(\eta \in \mathcal {N}_\tau \) such that \(w_{\eta }\) is a prefix of \(w_{\eta '}\).

Our construction is motivated by Green and Miers’ puncture encryption scheme [14], and built upon Waters’ IBE scheme [31]. Specifically, we divide the whole lifetime of the system into multiple time intervals, and each user uses different secrete keys during each time interval. For a time interval \(\tau \), we produce a secret key component \(\varvec{sk}_{\tau ,\eta }\) for each node \(\eta \in \mathcal {N}_\tau \). Then, at the end of \(\tau \), by the above property of \(\mathcal {N}_\tau \), we can unidirectionally derive a secret key component \(\varvec{sk}_{\tau +1,\eta '}\) from \(\varvec{sk}_{\tau +1,\eta }\) for each node \(\eta '\in \mathcal {N}_{\tau +1}\), where \(w_\eta \) is a prefix of \(w_{\eta '}\). At this point, we only captures general forward secrecy as in Canetti et al.’s scheme [7]. Furthermore, we embed a set S of descriptive tags into each ciphertext by introducing a polynomial defined over them, which enables the size of ciphertext in our construction to achieve constant, rather than being linear with the size of attached tags as in Green and Miers’ scheme [14]. Upon receiving and decrypting a ciphertext associated with the tag set S, we puncture the secret key with each tag belonging to S such that the punctured secret key will no longer be able to decrypt any ciphertext that is embedded with any tag in S. This procedure is similar to produce a secret key component for a negated attribute in [21]. Now, we achieve fine-grained forward secrecy. That is, the decryption capacity of those encrypted messages that have been received is revoked, while the decryption capacity of those unreceived ones is still reserved. Moreover, maintaining secret keys for multiple time intervals allow the user to retain the decryption capacity of more unreceived messages.

4.2 The Proposed Construction

The proposed fs-PIBE construction consists of a tuple of algorithms (Setup, KeyGen, Puncture, Update, Encrypt, Decrypt), which are specified as follows:

  • Setup\((\kappa ,\tau _{max},n)\): The setup algorithm is performed by a private key generator (PKG). Given a security parameter \(\kappa \), the total number of time intervals \(\tau _{max}\) and the maximum number of tags allowed to attach to a ciphertext n, this algorithm generates bilinear groups \((\mathbb {G},\mathbb {G}_T,e,p,g)\), chooses a random exponent \(\alpha \in \mathbb {Z}_p\) and lets \(Z=e(g,g)^\alpha \). Let the message space be \(\mathcal {M}\subseteq \mathbb {G}_T\), the tag space be \(\mathcal {T}\subseteq \mathbb {Z}_p\) and the identity space be \(\mathcal {ID}=\{0,1\}^{l}\). Particularly, let \(\hat{t}_0\in \mathcal {T}\) be a distinctive tag not used in normal encryption and puncture operations. Then, it initializes a binary tree \(\mathcal {BT}\) of depth \(\ell \) to manage all time intervals \(\{0,\ldots ,\tau _{max}-1\}\) such that \(\tau _{max}\le 2^\ell \). Moreover, this algorithm chooses random vectors \(\varvec{u}=(u_0,\ldots ,u_{l})\in \mathbb {G}^{l+1}\), \(\varvec{v}=(v_0,\ldots ,v_{\ell })\in \mathbb {G}^{\ell +1}\) and \(\varvec{h}=(h_1,\ldots ,h_{n})\in \mathbb {G}^{n}\). To simplify subsequent descriptions, for each identity \(\texttt {ID}\in \mathcal {ID}\) and binary string \(w\in \{0,1\}^{\le \ell }\), we define two functions \(H(\texttt {ID})=u_0\cdot \prod _{j=1}^{l}(u_j)^{\texttt {ID}[j]}\) and \(V(w)=v_0\cdot \prod _{j=1}^{|w|}(v_j)^{w[j]}\). Finally, the algorithm outputs the master secret key as \(\texttt {MSK}=g^{\alpha }\), and publishes the public parameter as \(\texttt {PP}=\{(\mathbb {G},\mathbb {G}_T,e,p,g),Z,\varvec{u},\varvec{v},\varvec{h}\}\).

  • KeyGen\((\texttt {PP},\texttt {MSK},\texttt {ID})\): The secret key generation algorithm is also run by the PKG. Given the public parameter \(\texttt {PP}\), the master secret key \(\texttt {MSK}\) and an identity \(\texttt {ID}\), this algorithm first chooses random exponents \(r_{id},r_0,r_0'\in \mathbb {Z}_p\), and computes

    $$\begin{aligned} \varvec{sk}_{\emptyset }&=(sk_{\emptyset ,1},sk_{\emptyset ,2},sk_{\emptyset ,3},\varvec{sk}_{\emptyset ,4}) = \big (g^{r_0},g^{r_{id}},\hat{t}_0,\varvec{sk}_{\emptyset ,4}\big ), \\ \varvec{sk}_{\emptyset ,4}&=(k_{\emptyset ,2},k_{\emptyset ,3},\ldots ,k_{\emptyset ,n})=\big ((h_1^{-\hat{t}_0}\cdot h_2)^{r_0},(h_1^{-\hat{t}_0^2}\cdot h_3)^{r_0},\ldots ,(h_1^{-\hat{t}_0^{n-1}}\cdot h_n)^{r_0}\big ). \end{aligned}$$

    Furthermore, for each node \(\eta \in \mathcal {N}_{0}\), this algorithm calculates

    $$\begin{aligned} \varvec{sk}_{0,\eta }&=(sk_{0,0},sk_{0,1},sk_{0,|w_{\eta }|+1},\ldots ,sk_{0,\ell })\\&=\big (g^{\alpha }\cdot h_1^{r_0}\cdot H(\texttt {ID})^{r_{id}}\cdot V(w_{\eta })^{r_0'},g^{r_0'},(v_{|w_{\eta }|+1})^{r_0'},\ldots ,(v_{\ell })^{r_{0}'}\big ). \end{aligned}$$

    Finally, this algorithm outputs an initial secret key \(\texttt {SK}_{0,\emptyset }=\{\varvec{sk}_\emptyset ,\{\varvec{sk}_{0,\eta }\}_{\eta \in \mathcal {N}_0}\}\) for identity \(\texttt {ID}\).

  • Puncture\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i-1}},\hat{t}_i)\): The puncture algorithm is performed locally by a user without interactions. Given the public parameter \(\texttt {PP}\), a punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i-1}}\) on time interval \(\tau \) and a tag \(\hat{t}_i\), this algorithm first parses \(\texttt {SK}_{\tau ,\mathcal {P}_{i-1}}\) as \(\{\varvec{sk}_\emptyset ,\varvec{sk}_{\mathcal {P}_1},\ldots ,\varvec{sk}_{\mathcal {P}_{i-1}},\{\varvec{sk}_{\tau ,\eta }\}_{\eta \in \mathcal {N}_\tau }\}\), where \(\varvec{sk}_{\emptyset }=(sk_{\emptyset ,1},sk_{\emptyset ,2},\) \(sk_{\emptyset ,3},\varvec{sk}_{\emptyset ,4})\), \(\varvec{sk}_{\emptyset ,4}=(k_{\emptyset ,2},\ldots ,k_{\emptyset ,n}) \) and \(\varvec{sk}_{\tau ,\eta }=(sk_{\tau ,0},sk_{\tau ,1},sk_{\tau ,|w_{\eta }|+1},\ldots ,\) \(sk_{\tau ,\ell })\). Then, it randomly picks exponents \(\lambda _i,r_i,r_i'\in \mathbb {Z}_p\), and computes

    $$\begin{aligned} \varvec{sk}_{\emptyset }'&=(sk_{\emptyset ,1}',sk_{\emptyset ,2}',sk_{\emptyset ,3}',\varvec{sk}_{\emptyset ,4}')=(sk_{\emptyset ,1}\cdot g^{r_i'},sk_{\emptyset ,2},sk_{\emptyset ,3},\varvec{sk}_{\emptyset ,4}'),\\ \varvec{sk}_{\emptyset ,4}'&=(k_{\emptyset ,2}',\ldots ,k_{\emptyset ,n}')=\big (k_{\emptyset ,2}\cdot (h_1^{-\hat{t}_0}h_2)^{r_i'},\ldots ,k_{\emptyset ,n}\cdot (h_1^{-\hat{t}_0^{n-1}}h_{n})^{r_i'}\big ),\\ \varvec{sk}_{\mathcal {P}_{i}}&=(sk_{\mathcal {P}_{i},1},sk_{\mathcal {P}_{i},2},sk_{\mathcal {P}_{i},3},\varvec{sk}_{\mathcal {P}_{i},4})=\big (g^{\lambda _i}\cdot h_1^{r_i},g^{r_i},\hat{t}_i,\varvec{sk}_{\mathcal {P}_{i},4}\big ),\\ \varvec{sk}_{\mathcal {P}_{i},4}&=(k_{\mathcal {P}_{i},2},\ldots ,k_{\mathcal {P}_{i},n})=\big ((h_1^{-\hat{t}_i}\cdot h_2)^{r_i},\ldots ,(h_1^{-\hat{t}_i^{n-1}}\cdot h_n)^{r_i}\big ),\\ \varvec{sk}_{\tau ,\eta }'&=\big (sk_{\tau ,0}\cdot g^{-\lambda _i}\cdot h_1^{r_i'},sk_{\tau ,1},sk_{\tau ,|w_{\eta }|+1},\ldots ,sk_{\tau ,\ell }\big ). \end{aligned}$$

    Finally, this algorithm outputs a new punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) in the form of \(\{\varvec{sk}_\emptyset ',\varvec{sk}_{\mathcal {P}_1},\ldots ,\varvec{sk}_{\mathcal {P}_{i-1}},\varvec{sk}_{\mathcal {P}_{i}},\{\varvec{sk}_{\tau ,\eta }'\}_{\eta \in \mathcal {N}_\tau }\}\).

  • Update\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\tau ')\): The secret key update algorithm is also run locally by a user without interactions. Given the public parameter \(\texttt {PP}\), a punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) on time interval \(\tau \) and a new time interval \(\tau '>\tau \), this algorithm first parses the secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}=\{\varvec{sk}_\emptyset ,\varvec{sk}_{\mathcal {P}_1},\ldots ,\varvec{sk}_{\mathcal {P}_{i}},\{\varvec{sk}_{\tau ,\eta }\}_{\eta \in \mathcal {N}_\tau }\}\), where \(\varvec{sk}_{\tau ,\eta }=(sk_{\tau ,0},sk_{\tau ,1},sk_{\tau ,|w_{\eta }|+1},\ldots ,sk_{\tau ,\ell })\). Then, for each \(\eta '\in \mathcal {N}_{\tau '}\) it finds out a node \(\eta \in \mathcal {N}_{\tau }\) such that \(w_{\eta }\) is a prefix of \(w_{\eta '}\), and further computes

    $$\begin{aligned} \varvec{sk}_{\tau ',\eta '}&=\Big (sk_{\tau ,0}\cdot V(w_{\tau '})^{r_{\tau '}}\cdot \prod _{j=|w_{\eta }|+1}^{|w_{\eta '}|}(sk_{\tau ,j})^{w_{\eta '}[j]},sk_{\tau ,1}\cdot g^{r_{\tau '}},\\&\quad \quad \quad sk_{\tau ,|w_{\eta '}|+1}\cdot (v_{|w_{\eta '}|+1})^{r_{\tau '}},\ldots ,sk_{\tau ,\ell }\cdot (v_\ell )^{r_{\tau '}}\Big ), \end{aligned}$$

    where \(r_{\tau '}\) is an exponent randomly sampled from \(\mathbb {Z}_p\). Finally, this algorithm outputs an updated secret key \(\texttt {SK}_{\tau ',\mathcal {P}_{i}}=\{\varvec{sk}_\emptyset ,\varvec{sk}_{\mathcal {P}_1},\ldots ,\varvec{sk}_{\mathcal {P}_{i}},\{\varvec{sk}_{\tau ',\eta '}\}_{\eta '\in \mathcal {N}_{\tau '}}\}\) for time interval \(\tau '\).

  • Encrypt\((\texttt {PP},\texttt {ID},S,M,\tau )\): This algorithm is performed by a sender intending to send a message to a receiver with identity ID. Given the public parameter \(\texttt {PP}\), a receiver’s identity ID, a tag set \(S=\{t_1,\ldots ,t_d\}\) \((d\le n)\), a message M to encrypt and a time interval \(\tau \), this algorithm first defines a coefficient vector \(\varvec{z}=(z_1,\ldots ,z_{n})\) form the polynomial \(f(x)=\prod _{t\in S}(x-t)=\sum _{j=1}^{n}z_jx^{j-1}\), where \(z_j=0\) for \(d+1<j\le n\). Then, it picks a random integer \(s\in \mathbb {Z}_p\) and computes

    $$\begin{aligned} \texttt {CT}&=(c_0,c_1,c_2,c_3,c_4)=\big (Z^s\cdot M,g^s,H(\texttt {ID})^s,V(w_\tau )^s,(h_1^{z_1}\cdots h_n^{z_n})^s\big ). \end{aligned}$$

    Finally, this algorithm outputs a ciphertext \(\texttt {CT}\), along with S and \(\tau \).

  • Decrypt\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\texttt {CT})\): This algorithm is run by a receiver with identity ID. Given the public parameter \(\texttt {PP}\), a punctured secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) on time interval \(\tau \) and a ciphertext \(\texttt {CT}\), this algorithm first uses the tag set S to compute a coefficient vector \(\varvec{z}=(z_1,\ldots ,z_{n})\) as in the encryption algorithm. Then, it parses the secret key \(\texttt {SK}_{\tau ,\mathcal {P}_{i}}\) as \(\{\varvec{sk}_\emptyset ,\varvec{sk}_{\mathcal {P}_1},\ldots ,\varvec{sk}_{\mathcal {P}_{i}},\{\varvec{sk}_{\tau ,\eta }\}_{\eta \in \mathcal {N}_\tau }\}\), where \(\varvec{sk}_{\emptyset }=(sk_{\emptyset ,1},sk_{\emptyset ,2},sk_{\emptyset ,3},\varvec{sk}_{\emptyset ,4})\), \(\varvec{sk}_{\emptyset ,4}=(k_{\emptyset ,2},\ldots ,k_{\emptyset ,n}) \). For \(m=1\) to i, let \(\varvec{sk}_{\mathcal {P}_{m}}=(sk_{\mathcal {P}_{m},1},sk_{\mathcal {P}_{m},2},sk_{\mathcal {P}_{m},3},\varvec{sk}_{\mathcal {P}_{m},4})\), \(\varvec{sk}_{\mathcal {P}_{m},4}=(k_{\mathcal {P}_{m},2},k_{\mathcal {P}_{m},3},\ldots ,k_{\mathcal {P}_{m},n})\). Let \(\varvec{sk}_{\tau ,\eta _\tau }=(sk_{\tau ,0},sk_{\tau ,1})\). Next, the algorithm successively computes

    Finally, this algorithm outputs the message \(M=c_0\cdot \prod _{j=0}^i C_j\).

Correctness. Now we demonstrate the correctness of the above construction. First, for each \(m\in [i]\), note that

$$\begin{aligned} k_m&=\prod _{j=2}^n (k_{\mathcal {P}_m,j})^{z_j}=\prod _{j=2}^n \big (h_1^{-\hat{t}_m^{j-1}}\cdot h_j\big )^{r_mz_j}=(h_1)^{-r_m\cdot \sum _{j=2}^nz_j\hat{t}_m^{j-1}}\cdot \prod _{j=2}^{n}h_j^{r_mz_j}\\&=(h_1)^{r_m\cdot (z_1-f(\hat{t}_m))}\cdot \prod _{j=2}^{n}h_j^{r_mz_j}=(h_1)^{-r_m\cdot f(\hat{t}_m)}\cdot \Big (\prod _{j=1}^{n}h_j^{z_j}\Big )^{r_m}. \end{aligned}$$

Similarly, we have that \(k_0=(h_1)^{-r_0\cdot f(\hat{t}_0)}\cdot \Big (\prod _{j=1}^{n}h_j^{z_j}\Big )^{r_0}\), where \(r_0\) is reassigned as \(r_0\leftarrow r_0+\sum _{j=1}^{i}r_j'\).

Second, observe that

$$\begin{aligned} C_0&=\Big (\frac{e\big ((h_1)^{-r_0\cdot f(\hat{t}_0)}\cdot \big (\prod _{j=1}^{n}h_j^{z_j}\big )^{r_0},g^s\big )}{e\big (g^{r_0},(h_1^{z_1}\cdots h_n^{z_n})^s\big )}\Big )^{\frac{-1}{f(\hat{t}_0)}}\cdot \frac{e\big (g^{r_{id}},H(\texttt {ID})^s\big )\cdot e\big (g^{r_\tau },V(w_\tau )^s\big )}{e\big (g^{\alpha '}\cdot h_1^{r_0}\cdot H(\texttt {ID})^{r_{id}}\cdot V(w_\tau )^{r_\tau },g^s\big )}\\&=e(h_1^{r_0},g^s)\cdot e(g,g)^{-\alpha ' s}\cdot e(h_1^{r_0},g^s)^{-1}=e(g,g)^{-\alpha 's}, \end{aligned}$$

where \(\alpha '=\alpha -\sum _{m=1}^{i}\lambda _m\). Similarly, we have that \(C_m=e(g,g)^{-\lambda _m\cdot s}\) for \(m\in [i]\). Thus, we conclude that

$$\begin{aligned} c_0\cdot \begin{matrix} \prod \nolimits _{m=0}^i C_m\end{matrix}&=M\cdot e(g,g)^{\alpha s}\cdot e(g,g)^{(\sum _{m=1}^{i}\lambda _m-\alpha )\cdot s}\cdot \begin{matrix}\prod \nolimits _{m=1}^i e(g,g)^{-\lambda _m\cdot s} \end{matrix} =M. \end{aligned}$$

4.3 Security Analysis

The security of the proposed fs-PIBE scheme is captured as follows:

Theorem 1

If the decisional q-BDHE assumption holds over bilinear groups \(\mathbb {G}\) and \(\mathbb {G}_T\), then the proposed fs-PIBE scheme is IND-PUN-ID-CPA secure. Formally, we have that

where l is the length of identity, \(q_{id}\) is the number of generated secret keys for answering queries, and \(\tau _{max}\) is the total number of time intervals.

Due to space constraints, we will provide the detailed proof in our full version.

4.4 Efficiency Analysis

In this subsection, we theoretically discuss the performance of the proposed fs-PIBE scheme, by comparing it with the underlying Waters’ IBE scheme [31] and the FSPE scheme of Green and Miers’ [14]Footnote 2. For ease of notation, we denote by \(|\mathbb {G}|\), \(|\mathbb {G}_T|\) and \(|\mathbb {Z}_p|\) the size of an element from \(\mathbb {G}\), \(\mathbb {G}_T\) and \(\mathbb {Z}_p\), respectively. Let \(|\mathcal {P}|\) be the number of punctured tags. \(\mathtt {Exp}\) means one exponentiation operation and \(\mathtt {Pair}\) one pairing operation.

Table 1. Comparisons with previous works in terms of storage and communication cost

In Table 1 we provide the sizes of public parameter, secret key and ciphertext in these listed schemes. Compared with the original Waters’ IBE scheme [31] and the FSPE scheme of Green and Miers [14], the sizes of public parameter and secret key in the proposed fs-PIBE scheme increase a lot. However, it is bounded by the maximum number n of allowed tags and the depth \(\ell \) of the binary tree used to manage time intervals. At the cost of acceptable storage space, the ciphertext size in the proposed scheme achieves constant as in Waters’ IBE scheme [31]. In fact, we can obtain a natural construction of fs-PIBE scheme by simultaneously running Waters’ IBE scheme [31] and the FSPE scheme of Green and Miers [14] as follows: Select a random element R when needing to encrypt a message M, then encrypt \(M\cdot R\) with IBE and R with FSPE. Although this construction achieves practical forward secrecy in the setting of IBE, it still needs PKIs to support the usage of FSPE, and brings redundancy of public parameter and ciphertext. It can be seen that the proposed fs-PIBE scheme is more compact.

Table 2 summaries the computation complexity of main algorithms in these listed schemes, in which we only consider the dominant operations: exponentiation and pairing. Similar to Green and Miers’ puncture encryption scheme [14], the computation cost of the proposed fs-PIBE scheme is determined by the number \(|\mathcal {P}|\) of punctured tags and the maximum number n of tags allowed to attach to each ciphertext. But the difference is that the number of attached tags in the proposed fs-PIBE scheme is allowed to dynamically range from 1 to n, but the number in Green and Miers’ scheme is fixed to be n. Thus, our scheme is more flexible. In addition, the computation complexity of the encryption algorithm in our proposal is independent of any parameter. Focusing on the security of these schemes, our fs-PIBE scheme and Waters’ IBE scheme are secure in the standard model, while the FSPE scheme is secure in the random oracle model.

Table 2. Comparisons with previous works in terms of computation overhead

5 Encrypted Cloud Email Systems from fs-PIBE

In this section, we introduce a framework of encrypted cloud email systems based on fs-PIBE. In our framework, there are four types of participants: PKG, email sender, email receiver and cloud email server.

Specifically, our framework employs a fs-PIBE scheme fs-PIBE = (Setup, KeyGen, Puncture, Update, Encrypt, Decrypt) and a symmetric encryption scheme SE = (Encrypt, Decrypt), and utilizes a hybrid encryption fashion to secure cloud email communications. Its workflow is comprised of the following phases:

  • Initialization: In this phase, the PKG selects necessary parameters, and runs the algorithm fs-PIBE.Setup\((\kappa ,\tau _{max},n)\rightarrow (\texttt {PP},\texttt {MSK})\). Then, it publishes the public parameter \(\texttt {PP}\).

  • Customer Registration: In this phase, each customer selects his/her email address ID (i.e., his/her public key), and then registers with the PKG. That is, the PKG issues an initial secret key \(\texttt {SK}_{0,\emptyset }\leftarrow \) fs-PIBE.KeyGen\((\texttt {PP},\texttt {MSK},\texttt {ID})\) to the customer.

  • Send Encrypted Cloud Emails: In this phase, when an email sender wants to send an email message M to an receiver with address ID, he/she first picks an encryption key K for SE, and respectively produces ciphertexts \(\textsf {fs-PIBE.Encrypt}(\texttt {PP},\texttt {ID},S,\texttt {K},\tau )\rightarrow \texttt {Header}\) and \(\textsf {SE.Encrypt}(\texttt {K},M)\rightarrow \texttt {CT}\). The encrypted email (Header, CT) is then sent to the cloud email server.

  • Cache and Deliver Encrypted Emails: In this phase, the cloud email server takes charge of caching and delivering encrypted emails. That is, when the intended receiver is online, it forwards (Header, CT) to him/her.

  • Decrypt Encrypted Emails: In this phase, upon receiving the encrypted email, the receiver first utilizes the current secret key to decrypt the encryption key fs-PIBE.Decrypt\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\texttt {Header})\rightarrow \texttt {K}\), and further recovers the email message \(\textsf {SE.Decrypt}(\texttt {K},\texttt {CT})\rightarrow M\).

  • Puncture and Update Secret Key: In this phase, the receiver punctures the current secret key by running fs-PIBE.Puncture\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i-1}},\hat{t}_i)\) for each \(\hat{t}_i\in S\). In addition, at the end of time interval \(\tau \), he/she derives the secret key for next time interval \(\texttt {SK}_{\tau ',\mathcal {P}_{i}}\leftarrow \) fs-PIBE.Update\((\texttt {PP},\texttt {SK}_{\tau ,\mathcal {P}_{i}},\tau ')\). Depending on the receiver’s security policy configuration, he/she can preserve secret keys for multiple time intervals simultaneously.

The correctness of our framework comes from the correctness of the underlying fs-PIBE scheme and symmetric encryption scheme. By correctly implementing the hybrid encryption fashion, its security can be reduced to the security of fs-PIBE and SE. Compared with previous encrypted email systems, our framework provides stronger security guarantee without sacrificing usability.

6 Conclusion

In this paper, focusing on how to achieve the forward secrecy of encrypted cloud email systems without requiring PKIs and sacrificing the usability, we introduce the notion of forward-secure puncturable identity-based encryption. Specifically, we formalize its syntax and security notion, and also propose a concrete construction. The proposed fs-PIBE scheme has constant size of ciphertext, and is proved to be secure in the standard model. The efficiency analysis indicates that the proposed fs-PIBE captures practical forward secrecy at the cost of acceptable storage overhead, and thus is desirable for encrypted cloud email systems.