EVOAC-HP: An Efficient and Verifiable Outsourced Access Control Scheme with Hidden Policy

Abstract

As medical data become increasingly important in healthcare, it is crucial to have proper access control mechanisms, ensuring that sensitive data are only accessible to authorized users while maintaining privacy and security. Ciphertext-Policy Attribute-Based Encryption (CP-ABE) is an attractive access control solution that can offer effective, fine-grained and secure medical data sharing, but it has two major drawbacks: Firstly, decryption is computationally expensive for resource-limited data users, especially when the access policy has many attributes, limiting its use in large-scale data-sharing scenarios. Secondly, existing schemes are based on data users’ attributes, which can potentially reveal sensitive information about the users, especially in healthcare data sharing, where strong privacy and security are essential. To address these issues, we designed an improved CP-ABE scheme that provides efficient and verifiable outsourced access control with fully hidden policy named EVOAC-HP. In this paper, we utilize the attribute bloom filter to achieve policy hiding without revealing user privacy. For the purpose of alleviating the decryption burden for data users, we also adopt the technique of outsourced decryption to outsource the heavy computation overhead to the cloud service provider (CSP) with strong computing and storage capabilities, while the transformed ciphertext results can be verified by the data user. Finally, with rigorous security and reliable performance analysis, we demonstrate that EVOAC-HP is both practical and effective with robust privacy protection.

1. Introduction

The rapid advancement of medical technology has revolutionized the healthcare industry, and one of its most significant impacts is the increasing prevalence of electronic health record (EHR) systems, replacing traditional paper-based medical records [1,2]. The adoption of EHRs has facilitated the real-time management and sharing of medical records for both doctors and patients. Additionally, healthcare practitioners can now access data more easily, enabling them to make more comprehensive diagnoses. With the emergence of 5G, cloud computing and big data, cloud-assisted EHR systems have become popular for outsourcing medical record management to the CSP and reducing management overhead. However, concerns about security and privacy arise when storing sensitive medical record data on cloud servers. Additionally, traditional encryption methods cannot achieve fine-grained data sharing and access. Access to such data without authorization can result in serious consequences, including identity theft, insurance fraud, and even the endangering of patient lives. Therefore, it is crucial to design robust security mechanisms for protecting medical data stored in the cloud [3]. To ensure data confidentiality and fine-grained access control to sensitive EHR data, Attribute-Based Encryption (ABE) was introduced as an appropriate encryption solution [4].

CP-ABE, proposed by Bethencourt et al. [5], provides a flexible way for data owners to specify their own access control policies. This is achieved by linking a ciphertext to an access policy defined by the user and associating a user’s secret key with a set of attributes. As a result, only users whose attributes satisfy the access policy can decrypt the ciphertext and access the data. However, existing CP-ABE schemes [5,6,7] may not meet security and privacy requirements. Firstly, the access policy that is associated with the ciphertext can be viewed publicly, which means that anyone can obtain useful sensitive private data and expose confidential details regarding the encrypted EHR data, which can result in the exposure of the identity and attributes of medical practitioners or patients, thus compromising their privacy [8]. In addition, those existing schemes have the disadvantage of having a linear increase in ciphertext size and decryption overhead with the number of attributes in the access policy, which can be a significant limitation for resource-limited users [9]. As more attributes are added to the policy, both the ciphertext size and decryption overhead grow proportionally. This can make it difficult or even impossible for users with limited resources to decrypt and access the data that they need in a timely manner. Furthermore, this linear growth in ciphertext size can increase the cost of storing and transmitting the encrypted data, as well as the computational overhead associated with performing encryption and decryption operations. Thus, these CP-ABE schemes may not be suitable for applications that require efficient access control and low computational overhead.

Some existing works have been proposed to address these issues, such as outsourcing decryption technology [9,10,11,12] to reduce computation overhead for data users or proposing fully or partially hidden access structure schemes [8,13,14] to protect the privacy of user attributes embedded in the access policy. However, these solutions fail to offer a large universe and reliable mechanism with adaptive security, or they lack flexibility and have low efficiency. To tackle these issues, we propose an efficient access control scheme with robust privacy protection and outsourced decryption with verifiability, which builds upon the work [15] with further optimizations. Our main contributions are outlined as follows:

• We designed an efficient and secure fine-grained access control scheme named EVOAC-HP for privacy preserving in the medical data scenario, which supports a large universe, adaptive security and flexible access control structure. This scheme uses the attribute bloom filter to achieve policy hiding, which effectively protects data users’ attribute information.
• We adopted outsourcing decryption technology to outsource complex computation to the CSP and support the verification of the outsourcing results, which largely reduces the computation overhead of data users.
• According to security analysis and performance analysis, EVOAC-HP demonstrated enhanced security and efficiency, which is appropriate for medical data-sharing application scenarios with high privacy requirements.

2. Related Work

Traditional identity-based encryption (IBE) schemes associate encryption keys with specific identities, and decryption is only possible for ciphertexts encrypted under the matching identities [16]. In contrast, fuzzy IBE allows partial matches between the encryption key and the access policy to be performed, which means that ciphertexts can be decrypted by users whose identities only partially match the policy. In order to achieve more fine-grained access control, the notion of ABE, which enables secure encryption and decryption to be achieved without the need for exact identity matching, was first conceived by Sahai and Waters [4]. According to different application scenarios, ABE is divided into Key-Policy Attribute-Based Encryption (KP-ABE) and CP-ABE. In 2006, Goyal et al. [17] proposed the first construction of a scheme that associates attributes with the private keys of the users, mainly used in paid video sites and broadcast encryption. The first CP-ABE scheme proposed by the work [5] allows complex access policies in which attributes are associated with the ciphertext to be used, which is suitable for data sharing. Although this scheme is very expressive, it was proved to be safe under the general group model, and the security of this model is relatively weak. Afterwards, a significant amount of research has been conducted on CP-ABE and KP-ABE in recent years, with various constructions and optimizations proposed to enhance their efficiency and security. Waters [18] proposed an improvement to CP-ABE schemes by introducing a linear secret sharing scheme (LSSS) based on the previous work [5], which results in enhanced efficiency and expressiveness of the encryption scheme while maintaining stronger security. Many CP-ABE schemes have since emerged, including some classic works [6,7,15]. However, as the access policy becomes more complex and the number of user attributes increases, the size of the ciphertext and the computational overhead required for decryption also increase. Since the decryption process can be expensive due to the large size of the ciphertext and the required pairing operations, resource-limited devices may experience significant delay or even have to abort the decryption process.

To address this inefficiency issue, Green et al. [9] introduced the innovative notion of ABE with outsourced decryption (ABE-OD), which allows a CSP to transform any ABE ciphertext of any size into an ElGamal-type ciphertext with a constant size, so that the user only needs to obtain the decrypted message with one exponentiation. One limitation of outsourcing decryption to the CSP is that they may not perform the transformation operations honestly. To address this concern, the work [10] proposed the concept of ABE verifiable outsourced decryption (ABE-VOD), which enables data users to check whether the transformation results are correct. However, this scheme needs to encrypt additional random messages, which doubles the computing overhead of the data user, resulting in twice the size of the ciphertext. This undoubtedly increases the user’s bandwidth requirements and computing costs. Afterward, several efficient and generic ABE-VOD schemes have been proposed [11,19,20,21,22,23,24]. Some works [19,20] also considered performing outsourced key issuing and outsourced decryption operations by introducing two cloud service providers. Mao et al. [11] and Lin et al. [21] proposed an efficient construction using a commitment scheme and an encapsulation mechanism. These ABE schemes have shown great promise in enabling the secure and verifiable outsourced decryption of ciphertexts to be performed in cloud-based environments. While these ABE schemes are well suited to flexible and fine-grained data-sharing systems, they may not be suitable for applications with high privacy requirements, such as EHR systems. This is because the access policy, which typically includes sensitive attribute information, such as the patient’s medical condition and medical history, is directly exposed in the ciphertext. Anyone can obtain some sensitive information with the ciphertext. As a result, malicious adversaries are likely to infer sensitive information about the patient’s health status, potentially leading to privacy breaches and other security risks.

In order to improve the above privacy protection issues, CP-ABE with policy hiding has been researched to address sensitive attribute information exposure in the access policy of traditional CP-ABE schemes. The concept of partially hidden access structures was proposed by Nishide et al. [8] and splits the attribute into an attribute name exposed to the ciphertext and sensitive attribute values hidden within the ciphertext. Nevertheless, this solution only supports the less expressive “AND gates” access structure. Lai et al. [25] proposed a CP-ABE scheme with adaptive security and policy hiding under the standard model, but this scheme is constructed based on bilinear groups of composite order, resulting in low efficiency. Subsequently, several works based on [8,25] have since been proposed to enhance the security, efficiency, flexibility and availability of partially hidden access structure CP-ABE [14,26,27,28,29,30]. However, all these existing schemes can only hide the attribute value but cannot hide the attribute name, and the attribute name itself still leaks some useful information. Therefore, CP-ABE schemes with fully hidden policy are also available, where the access policy is invisible to the data user, ensuring that their attribute sets are not revealed in plaintext. Recently, most of the solutions hide the whole attribute by employing the specified garbled bloom filter [31] to eliminate the attribute mapping function embedded in the access structure and achieve full policy hiding [32,33,34,35,36]. This strategy of policy hiding is well suited to applications with strong privacy requirements. However, these schemes either do not support verifiable outsourced decryption or do not support flexible access structures under the standard model.

Inspired by the works [11,15,32], we propose EVOAC-HP to be applied in EHR systems. Consider a healthcare scenario where a data owner, such as a patient, wants to share their medical records with a data user, such as a doctor, but does not want to allow other doctors or unauthorized users to access the records. To protect privacy, the patient first establishes an access policy for who is allowed to access the records and encrypts the records using CP-ABE before uploading them to a CSP. Then, doctors who meet the defined access policy can successfully decrypt the ciphertext. Note that the private attributes embedded in the access policy do not reveal the identity of the doctors. Since the doctor’s device may be resource-limited, they can request the CSP to transform the ciphertext and obtain the transformed ciphertext for decryption. Finally, the doctor can locally confirm whether the transformed ciphertext is correct to ensure the integrity of the decryption result.

3. Preliminary

In this section, we mainly review the fundamental knowledge about the CP-ABE definition, the security model for the CP-ABE, the commitment scheme, the attribute bloom filter and the decisional linear assumption.

3.1. CP-ABE Definition

A classic CP-ABE scheme is given by the following four algorithms:

• $Setup(1^{\lambda },U)$: This algorithm takes the security parameter $\lambda$ and attribute universe description U as input, and it outputs a master public key $mpk$ and a master key $msk$.
• $KeyGen(msk,S)$: This algorithm takes the master key $msk$ and a set of attributes S, and it outputs a secret decryption key $sk$.
• $Encrypt(mpk,(\mathbb{M},\rho ),M)$: This algorithm takes the master public key $mpk$, an access structure $(\mathbb{M},\rho )$ over the universe of attributes and a message M, and it outputs a ciphertext $ct$.
• $Decrypt(mpk,ct,sk)$: This algorithm takes the master public key $mpk$, a ciphertext $ct$ and a secret decryption key $sk$, and it outputs a message M or a special symbol ⊥.

3.2. Security Model for CP-ABE

We introduce the security model for the CP-ABE scheme. The security between adversary $\mathcal{A}$ and challenger $\mathcal{C}$ is given as follows:

• $Initialization$: $\mathcal{A}$ defines the challenge access structure ${\mathbb{A}}^{*}$ and gives it to $\mathcal{C}$.
• $Setup$: $\mathcal{C}$ runs $Setup$ to obtain the master public key $mpk$ and returns it to $\mathcal{A}$.
• $Phase1$: $\mathcal{A}$ has the ability to request secret keys corresponding to collections of user attributes ${\mathcal{S}}_1,{\mathcal{S}}_2$, $\dots ,{\mathcal{S}}_{Q_1}$. For each ${\mathcal{S}}_i$, $\mathcal{C}$ runs $KeyGen$ and returns $s{k}_i$ to $\mathcal{A}$. The queried sets must not meet the access structure requirements of the challenge phase above each query, i.e., $\forall i\in \left[Q_1\right]:{\mathcal{S}}_i\notin$${\mathbb{A}}^{*}$.
• $Challenge$: $\mathcal{A}$ submits two messages, $m_0$ and $m_1$, with equal length and returns them to $\mathcal{C}$. $\mathcal{C}$ chooses random number $b\in \{0,1\}$ and invokes $Encrypt$ to obtain $ct$, which is given to $\mathcal{A}$.
• $Phase2$: Phase 1 is reiterated under the same constraint. $\mathcal{A}$ can continue to query the secret keys for the sets ${\mathcal{S}}_{Q_1+1},{\mathcal{S}}_{Q_1+2}$, $\dots ,{\mathcal{S}}_Q$.
• $Guess$: $\mathcal{A}$ outputs his guess value $b^{\prime }\in \{0,1\}$ for b.

Definition 1. 

A CP-ABE scheme Π is secure if all polynomial-time attackers $\mathcal{A}$ have at most a negligible advantage in the above security game. The advantage of an attacker $\mathcal{A}$ for breaking this confidentiality game is defined as $Ad{v}_{\mathsf{\Pi }}^{\mathcal{A}}\left(\lambda \right)=|Pr\left[b^{\prime }=b\right]-1/2|$.

3.3. Commitment

A commitment scheme has three algorithms: $InitCom$, $Commit$ and $Reveal$.

• $Setup\left(1^{\lambda }\right)$: This algorithm takes a security parameter $\lambda$ as input and outputs the public commitment key $pk$.
• $Commit(M,r)$: This algorithm takes a message M and an additional random number r as input and outputs a commitment $cm$.
• $Reveal(M,r,cm)$: This algorithm takes a message M, an additional random number r and a commitment $cm$ as input and outputs a bit value $b\in \{0,1\}$. If $b=1$, it indicates that $cm$ is a valid commitment to M; otherwise, it indicates that $cm$ is not a commitment to M.

A correct commitment scheme satisfies $Reveal(M,r,Commit(M,r\left)\right)=1$ for all $pk$ output by the algorithm $Setup$ and for any message M and an additional random number r. If a commitment scheme satisfies the hiding property and the binding property, it is considered secure. The commitment $cm$ to M satisfies the hiding property, which ensures that no information about M can be inferred from $cm$. The binding property ensures that it is computationally infeasible to reveal a commitment $cm$ to a value $M_{EHR}^{\prime }$ other than the original value M.

3.4. Attribute Bloom Filter

The attribute bloom filter (ABF) is a data structure that can efficiently query a large dataset [32]. It is a variant of the bloom filter, where each element is assigned one or more attributes so that it can be filtered and queried by the attribute. During the search stage, one or more attributes can be specified, and only elements with the specified attributes are returned. Unlike traditional bloom filters, the ABF stores an additional attribute vector, where each element corresponds to an attribute vector. Each position in the attribute vector corresponds to an attribute, and if the element has that attribute, the position is set to 1; otherwise, 0. The element is returned during the query stage if all specified attribute positions are 1.

To construct the ABF, a sequence of $\lambda$ bits in length is joined with two constant strings: one that includes the row number with $L_{rownum}$ bits and another that contains the attribute with $L_{att}$ bits, where the security parameter $\lambda =L_{rownum}+L_{attr}$. The ABF can be divided into two components: $ABFBuild$ and $ABFQuery$. These two components are detailed below:

• $ABFBulid(\mathbb{M},\rho )$: This algorithm takes as input an access policy $(\mathbb{M},\rho )$. The attributes $at{t}_e$ and their corresponding row number i involved in access matrix $\mathbb{M}$ are concatenated, where each row i maps to attribute $at{t}_e$ according to the mapping function $\rho \left(i\right)$, and they are left-padded with zeros to achieve a maximum bit length. The resulting set of elements $S_{et}={\left\{i\left|\right|at{t}_{et}\right\}}_{i\in [1,\dots ,l]}$ is used as input in the garbled BF building algorithm to create $AB{F}_S$, as described in [31].
  When an element $et$ needs to be inserted into $AB{F}_S$, this algorithm randomly produces $x-1\lambda$-bit strings $r_1,r_2,\cdots ,r_{x-1}$ and adopts the XOR-based secret sharing scheme $(x,x)$ to distribute element $et$. It then assigns $r_x=r_1\oplus r_2\oplus \cdots \oplus r_{x-1}\oplus et$. Afterward, x independent and uniform hash functions $H_i$ are used to hash attribute $at{t}_e$ to obtain $H_i\left(at{t}_{et}\right)$ for $i\in [1,\dots ,x]$, where $H_i\left(at{t}_{et}\right)$ represents the specific index position in $AB{F}_S$. The i-th share $r_i$ of the element is then stored in $AB{F}_S$ at the position indicated by the hash function $H_i\left(at{t}_{et}\right)$. When adding more elements to $AB{F}_S$, it is possible that a location $j=H_i\left(et\right)$ has already been filled by an element added earlier. In this case, we can repurpose the existing share assigned as a share for the new element.
• $ABFQuery(mpk,S,AB{F}_S)$: This algorithm takes as input the master public key $mpk$, an attribute set S and the attribute bloom filter $AB{F}_S$. For each attribute $att$ within the attribute set S, the algorithm calculates the position index $H_i\left(at{t}_{et}\right)$ in $AB{F}_S$ with x hash functions. The value $r_i$ stored in the corresponding position $H_i\left(att\right)$ can then be retrieved.
  Once the element shares the $r_i$ that have been stored in $AB{F}_S$, element $et$ can be reconstructed using the formula $et=r_1\oplus r_2\oplus \dots \oplus r_{x-1}\oplus r_k=r_1\oplus r_2\oplus \dots \oplus r_{x-1}\oplus r_k\oplus et$, where $et$ is represented as $i\left|\right|at{t}_e$ and attribute $at{t}_e$ is derived from the rightmost $L_{att}$ bits of element $et$. If there are redundant zeros in $at{t}_e$, they are removed. When $at{t}_e$ matches the attribute $att$ specified in the access policy, this implies that attribute $att$ exists in the access control policy. Otherwise, attribute $att$ is not present in the access policy. Similarly, the row number i is derived from the leftmost L bits of element $et$, and redundant zeros are removed if present. Once $at{t}_e$ and i have been obtained, the attribute mapping can be rebuilt as ${\rho }^{\prime }={(rownum,att)}_{att\in S}$.

Above all, the $ABFBuild$ algorithm hides the attribute mapping, while the $ABFQuery$ algorithm reconstructs it. This access control structure can allow full policy hiding to be achieved.

3.5. Decisional Linear Assumption

Suppose we have two multiplicative groups, $\mathbb{G}$ and $\mathbb{H}$, of prime number order q and two generators, $g\in \mathbb{G}$ and $h\in \mathbb{H}$. We randomly select $x,y,m,n\in {\mathbb{Z}}_p$ and define a tuple $T_1=(g,h,g^x,g^y,h^x,h^y,g^{mx},g^{ny},h^{mx},h^{ny},g^{m+n},h^{m+n})$. We randomly choose a random number $\mu \in {\mathbb{Z}}_p$ and define another tuple $T_2=(g,h,g^x,g^y,h^x,h^y,g^{mx},g^{ny},h^{mx},h^{ny},g^{\mu },h^{\mu })$. The assumption then is that no polynomial-time adversary can distinguish tuple $T_1$ from tuple $T_2$ with negligible advantage.

4. Access Control System

In this section, we introduce our system model and the concrete EVOAC-HP, which is composed of five stages, including system parameter initialization, key generation, EHR data encryption, ciphertext transformation, and EHR data decryption and verification.

4.1. System Model

As shown in Figure 1, the system model of EVOAC-HP comprises four entities: a certificate authority (CA), many data owners (DOs), many data users (DUs) and a cloud service provider (CSP). The following provides the definition and functions of each participant:

Figure 1. The system model of EVOAC-HP.

• Certificate authority (CA): The central component of the entire system is the CA, which is in charge of the initialization of the system. The CA is responsible for creating the master private key and public parameters. Additionally, the CA generates transformation keys for users based on their attribute set when requested. It is assumed that the CA is a trusted entity.
• Data owners (DOs): DOs are the producers of medical data. When they need to share their data, they first establish a custom access policy that allows users to access and encrypt the data using our proposed encryption scheme. The resulting ciphertext is then uploaded to the CSP. It is worth noting that the access policy in the ciphertext does not reveal the sensitive attributes of the data owner. In a medical scenario, the data owners are the patients.
• Data users (DUs): In the healthcare scenario, the DUs play the role of a doctor or a nurse. They need to retrieve the corresponding ciphertext from the CSP and request it to assist in the transformation of the ciphertext. When obtaining the transformed decrypted ciphertext from the CSP, the data user locally decrypts it to access the EHR data and checks whether the transformation result is correct. Considering that the data user is likely to use resource-limited devices such as conventional desktop computers, the decryption operation is delegated to simplify the computation.
• Cloud service provider (CSP): The CSP is a powerful server with storage and computing services. Its main responsibilities include storing ciphertext corresponding to medical data and providing ciphertext transformation service. It should be noted that the CSP is honest but curious, which means that it may attempt to extract useful information from the ciphertext.

4.2. The Proposed Scheme

System parameter initialization. The entire process of system initialization is performed by the CA. It runs $Setup(1^{\lambda },U)$ to generate $(mpk,msk)$. This process is shown in Algorithm 1. This algorithm takes as input the security parameter $\lambda$ and a large attribute universe description U, and it outputs the master public key $mpk$ and the master key $msk$. In this process, the CA executes the initialization stage of the FAME scheme [15] and the commitment scheme. In addition, the attribute bloom filter is parameterized. Finally, the master public key is $mpk$, and the master key is $msk$.

Algorithm 1 Setup (Invoked by CA).

Input Security parameter $\lambda$, attribute universe description U Output: The master public key $mpk$, the master key $msk$ 1: Suppose $L_{att}$ and $L_{rownum}$ denote the maximum bit length of attributes in the whole system and the row numbers in the access matrix. The ABF has a bit array of size $L_{ABF}$ and is associated with x hash functions; 2: Generate x hash functions $H_i$ for $i\in [1,\dots ,x]$: $H_i:{\left\{0,1\right\}}^{*}\to [1,L_{ABF}]$ and a hash function $\mathcal{H}:{\left\{0,1\right\}}^{*}\to \mathbb{G};$ 3: Randomly pick three groups $\mathbb{G}$, $\mathbb{H}$ and ${\mathbb{G}}_{\mathbb{T}}$ of prime order p and defines a bilinear map $\widehat{e}:\mathbb{G}\times \mathbb{H}\to {\mathbb{G}}_T$ and generators $g_0,g,h_0\in \mathbb{G},h\in \mathbb{H}$ and random number $a_1,a_2,b_1,b_2\in Z_p^{*}$ and $d_1,d_2,d_3\in Z_p;$ 4: Calculate $A_1=h^{a_1},A_2=h^{a_2},E_1=e{(g,h)}^{d_1{a}_1+d_3},E_2=e{(g,h)}^{d_2{a}_2+d_3};$ 5: Set the master public key $mpk=\{g_0,h_0,h,A_1,A_2,E_1,E_2,H_{i\in [1,\dots ,x]},\mathcal{H}\};$ 6: Set the master key $msk=\{g,h,a_1,a_2,b_1,b_2,g^{d_1},g^{d_2},g^{d_3}\}.$

Key generation. This stage has two steps: Firstly, the data user randomly selects $z\in {\mathbb{Z}}_p$ as a secret decryption key $dk=z$ and produces a shared public key $spk=g^{\frac{1}{z}}$. When the data user needs to apply for the transformation key, the data user sends the shared public key $spk$ to the CA responsible for issuing transformation keys. The CA runs $TkGen(msk,S,spk)$ to generate the transformation key $tk$, and this process is shown in Algorithm 2. This algorithm takes as input the master key $msk$, a set of the data user attributes S and a shared public key $spk$, and it outputs the transformation key $tk=(t{k}_0,{\left\{t{k}_y\right\}}_{y\in S},t{k}^{\prime }).$

Algorithm 2 TkGen (Invoked by CA).

Input The master key $msk$, attribute set S, a shared public key $spk$ Output: Transformation key $tk$ 1: Randomly chooses two random number $r_1,r_2\in {\mathbb{Z}}_p$ and calculate $t{k}_{0,1}=h^{b_1{r}_1},t{k}_{0,2}=h^{b_2{r}_2},t{k}_{0,3}=h^{r_1+r_2};$ 2: Set $t{k}_0=(t{k}_{0,1},t{k}_{0,2},t{k}_{0,3});$ 3: for each $y\in S$ do 4:    for $k\in \{1,2\}$ do 5:      Randomly chooses a random number ${\sigma }_y\in {\mathbb{Z}}_p$ and calculates $t{k}_{y,k}=\mathcal{H}{\left(y1k\right)}^{\frac{b_1{r}_1}{a_k}}·\mathcal{H}{\left(y2k\right)}^{\frac{b_2{r}_2}{a_k}}·$$\mathcal{H}{\left(y3k\right)}^{\frac{r_1+r_2}{a_k}}·g^{\frac{{\sigma }_y}{a_k}}$; 6:    end for 7: end for 8: Set $t{k}_y=(t{k}_{y,1},t{k}_{y,2},g^{-{\sigma }_y});$ 9: for  $k\in \{1,2\}$  do 10:    Randomly chooses ${\sigma }^{\prime }\in {\mathbb{Z}}_p$ and calculates $t{k}_k^{\prime }=g^{\frac{d_k}{z}}·\mathcal{H}{\left(011t\right)}^{\frac{b_1{r}_1}{a_k}}.\mathcal{H}{\left(012t\right)}^{\frac{b_2{r}_2}{a_k}}·\mathcal{H}{\left(013t\right)}^{\frac{r_1+r_2}{a_k}}·g^{\frac{{\sigma }^{\prime }}{a_k}};$ 11: end for 12: Set $t{k}^{\prime }=(t{k}_1^{\prime },t{k}_2^{\prime },g^{\frac{d_3}{z}}·g^{-{\sigma }^{\prime }});$ 13: Set $tk=(t{k}_0,{\left\{t{k}_y\right\}}_{y\in S},t{k}^{\prime }).$

EHR data encryption. When encrypting sensitive EHR data $M_{EHR}$ under the defined access structure $(\mathbb{M},\rho )$, the data owner first randomly picks a value r and uses a concatenation operation represented by “$\left|\right|$” to encrypt the combination of EHR data and the random number $M_{EHR}\left|\right|r$. This means that the encrypted result contains both the original EHR data and the random value. That is, it runs $Encrypt(mpk,M_{EHR}||r,(\mathbb{M},\rho ))\to ct$. This algorithm takes the master public key $mpk$, the EHR data $M_{EHR}$, the random number r and the access structure $(\mathbb{M},\rho )$ as input, and it outputs the encrypted EHR data $ct$. This process is shown in Algorithm 3. To hide the access structure $(\mathbb{M},\rho )$, we adopt the attribute bloom filter to achieve this property. It invokes $ABFBulid(\mathbb{M},\rho )\to AB{F}_S$ to obtain $AB{F}_S$. This algorithm takes as input the access structure $(\mathbb{M},\rho )$, and it outputs the attribute bloom filter $AB{F}_S$. The concrete process is detailed in Section 3.5. In order to commit to $M_{EHR}$ using the value r, it runs $Commit(M_{EHR},r)\to cm$. The data owner calculates a commitment of the EHR data $cm=g_0^{M_{EHR}}{h}_0^r$. The final ciphertext $c{t}^{\prime }$ is $(ct,cm,\mathbb{M},AB{F}_S)$.

Algorithm 3 Encrypt (Invoked by DO).

Input Master public key $mpk$, the combination of the message and random number $\left(M_{EHR}\right|\left|r\right)$, access structure $(M,\rho )$, attribute set S Output: Encrypted message $ct$ 1: Randomly chooses two random number $s_1,s_2\in {\mathbb{Z}}_p$ and calculates $c{t}_{0,1}=A_1^{s_1},c{t}_{0,2}=A_2^{s_2},c{t}_{0,3}=h^{s_1+s_2};$ 2: Set $c{t}_0=(c{t}_{0,1},c{t}_{0,2},c{t}_{0,3});$ 3: for each $i\in (1,n_1)$ do 4:    for $l\in \{1,2,3\}$ do 5:      Calculate $c{t}_{i,l}=\mathcal{H}{\left(\rho \left(i\right)l1\right)}^{s_1}·\mathcal{H}{\left(\rho \left(i\right)l2\right)}^{s_2}·{\prod }_{j=1}^{n_2}{\left[\mathcal{H}{\left(0jl1\right)}^{s_1}·\mathcal{H}{\left(0jl2\right)}^{s_2}\right]}^{{\left(M\right)}_{i,j}};$ 6:    end for 7: end for 8: Set $c{t}_i=(c{t}_{i,1},c{t}_{i,2},c{t}_{i,3});$ 9: Calculate $c{t}_{M_{EHR}}=E_1^{s_1}·E_2^{s_2}·(M_{EHR}\left|\right|r);$ 10: Set $ct=(c{t}_0,c{t}_1,\cdots ,c{t}_{n_1},c{t}_{M_{EHR}}).$

Ciphertext transformation. In this stage, the CSP invokes $Transform(ct,tk)\to pct$. This algorithm takes as input the encrypted EHR data $ct$ and the transformation key $tk$ and outputs the partially decrypted ciphertext $pct$. This process is shown in Algorithm 4. Notice that the CSP might be malicious or lazy, so the transformation result is not necessarily true.

Algorithm 4 Transform (Invoked by CSP).

Input Ciphertext $ct$, transformation key $tk$ Output: Partially-decrypted ciphertext $pct$ 1: Calculate $num=e({\prod }_{i\in I}^{{\gamma }_i}c{t}_{i,1}^{{\gamma }_i},t{k}_{0,1})·e({\prod }_{i\in I}^{{\gamma }_i}c{t}_{i,2}^{{\gamma }_i},t{k}_{0,2})·e({\prod }_{i\in I}^{{\gamma }_i}c{t}_{i,3}^{{\gamma }_i},t{k}_{0,3});$ 2: Calculate $den=e(t{k}_1^{\prime }·{\prod }_{i\in I}t{k}_{\rho \left(i\right),1}^{{\gamma }_i},c{t}_{0,1})·e(t{k}_2^{\prime }·{\prod }_{i\in I}t{k}_{\rho \left(i\right),2}^{{\gamma }_i},c{t}_{0,2})·e(t{k}_3^{\prime }·{\prod }_{i\in I}t{k}_{\rho \left(i\right),3}^{{\gamma }_i},c{t}_{0,3});$ 3: Calculate $pct=num/den.$

EHR data decryption and verification. When the data user requests the full ciphertext from the CSP, it firstly decomposes the ciphertext $c{t}^{\prime }$ into $(ct,cm,\mathbb{M},AB{F}_S)$ and runs $ABFQuery(mpk,S,AB{F}_S)\to {\rho }^{\prime }$. The concrete process is detailed in Section 3.5. This algorithm takes as input the master public key $mpk$, a set of data user attributes S and attribute bloom filter $AB{F}_S$ and outputs the rebuilt attribute mapping ${\rho }^{\prime }$. When recovering the corresponding access structure $(\mathbb{M},{\rho }^{\prime })$, the resource-constrained data user is able to delegate the ciphertext $ct$ to the CSP for decryption; the CSP transforms the ciphertext $ct$ into partially decrypted ciphertext $pct$ and gives it to the data user. Then, the data user runs $Decrpt(c{t}^{\prime },pct,dk)$. This algorithm takes as input the full ciphertext $c{t}^{\prime }$, the partially decrypted ciphertext $pct$ and decryption key $dk=z$ and outputs the final result $result=c{t}_{M_{EHR}}·pc{t}^z$. The result is the combination of the message and the random number $\left(M_{EHR}\right|\left|r\right)$. Aiming to check the correctness of the transformation result, the data user runs $Reveal(M_{EHR},r,cm)$. This process checks whether $cm\stackrel{\text{?}}{=}{g}_0^{M_{EHR}}{h}_0^r$. If it passes verification, the data user finally obtains the true message, $M_{EHR}$. Otherwise, the transformation result is wrong.

5. Security Analysis

Theorem 1. 

EVOAC-HP can guarantee the confidentiality of data under the random oracle model.

Lemma 1. 

If FAME [15] can guarantee the confidentiality of data, the proposed scheme can also guarantee the confidentiality of data.

Proof. 

Suppose that there is an adversary that solves the difficult decisional linear problem in probabilistic polynomial time, whose advantage $\epsilon$ cannot be ignored. With the help of adversary $\mathcal{A}$, an algorithm $Alg$ can be constructed so that the algorithm can break the confidentiality of FAME in probabilistic polynomial time, and the advantages are not negligible.

Let $\mathcal{C}$ be the challenger of a safe game in the FAME scheme, and let $\mathcal{A}$ be the adversary of the game. Algorithm $Alg$ can break FAME’s confidentiality by performing the following:

• System initialization: Adversary $\mathcal{A}$ sends the access structure ${\mathbb{A}}^{*}$ that needs to be challenged to algorithm $Alg$. Algorithm $Alg$ gives ${\mathbb{A}}^{*}$ to challenger $\mathcal{C}$. Challenger $\mathcal{C}$ generates public parameter $mpk=\{h,A_1,A_2,E_1,E_2,\mathcal{H}\}$ with the $Setup$ algorithm in FAME and sends $mpk$ to algorithm $Alg$. Algorithm $Alg$ calls the $Setup$ algorithm in EVOAC-HP to complete public parameter $mpk=\{g_0,h_0,h,A_1,A_2,E_1,E_2,H_{i\in [1,\dots ,x]},\mathcal{H}\}$ and send it to adversary $\mathcal{A}$.
• Query phase 1: Algorithm $Alg$ receives the decryption key query request submitted by adversary $\mathcal{A}$. Let adversary $\mathcal{A}$ ask for the decryption key of the attribute set $S_e$, and let algorithm $Alg$ forward this query request to challenger $\mathcal{C}$. Challenger $\mathcal{C}$ calls the $KeyGen$ algorithm in the FAME scheme to output the decryption key given to algorithm $Alg$, and algorithm $Alg$ forwards its key to adversary $\mathcal{A}$.
• Challenge phase: Adversary $\mathcal{A}$ submits two equal-length plaintexts, $m_0^{*}$ and $m_1^{*}$, to algorithm $Alg$. Algorithm $Alg$ sends them to challenger $\mathcal{C}$ and asks for the challenge ciphertext. Challenger $\mathcal{C}$ randomly selects $b\in \{0,1\}$ and calls the $Encrypt$ algorithm in the FAME scheme to encrypt the message $m_b^{*}$. Finally, challenger $\mathcal{C}$ sends the ciphertext $ct$ to algorithm $Alg$. After receiving the challenge ciphertext $ct$, algorithm $Alg$ completes $ct$ according to the ciphertext form of EVOAC-HP and then sends it to adversary $\mathcal{A}$.
• Query phase 2: This phase is the same as Query phase 1.
• Guess phase: If adversary $\mathcal{A}$ outputs a bit $b^{\prime }$, then algorithm $Alg$ also outputs $b^{\prime }$.

If adversary $\mathcal{A}$ can break the FAME scheme, it means that adversary $\mathcal{A}$ can calculate the ciphertext $e{(g,h)}^{-E_1^{s_1}·E_2^{s_2}}$ according to algorithm $Alg$. With the help of adversary $\mathcal{A}$, algorithm $Alg$ can calculate $m_b^{*}$ in the FAME algorithm, thereby breaking the FAME scheme. □

Theorem 2. 

If the decisional linear assumption is correct, FAME is adaptively secure under the random oracle model.

Lemma 2. 

FAME [15] has proved that the decisional linear assumption is adaptively secure under the random oracle model. EVOAC-HP is constructed based on FAME, so EVOAC-HP can guarantee the confidentiality of data under the random oracle model.

Theorem 3. 

EVOAC-HP can guarantee the confidentiality of ciphertext transformation.

Proof. 

The proposed scheme guarantees transformation result confidentiality with the discrete logarithm problem. Specifically, EVOAC-HP generates a transformation key using a shared public key $spk=g^{\frac{1}{z}}$ provided by the data user. Even if an adversary gains access to the transformation key $tk$ and the intermediate ciphertext $ct$ from the CSP, they cannot compute $c{t}_{M_{EHR}}·pc{t}^z$ without the user’s secret decryption key z. Thus, the adversary does not have the ability to decrypt the combination of the EHR data and the random number ($M_{EHR}\left|\right|r$) and gain access to sensitive data $M_{EHR}$. This adds an extra layer of security to the scheme, ensuring that confidential information remains protected even if the adversary gains access to some of the intermediate data. □

Theorem. 4

EVOAC-HP can guarantee the privacy of the access policy.

Proof. 

To prevent the potential leakage of attribute information, EVOAC-HP eliminates the attribute mapping function $\rho$ embedded in the access policy using the $ABFBulid$ and $ABFQuery$ procedures. Adversaries without knowledge of the attribute string cannot carry out a successful brute-force attack within polynomial time, so they are incapable of accessing and inferring confidential information from the access policy. Furthermore, data users are only able to check whether they possess the required attributes for accessing the data. It is impossible for a single data user to verify all the attributes from the attribute universe description U unless they possess all of the attributes or multiple data users work together to achieve it. Therefore, EVOAC-HP provides protection for policy privacy by concealing attribute information in the access policy. □

6. Performance Analysis

In this section, the performance of EVOAC-HP is analyzed from functional, theoretical and experimental perspectives.

6.1. Functional Analysis

When it comes to the comparisons of functional analysis, we compare related works in terms of five functionalities: security model, large universe, hidden policy, outsourced decryption and verifiability. Note that in the security model, adaptive security provides stronger security guarantees than selective security. As shown in Table 1, most schemes support only two or three of these features, while the work [18] only supports large universe, and the work [8] only achieves hidden policy. For better security, only schemes [15,25] and EVOAC-HP achieve adaptive security. The schemes [10,11] both support large universe, outsourced decryption and verifiability. According to the above comparison, EVOAC-HP simultaneously achieves large universe, adaptive security, hidden policy, outsourced decryption and verifiability, thus showing functional advantages.

Table 1. Comparisons of functionality ¹.

Scheme	Security Model	Large Universe	Hidden Policy	Outsourced Decryption	Verifiability
[8]	Selective security	✘	✔	✘	✘
[18]	Selective security	✔	✘	✘	✘
[9]	Selective security	✔	✘	✔	✘
[25]	Adaptive security	✘	✔	✘	✘
[10]	Selective security	✔	✘	✔	✔
[11]	Selective security	✔	✘	✔	✔
[32]	Selective security	✔	✔	✘	✘
[15]	Adaptive security	✔	✘	✘	✘
EVOAC-HP	Adaptive security	✔	✔	✔	✔

¹ Here, ✔ denotes support; ✘ denotes no support.

6.2. Theoretical Analysis

Here, we only consider some expensive operations and use the symbols $Exp$, $Pair$ and $Hash$ to denote exponentiation, pairing and hashing operation, respectively. As shown in Table 2, we evaluate EVOAC-HP and compare it with other similar schemes based on the computational complexity of their encryption and decryption algorithms. Regarding the encryption process, although the scheme [32] and EVOAC-HP incur high computational overhead, most of the computational overhead is attributed to the construction of the attribute bloom filter, which requires additional hashing operations to achieve policy hiding. On the other hand, it is obvious that in the decryption stage, existing schemes [15,18,32] need to perform pairing operations, which is expensive for data users, while EVOAC-HP only requires $2Exp+xHash$ operations. Due to outsourced decryption, EVOAC-HP outperforms other existing schemes that require pairing operations in the decryption stage with regard to performance.

Table 2. Comparisons of computation cost ¹.

Scheme	Encryption	Decryption
[18]	$(2n_1+2)Exp$	$IExp+(2I+1)Pair$
[32]	$(2n_1+2)Exp+xHash$	$IExp+(2I+1)Pair+xHash$
[15]	$(6n_1+3)Exp+6(n_1+n_2)Hash$	$6Pair$
EVOAC-HP	$(6n_1+3)Exp+(6n_1+6n_2+x)Hash$	$2Exp+xHash$

¹ Here, I denotes the number of attributes used in the final successful decryption; $n_1$ and $n_2$ are the dimensions of the access matrix in the access policy; and x is the number of hash functions for the attribute bloom filter.

6.3. Experimental Analysis

We implemented similar schemes in Python 3.8 in the same experimental environment (Ubuntu-20.04 with Intel Core i7 and 16 G RAM) on top of the Charm framework [37] and MNT224 curve for pairing. The double-hash technique [38] based on 128-bit MurmurHash and SpookyHash was used to construct x hash functions for the attribute bloom filter. We compared the computational time of data encryption and data decryption with schemes [15,32] and EVOAC-HP. We evaluated all the schemes using access policies and attribute sets of sizes ranging from 5 to 50, and the number of hash functions for the ABF was 10. Those schemes were tested in 10 trials, so that the experimental results were averaged. As shown in Figure 2, as the number of attributes increases, the encryption overhead of all three schemes shows a linear growth trend. However, our scheme, EVOAC-HP, has significantly smaller encryption overhead than the scheme proposed in [32], while it has time overhead similar to that of the scheme proposed in [15]. It is worth noting that the scheme proposed in [15] does not consider policy privacy, while our scheme requires the construction of the ABF during the encryption phase to achieve fully hidden policy, resulting in additional computational overhead depending on the number of hash functions used. As shown in Figure 3, the data decryption overhead of scheme [32] shows a linear growth trend as the number of attributes increases, which leads to an increased computational burden for data users. In contrast, EVOAC-HP and scheme [15] maintain constant data decryption overhead. Moreover, EVOAC-HP adopts outsourcing decryption techniques, which further reduces decryption overhead to 2 ms.

Figure 2. Computation time comparison of data encryption among FAME [15], Yang et al.’s scheme [32] and our scheme.

Figure 3. Computation time comparison of data decryption among FAME [15], Yang et al.’s scheme [32] and our scheme.

In order to evaluate the time cost of five algorithms in EVOAC-HP, we conducted experiments under three curves, MNT159, MNT201 and MNT224. Figure 4 shows the computational time of each algorithm in our proposed scheme with the number of attributes. Obviously, the MNT224 curve had the highest overhead among all algorithms, while MNT159 had the lowest. The $Setup$ algorithm maintained constant computational overhead, and system initialization was only required once. Except for the $Decrypt$ algorithm, the computation overhead of all algorithms was proportional to the number of attributes. Due to outsourced decryption, the $Decrypt$ algorithm only spent a constant time of around 2 ms.

Figure 4. Computational overhead with the number of attributes.

7. Conclusions and Future Work

In this paper, we introduce a practical and reliable scheme for fine-grained privacy protection and outsourced computation access control for sharing medical data, named EVOAC-HP. We employ CP-ABE as a fundamental building block to encrypt the medical data and outsource the decryption operation to alleviate the computation overhead for data users, which reduces the decryption computation overhead to a constant. Additionally, we achieve policy hiding by utilizing the attribute bloom filter, which prevents any individual from accessing sensitive attribute information from the access policy. The user’s attributes are not disclosed in the access policy, which effectively guarantees the security of our scheme. The proposed scheme is proved to be adaptively secure under the random oracle model under the decisional linear assumption. As demonstrated with performance analysis and comparative analysis, EVOAC-HP has functional advantages, better performance and stronger security, which are suitable for EHR data sharing and complex access control in medical scenarios.

Our scheme also has some limitations. First of all, with our scheme, it is difficult to efficiently deal with the policy update problem. When the access policy needs to be updated, the data owner can complete the update with a small computational cost. In this scheme, the data owner needs to re-encrypt according to the new access policy, which is obviously inefficient. Secondly, in most medical scenarios, users’ identities may often change, which requires a new solution that supports user attribute update and revocation to meet this requirement. Finally, our scheme has the problem of offline dictionary attack, that is, the user can continuously query whether the attribute is in the access policy with the attribute bloom filter, which may expose user attributes. In the future, we plan to focus on incorporating features such as CP-ABE with policy update and user attribute revocation while preventing dictionary attacks to better meet practical application scenarios.