Multi-security-level cloud storage system based on improved proxy re-encryption

Abstract

Based on the characteristics and data security requirements of the cloud environment, we present a scheme for a multi-security-level cloud storage system that is combined with AES symmetric encryption and an improved identity-based proxy re-encryption (PRE) algorithm. Our optimization includes support for fine-grained control and performance optimization. Through a combination of attribute-based encryption methods, we add a fine-grained control factor to our algorithm in which each authorization operation is only valid for a single factor. By reducing the number of bilinear mappings, which are the most time-consuming processes, we achieve our aim of optimizing performance. Last but not least, we implement secure data sharing among heterogeneous cloud systems. As shown in experiment, our proposed multi-security-level cloud storage system implements services such as the direct storage of data, transparent AES encryption, PRE protection that supports fine-grained and ciphertext heterogeneous transformation, and other functions such as authentication and data management. In terms of performance, we achieve time-cost reductions of 29.8% for the entire process, 48.3% for delegation and 47.2% for decryption.

1 Introduction

1.1 Motivation

Cloud computing has provided very important support for information use by government agencies and enterprises. Security issues have restricted the development of public cloud services[1], and in particular, the problem of how to protect the privacy of users has become a significant factor in their reluctance to adopt cloud computing[2, 3]. Most existing solutions only focus on a single type of threat, and this has given rise to certain problems.

Recently, the protection of data privacy for users of cloud storage has become one of the most critical issues in public cloud applications and has impeded the rapid development of cloud services. There are still many weaknesses in the current methods for the protection of private user data in cloud environments [4, 5]. Theoretical research has developed many algorithms for cloud storage security requirements, such as distributed systems with information flow control (DIFC) [6], attribute-based encryption (ABE) [7], proxy re-encryption (PRE) [8], fully homomorphic encryption [9], ciphertext search algorithms, and so on. However, the most common way to share stored ciphertext is to download the ciphertext data, decrypt it into plaintext, and then re-encrypt it before sending it to users to share. This process consumes a lot of network and computing resources and loses the advantage of cloud storage [10, 11].

With regard to the security issues around the privacy of users’ data in the cloud environment [6], and after investigation and study of the inadequacy of the existing solutions, we aim to develop a scheme that can protect data privacy in the cloud environment. This scheme should be able to resolve the core issues preventing users from trusting cloud services; in other words, we aim to allow the users themselves to have control over their data file. Simultaneously, from a practical point of view, basic fine-grained control must be implemented, and there is also a need to carry out optimization to achieve good performance and compatibility [12–14].

1.2 Methodology

We observe that all of the existing methods of protecting a user’s data in a cloud environment have limitations to a greater or lesser extent, and we therefore propose a scheme that can resolve all of these problems, including key control, fine-grained control, revoking of permissions, performance optimization, and compatibility.

Firstly, in our scheme, each user has a pair of identity-based encryption (IBE)-type private and public keys, and some users may also have another pair of public key encryption (PKE)-type private and public keys. These are all generated by a trusted third party, and all private keys are kept by users themselves. There is never a need to tell other users the private key. When a user updates data in the cloud, he or she can encrypt these data using the IBE-type public key and can compute a re-encryption key that does not leak the user’s secret key. The proxy also cannot obtain the plaintext during re-encryption. We also add fine-grained control, since each time the user computes the re-encryption key, this applies only to the data of the designated type. The proxy cannot transform data of one type to a ciphertext using a re-encryption key of the wrong type.

Secondly, our scheme can transform IBE-type ciphertext to PKE-type ciphertext; this feature means that our scheme has good compatibility, and it is straightforward to integrate our scheme with existing systems. Using optimization, we can reduce the use of bilinear mapping, which is a major influence on the performance of an algorithm, and our scheme therefore gives acceptable performance in real-world systems. We will describe this optimization in a later section.

Thirdly, we explicitly describe how to change and revoke permissions; when users do not want others to use data that were previously shared, the permissions can be conveniently changed.

We integrate all of these capabilities into a single scheme. Our main design goal is to help users achieve fine-grained access control to the storage and sharing of files in a cloud environment. Specifically, we aim to ensure that data are under the control of data owners, rather than cloud service providers. We also aim to create a scheme that has excellent performance and has all the relevant functions, such as permission revoking, type changing, data searches, and so on, to be appropriate for a real-world system.

This paper proposes an improved PRE algorithm to support fine-grained control and ciphertext heterogeneous transformation. A multi-security-level cloud storage system is designed that involves AES symmetric encryption and other algorithms. The user’s private data are protected, while control over the data remains in the hands of the user.

This paper is organized as follows. In Section 2, we introduce related work on data protection using PRE in the public cloud. We carry out a formal analysis of the modeling and the macro definition of our scheme in Section 3. In Section 4, we introduce the associated implementation issues, including the system architecture and feature model. In Section 5,we conducted a safety analysis of our scheme. Section 6 presents an evaluation of our scheme. Finally, Section 7 concludes the paper and discusses future work.

2 Related work

Encryption is one of the most commonly used methods for traditional privacy data protection. Typical research results for cloud data security protection methods based on cryptography algorithms can be divided into symmetric and public key encryption classes, according to the type of encryption used.

Based on a symmetric encryption system, Li et al. [7] realized secure storage of cloud data and isolation of encrypted cloud data by adopting a method involving multiple keys and file partitioning. Sookhak et al. [8] combined the “lazy undo”, “keychain” and “broadcast encryption” operations to achieve more secure updating and permission transformation of cloud data. Liu et al. proposed the TrustStore method and introduced a special key management service provider to realize different forms of key encryption for different files. These authors also verified the integrity of cloud data by creating hash checking information [9]. Although this scheme solved the problem of secure storage and access control over cloud data to a certain extent, symmetric encryption lacks flexibility when used in key management and an encryption algorithm. Therefore, in a cloud computing environment with fine-grained multi-tenant dynamic sharing and large-scale networks, this type of method has drawbacks.

In an asymmetric encryption system, the core idea of ABE is to realize public key encryption of data by using the attributes of the data as the public key. In addition, the Boolean paradigm of data attributes can be used to realize fine-grained access control based on cryptography. Wu proposed a mixed scheme using ABE and symmetric encryption, and achieved secure encrypted storage and fine-grained access control for cloud data [15]. The work in [16] uses an ABE scheme to realize the secure sharing of health documents in the cloud. In addition to ABE, PRE is also used to implement secure storage and access control for cloud data. The core idea of PRE is that a third party can be authorized to re-encrypt the encrypted stored data to achieve secure access to the encrypted data [17]. The fine-grained scheme proposed by Zhang is based on a pre-identity scheme with a pre-interactive conditional scheme and solves the problem of the early pre-scheme being unable to realize fine-grained access control over the encrypted cloud data [18]. Jiang and Guo [19] proposed a PRE scheme for realizing the confidentiality of the data access control conditions of the encryption cloud. Zuo [20] proposed a PRE scheme that can be used one way and re-encrypted many times, thus realizing multi-tenant sharing of cloud data that can be transmitted. Li et al. [21] proposed an attribute-based, fine-grained authorization keyword search scheme for cloud computing, and Ding et al. [22] proposed a multi-keyword fuzzy search scheme, thus realizing privacy protection for encrypted data in cloud.

A symmetric, searchable encryption algorithm was proposed by Shen et al. [23]. Xu et al. [24] improved this scheme and gave the security definition. This scenario applies to both the data searcher and the data producer, with the main drawback being that existing solutions find a compromise between performance and functionality. An asymmetric searchable encryption algorithm was proposed by Ni et al. [25] and was improved by [26]. The disadvantage of this scheme is that existing asymmetric searchable encryption algorithms require elliptic curve pairing, which performs worse than a hash function or block cipher. The fast asymmetric searchable encryption algorithm proposed by Masayuki [27] improves the performance of the asymmetric searchable encryption algorithm but is also vulnerable to a dictionary attack. Guo [28] proposed a multi-user, symmetric, searchable encryption algorithm that is mainly aimed at the scenario in which encrypted data are generated by a single producer and multiple parties search these data. This not only supports the encryption of indices and the generation of search tokens, but also allows the data owner to add and revoke search rights to the data for certain users.

No complete solution exists for the dynamic protection of the user’s data privacy. Crypt DB uses an onion-based security scheme to ensure different levels of data privacy. At the same time, this method uses homomorphic encryption to enable ciphertext to directly perform some simple operations, such as query and comparison, ensuring that data with a high privacy level is stored in memory as ciphertext. Holomorphic encryption refers to any operation that can be performed on plaintext on encrypted data without decryption [29]. Gasti et al. [30] proposed a feasible method for full mathematically homomorphic encryption, and this represented a decisive breakthrough in this technology. At present, software algorithms cannot perform complex calculations using ciphertext, so in order to encrypt the data in memory, many researchers have used hardware to ensure the privacy of dynamic data. XOM [31] guarantees that private data are still stored in memory as ciphertext and that data are decrypted by special hardware when entering the CPU for calculation.

3 Multi-security-level cloud storage system

Due to the diversity of tenants in the cloud environment, different tenants have different requirements for the security protection level of data, and even the same tenant has different requirements for the different data they own. In the cloud, user data exist in two forms: dynamic and static data. Static data refers to the information that does not participate in calculation and is mainly used for mass storage and convenient access, such as documents, pictures, video, reports, materials and so on stored by users for a long time. Dynamic data refers to the data that needs dynamic verification or participation in calculation, such as database files, program files, configuration files, etc. Our scheme for the protection of users data privacy in cloud storage includes the following: (1) normal interface and security interface: normal interface is used when users access public data, and security interface is used when they access data with a certain level of security; (2) security-level-based encrypted storage for static data, by applying encryption policies with different strengths to different user data, thus ensuring the user data confidentiality and high performance for the whole system; (3) a fine-grained access control mechanism for static data that combines PRE algorithms to support fine granularity and ciphertext heterogeneous conversion, web services technology, and secure plugging in client to protect the user’s privacy; (4) security-level-based segmentation storage for dynamic data that provides segmentation storage for different user data, based on sensitivity; and (5) secure search technology for dynamic data, thus providing secure search services without exposing the data information to the cloud platform. The scheme is illustrated in Fig. 1.

Fig. 1

The multi-security-level cloud storage system

In this paper, we focus solely on static data. The functional architecture based on multiple security levels is shown in Fig. 2. The functions on the front-end nodes of the system includes: (1) a user authentication module, (2) a client security plug-in module, (3) a multi-security-level encryption module, and (4) a data storage module. The PRE server includes the PRE service module and the client security plug-in module and provides a client security interface for users.

Fig. 2

Architecture of the static data storage system

3.1 Enhanced RBAC

In order to solve the data security problem of the medical cloud platform, it is necessary to combine the access control policy with the encryption mechanism to deal with the privacy leakage problem of data storage procedures in the cloud environment. On the one hand, the access control policy authenticates the user’s identity, which can ensure the confidentiality of the data (but the data stored in plaintext can be accessed by CSP, which cannot protect the privacy of the data). On the other hand, the data can be encrypted by encryption mechanism, and access control can be further strengthened by controlling the distributions of secret key. The access control model of medical cloud platform is shown in Fig. 3.

Fig. 3

The access control enhancement model of medical cloud platform

The platform realizes the access control and authorization for legal users of the system based on RBAC model. On the other hand, encryption is adopted to ensure the confidentiality of data in the cloud platform. The specific workflow is shown in Fig. 4.

Fig. 4

Access control model workflow in medical cloud platform

The system management module is operated in the system initialization stage to realize the creation of users and roles and generate the corresponding public information Mpp_R to the roles and the secret keys of the users and roles.

The user corresponding to each role in the Role Management Module Management System will establish the relationship between the user and the role to realize the addition and deletion of users in the role. The general permission distribution corresponding to the role is initialized by the system management.

Mpp_R, the public parameter that belongs to the date owners, is used to encrypt and store the date. Meanwhile, the date owners request the role management module to encrypt the data onto the corresponding role. The role management module determines which users are assigned to roles and which are excluded from its function to control user-to-role mapping.

The data requester uses the decryption key DK_U provided by the system and the public information Mpp_R of the role to decrypt the ciphertext from the cloud. It can be decrypted correctly when the data requester is a member of the data encryption or the role to which the data requester belongs inherit the ciphertext encryption role.

3.2 Design of the scheme

In this paper, the improved PRE algorithm supports fine-grained and ciphertext heterogeneous transformation. Based on the traditional identity-based PRE algorithm, fine-grained control and ciphertext heterogeneous transformation are added to allow fine-grained control of proxy authorization. Meanwhile, using the traditional public key system, the re-encrypted ciphertext can be decrypted.

IBE algorithm consists of four main functions:

• Setup_IBE(k): This algorithm generates system parameter pairs (params,mk), where k is a security parameter, and params is a collection of system parameters. This parameter will be used in later functions. mk is the system master security key, and is related to the security of the overall system.

• KeyGen_IBE(mk,params,ID): mk is the system master security key, params is the system parameter set, and ID is the user’s identity information. ID may include a mailbox, IP, ID number or other information. This algorithm generates the private key sk_ID.

• Enc_IBE(ID,params,M,t): For plaintext data M, we use the system parameter set params, identity information ID (public key), and a type value for fine-grained control t to compute M, which corresponds to the original ciphertext.

• Dec_IBE(sk_ID,params,C_ID): If the proxy authorizer needs to decrypt and view encrypted data, the system parameter set params and the private key he holds can be used to decrypt the original cipher.

The Setup and KeyGen algorithms are executed by a trusted third-party key generation center (KGC) during the initialization phase of the system. The system parameters are generated and sent to the system through a secure channel for later use, while users can use their identity information to apply for the private key corresponding to the identity in the KGC.

The traditional public-key cryptographic algorithm consists of three functions (KeyGen_PKE,Enc_PKE,Dec_PKE):

• KeyGen_PKE(k,aux): k is the security parameter, and aux is the corresponding parameter. This algorithm generates a pair of public and private key pairs (pk,sk), where pk is the public key, and sk is the private key.

• Enc_PKE(pk,aux,M): pk and aux are used to encrypt the plaintext M to get the ciphertext C_pk.

• Dec_PKE(sk,aux,C_PK): Using sk and aux, the ciphertext C_pk is decrypted to get the plaintext M.

This part of the function is used when converting the original ciphertext encrypted by the identity-based encryption algorithm into ciphertext that can be decrypted by the traditional algorithm, thus ensuring that the conversion process will not be affected by security problems.

The functions related to proxy re-encryption are KeyGen_PRO(), ReEnc(), ReDec() and ChaType():

• KeyGen_PRO(sk_ID,sk_i,pk_j,t,params): This uses the system parameter set params, the fine-grained parameter t, the identity-based private key sk_ID of the proxy authorizer, the private key sk_i of the traditional public key system, and the public key pk_j of the traditional public key system. This algorithm generates the PRE key rk_ID and sends it to the PRE server for storage.

• ReEnc(rk_ID,params,C_ID): This is the re-encryption function. Using rk_ID and the corresponding system parameters, the original ciphertext C_ID encrypted by IBE is re-encrypted into the ciphertext C_pk of the traditional public key system.

• ReDec(C_PK,params,sk_j): The decryption function of the re-encrypted ciphertext, using the private key sk_j of the agent receiver and the corresponding system parameters, is used to decrypt the ciphertext C_pk generated by re-encryption to the data plaintext M.

• ChaType(C_ID,params,t^′): This is the fine-grained dynamic change function. Using the changed fine-grained t^′ and system parameters, the fine-grained information of ciphertext C_ID is changed, and the fine-grained t of ciphertext C_ID is changed to the fine-grained t^′ of ciphertext $C_{\text {ID}}^{'}$.

3.3 Implementation of the scheme

The basic structure described in the previous section is used for a detailed overview of the proposed algorithm:

• Set_IBE(k): This algorithm is run by the KGC, and generates a public parameter:

  $$ \text{params}=(G_{1},G_{T},p,g,H_{1},H_{2},\hat{e},\text{pk}) $$

  (1)

  where pk=g^a,is the public key for the KGC. The security parameter k is generated by a random algorithm in this system. p is a prime, producing the multiplication groups G₁ and G_T of order q. g is a generator of G₁, and a number $\alpha \in Z_{q}^{*}$ is randomly generated as the main safety parameter mk. A bilinear mapping function $\hat {e} : G_{1} \times G_{2} \rightarrow G_{T}$ and two hash function $H_{1}:\{0,1\}^{*} \rightarrow G_{1},H_{2}:\{0,1\}^{*} \rightarrow Z_{P}^{*}$ are used.

• KeyGen_IBE(mk,params,id): When the user logs in, the KGC obtains the user’s legitimate identity information id, and uses params and the main security parameter mk to generate the key pair (pk_id,sk_id) for the user, where

  $$ \mathrm{pk_{id}}=H_{1}(\text{id}),\mathrm{sk_{id}=pk_{id}^{\alpha}} $$

  (2)

• KeyGen_PKE(params): This is run by the KGC when the user submits the application. Like the public and private keys based on identity type, (pkid′,skid′) is generated by generating a random number $\gamma \in Z_{p}^{*}$ and calculating

  $$ \text{pk}_{\text{id}}'=g^{\text{sk}_{\text{id}}'},\text{sk}_{\text{id}}'=\gamma $$

  (3)

• Enc_IBE(pk_id,sk_id,params,m,t): This algorithm is executed when the data owner encrypts the data. The data owner uses his or her private key pair (pk_id,sk_id) based on identity type, type information t for fine-grained control, and a random number $\gamma \in Z_{p}^{*}$. The data are encrypted in plaintext to cipher c=(c₁,c₂,c₃), where

  $$ c_{1}=g^{r},c_{2}=m \cdot \hat{e} (\text{pk}_{\text{id}},\text{pk})^{r \cdot H_{2}(\text{sk}_{\text{id}})\|t},c_{3}=t $$

  (4)

• Dec_IBE(sk_id,params,c): This function is used when the user decrypts a file that he or she has encrypted. Of course, the result could be obtained by requesting authorization and then re-encrypting the data, but the performance would be affected. When decrypting, the private key sk_id of the data owner is entered, based on the identity type and the relevant system parameter params, and the cipher text params can then be decrypted to plaintext m using the following calculation:

  $$ m=\frac{c_{2}}{\hat{e}(\mathrm{PK_{id}},\text{pk})^{r \cdot H_{2}(\mathrm{sk_{id}})\|t}} $$

  (5)

• KeyGen_PRO(sk_id,skid′,pkid′,t,params): When the data owner authorizes access, this step uses the $\phantom {\dot {i}\!}\text {sk}_{\text {id}_{i}}$ for the data owner based on the identity type, skid_i′ of the traditional type, pkid_j′ of the agent receiver’s traditional type and the fine-grained type t, to calculate the agent from user i to user j to re-encrypt and re-encrypt the key.

  $$ \text{rk}_{\text{id}_{i} \rightarrow \text{id}_{j}}=(t,\text{sk}^{-H_{2}(\text{sk}_{\text{id}} \parallel t)} \cdot H_{1}(\text{pk}_{\text{id}_{j}}^{\prime\text{sk}_{\text{id}_{i}}\prime}),\text{pk}_{\text{id}_{i}}\prime) $$

  (6)

• $\text {ReEnc}(C_{i},\text {rk}_{\text {id}_{i} \rightarrow \text {id}_{j}},\text {params})$: This function is transparently executed on the server side, and encrypts the original ciphertext encrypted by user i into ciphertext that user j can decrypt. The ciphertext c_i=(c_i1,c_i2,c_i3) is encrypted by user i and the agent of type t from user i to j re-encrypt the key $\text {rk}_{\text {id}_{i} \rightarrow \text {id}_{j}}$ and relevant system parameters are used as input, and the re-encrypted c_j=(c_j1,c_j2,c_j3) is the output after calculation.

  $$ {\left\{\begin{array}{l} c_{j1}=c_{i1}\\ c_{j2}=c_{i2} \cdot \hat{e} \left(c_{i1},\text{sk}_{\text{id}_{i}}^{-H_{2}(\text{sk}_{\text{id}_{i}}c_{\text{is}})} \cdot H_{1}\left(\text{pk}_{\text{id}_{i}}^{'\text{sk}_{\text{id}_{i}}^{'}}\right)\right)\\ \quad \ =m \cdot \hat{e} (g^{\alpha},\text{pk}_{\text{id}_{i}}^{\gamma}H_{2}(\!\text{sk}_{\text{id}_{i}} \parallel t)\cdot \hat{e}\left(g^{\gamma},\text{sk}_{\text{id}_{i}}^{-H_{2}(\text{sk}_{\text{id}_{i}}\parallel t)}\cdot H_{1}\left(\text{pk}_{\text{id}_{i}}^{'\text{sk}_{\text{id}_{i}}^{'}}\right)\!\right)\\ \quad \ =m \cdot \hat{e}\left(g^{\gamma},\left(\text{pk}_{\text{id}_{i}}^{'\text{sk}_{\text{id}_{i}}^{'}}\right)\right)\\ c_{j3}=\text{pk}_{\text{id}_{i}}^{'} \end{array} \right.} $$

  (7)

• $\mathrm {Dec_{PKE}}(c_{j},\text {sk}_{\text {id}_{j}}^{'},\text {params})$: The decryption function of the ciphertext is re-encrypted. After receiving the ciphertext c_j=(c_j1,c_j2,c_j3) sent by the proxy server, the proxy receiver uses the private key skid_i′ of a traditional cryptography system to calculate the data plaintext using the following algorithm:

  $$ m^{'}=\frac{c_{j2}}{\hat{e}(c_{j1},H_{1}(\text{pk}_{\text{id}_{i}}^{'\text{sk}_{\text{id}_{j}}^{'}}))}=\frac{m \cdot \hat{e}(g^{\gamma},H_{1}(\text{pk}_{\text{id}_{i}}^{'}\text{sk}_{\text{id}_{j}}^{'}))}{\hat{e}(g^{\gamma},H_{1})(\text{pk}_{\text{id}_{i}}^{'\text{sk}_{\text{id}_{j}}'})}=m $$

  (8)

• $\phantom {\dot {i}\!}\text {ChaType}(C_{\text {ID}},t^{'})$: This function is implemented when the data owner modifies the type of a file in order to change the authorization state or revoke authorization. The original ciphertext c=(c₁,c₂,c₃) and the new fine-grained control type t^′ is used to calculate the new ciphertext c^′=(c1′,c2′,c3′) using the following steps:

  $$ \left\{\begin{array}{l} c_{1}'=c_{1},\\ c_{2}'=c_{2}(\hat{e}(\text{pk}_{\text{id}},\text{pk})^{r \cdot H_{2}(\text{sk}_{\text{id}} \parallel t)})^{\frac{t^{'}}{t}}\\ c_{3}'=c_{3} \end{array} \right. $$

  (9)

The transformation from c₂ to c2′ can also be obtained using $c_{2}' = m\frac {t}{t'} \cdot c_{2}\frac {t'}{t}$.

4 Implementation

In this section, we introduce the system modules and functions in detail, and describe their characteristics and optimization in cloud environments. We use Cassandra as our distributed network database.

4.1 Overall architecture

The architecture of the improved PRE module is shown in Fig. 5. The user encrypts the data using key encapsulation via the client, by taking the following steps: (1) using AES to encrypt user data, (2) using the proxy server to re-encrypt the symmetric key for the encrypted file, and (3) storing the data from steps (1) and (2) together as the original ciphertext in the data center cluster.

Fig. 5

Architecture of PRE for data protection

Before the data owner stores data in the cloud, the file must first be encrypted with a symmetric encryption key (SEK). We call this the ciphertext body. The SEK is used with the private key in the proposed improved PRE scheme, to form the ciphertext of the SEK, SEKey, and the body and the SEKey are then stored together in the cloud. To share this file with recipients, the data owner computes re-encryption keys for trusted recipients. The proxy server is held by the cloud service provider and runs transparent proxy services. When the user sends a request to the cloud, the request distribution server sends this request to the proxy, which checks whether this user has the authority to access the requested file. If so, the proxy service obtains the re-encryption key from a database of re-encryption keys, and fetches the data, including the body and SEKey, from the data center. The proxy server then re-encrypts the SEKey to a type of ciphertext that the recipient can decrypt with his own secret key. All of these processes taking place on the proxy server are transparent to the user. In this way, the user receives the required data files but they do not leave the proxy. When the recipient has gained access to the required files, he or she can decrypt the data using the client software.

In order to achieve the purpose of the fine-grained control, we add an element named “type” to the algorithm. Users can add a file to a type or many files to a single type. The type is included in the ciphertext when a data file is encrypted, and each re-encryption key for authorization is also of the same type, since the proxy cannot re-encrypt the data file successfully using a re-encryption key and data that do not match.

In addition, if after recipient has finished processing the data file need feedback to the user, and the data will then be used by a user with a different type, this can be achieved directly by computing c^′=(c1′,c2′,c3′), where

$c_{1}'=c_{1},c_{2}'=m^{t \cdot t'^{-1}} \cdot c_{2}^{t' \cdot t^{-1}},c_{3}'=c_{3}$

This means that we can sidestep the process of encryption using the recipient’s public key and sharing with the user, followed by decryption and sharing again. Any more, if user wants to recover authority or wants to change the type, this can be conveniently achieved by computing c^′=(c1′,c2′,c3′), where

$\phantom {\dot {i}\!}c_{1}'=c_{1},c_{2}'=c_{2} \cdot (e(\text {pk}_{\text {id}},\text {pk})^{r \cdot H_{2}(\text {sk}_{\text {id}} \parallel t)^{t' \cdot t^{-1}}}),c_{3}'=c_{3}$

4.2 System processing flow

Key management is always an important issue in system implementation. In our system, we implement a KGC to generate and distribute key pairs. The user’s IBE-type public key is the email address that was given when registering, and the IBE-type secret key is generated by KGC and held by the users themselves. The user’s PKE-type secret key and public key are generated and distributed by CA. The search feature in our system was implemented by using the Cassandra NoSQL database, in which we can search for a data value by key. We also implement the user authorization function and friend management scheme in order to allow sharing of data files.The process used in our scheme is illustrated in Fig. 6.

Fig. 6

The system processing flow

The process nouns in Fig. 6 are explained in the following.

body=symmetricEnc(M,SEK)

SEKey=Enc_ibe(id,params,SEK.t)

$\text {rk}_{(\text {id}_{i} \rightarrow \text {id}_{k})}=\mathrm {KeyGen_{pre}}(\text {sk}_{(\text {id}_{i})},\text {sk}_{\text {id}_{i}}',\text {pk}_{(\text {id}_{j})}',t,\text {params})$

REQ=FileAccessREQ(fileKey,userName)

C=body,SEKey=getTuple(REQ)

$\text {SEKey}_{j}=\text {ReEnc}(C_{i},\text {rk}_{(\text {id}_{i} \rightarrow \text {id}_{j})},\text {params})$

SEK=Dec_pke(SEKey_j,skid_i′,params)

M=symmetricDec(M,SEK)

$\phantom {\dot {i}\!}\text {TCkey}=e(\text {pk}_{\text {id}},\text {pk})^{r \cdot H_{2}(\text {sk}_{\text {id}} \parallel t)t' \cdot t^{-1}}$

REQT=TypeREQ(userName,FileList,TCkey)

Ci′=chaType(C_i,t^′)

5 Security analysis

Theorem 1

If the initial ciphertext and private key are correctly generated and meet the following conditions: $C\leftarrow \mathrm {Enc_{IBPRE}(PP_{IBPRE}},U_{\text {RoleId}},m,\alpha), \mathrm {SK_{IBPRE}^{UserId}} \leftarrow \mathrm {Extract_{IBPRE}(MK_{IBPRE},UserId)}$, and UserId∈U_RoleId. Then, the plaintext m can be calculated by executing the algorithm $\mathrm {Dec_{IBPRE} (PP_{IBPRE},UserId, SK_{IBPRE}^{UserId},}C,U_{\text {RoleId}})$.

Proof

if UserId∈U_RoleId, then we have

$(e(c_{1},h^{(\Delta _{\gamma },U_{\text {RoleId}})}) \cdot e(\mathrm {SK_{IBPRE}^{UserId}},c_{2}))^{\frac {1}{\prod \limits _{j=1,j\neq i}^{n} H_{1}(\text {UserId}_{j})}}\\ =(e(g^{-k \cdot \gamma },h^{\Delta \gamma (\mathrm {UserId,U_{RoleId}})})\cdot e(g^{\frac {1}{\gamma + H_{1}(\text {userId})}}, h^{k \cdot \prod \limits _{j=1}^{n} \gamma +H_{1}(\text {UserId}_{j})}))^{\frac {1}{\prod \limits _{j=1,j\neq i}^{n} H_{1}(\text {UserId}_{j})}}\\ =(e(g^{-k \cdot \gamma },h^{\Delta \gamma (\mathrm {UserId,U_{RoleId}})})\cdot e(g,h)^{k \cdot \prod \limits _{j=1}^{n} \gamma +H_{1}(\text {UserId}_{j})})^{\frac {1}{\prod \limits _{j=1,j\neq i}^{n} H_{1}(\text {UserId}_{j})}}\\ =(e(g,h)^{k \cdot \prod \limits _{j=1}^{n} H_{1}(\text {UserId}_{j})})^{\frac {1}{\prod \limits _{j=1,j\neq i}^{n} H_{1}(\text {UserId}_{j})}}\\ =v^{k}\\ m=\frac {c_{3}}{v^{k}}$

Now, if UserId∈U_RoleId,then $\mathrm {Dec_{IBPRE}}(\mathrm {PP_{IBPRE},} \text {UserId},\text {SK}_{\text {IBPRE}}^{\text {UserId}},U_{\text {RoleId}})=m$. Similarly, the selected receiver can decrypt the correctly generated initial ciphertext into the original plaintext. □

Theorem 2

If the ciphertext is correctly generated by algorithm $\phantom {\dot {i}\!}\mathrm {{ReEnc_{IBPRE}}}():C' \leftarrow \mathrm {ReEnc_{IBPRE}} (\text {PP}_{\text {IBPRE},d_{\text {UserId} \rightarrow U'_{\text {RoleId} \mid \alpha '}},C,U_{\text {RoleId}}})$, and private key is correctly generated by algorithm $\mathrm {Extract_{IBPRE}}(): SK_{\text {IBPRE}}^{\text {UserId}'} \leftarrow \mathrm {Extract_{IBPRE}}(\mathrm {MK_{IBPRE},}\\ \text {UserId}')$,$d_{\text {UserId} \rightarrow U'_{\text {RoleId} \mid \alpha '}} \leftarrow \mathrm {RKExtract_{IBPRE}}(\mathrm {PP_{IBPRE},UserId,SK_{IBPRE}^{UserId}},U'_{\text {RoleId}},\alpha '),\\ \quad C \leftarrow \mathrm {Enc_{IBPRE}}(\mathrm {PP_{IBPRE}},U_{\text {RoleId}},m,\alpha),and\\ \mathrm {SK_{IBPRE}^{UserId}} \leftarrow \mathrm {Extract_{IBPRE}(MK_{IBPRE},UserId)}$ are all executed correctly, and they are valid for any UserId∈U_RoleId,α=α^′,and UserId^′∈URoleId′. Then, execute $\mathrm {ReDec_{IBPRE}}(\mathrm {PP_{IBPRE},UserId',SK_{IBPRE}^{UserId'}},C',U'_{\text {RoleId}})$, thus we would obtain plaintext m.

6 Simulation results and discussion

In this section, we evaluate the performance of the encryption and decryption by the data owner, re-encryption by the cloud proxy, and the performance of decryption by the recipients. These steps are implemented using the library of miracle on IBE and an elliptic curve defined on a 512-bit prime field with a generator order of 160 bits. The embedded degree of the curve is two. The experimental environment has the following configuration: a Ubuntu virtual machine (3.0 GHz vCPU, 1 GB RAM) running on a PC (Intel i5 3.0 GHz, 8 GB RAM).

6.1 Performance of encryption by data owner

The algorithm Enc(pk,aux,M) is executed on the client side. It does not reduce the use of bilinear mapping, and the calculation time is not significantly optimized.

Figure 7 shows the computational overhead of the data owner when performing different frequency encryption operations on the system. This step is executed when the data owner uploads a data file; the data must first be encrypted with a random 128-bit AES symmetric key, and this key is then encrypted using the encryption algorithm in our scheme. Our scheme consumes about the same amount of time as the standard PRE scheme; this step takes less than 20 ms, which is acceptable for a real system.

Fig. 7

Performance of encryption by data owner

6.2 Performance of decryption by data owner

Decryption of the original ciphertext function is performed by the data owner via the client. The algorithm Dec_PKE(sk,aux,C_PK) cannot reduce the number of bilinear mappings. Figure 8 shows the computational overhead of the data owner when performing different frequency decryption operations on our system. This step is executed when the data owner downloads and decrypts data. In this step, the ciphertext is not transformed by the proxy server. The proposed scheme consumes about the same amount of time as the standard PRE scheme; this step takes less than 15 ms, and since this is carried out only once per file, this is an acceptable value.

Fig. 8

Performance of decryption by data owner

6.3 Performance of delegation by data owner

Figure 9 shows the computational overhead due to the data owner performing different frequency delegation operations on the system. This step is executed by the data owner after the encrypted data file is uploaded. The delegation progress involves generating a PRE key and sending it from the data owner to a recipient of the class file of a given type. The more recipients with whom the data owner wants to share files, the more times this sharing step is performed, meaning that this step has a significant impact on the overall client performance. As we can see from Fig. 8, our solution takes less than half the time required by the standard PRE solution; the proposed solution takes around 20 ms, while standard PRE takes around 45 ms, meaning that the optimization of this step is significant.

Fig. 9

Performance of delegation by data owner

6.4 Performance of re-encryption by cloud proxy

Figure 10 shows the computational overhead of the cloud proxy as it performs different frequency re-encryption operations in our scheme. This step transforms the ciphertext from the data owner to the recipients. The time costs of our scheme in this process are also similar to those of standard PRE, with an average time of about 12 ms. As is well-known, the computing resources of cloud platforms are abundant, and the development of hardware is also taking place rapidly. Cloud service providers can therefore take many measures to speed up this process, such as dedicating more hardware resources or using visualization, meaning that the cost of this step would not be onerous to the cloud service provider.

Fig. 10

Performance of re-encryption

6.5 Performance of decryption by recipient

The decryption algorithm is executed when the recipient decrypts the re-encrypted data shared by the data owner, and this algorithm is executed by the client. As can be seen from Fig. 11, our scheme is about 47% better than the standard PRE scheme. The average times required by our scheme and the standard PRE scheme are about 21 and 40 ms respectively, giving a very high proportion of optimization.

Fig. 11

Performance for decryption by recipient

7 Conclusion

The aim of this paper is to develop an improved PRE scheme for protecting users’ private data. Our scheme is unique in that it integrates fine-grained delegation based on the element of type and heterogeneous features that can transform ciphertext from IBE-type to PKE-type text. The fine-grained features mean that the data owner can share private data using a fine-grained approach, e.g., adding a single file or a class of files. The feature of heterogeneity greatly improves the performance of the algorithm and at the same time makes it more convenient and compatible with the system developed based on the traditional PKE encryption algorithm. An interesting direction for future work would be to make this scheme more secure by supporting other ciphertext security schemes and addressing other security issues. We also need to continue to optimize the performance and make this scheme more practical and to carry out research into dynamic data privacy protection in the cloud.