Identity-based conditional proxy re-encryption

Identity-based conditional proxy re-encryption (IBCPRE) is a type of proxy re-encryption (PRE) scheme in the identity-based public key cryptographic setting. An IBCPRE scheme is a natural extension of proxy re-encryption on two aspects. The first aspect is to extend the proxy re-encryption notion to the identity-based public key cryptographic setting. The second aspect is to extend the feature set of proxy re-encryption to support conditional proxy re-encryption. By conditional proxy re-encryption, a proxy can use an IBCPRE scheme to re-encrypt a ciphertext but the ciphertext would only be well-formed for decryption if a condition applied onto the ciphertext together with the re-encryption key is satisfied. This allows fine-grained proxy re-encryption and can be useful for applications such as secure sharing over encrypted cloud data storage.

Introduction

A public-key encryption scheme allows anyone who has the public key of a receiver to encrypt messages to the receiver using the public key in such a way that only the corresponding private key known only to the receiver can decrypt and recover the messages. The public key of a user, therefore, can be published for allowing everyone to use it for encrypting messages to the user while the private key of the user has to be kept secret for the decryption purpose. Both the public key and the corresponding private key of the user are generated by the user in general .[1]

Under the identity-based cryptographic setting, the public key of the user can be an arbitrary string of bits provided that the string can uniquely identify the user in the system. The unique string, for example, can be an email address, a phone number, and a staff ID (if used only internally within an organization). However, the corresponding private key is no longer generated by the user. From the public key, which is a unique binary string, there is a key generation center (KGC), which generates and issues the private key to the user. The KGC has a public key, which is assumed to be publicly known, and the encryption and decryption then work under the unique binary string defined public key and the corresponding private key, respectively, with respect to the KGC’s public key.

Proxy Re-encryption allows a ciphertext, which originally can only be decrypted by a user, to be transformed by a public entity, called proxy, to another ciphertext so that another user can also decrypt. Suppose the two users are Alice and Bob. Alice has some messages: M1, M2, … Mn. She intends to encrypt them under her public key, and then upload the encrypted messages to some server.

Now when Alice wants to share these n encrypted messages with Bob, Alice can use a proxy re-encryption scheme to allow the server to re-encrypt these n encrypted messages so that Bob can decrypt these re-encrypted messages directly using his own private key.

To do so in the proxy re-encryption scheme, Alice uses her private key and the public key of Bob to generate a re-encryption key. Alice then sends the re-encryption key to the server. Upon receiving this re-encryption key, the server uses the key to transform all the n encrypted messages C1, C2, …, Cn to a new form denoted as D1, D2, …, Dn. Bob can then download D1, D2, …, Dn, decrypt them, and recover the messages M1, M2, … Mn using his private key.

In an identity-based conditional proxy re-encryption (IBCPRE) system, users set their public keys as unique identities of the users. One of the main advantages of using identity-based cryptographic algorithms is the elimination of public key certificates which can help enhance the usability of the target security applications. The term ‘Conditional’ in IBCPRE refers to an additional feature, which allows each encrypted message to have a ‘tag’ associated with. In addition to the tag, each re-encryption key also has a ‘tag’ attached. The IBCPRE is designed so that only if the tag of an encrypted message matches with the tag of a re-encryption key can the encrypted message be re-encrypted.

Features

One of the key features of IBCPRE is that when Alice as a data owner encrypts messages, the encryption is done for herself and only Alice herself can decrypt the encrypted messages using her secret key. There is no need for Alice to know in advance about who that she would like to share the encrypted messages with. In other words, picking the friends to share with by Alice can be done after she encrypts the messages and uploads to the Server.

Another feature of IBCPRE is that it supports end-to-end encryption. The server which stores the encrypted messages cannot decrypt the messages both before and after the re-encryption.

IBCPRE supports one-to-many encryption. The data owner Alice can choose multiple friends to share her data with. For multiple friends to share the encrypted messages with, Alice simply needs to generate a re-encryption key for each of her friends and sends all the re-encryption keys to the server for carrying out the re-encryption. The number of re-encryption keys that Alice needs to generate depends on the number of friends that Alice wants to share the encrypted messages with. It does not depend on the number of encrypted messages. One re-encryption key will allow the Server to convert all the encrypted messages provided the tag of the encrypted messages and the tag of the re-encryption key matches.

The conditional ‘tag’ of the IBCPRE facilitates the fine-grained access of encrypted messages. By setting different tag values onto different encrypted messages, the data owner Alice can control the exact set of encrypted messages that she wants to share with any particular friends of her with great flexibility.

Applications

Consider a user Alice who encrypts some messages M1, M2, …, Mt with a tag ‘Private’, Mt+1, Mt+2, …, Mm with a tag ‘toShareWithFamily’, Mm+1, Mm+2, …, Mn with a tag ‘toShareWithFriend’, using IBCPRE under her unique identity, which is considered as the public key of Alice. Alice then uploads the corresponding encrypted messages C1, C2, …, Ct, Ct+1, …, Cm, Cm+1, …, Cn to a server.

When Alice is about to share Mm+1, Mm+2, …, Mn with another user Bob, who becomes her friend recently, Alice generates a re-encryption key using IBCPRE with an associated tag ‘toShareWithFriend’. This generation is done by taking as input Alice’s private key and Bob’s identity. Then Alice sends the re-encryption key to the server. By using the re-encryption key, the server runs the IBCPRE re-encryption function on Cm+1, Cm+2, …, Cn for transforming them into another form, Dm+1, Dm+2, …, Dn so that Bob can decrypt them directly using his private key. This transformation can be done as the tag associated with the encrypted messages, namely ‘toShareWithFriend’, matches with the tag associated with the re-encryption key.

Note that the server cannot transform C1, C2, …, Ct, Ct+1, …, Cm to another form for Bob to decrypt using the re-encryption key because the tag of these m encrypted messages, namely ‘Private’ or 'toShareWithFamily', does not match with the tag of the re-encryption key. Also note that the server cannot retrieve any of the messages at any time.

IBCPRE has been used for secure cloud data sharing and related key management solutions in products of AtCipher Limited.

Schemes and security

A related concept to proxy re-encryption called decrypt right delegation was introduced by Mambo and Okamoto[2] in 1997. Then in 1998, Blaze, Bleumer and Strauss[3] formalized the notion of proxy re-encryption by giving a definition to the set of algorithms of a proxy re-encryption scheme. The authors also proposed a scheme for achieving chosen-plaintext security (CPA-security). Later on, various PRE schemes have been proposed.[4][5][6][7][8][9][10][11]

In 2007, Green and Ateniese[12] and Ivan and Dodis[8] independently proposed several proxy re-encryption schemes in the identity-based cryptographic setting. This type of scheme is usually called identity-based proxy re-encryption (IBPRE). The schemes are unidirectional, namely, the re-encryption key is for one party to re-encrypt cipher-texts to another party, but not vice versa. A new re-encryption key has to be generated for the other direction of re-encryption. In terms of security, the security analyses of the schemes have been done in the random oracle model. One is CPA-secure, multi-hop and the other is chosen-ciphertext-attack-secure (CCA-secure), single-hop. The schemes, however, are not collusion resistant. This means that if a proxy colludes with the corresponding delegatee, the private key of the delegator will be compromised. CPA-secure IBPRE schemes secure without random oracles were subsequently proposed by Matsuo[13] and Mizuno and Doi.[14]

Type-based PRE[15] and conditional PRE (CPRE)[16] are designed to ensure that the proxy can re-encrypt a ciphertext tagged with a specific condition only if the re-encryption key given by the delegator is tagged with the same condition. Two identity-based CPRE (IBCPRE) schemes were proposed to achieve conditional control in both re-encryption and identity-based re-encryption by Liang et al.,[17] and achieved CCA security in the standard model, and the other by Shao et al.[18] and achieved CCA security in the random oracle model.

See also

References

  1. ↑ "WHAT IS A DIGITAL ENVELOPE?". RSA Laboratories.
  2. ↑ M. Mambo; E. Okamoto (1997). Proxy cryptosystems: Delegation of the power to decrypt ciphertexts. IEICE Transactions E80-A(1). pp. 54–63.
  3. ↑ M. Blaze; G. Bleumer; M. Strauss (1998). Divertible protocols and atomic proxy cryptography. EUROCRYPT. LNCS, vol. 1403: Springer. pp. 127–144.
  4. ↑ B. Libert; D. Vergnaud (2011). Unidirectional chosen-ciphertext secure proxy re-encryption. IEEE Transactions on Information Theory 57(3): IEEE. pp. 1786–1802.
  5. ↑ T. Isshiki; M. H. Nguyen; K. Tanaka (2013). Proxy re-encryption in a stronger security model extended from CT-RSA2012. CT-RSA 2012. LNCS, vol. 7779: Springer. pp. 277–292.
  6. ↑ G. Hanaoka; Y. Kawai; N. Kunihiro; T. Matsuda; J. Weng; R. Zhang; Y. Zhao (2012). Generic construction of chosen ciphertext secure proxy re-encryption. CT- RSA. LNCS, vol. 7178: Springer. pp. 349–364.
  7. ↑ B. Libert; D. Vergnaud (2008). Unidirectional chosen-ciphertext secure proxy re-encryption. Public Key Cryptography. LNCS, vol. 4939: Springer. pp. 360–379.
  8. 1 2 A. A. Ivan; Y. Dodis (2003). Proxy cryptography revisited. NDSS: The Internet Society.
  9. ↑ R. Canetti; S. Hohenberger (2007). Chosen-ciphertext secure proxy re-encryption. ACM Conference on Computer and Communications Security: ACM. pp. 185–194.
  10. ↑ G. Ateniese; K. Fu; M. Green; S. Hohenberger (2006). Improved proxy re-encryption schemes with applications to secure distributed storage. ACM Trans. Inf. Syst. Secur. 9(1). pp. 1–30.
  11. ↑ G. Ateniese; K. Fu; M. Green; S. Hohenberger (2005). Improved proxy re-encryption schemes with applications to secure distributed storage. NDSS: The Internet Society.
  12. ↑ M. Green; G. Ateniese (2007). Identity-based proxy re-encryption. ACNS. LNCS, vol. 4521: Springer. pp. 288–306.
  13. ↑ T. Matsuo (2007). Proxy re-encryption systems for identity-based encryption. Pairing. LNCS, vol. 4575: Springer. pp. 247–267.
  14. ↑ T. Mizuno; H. Doi (2011). Secure and efficient IBE-PKE proxy re-encryption. IEICE Transactions 94-A(1): IEICE. pp. 36–44.
  15. ↑ Q. Tang (2008). Type-based proxy re-encryption and its construction. INDOCRYPT. LNCS, vol. 5365: Springer. pp. 130–144.
  16. ↑ J. Weng; R. H. Deng; X. Ding; C. K. Chu; J. Lai (2009). Conditional proxy re-encryption secure against chosen-ciphertext attack. ASIACCS: ACM. pp. 322–332.
  17. ↑ K. Liang; Z. Liu; X. Tan; D. S. Wong; C. Tang (2012). A CCA-secure identity-based conditional proxy re-encryption without random oracles. The 15th International Conference on Information Security and Cryptology (ICISC 2012), LNCS 7839: Springer. pp. 231–246.
  18. ↑ J. Shao; G. Wei; Y. Ling; M. Xie (June 2011). Identity-Based Conditional Proxy Re-Encryption. Proceedings of IEEE International Conference on Communications, ICC 2011: IEEE.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.