1. Introduction
Cloud computing has become a priority and integral to modernizing the information technology (IT) environment. It spawned a whole new dimension of IT, which utilized a wide range of resources that contributed to many domains, such as business, military, health, and medical. In the healthcare and medical domain, Cloud computing has been adopted to facilitate day-to-day operations. This is because the Cloud provides ‘on-the-fly’ services, that is, storage, computation, and data sharing, which allow healthcare and medical practitioners to run their business according to their required operations. For example, electronic health records (EHRs) have been widely employed in the healthcare industry to improve the accessibility and sharing of medical data among medical practitioners. Patients’ information, laboratory results, medication lists, diagnostic tests, physical examinations, and historical observations are all kept in the EHR, which is stored in Cloud storage. Furthermore, resource management and system administration (infrastructure) can be effectively monitored through Cloud computing, making healthcare services easy to maintain [
1]. Besides, Cloud Service Providers (CSPs) facilitated Cloud users by granting resource sharing regardless of geographical boundaries using the pay-per-use model [
2,
3,
4], which can reduce organizations’ management and maintenance costs. Moreover, Cloud adoption in organizations is expected to lift performance with the high-speed deployment of services and to improve clients’ satisfaction.
Organizations are willing to adapt their business operations to the Cloud environment due to ultimately easier access to Cloud services and numerous benefits. One of the areas that organizations particularly choose is using Cloud storage to afford them the ability to access their files (data and information) from any device and any place. Another reason is by making Cloud storage to be part of the backup solution. In addition, assessing and sharing data from the Cloud environment offers highly available services. That feature is crucial for organizations dealing with numerous clients besides diverse roles and demands. Once Cloud computing is established with its core services (i.e., IaaS, PaaS, SaaS), Cloud users begin to be concerned about security matters [
5,
6,
7,
8]. From the Cloud storage perspective, data confidentiality and privacy have become debatable among Cloud users due to the skeptical location where the files reside. Furthermore, when they noticed that the CSPs operated in a multi-tenant environment, the organizations raised the demand for security features from the CPSs. It is mainly to ensure the users’ data and information stored in the Cloud are not exposed or disclosed to any illegitimate access.
Since early in the year of 2000, many types of research have been developed in tackling the Cloud security issue. Among security approaches, encryption has initially become the essence of the Cloud security call. The authors of [
9,
10,
11] proposed the encryption algorithm for securing Cloud data that converts the data into unreadable forms. Therefore, any attempt to sniff data over cloud storage can be prevented. However, studies by the authors of [
12,
13] stated that the encryption algorithm alone does not guarantee data safety in Cloud storage. In fact, in a multi-tenant environment, the probability of data exposure is high because different users share the same Cloud infrastructure and storage. It means that they stored the data in the same location, and more crucially, it was probably kept in the same stack of the server. This leads to unauthorized access by other users [
14,
15], especially when those users have the intention of hacking and stealing the data. Thus, besides performing data encryption, access control over Cloud storage needs to be addressed.
Therefore, other researchers began to bring together encryption with other solutions, such as privacy-preserving schemes and access control schemes [
16], to enhance data privacy further. Attribute-based Encryption (ABE) is a promising solution that offers fine-grained access control and provides data confidentiality on Cloud storage [
17]. Sahai and Waters [
18] were the pioneers of Attribute-based Encryption (ABE), where they claimed that the fine-grained access control scheme was able to support better security services for Cloud users and CSPs. In ABE, different attributes of various Cloud environment entities, for example, data owner, file, and data recipient, are used to describe the encrypted data and built policies into the user’s keys. Later, the authors of [
19] introduced Ciphertext Policy ABE (CP-ABE), which uses attributes to describe a user’s credentials, and a party encrypting data determines a policy for who can decrypt the ciphertext. Basically, in CP-ABE, the access policy created for the encrypted message is sent in a plaintext format. It provides the opportunity for illegal parties to retrieve the attribute details in the access policy, subsequently disclosing the data. Besides, several other issues related to CP-ABE have also been discussed in [
20]. Thus, many researchers [
6,
19,
21,
22] introduced new CP-ABE schemes to solve the issues. The authors of [
18] introduced a CP-ABE scheme to enhance the efficiency of data sharing between data owners and other users. It also allowed data owners to define the access policy of the encrypted data so that only users who match the access policy can download and reveal the data. According to [
6], most proposed CP-ABE schemes have accomplished their objectives by providing efficient and secure data sharing. However, most of these constructions disregard the privacy of data owners and data users. For instance, in the healthcare system (
Figure 1), a doctor needs to share his patient’s health record with other doctors. Based on the conventional method of CP-ABE, the nurses could also have access to cloud storage to obtain patient information from the attributes in the access policy. It is due to the access policy that is partially hidden and can be read by authorized entities, which might turn into malicious access. Hence, it is crucial to enforce the encryption scheme to not merely encrypt the message but entirely hide the access policy details.
Therefore, inspired by the literature [
23], we present a Policy Hiding using Logical Connective in CP-ABE (PHLC) scheme for Cloud storage, which adopts XOR operation to modify access policy information. This proposed work can overcome the encryption challenges outlined by [
24] since it was designed to provide data confidentiality using a symmetric encryption scheme and offered fine-grained access control with data sharing provision. Besides, this scheme preserved users’ privacy through an access policy hiding scheme. In addition, PHLC achieved efficient data storage utilization by using a pre-processing process to eliminate redundant data in raw shared data. This operation helps the scheme to reduce ciphertext size and decrease the computational overhead for the encryption process. Security analysis shows that the proposed scheme preserved Cloud users’ privacy and guaranteed secure data sharing in cloud storage. Furthermore, we conducted an extensive simulation to demonstrate that PHLC CP-ABE was secure against passive attacks.
The rest of the paper is arranged as follows.
Section 2 discusses related work and
Section 3 provides some preliminaries of CP-ABE, whereas
Section 4 presents the proposed scheme’s implementation.
Section 5 discusses security analysis and
Section 6 provides results and discussion. Finally,
Section 7 concludes this study.
2. Related Work
Numerous works of research such as revocable CP-ABE [
25], lightweight CP-ABE [
26], multi-authority CP-ABE [
4,
27], and large universe CP-ABE [
28] have been developed in response to upgrading the competency of the Ciphertext Policy Attribute-based Encryption (CP-ABE) scheme. However, most of the schemes exposed the access policy in plaintext, which incurred privacy leakage. As a result, there are other works that focus on encrypting the data while hiding the access policy during data sharing. Nishide et al. [
29] proposed the hiding access policy by splitting attributes into attribute names and multiple attribute values, where they then hid the attribute values. Meanwhile, Zhou et al. [
30] proposed the partially hidden access algorithm, whereby the hidden access policies are implemented with wildcards regardless of the number of attributes. Although the data construction effectively secures the shared information, it fails to offer total data security. It is due to the wildcard attributes not yet being in readable form and might cause privacy leakage. The authors of [
23] supported fast decryption while hiding the access policy by sending the access matrix and the defined function along with ciphertext to the Cloud environment. However, it is unable to preserve privacy in the access policy. In [
31], the authors eliminated all redundant attributes in the access policy, and their approach significantly reduced computation overhead. With the same intention, the author of [
32] proposed the ‘test-decrypt-verify’ approach to reduce the computation cost in their CP-ABE scheme. In their scheme, the testing phase is added before the encryption phase, and the new component, Outsourcing Cloud Server, is adopted as an outsource agent to reduce the decryption calculation. However, the proposed scheme only employed a partially hidden access policy. The authors of [
33] also provided a partially hidden access policy by removing the attribute name from the access structure of the ciphertext. However, the probability of data exploitation by dishonest entities or unauthorized users is still high because only a part of the access policy is hidden.
Other researchers expressed access policies using Linear Secret Sharing Schemes (LSSS) in the CP-ABE scheme for better data access control. In Lai et al. [
11], they proposed partial hiding access structures with LSSS that are able to accommodate any access structure. They proved that their scheme was suitable for outsourcing data with attribute values of the data that had been hidden. Other studies, such as [
34,
35,
36] also constructed the LSSS-based access policy schemes with CP-ABE, which hid attribute values to secure the information. Besides the partially hidden access policy, Xiong’s scheme [
34] supported attribute revocation and verifiable outsourced decryption. However, the attribute values carry more intricate information in comparison to generic attribute names, which leads to high computing overhead during the decryption process. Meanwhile, the authors in [
35] proposed the control access scheme to provide privacy protection via partial concealment of access policy. They have utilized CP-ABE in the intelligent healthcare system known as the privacy-aware-health access control system (PASH). PASH hides the attribute value of the access policy in the encrypted Smart Health Record and only specifies the attribute name, which destroys the system-user privacy. Therefore, the existing CP-ABE scheme needs improvement to prevent information leakage from access policies and ensure data sharing on the Cloud is secured. Although various approaches have been proposed in the existing literature on the policy hiding scheme, the study on privacy-preserving with a fully hidden access policy is still inadequate. It could not solve the privacy leakage issues completely. Thus, the privacy-preserving of data users cannot be guaranteed.
3. Design of CP-ABE
This section discussed the preliminary work involved in designing the CP-ABE. In addition, it also covers the overview of CP-ABE, PHLC scheme’s system model, security goals, and security model.
3.1. Preliminaries Works
This section presents the bilinear map, Linear Secret Sharing Scheme (LSSS), XOR-based Logical Connective, and notation definition.
3.1.1. Definition of Notations
This section gives notation explanations used in this research, as shown in
Table 1.
3.1.2. Bilinear Pairing
In our CP-ABE scheme, bilinear pairing is used to create a public key. The Attribute Authority generates this public key based on a composite order bilinear group with a distinct prime order
, which we adopted from [
23]. The algorithm takes an input
where
is a security parameter and produces a tuple (
,
,
) where
are distinct primes. The order of cyclic group
and
is
=
and map
:
×
→
, with properties:
- i.
Bilinearity: , ) =
- ii.
Non-degenerate: ∈ such that , has order in
- iii.
Computable: can be computed efficiently.
3.1.3. Linear Secret Sharing Schemes (LSSS)
The LSSS is used to express access policy in access structure (
where
is a policy matrix and
is a mapping of each row
i of the matrix
to an attribute [
37]. In this scheme, the presence of an attribute universe was denoted as
AU, which has n categories of attributes.
Definition 1 (LSSS). LetAU = (Att1, Att2, Att3, …, Attn). Each attribute Attn contains two-part which are attribute name and attribute values. Possible values of the attribute value, . Meanwhile, refers to a share-generating matrix, while each row in is a map to an attribute name index, and that mapping was denoted as . LSSS consisting of the two following algorithms:
- i.
Secret share: The secret shared, and the value is computed for each row of , where = and are chosen randomly from . Hence, the secret share value is given v.
- ii.
Secret Construction: This algorithm takes in the secret share {} and set which contains the authorized attribute name index. Then it sets and computes the constant such that . Then the secret is reconstructed by .
Similar to [
23], we construct the LSSS matrices over
. In our proposed scheme, we denoted the user’s attribute as
, where
is the attribute name index, and
is the attribute value set. Denote
) as access policy and
is the attribute value for each row of
A where
satisfies
means that there exits
satisfying
and
.
3.1.4. XOR-Based Logical Connective Policy Hiding
The proposed policy hiding algorithm uses an XOR-based logical connective to hide the access policy in the CP-ABE scheme. We utilized XOR to modify the entire access policy to form a reliable proposition. According to Rosen [
38], logical connective is defined by the truth table, which declares that a fact could be either true or false, but not both. Rosen described proposition logic as: ‘Let
p and q be propositions. The exclusive-or of
p and q, denoted by
p XOR q, is the proposition that is true when exactly one of
p and q is true and is false otherwise. According to [
39], XOR is a lightweight operation that does not incur much computational overhead. Therefore, it is very appropriate to be adopted in this scheme as a second layer of protection.
3.2. Overview of Ciphertext Policy Attribute-Based Encryption
In this work, we enhanced the functionality of the CP-ABE scheme to embrace the fully hidden access policy. Therefore, four significant modules of CP-ABE were involved in constructing our hiding reinforcement approach.
System Setup (): It takes security parameter, λ as an input, and produces a public parameter key , also a master key as the outputs. They are used as input for the key generation algorithm.
Key Generation (: Attribute Authority is the main component in CP-ABE that we utilized to execute the key generation algorithm. The Attribute Authority used inputs from the system setup (i.e., public parameters , master key and users’ attributes ) for generating a secret key . Later, the secret key is employed by the data user to decipher the encrypted data.
Encryption (): In this module, it captures the public parameters , a message and an access structure ) as the inputs. The encryption algorithm then produced the ciphertext . The data owner sends out the ciphertext along with the hashed value in the Cloud environment.
Decryption (): The decryption module took the public parameters , a secret key associated with the attributes set , and a ciphertext as the input. All these three inputs are used to decrypt the ciphertext and produce message .
3.3. System Model
Figure 2 shows that the system model consists of four entities, which are Data Owner (DO), Cloud Service Provider (CSP), Attribute Authority (AA), and Data User (DU). The DO are legal users that are responsible for encrypting and outsourcing the data in the Cloud. The data owner defined the access policy and performed a policy hiding process. While in the pre-processing process, the redundant data in the raw message is eliminated before it is encrypted in the encryption process. Next, the data owner uploads the ciphertext with the hidden value of the access policy to the Cloud storage. Hence, the DU (or recipients) who satisfy the access policy will be able to decrypt the data. In this work, Cloud Service Providers (CSPs) are assumed to be solitary entities that do not interest their users/clients. It means acting as a platform where various data and users can reach, passing the messages, and storing the files. The access policy is handled on the user’s side (DO). The Attribute Authority (AA) is an accountable entity that works as a key generation center. The users’ attributes will be authenticated by AA before granting access privileges to the authorized users to interact with the system. The AA might receive authentication privileges from the DO or any other Cloud security mechanism agreements.
3.4. Security Goals
Our reinforcement hiding in access policy means to conceal the attributes’ details. Hence, it ought to consider the security features as follows:
Confidentiality: It is achieved when unauthorized users are unable to access the encrypted data, and only users who satisfy the access policy can perform the encryption and decryption module. Data confidentiality is also achieved when other entities, including the CSPs, cannot read/access any information from the encrypted data.
Data privacy: The access policy in our scheme complied with the encrypted data features where it had been hidden even though it was already in the ciphertext. It is performed in a two-level data concealment strategy that fully hides the attributes and data compression. When it reaches its destination, the decryption is performed with the respective key to disclose the data in a readable form. Therefore, it prevented the user’s privacy from being exposed.
Fine-grained access control: Users of the Cloud do not have the equal privilege of retrieving data. The privilege depends on the extent to which the user is involved or responsible. In our design, users are assigned to dissimilar access privileges defined based on the access policy imposed by the Attribute Authority (AA). All the attributes should be matched with the user access policy structure to retrieve the required information.
3.5. Security Model
This section discusses the security model for the proposed PHLC scheme. This scheme was constructed based on Zhang’s scheme [
23] by re-simulating their works. Hence, this scheme’s security model is based on a security game between adversary
and challenger
as presented in [
23]. The following is a full description of the game:
Setup. To obtain the public parameters and the master key , Challenger runs the setup algorithm. The Challenger holds the master key and sends adversary the public parameters .
Phase 1: Adversary adaptively issues a secret key query to the key generation module. For each query on an attribute set , challenger returns a Secret Key to Adversary .
Challenge. Adversary generates two messages , , (|| = ||) and an access structure ((), (() in Phase 1 with the restriction that none of them can fulfill any of the queried attributes set . In response, challenger selects a bit ← {0,1}, choose 0, ∈ at random. The challenge ciphertext of the message was then computed under the access structure ), and the challenge ciphertext was sent to Adversary .
Phase 2: Repeat Phase 1. The adversary request a private key, however none of the attribute met the access structure.
Guess: If , the adversary produces a guess bit and wins the game.
In this game, the adversary ’s advantage is defined as , where the probability is divided by the number of random bits used by the adversary and the challenger .
Definition 2. A PHLC scheme with hidden access policy is fully secure if all polynomial-time adversaries have at most a negligible advantage in the security game.
4. Implementation of Policy Hiding in CP-ABE Using Logical Connective
Note that the attribute values of the access policy contain sensitive users’ data. For example, the medical and healthcare Cloud system’s attribute value could include information on patients’ ailments and family history of hereditary diseases. Hence, such information needs to be concealed to protect the users’ privacy. Applying the attribute hiding in access policy preserves the attribute values for gaining Cloud data privacy.
In our encryption solution, the access policy is constructed in CP-ABE using the policy hiding logical connective (PHLC) strategy. Specifically, as mentioned earlier, we integrate policy hiding schemes into CP-ABE components, that is, Setup, Key Generation, Encryption, and Decryption. We improved the Data Owner (DO) roles in the CP-ABE by appointing the encryption process with a hiding policy.
Figure 3 describes in detail our enforcement of hiding by enhancing CP-ABE.
4.1. SETUP (1λ) → PK, MSK
The Attribute Authority (AA) ran the setup algorithm by taking
λ as a security parameter in the setup module. The setup algorithm produced a tuple N = (
;
T;
) which contained four prime numbers,
. Meanwhile, four distinct ordered subgroups given as
are structured based on the prime numbers. Let
and
T; be a cyclic group with order N. Therefore, the attribute authority uniformly chooses
1,
R and
,
1
.
1 were set as public hash functions, with
mapped the attribute value,
to an element in
, and
was a pseudo-random function that mapped elements in
and
to elements in
.
is a bilinear map, and it will be computed value
, Public Parameters
and Master Key
as:
4.2. KEYGEN (PK, MSK, S) → SK
Attribute Authority (AA) checked the users to ensure that only legitimate users could access the file system. The AA aborted any illegal access towards the file system by generating the secret key. Specifically, it takes input public parameters , master key users’ attributes to generate the secret key, . Given represents the attribute name index set and is the attribute value set for the user. The AA ran the KeyGen module as follows:
AA chose
and
for
. It computed
as
Then, the secret keys associated with attribute set
were calculated as
4.3. PRE-PROCESSES () →
This new module is constructed to eliminate redundant data in a raw file before it has been encrypted in the encryption module. Each data in the input message is assigned an index number. For each re-appearance word, the index number is combined with the existing word, and the new message without redundant data is saved as message
. Algorithm 1 represents the pre-processing process named FWA pre-processing.
Algorithm 1 FWA pre-processing |
Input |
Output: |
Begin |
= 0, |
Foreach
|
|
|
If exist, |
update |
Else |
|
|
End the process |
4.4. ENCRYPT
In this module, we input public parameter
, Message
and access structure
and produced the ciphertext,
. In access structure
,
is an access matrix
and
mapped each row
to an index of the attribute name. Meanwhile
is a set of attribute-value related to the access policy (
. The encryption algorithm selected a random vector
where
was randomly selected from
and
is a shared value. For
to
, it computed
, where
corresponded to the
row of
and calculated
Additionally, it also randomly took
Finally, it calculated the entire ciphertext components
as follows:
Previously, the access policy ((
) is appended to the ciphertext
then outsourced to the cloud storage. However, this access policy is in a readable format, possibly exposing several sensitive information about the users. The researchers in [
25] had emphasized that the attribute mapping function
ρ will be caused attribute leakage. Hence, we improved the scheme to prevent the user’s privacy leakage by eliminating the attribute mapping function. In this scheme, we replaced attribute value in access structure
with attribute location in the form of
. Nonetheless, this strategy is insufficient to preserve Cloud data privacy. Therefore, XOR-based logical connective is used in policy hiding strategy to enhance the privacy of access policy.
Our policy hiding logical connective (PHLC) strategy is used to convert the location attribute value (
in the access policy to ciphertext. We specifically extracted the exact location of attribute value from the access policy ((
). Once the location is obtained, it has then been converted into a ciphertext based on the XOR operation.
Figure 4 portrays the example of the access matrix
where the
and
values are represented as the location of the attribute value, which comprises of attribute name, attribute value, and the act of mapping
ρ to the index of the attribute name. We removed the mapping
and used the attribute location
.
The post-encryption module is then executed where it is where our main contribution of CP-ABE extension takes place. It is deliberated as below:
4.5. Policy Hiding (() →
In this process, we derived the hidden value
HV, which is the location of the attribute value that has been encrypted. The policy hiding algorithm adopts an access policy ((
as an input. It first extracted the attribute values’ set associated with access policy (
) and then got the exact location
of each attribute value. Each location is converted to ciphertext via operation
and
. Finally, our CP-ABE solution produced the output of ciphertext and hidden value in (
,
) and outsourced it to Cloud servers. Algorithm 2 depicts the entire Policy Hiding Algorithm.
Algorithm 2 Policy Hiding Algorithm |
Input: Access policy (() |
Output: Hidden Access Policy |
Begin |
foreach AVx of , x = index of AV. |
Extract location (Xx, Yx) |
Convert location (Xx, Yx) String to Binary |
Compute x = XxYx |
Compute x = xYx |
Convert Binary to Hexadecimal for each x, store as = x |
End the process |
4.6. Decryption
Data users (recipients) accessed the encrypted data from the Cloud and downloaded it according to their preferences. Nonetheless, the decryption process is secured via access controls in which only legitimate data users are allowed to decrypt the ciphertext. Hence, when the user attribute satisfied with the access policy; the users are eligible to perform the decryption process. In prior, the data user (DU) needs to extract the hidden policy after receiving from the Cloud storage based on the following decryption algorithm.
4.7. Ext Hidden Policy → ()
In the decryption process, the hidden value,
is used as an input that is retrieved from the cloud storage. Based on
HV, it converted the value of
HV into a binary set, then formed the operation of
and
obtained the attribute’s original location. It describes further in Algorithm 3.
Algorithm 3 Extracting Hidden Access Policy |
Input: Hidden Access Policy |
Output: Access policy (() |
Begin |
foreach of access policy = index of . |
Convert hexadecimal to binary; store as (Xx, Yx) |
Compute = Yx |
Compute Yx |
Convert into Unicode Text |
End the process |
Upon successful concealment of the hidden access policy, the data users run the following decryption algorithm below:
4.8. Decrypt
Similar to [
23], after accepting
, the decrypt algorithm checks whether the hash value of
. If the value is equal, then the system authorized the DU to decrypt the
CT as below:
Given that if the key of the symmetric encryption scheme had been successfully computed, then the decryption algorithm determined the values . Only if the equation holds, the message will be produced. Otherwise, the process will be terminated. The plaintext is recovered via the calculation . Specifically, the reinforcement hiding in access policy is employed to maintain the Cloud data privacy by concealing the values of attributes. The policy hiding (Algorithm 2) is concealed in the encryption module, and it runs after the encryption algorithm. Algorithm 3 then extracted the policy hiding algorithm before the decryption algorithm.