Hybrid Private Key-based Cryptosystem for Cloud Storage Systems

(1)

International Journal of Digital Communication and Networks (IJDCN) Volume 5, Issue 4, May 2017

Hybrid Private Key-based Cryptosystem

for Cloud Storage Systems

Shiny. A, Mukund Vijayaraghavan, Karthikeyan. P. Rammohan, Vishal Rathina Sankar, Ruchitha Kalluru Reddy SRM University, Chennai

Abstract—We propose a hybrid two-factor data security protec-tion mechanism in the form of a cryptosystem with factor revo-cability for cloud storage systems. This identity-based encryption (IBE) system allows the sender to send an encrypted message through a cloud storage server to a receiver. The identity of the receiver is the only information that the sender needs to know. No other information (such as its certificate) is required. The receiver is required to possess two things so as to decrypt the ciphertext. The first thing being the secret key stored in his/her personal computer. This secret key has two parts - one static human-set part and a dynamic part (generated upon every instance of file uploaded). The second one is a unique personal security device which is used to connect to the computer. It is absolutely not possible to decrypt the ciphertext without either piece as mentioned above. Also, more importantly once the security device is stolen or lost, this device can be revoked. It cannot be used to decrypt any ciphertext. This can be done by the cloud server which immediately executes some algorithms to change the existing ciphertext to be non-decryptable by this device. This system is not only secure but also practical.

Keywords—cryptosystem, two-factor, IBE, revocability, cloud

I. INTRODUCTION

Cloud storage [4] is a form of networked storage system where the data is stored in pools of storage which are normally hosted by third parties. Of the most benefits to use cloud storage the most notable one is data accessibility. As long as there is network access, data stored in the cloud can be accessed at any time from any place. Storage maintenance tasks, like purchasing additional storage capacity, can be offloaded to the responsibility of a service provider. One more benefit of cloud storage is sharing data between users. If wants to share a piece of data (e.g. a video) to Bob, she might face a difficulty while sending it through mail due to the size of the file. As an alternative if Alice uploads the video file to a cloud storage system so that Bob can download it at any time. Regardless of its advantages, outsourcing data storage also increases the attack surface area at the same time. For example, when the data is spread, the risk it contains for unauthorized physical access to the data depends on more locations the data is stored. It is also possible for other unauthorized users to access your data by sharing storage and networks with many other users. This might be because of mistaken actions, faulty equipment, or sometimes even because of the criminal intent. Deploying encryption technology is a promising solution to offset this

risk. The data that is being transmitted to and from the cloud service is taken care by encryption. The data that is stored at the service provider is also protected by this. Even if there is an unauthorized foe who has gained access to the cloud, he can cannot get any information about the plaintext as it has been encrypted. In asymmetric encryption only the public information (e.g. public key or identity of the receiver) is open for use for the encryptor to generate a ciphertext and a secret key is used by the receiver to decrypt. This is the simplest and easiest mode of encryption for data transition, due to the elimination of key management which exists in symmetric encryption.

A. Enhanced Security Protection

There is a single secret key corresponding to a public key or an identity in a normal asymmetric encryption. The decryption of ciphertext only requires this particular key. The key is usually stored inside either a personal computer or a trusted server, and may be protected by a password. If the computer/server is isolated from an opening network the security protection is sufficient. Unfortunately, this is not what happens in the practice. The computer/server may suffer from a potential risk that hackers may intrude into it to compromise the secret key without letting the key owner know when being connected with the world through the Internet. The computer storing a user decryption key may be used by another user when the original computer user (i.e. the key owner) is away (e.g. when the user goes to the restroom for a while without locking the machine), in the physical security aspect. The sharing usage of computers is common in an enterprise or college. For example, in a college, all students staying at the same floor share a public computer in a copier room .The secret key can be compromised by some attackers who can access the victims personal data stored in the cloud system in such cases. Therefore, there exists a need to enhance security protection. A correlation is e-banking security. Many e-banking apps require a user to use both a password and a security device (two factors) to login system for the sake of money transfer. The security device gives an OTP (one time password) which is required to be entered into the system by the user. To enhance the security protection for the access control is the main purpose of using two factors. It is easy to foresee that the security for data protection in the cloud should be further enhanced [5], [6], as cloud computing becomes more mature and more applications and storage services are provided by

(2)

the cloud. As in the e-banking analogy, they will become more sensitive and important. Actually, we have noticed one of the encryption trends for data protection emerging is the concept of two-factor encryption, which has spread into some real-world applications, for example, full disk encryption with Ubuntu system, Verizon two-factor encryption for smartphones electronic vaulting and Verizon cloud-based data encryption. However, these applications suffer from a potential risk about factor revocability that may limit their practicability. A flexible and scalable two factor encryption mechanism is really desir-able in the era of cloud computing. This is the main motivation for our work.

B. Some Naive Approaches

Let us look at some naive approaches for improvement of security protection and explain why they are not the best candidates to achieve the goal of flexibility.

1) Double encryption: A security device (with an additional public key or serial number which is not used here) is still a requisite, as it contains one key required for this system. The encryption process is executed two times. First encrypt the plaintext analogous to the private key stored in the device. Then repeat the process again corresponding to the user private key. For the decryption part, the security device decrypts the first encryption layer. The partially decrypted ciphertext is then given to the computer which uses the user secret key to further decrypt it. So there are two different keys here, which correspond to two encryption layers. This approach seems to achieve our goal. However, there exist many practical issues that it cannot solve. For example, if one key is lost, the ciphertext in the cloud cannot be decrypted forever! What makes the encryption process more complicated is that the sender needs to know the private key of the security device, in addition to the user’s secret key. The concept of ”identity-based” has been totally lost as the sender needs to know more than the identity of the receiver, including the private key stored in the device.

2) Split the secret key into two parts: Simply splitting the secret key into two parts is another way to think of. The first part is stored in the computer while the second part is embedded into a security device. Without either part one cannot decrypt the ciphertext similar to the above approach. Again it might appear as if this approach can achieve our goal. However, if part of the secret key has been exposed note that the security of a normal encryption scheme cannot be guaranteed. If the whole secret key has not been exposed to the adversary only then the security is guaranteed. In other words, if we simply split the secret key into two parts, the adversary with either part may have non-negligible chance to decrypt (or at least to know some information about the plain text). There exists a cryptographic primitive called ”Leakage -resilient Encryption” [7]. If the leakage of the secret key is up to certain bits such that the knowledge of these bits does not help to recover the whole secret key the security of the

I International Journal of Digital Communication and Networks (IJDCN) Volume 5, Issue 4, May 2017

scheme is still guaranteed. Suppose we put part of the secret key into the security device and the device is stolen. In order to continue to decrypt his/her corresponding secret key the user needs to obtain a replacement device. The trivial way is to copy the same bits (as in the stolen device) to the new device by the private key generator (PKG). This approach can be easily achieved. But, there exists a security risk. If the person who has stolen the security device can also break into the computer where the other part of secret key is stored, then it can decrypt all ciphertext corresponding to the victim user. To cease the validity of the stolen security device is the most secure way. The same is the scenario for online banking. A user needs to have a security device (along with the knowledge of his/her password) in order to login the e-banking service. If the security device is reported as lost, the user can no longer use the old device to login. Thus using leakage resilient primitive cannot provide this security feature which is considered as the most important criterion of two factor security protection.

3) Two-Factor security with no human-set key: Consider a two-factor security system with none of the above two methods which contribute to shortcomings [22]. One of such system’s security is based on two factors, one a private key and the other a security device [1]. The private key is automatically generated for every file encrypted and uploaded to the cloud server. This generation of the private key is done by a third-party agency called the Private Key Generator (PKG). The security device is provided by another third-party agency called the Security Device Issuer (SDI). So far, we have been using a cloud storage server for all communication, and this server is semi-trusted, ie. it does not attempt directly to decrypt the data stored, but it is not completely trusted. On the contrary, both the PKG and the SDI are trusted parties, and they perform the function only meant for them. So there is a total of three entities we must trust/rely upon for our security. This web of trust is therefore very important in the system. This introduces another shortcoming, namely ”Trust Failure”. We can say that this trust failure greatly increases if there does not exist a human-set key (password) which only exists in the cloud server database. Suppose both trusted parties have been compromised, and both private key and the security device are exposed. There is nothing stopping any attacker from exploiting this vulnerability.

(3)

user loses the key k2, all data of the user stored in the cloud cannot be retrieved. The lack of revocability for encryption factor limits the flexibility of the system.

C. Our Contributions

In this paper, we propose a two-factor security protection mechanism for data stored in the cloud. Our mechanism provides the following features:

1) Our system is based on an IBE mechanism. Here, to send an encrypted data (ciphertext) to a receiver, the sender only needs to know the identity of him/her. No other information of the receiver (e.g. certificate etc.) is required. Then the sender sends the ciphertext to the cloud where the receiver can download it at any time. 2) Our system provides two-factor data encryption

protec-tion. To decrypt the data stored in the cloud, the user needs to possess two important things. First, the user needs to have his/her secret key which is stored in the computer. Here, the required secret key is K2. Secondly, the user needs to have a unique personal security device which will be connected to the computer (e.g. USB, Bluetooth, NFC, etc.). It is impossible to decrypt the ciphertext without either of the above. 3) Most importantly, our system provides security device

revocability. Once the security device is stolen or re-ported as lost, this device is revoked. i.e., this device can no longer decrypt any ciphertext (corresponding to the user) in any circumstance. The cloud will imme-diately execute some algorithms to change the existing ciphertext to be non-decryptable by this device. After getting a new device or a replacement device, the user needs to use his new/replacement device together with his secret key to decrypt his/her ciphertext. This process is completely transparent to the sender.

4) The system is more immune to ”trust failure”. This is

implemented by having part of the private key as a human-set password. It is given upon registration to the cloud server. This way, even on the failure of both trusted agencies, the data is not compromised as this part of the password is required.

5) The cloud server cannot decrypt the ciphertext at any point of time.

We provide an estimation of the running time of our prototype to show its practicality using some results. Even though there exists some nave and simple approaches that seem to achieve our goal, we have discussed that there are many limitations to each of them and thus we believe our mechanism is the first to achieve all the above mentioned features.

II. RELATED WORK

We will further review some solutions which may contain sim-ilar functionalities. These are different cryptosystems which

may have similar approaches but produce different results. Now we will attempt to explain why they cannot fully achieve our goal.

A. Cryptosystems with Two Secret Keys

There are two kinds of cryptosystems that requires two secret keys for decryption. They are certificate-less cryptosystem and certificate-based cryptosystems [8]. Certificateless cryp-tosystem (CLC) [2] combines the merits of identity-based cryptosystem (IBC) and PKI. In a CLC, a user with an identity chooses his own user secret key and user public key. At the same time the authority called the Key Generation Centre (KGC) generates a partial secret key in accordance to the identity. Encryption or signature verification requires the knowledge of both the public key and the user identity. On the opposite, decryption or signature generation requires the knowledge of both the user secret key and the partial secret key given by the KGC. Difference between the traditional PKI and CLC is that, there is no certificate required here in CLC. Thus, the costly process of certificate validation can be eliminated. However, the encryptor or the signature verifier still needs to know the user public key. It is less convenient than IBC, where only identity is required for encryption or signature verification. Similar to CLC, another primitive called certificate-based cryptosystem (CBC) exists [3], [9]. The concept is almost the same as CLC, except that the partial secret key given by the KGC which is called the certificate. It is a signature of the identity and the public key of the user by the KGC. But in CLC, the partial secret key given by the KGC is just the signature of the identity of the user. Due to the similarities, CBC faces the same disadvantages as CLC mentioned above.

B. Cryptosystems with Online Authority

Mediated cryptography was first introduced in [10] for the purpose of revocation of public keys. It requires an online mediator, referred to as SEM (SEcurity Mediator), for every transaction. The SEM also provides a control of security capabilities. If the SEM does not cooperate, then no trans-actions with the public key are possible any longer. In other words, any revoked user cannot get the cooperation from the SEM. That means revoked users cannot decrypt any ciphertext successfully. Later on, this notion was generalized as security mediated certificateless (SMC) cryptography [11], [12]. In a SMC system, a user has a secret key, public key and an identity. The user secret key and the SEM are required to decrypt a ciphertext or sign a message. On the other side, the user public key and the corresponding identity are needed for signature verification or encryption. Since the SEM is controlled by the revocation authority, the authority can refuse to provide any cooperation for revoked user so that no revoked user can generate signature or decrypt ciphertext. Note that SMC is different from our concept. The main purpose of SMC is

(4)

to solve the revocation problem and it is controlled by the authority. The SME has to be online for every signature signing and ciphertext decryption. Furthermore, it is not identity-based. The encryptor or signature verifier needs to know the corresponding public key in addition to the identity. That makes the system less practical and loses the advantages of using identity-based system.

setting, Green and Ateniese [20] defined the notion of identity-based PRE (IB-PRE). Later on, Tang, Hartel and Jonker [21] proposed a CPA-secure IB-PRE scheme, in which delegator and delegatee can belong in different domains. After that there have been many IB-PRE systems proposed to support different user requirements.

III. OVERVIEW

C. Cryptosystems with Security Device

The paradigm of Key-insulated cryptography [13] comprises of a physically-secure but computationally-limited device in the system. A long-term key is stored in this device, while a short-term secret key is kept by users on a powerful but insecure device where cryptographic computations take place. The public key remains unchanged throughout the lifetime of the system while the short term secrets are refreshed at discrete time periods via interaction between the user and the base. The user obtains a partial secret key from the device at the beginning of each time period. In order to renew the secret key for the current time period, he/she combines this partial secret key with the one from the previous period. Different from our concept, key-insulated cryptosystem requires all users to update their key in every time period. It may require some costly time synchronization algorithms between users which may not be practical in many scenarios. The key update process requires the security device. Once the key has been updated, the signing or decryption algorithm does not require the device anymore within the same time period while our concept does require the security device every time the user tries to decrypt the ciphertext. Furthermore, there is no key updating required in our system. Thus we do not require any synchronization within the whole system.

D. Cryptosystems with Revocability

Since our system is an IBE-based mechanism, we introduce IBE-based systems supporting revocability. The first revocable IBE is proposed by Boneh and Franklin [14], in which a ciphertext is encrypted under an identity ID and a time period T, and a non-revoked user is issued a private key T by a PKG such that the user can access the data in T. Boldyreva, Goyal and Kumar proposed the security notion for revocable IBE [15]. To achieve adaptive security, Libert and Vergnaud [16] proposed a revocable IBE scheme based on the combination of attribute-based encryption and IBE. Recently, Seo and Emura [17] formalized a revised notion for revocable IBE. The premise of a revocable IBE system is mainly related to a time period: The decryption rights of the next time period relies on a secret token for the next time period issued by PKG and a current time period key. However, this premise yields inconvenience once the current time period key is lost. Another cryptosystem supporting revocability is proxy re-encryption (PRE) [18]. Blaze, Bleumer and Strauss [19] formally defined the notion of PRE. To employ PRE in the IBE

A. Our Intuition

We propose a hybrid data security protection cryptosystem. Before giving the description of our mechanism, we first give an intuition for it. In our system, we have the following entities. They compose the architecture of the system:

Private Key Generator (PKG): It is a trusted party responsible for issuing the dynamic private key to every user, and is unique for every file uploaded.

Security Device Issuer (SDI): It is a trusted party re-sponsible for issuing the security device to every user.

Sender: The sender is the creator of the ciphertext. He/she only knows the identity of the receiver and nothing else related to the receiver. After he/she has created the ciphertext, he/she sends it to the cloud server to let the receiver download it.

Receiver: The receiver of the ciphertext has a unique public identity. The ciphertext is stored on a cloud storage server so that it can be downloaded any time for decryption. He/she has a private key stored in his computer and a security device, provided by the PKG and the SDI respectively. The reciever also has to set a custom password which is integrated with the private key. The decryption of ciphertext requires both the private key and the security device.

Cloud Server: The cloud server is responsible for storing all ciphertext (for receiver to download). Once a user has reported the loss of his/her security device (and has obtained a new one from the SDI), the cloud acts as a proxy to re-encrypt all past ciphertext corresponding to the new device.

(5)

Fig. 1. System Architecture

Here we refer to this ciphertext as first-level ciphertext. After receiving the first-level ciphertext from Alice, the cloud server then turns the ciphertext to become a second-level ciphertext for the corresponding security device belonging to Bob. Bob then downloads the second-level ciphertext from the cloud, and next recovers the data from its encrypted form by using his private key and security device. When the security device of Bob is either lost or stolen, Bob first reports the issue to the SDI. The SDI then issues a new security device to Bob, and meanwhile, it sends a request for updating Bobs corresponding ciphertext along with a special key to the cloud server. The cloud server updates the ciphertexts of Bob currently under an old security device to the ones under a new device. However, it does not gain access to the underlying data in the update process. Here Bob is allowed to download and recover the data by using his private key and new security device.

B. Assumptions

In our system, we assume that the PKG is a trusted party. We further assume that the SDI is trusted, and the cloud service is semi-trusted. That is, it is honest that it will execute all prescribed algorithms but it is curious. It may try to decrypt the ciphertext stored in the cloud, but not by any direct means. In any case, we assume that all three trusted agencies will not fail simultaneously, as this case is not in the slightest sense possible. We also assume that an honest system user will not expose his/her security device or secret key to an adversary, and that the security device is temper-resistant.

C. Threat Model

The following threats are considered:

1) Type-I: Decrypt without security device: The adversary tries to decrypt the ciphertext without the security device, or using a revoked security device, or using another security device belonging to others. It can have its own secret key.

2) Type-II: Decrypt without secret key: The adversary tries to decrypt the ciphertext without any secret key. It can have its own security device. Note that the above threat model has already captured the semi-trust behaviour of the cloud server.

IV. PROPOSED MECHANISM

A. System Architecture

Our system contains the aforementioned components, and is based on a web of trust. We also provide a counter mechanism when trust failure occurs. This mechanism is implemented right into the system, and is just another step which results in the creation of the private key.

Consider the two-factor system as described above, with one factor being the security device and the other the private key. The private key is divided into two parts, one static and the other dynamic. The dynamic part of the private key is generated by the Private Key Generator (PKG) for every instance of a file uploaded. Note that ’instance’ here does not mean every instance the file is downloaded by the receiver. It

(6)

Fig. 2. Use-Case Diagram

means the instance when the sender uploads the file onto the cloud server, which happens only once (as the upload takes place only a single time). The static part of this private key is set by the receiver upon registration to the system. It is then stored in the cloud server’s database. Only the combination of the static and dynamic parts will make up the complete secret key. The cloud server is the medium of storage for all files. It is the coordinator between the sender and the receiver. The security device is provided by the Security Device Issuer (SDI) which is another trusted third-party agency like the PKG.

The SDI is the entity responsible for the issuance of the unique device and the possible revocation of the same device. It is also responsible for providing a new device to the receiver. For the purposes of revocation and thus re-encryption of the ciphertext corresponding to the new device, the SDI has a working relationship with the Cloud Server. When the receiver’s SDI is lost or stolen, he/she sends a request to the cloud server for a new security device. This request is relayed from the cloud server to the SDI. It is accompanied with details about the current ciphertext, so that the new device can be configured to a completely random new identity. This is then used to re-encrypt the existing ciphertext in the cloud server, corresponding to the new device.

Therefore, the revocation process takes place with the SDI and the Cloud Server playing equal roles. The architecture as such is simple; but it provides the layout for a very secure system by which cloud storage can be fully utilized without security concerns.

B. Algorithm Description

The system mainly employs the AES encryption technique for encryption and decryption of the data/message. The Advanced Encryption Standard (AES) algorithm (original name Rijndael) is a symmetric-key block-cipher algorithm used for secure encryption and decryption of data. It is based on the design principle of a substitution-permutation network, which is a combination of both substitution and permutation that runs fast on software and hardware.

The communication aspect of the system, ie. the data-sharing part of the system, is governed by the RSA cryptosystem. This is based on the RSA algorithm, which is an asymmetric-key algorithm used for exchanging data without sharing the same keys. It is based on the Diffie-Hellman key exchange, by which the cryptography is public and is open for everyone to see, and yet it cannot be broken into. This kind of public key cryptography is required for communication over insecure channels such as the Internet.

(7)

Fig. 3. Algorithm Flow Diagram

C. System Implementation V. CONCLUSION

The system is entirely implemented using Microsoft’s .NET

platform. Technologies used includes C# for scripting the communication between the ASP server pages and the SQL back-end, ASP.NET for flexible server-side scripting and SQL Server for a robust back-end.

C# has long been hailed as a feature-complete and reliable general-purpose programing language. It is also among the best for building large, distributed and scalable systems. It also contains the necessary libraries that we require to implement our system. Among these are the SQL libraries and cryptography libraries (which includes AES encryption). ASP.NET is used for server-side scripting, generating the front-end. It is based on HTML syntax and the extension used is ’.aspx’. ASP pages with this extension are normally static web pages with content or component placeholders. These areas are automatically generated by communication with the back-end. The database used is Microsoft SQL Server, which is one of the most reliable relational database management systems (RDBMS). The database stores information about everything on the Cloud Server. This includes user registration information - both sender and receiver, information about the data (file number, name, description). This database is accessed by queries given via the C# SQL library, which is the middle ground between the ASP web pages and the database. The implementation works as intended with functionalities such as security device revocation and minimization of trust failure.

In this paper, we have attempted to create a more secure and foolproof cryptosystem which uses two-factor security authentication. It uses two fundamentally different algorithms (AES and RSA) to create a hybrid security. Specifically, this two-factor scheme involves a private key and a unique security device. The cryptosystem is focused on the strength of the private key, as it is crucial in the web of trust. We have introduced a new entity into the private key, which is a human-set password. This human-human-set password is required to overcome the shortcomings of trust failure, ie. when one or more trusted third-parties fail to be secure or compromise information. Future work can possibly be in the form of a practical real-world implementation or an attempt to speed up the cryptosystem. Considering we have many algorithms involved, optimizations can be done to make the system faster.

REFERENCES

[1] Joseph K. Liu, Kaitai Liang, Willy Susilo, Jianghua Liu, Yang Xiang,

Two-Factor Data Security Protection Mechanism for Cloud Storage System, 10.1109/TC.2015.2462840, IEEE Transactions on Comput-ers, 2015

[2] S. S. Al-Riyami and K. G. Paterson, Certificateless public key cryptog-raphy, In ASIACRYPT, volume 2894 of Lecture Notes in Computer Science, pages 452473. Springer, 2003.

[3] C. Gentry, Certificate-based encryption and the certificate revocation problem, In EUROCRYPT, volume 2656 of Lecture Notes in Computer Science, pages 272293. Springer, 2003. [4] C. Wang, Q. Wang, K. Ren, N. Cao, and W. Lou, Toward secure

and dependable storage services in cloud computing, IEEE T. Services Computing, 5(2):220232, 2012.

[5] L. Ferretti, M. Colajanni, and M. Marchetti, Distributed, concurrent, and independent access to encrypted cloud databases, IEEE Trans. Parallel Distributed Systems, 25(2):437446, 2014.

(8)

[6] V. Varadharajan and U. K. Tupakula, Security as a service model for cloud environment, IEEE Transactions on Network and Service Management, 11(1):6075, 2014.

[7] M. Naor and G. Segev, Public-key cryptosystems resilient to key leakage, In CRYPTO, volume 5677 of Lecture Notes in Computer Science, pages 1835. Springer, 2009.

[8] J. K. Liu, M. H. Au, and W. Susilo, Self-generated-certificate public key cryptography and certificateless signature/encryption scheme in the standard model: extended abstract, In ASIACCS, pages 273283. ACM, 2007.

[9] J. K. Liu and J. Zhou, Efficient certificate-based encryption in the standard model, In SCN, volume 5229 of Lecture Notes in Computer Science, pages 144155. Springer, 2008.

[10] D. Boneh, X. Ding, and G. Tsudik, Fine-grained control of security capabilities, ACM Trans. Internet Techn., 4(1):6082, 2004.

[11] S. S. M. Chow, C. Boyd, and J. M. G. Nieto, Security-mediated certificateless cryptography, In Public Key Cryptography, volume 3958 of Lecture Notes in Computer Science, pages 508524. Springer, 2006.

[12] W.-S. Yap, S. S. M. Chow, S.-H. Heng, and B.-M. Goi, Security mediated certificateless signatures, In ACNS, volume 4521 of Lecture Notes in Computer Science, pages 459477. Springer, 2007.

[13] Y. Dodis, J. Katz, S. Xu, and M. Yung, Key-insulated public key cryptosystems, In EUROCRYPT, volume 2332 of Lecture Notes in Computer Science, pages 6582. Springer, 2002.

[14] D. Boneh and M. Franklin, Identity-based encryption from the weil pairing, In CRYPTO 01, volume 2139 of LNCS, pages 213229. Springer, 2001.

[15] A. Boldyreva, V. Goyal, and V. Kumar, Identity-based encryption with efficient revocation, In ACM Conference on Computer and Communi-cations Security, pages 417426. ACM, 2008. [16] B. Libert and D. Vergnaud, Adaptive-ID secure revocable

identity-based encryption, In CT-RSA, volume 5473 of Lecture Notes in Computer Science, pages 115. Springer, 2009. [17] J. H. Seo and K. Emura, Efficient delegation of key generation

and revocation functionalities in identity-based encryption, In CT-RSA, volume 7779 of Lecture Notes in Computer Science, pages 343358. Springer, 2013.

[18] M. Mambo and E. Okamoto, Proxy cryptosystems: Delegation of the power to decrypt ciphertexts, IEICE Transactions, E80-A(1):5463, 1997.

[19] M. Blaze, G. Bleumer, and M. Strauss, Divertible protocols and atomic proxy cryptography, In EUROCRYPT, volume 1403 of LNCS, pages 127144. Springer, 1998.

[20] M. Green and G. Ateniese, Identity-based proxy re-encryption, In ACNS 07, volume 4512 of LNCS, pages 288306. Springer, 2007. [21] Q. Tang, P. H. Hartel, and W. Jonker, Inter-domain

identity-based proxy re-encryption, In Inscrypt, volume 5487 of Lecture Notes in Computer Science, pages 332347. Springer, 2008.