Identity-based conditional proxy re-encryption

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Identity-based conditional proxy re-encryption" – news · newspapers · books · scholar · JSTOR (June 2015) (Learn how and when to remove this message)

Identity-based conditional proxy re-encryption (IBCPRE) is a type of proxy re-encryption (PRE) scheme in the identity-based public key cryptographic setting.^[1] 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.

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.^[2]

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: M₁, M₂, … M_n. 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 C₁, C₂, …, C_n to a new form denoted as D₁, D₂, …, D_n. Bob can then download D₁, D₂, …, D_n, decrypt them, and recover the messages M₁, M₂, … M_n 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.

One of the key features of IBCPRE is that when a data owner encrypts messages, the encryption is done for themselves and only they themselves can decrypt the encrypted messages using their secret key. There is no need for them to know in advance about who that they would like to share the encrypted messages with. In other words, picking the friends to share with by them can be done after they encrypt the messages and uploads them 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 can choose multiple friends to share their data with. For multiple friends to share the encrypted messages with, the owner simply needs to generate a re-encryption key for each of their friends and send all the re-encryption keys to the server for carrying out the re-encryption. The number of re-encryption keys that they need to generate depends on the number of friends that they want 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 can control the exact set of encrypted messages that they want to share with any particular friends of theirs, with great flexibility.

Consider a user Alice who encrypts some messages M₁, M₂, …, M_t with a tag ‘Private’, M_t+1, M_t+2, …, M_m with a tag ‘toShareWithFamily’, M_m+1, M_m+2, …, M_n 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 C₁, C₂, …, C_t, C_t+1, …, C_m, C_m+1, …, C_n to a server.

When Alice is about to share M_m+1, M_m+2, …, M_n 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 C_m+1, C_m+2, …, C_n for transforming them into another form, D_m+1, D_m+2, …, D_n 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 C₁, C₂, …, C_t, C_t+1, …, C_m 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.

A related concept to proxy re-encryption called decrypt right delegation was introduced by Mambo and Okamoto^[3] in 1997. Then in 1998, Blaze, Bleumer and Strauss^[4] 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.^{[5][6][7][8][9][10][11][12]}

In 2007, Green and Ateniese^[13] and Ivan and Dodis^[9] 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^[14] and Mizuno and Doi.^[15]

Type-based PRE^[16] and conditional PRE (CPRE)^[17] 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.,^[18] and achieved CCA security in the standard model, and the other by Shao et al.^[19] and achieved CCA security in the random oracle model.

• ID-based encryption
• ID-based cryptography
• Proxy re-encryption