CESCR: CP-ABE for efficient and secure sharing of data in collaborative ehealth with revocation and no dummy attribute.

With the rapid advancement of information and communication technologies, there is a growing transformation of healthcare systems. A patient's health data can now be centrally stored in the cloud and be shared with multiple healthcare stakeholders, enabling the patient to be collaboratively treated by more than one healthcare institution. However, several issues, including data security and privacy concerns still remain unresolved. Ciphertext-policy attribute-based encryption (CP-ABE) has shown promising potential in providing data security and privacy in cloud-based systems. Nevertheless, the conventional CP-ABE scheme is inadequate for direct adoption in a collaborative ehealth system. For one, its expressiveness is limited as it is based on a monotonic access structure. Second, it lacks an attribute/user revocation mechanism. Third, the computational burden on both the data owner and data users is linear with the number of attributes in the ciphertext. To address these inadequacies, we propose CESCR, a CP-ABE for efficient and secure sharing of health data in collaborative ehealth systems with immediate and efficient attribute/user revocation. The CESCR scheme is unbounded, i.e., it does not bind the size of the attribute universe to the security parameter, it is based on the expressive and non-restrictive ordered binary decision diagram (OBDD) access structure, and it securely outsources the computationally demanding attribute operations of both encryption and decryption processes without requiring a dummy attribute. Security analysis shows that the CESCR scheme is secure in the selective model. Simulation and performance comparisons with related schemes also demonstrate that the CESCR scheme is expressive and efficient.

1 Introduction

Collaborative ehealth is a paradigm that enables sharing of electronic health information between healthcare stakeholders for efficient coordination and quality healthcare delivery to patients. In modern healthcare systems, the paradigm is playing a vital role in patients being simultaneously treated by multiple healthcare institutions [1]. In collaborative ehealth systems, the electronic health information can be obtained through wearable and embeddable health sensors [2, 3], medical recordings from health facilities, etc., and be outsourced to the cloud for sharing [4-6]. For example, consider a patient being treated simultaneously by two hospitals H-A and H-B for a heart problem and diabetes, respectively. As part of the treatment plan, H-A gives the patient a wearable health sensor to monitor her daily heart rate. Through a mobile device, the health sensor data is outsourced to the cloud for access by both H-A and H-B. This way, the need for repeated and duplicated medical examinations by H-B is minimized.

As fascinating as it may be, there are still several concerns that need to be addressed for its total acceptance. In particular, the use of third party servers for data storage presents privacy and security issues which are increasingly becoming the biggest concern in collaborative ehealth systems. Adoption of the traditional access control techniques can be used to address the data privacy and security concern in collaborative ehealth. However, these techniques only allow coarse-grained access policies which are not ideal for scalable environments.

An attractive solution is to adopt the attribute-based encryption (ABE) scheme which allows for the realization of fine-grained access policies [7]. ABE is primarily divided into: key-policy attribute-based encryption (KP-ABE) [7, 8] and ciphertext-policy attribute-based encryption (CP-ABE) [9] which is our focus in this work. In CP-ABE, the ciphertext is associated with an access policy and the user key is labeled with a set of attributes. Since its inception, CP-ABE has attracted a lot of attention for fine-grained access control in cloud environments. In [10-16], different CP-ABE schemes are proposed for fine-grained access control of data in the cloud. However, the schemes rely on access structures that are either monotonic or restrictive, thus affecting the expressiveness and efficiency of the resulting schemes. As a result, ordered binary decision diagram (OBDD) access structure has been proposed and used for construction of expressive and efficient CP-ABE schemes in [17, 18].

Although the traditional OBDD-based CP-ABE schemes are expressive, their direct adoption for collaborative ehealth does not seem suitable. It is still necessary to simultaneously resolve the issues of unboundedness, expressiveness, efficiency and attribute/user revocation to ensure their usability and effectiveness for fine-grained access control in collaborative ehealth environments.

Attribute/user revocation and collusion resistance

Revoking misbehaving/compromised or obsolete users is a key requirement in collaborative ehealth systems [19]. However, the users share attributes and revoking a user of an attribute affects other users bearing the same attribute. As such, techniques like the expiration times [20, 21], version numbers [22, 23], attribute groups [24, 25], etc., have been proposed to achieve attribute/user revocations in systems deploying ABE schemes. The most important aspect in revocation is that collusion between revoked and non-revoked users should be prevented.

Unboundedness

ABE schemes are alternatively classified into “bounded” and “unbounded” schemes. In “bounded” schemes, the total number of attributes in the attribute space is fixed during setup and is polynomially bounded in the security parameter. The bounding of the size of the attribute universe can have undesirable effects on systems deploying ABE schemes. A smaller bound might result in the system exhaustion and a need for complete rebuilding when expansion is required. For example, consider the previous scenario in which the patient suffering from the heart disease is being treated by a doctor in hospital H-A. In a smaller bound ABE scheme deployment, the attribute universe leveraged for encryption and user key generation can be set as {hospital, department, profession}. However, at a later time, if the patient requires her data to be accessed only by experienced doctors, a new attribute “experience” might be introduced. In this bounded setting, to generate parameters associated with the “experience” attribute, the system will have to be completely rebuilt and additional expenses are incurred to re-encrypt all the ciphertexts. On the other hand, a larger bound might result in inefficient use of system resources as some parameters might be redundantly stored. Meanwhile, in the “unbounded” schemes, the total number of attributes in the attribute space is not bounded during setup and can expand exponentially.

Efficiency

In collaborative ehealth, several less powerful computing devices are involved. Consider the same scenario in which the patient suffering from the heart disease is being given a sensor device to monitor her daily activities by H-A. The captured sensor data is encrypted and sent to the cloud for analysis and diagnosis by doctors in H-A. In such a setting, the patient might be mobile and most likely use her mobile phone which has limited computing power to perform the data encryption before sending it to the cloud. This necessitates outsourcing of the computationally demanding ABE attribute operations incurred during encryption to the cloud. The same might apply to the doctor and thus, necessitates outsourcing of computationally demanding attribute operations incurred during decryption to the cloud. The most common technique used for secure outsourcing of computations in ABE involves the use of a dummy attribute which is borne by all the users in the system [26].

Expressiveness

Apart from the mentioned issues, expressiveness is another important issue to consider in attribute-based access control schemes. Several existing schemes support restrictive and monotonic access structures which are less expressive. A more expressive and non-restrictive access structure is the OBDD access structure and it can represent any non-monotonic boolean formula.

Our contribution

In this study, we address the security and privacy concerns in collaborative ehealth by proposing CESCR scheme. In CESCR, we simultaneously address the issues of attribute/user revocation, user collusion, unboundedness, expressiveness and efficiency. We provide a comprehensive security analysis, and simulation and performance evaluation for the CESCR scheme. The security analysis, and the simulation and performance evaluation results show that CESCR is secure and efficient for sharing of health data in collaborative ehealth systems. Specifically, CESCR scheme has the following features:

Attribute/user revocation: In CESCR, we adapt the attribute group approach [24]. Attribute groups are created whose members are users sharing the same attribute. A user can belong to multiple attribute groups depending on the number of attributes he/she bears. Each attribute group has a unique key only known to its group members. When a user is revoked of an attribute, a new attribute group is generated and broadcast to all the group members except the revoked user and the ciphertext element associated with the revoked attribute is updated. Unlike in [24, 25], in CESCR, the attribute keys are tightly and efficiently bound to the user identity which helps to prevent collusion attacks.

Unboundedness: In CESCR, the size of attribute universe is not bounded to the security parameter and thus, the number of attributes can expand exponentially while keeping the number of system public parameters constant. To achieve this, we propose a novel technique in which the only attribute elements in CESCR’s ciphertexts are those associated with the attribute groups of the ciphertext attributes.

Efficiency: CESCR securely outsources the computationally demanding attribute operations in both encryption and decryption to the cloud. But unlike other schemes that leverage dummy attributes to achieve secure outsourcing, the CESCR scheme does not require a dummy attribute.

Expressiveness: CESCR uses the OBDD access structure, which is non-monotonic and non-restrictive. Thus, it can handle any non-monotonic access policy expressable using the OBDD access structure.

User collusion resistance: In CESCR, the decryption keys are bound to the user identity, which makes it collusion resistant.

Paper organization

The rest of the paper is organized as follows, in Section 2, we present the related works. In Section 3, we present the summary of access structure, and mathematical and cryptographic complexity assumptions used in this work. Section 4 covers the system architecture, the formal scheme definition and the security model. In Section 5, we present the concrete construction of the CESCR scheme. We present the security analysis of our scheme in Section 6. Sections 7 and 8 present the simulation and performance evaluation, and conclusion, respectively.

2 Related work

The demand for improved healthcare service delivery is constantly increasing. Additionally, healthcare services are shifting from treatment oriented to proactive prevention. To achieve this, there is a need to have electronic health information centrally stored to be accessed and shared with healthcare stakeholders. For this reason, cloud-based health systems have turned out to be useful. In [27], an intelligent cloud-based healthcare service system is designed in which health sensors are utilized to obtain health data from a patient and sent to the cloud for storage and analysis. The system provides real time monitoring of patients for chronic diseases. In [28], Miah et al. designed a cloud-based ehealth system to enable health workers to collaborate for identifying and treating non-communicable diseases in rural areas of developing countries. In their system, less knowledgeable health workers in rural communities record health information from patients which are then stored in the cloud and made accessible to remotely located but knowledgeable doctors for analysis and recommendations. [29, 30] proposed integration of smart homes in cloud-based health systems. Their proposed system utilizes the smart home environment to gather health information which is then sent to the cloud for analysis.

Although the above-discussed studies have proposed and designed interesting health systems, none of them has focused on the data security and privacy issues encountered during health data sharing. To address the above issues, [31] designed a scheme that provides location privacy for patients and doctors in IoT-based health systems. The scheme employs the Chinese remainder theorem to preserve location privacy. Similarly, in [32], Azees et al. proposed schemes for anonymous authentication of patients and doctors in IoT-based health systems, and preserve the confidentiality of health data exchanged between the entities. [5, 6, 21, 33, 34] have studied and proposed ABE schemes for secure sharing of electronic health information in cloud-based health systems. ABE was originally proposed by Sahai and Waters in the form of fuzzy identity-based encryption [7]. It has since then been categorized as: KP-ABE in which secret keys are associated with access policies while ciphertexts are associated with attribute sets [8], and CP-ABE in which secret keys are associated with attribute sets while ciphertexts are associated with access policies [9]. Cheung and Newport then proposed a CP-ABE scheme based on the AND-gate access structure [11]. In the same work, they presented a security proof for their scheme in the standard model. Further ABE schemes have been proposed focusing on multi-authority [35, 36], hidden access-structure [37, 38] and hierarchy [39, 40]. However, these schemes rely on access structures that are either monotonic or restrictive. [17, 18] proposed CP-ABE schemes based on the non-monotonic and non-restrictive OBDD access structure. However, their schemes are bounded and aggregate attribute elements in ciphertext and decryption keys together, which makes it difficult to integrate an efficient and immediate attribute/user revocation.

A number of attribute/user revocation approaches have been proposed for ABE systems. In [20, 21, 41], a revocation list is included during encryption which is updated periodically. A user whose ID is listed in the revocation list is denied key updates and thus unable to decrypt the updated ciphertext. One drawback with this approach is that, revocations are not immediate. [24, 25, 42] proposed attribute group approach, in which attribute groups whose members are users sharing the same attribute are created. Each group is assigned a key only known to its members. Whenever a user is revoked from the group, a new key is generated and broadcast to all the group members except the revoked user. However, the [24] scheme suffers from collusion attacks, the [25] scheme is computationally inefficient and the [42] scheme is less expressive as it relies on the monotonic LSSS access structure. Version number approach is proposed in [22, 43]. In these schemes, user keys and ciphertexts are assigned version numbers, whenever a user is revoked of an attribute, an update key is generated and forwarded to all non-revoked users and their key version number is increased by one. The ciphertext is also updated and its version number gets increased by one. Further ABE schemes focusing on efficiency through generation of fixed-sized ciphertexts and outsourcing are presented in [26, 44, 45]. In [26], to securely outsource computations to the cloud, an inefficient approach in which a redundant dummy attribute which is shared by all the users is used. The elements associated with the dummy attribute are never updated.

The first construction of an unbounded (large universe) KP-ABE scheme was given by [46] in the composite order groups. Rouselakis and Waters in [47] constructed unbounded KP-ABE and CP-ABE schemes supporting LSSS access structures in the prime order groups. The construction in [47] was used by [48] to construct an unbounded CP-ABE scheme with partially hidden LSSS access structures in prime order groups. Recently, Zhang et al. [49] proposed an unbounded CP-ABE scheme for security and privacy protection in smart health systems. Their scheme partially hides LSSS access structures and its construction is based on the composite order groups. An unbounded CP-ABE scheme based on prime order group that supports partially hidden AND access structures is proposed in [50]. A large universe CP-ABE scheme supporting traceability and revocation is proposed in [51]. However, the scheme supports only the monotonic LSSS access structures and leverages the direct revocation mechanism in which the revocation lists are included during encryption. As such it is less expressive and does not achieve immediate attribute/user revocation.

In this work, we adapt the attribute group approach of [24, 25, 42] to achieve immediate and efficient attribute/user revocations. However, unlike in previous works, to prevent collusion attacks, the attribute group keys are efficiently bound to the user identities in this work. The unboundedness in our scheme is achieved through a novel technique that limits the attribute elements in the ciphertexts to only those associated with the attribute group keys of the ciphertext attributes. Our scheme also securely outsources computations to the cloud with no need for a redundant dummy attribute. To achieve expressiveness, we leverage the OBDD access structure. However, unlike in [17, 18], the attribute elements in the ciphertext and secret keys are not bound together, thus making it possible to achieve efficient and immediate attribute/user revocations.

3 Preliminaries

In this section, we present the summaries of bilinear map, complexity assumption, access structure, and the CP-ABE scheme that lays the foundation for the construction of the CESCR scheme.

3.1 Bilinear map

As in [9], let and be two cyclic multiplicative groups of prime order p and g be the generator of . A bilinear map is defined as, , subject to satisfaction of the following properties:

Bilinearity. That is, e(u, v) = e(u, v) = e(u, v) for a given and .

Non-degeneracy. That is, ∃ such that e(u, v) ≠ 1.

Computability. That is, ∀ , e(u, v) is computationally feasible.

3.2 Decisional Bilinear Diffie-Hellman (DBDH) assumption

Definition 1: The DBDH [14] assumption states that, given two tuples (g, g, g, g, e(g, g)) and (g, g, g, g, e(g, g)), where , a probabilistic polynomial time algorithm that outputs {0, 1} can distinguish the two tuples with at most a negligible advantage ε, i.e., .

3.3 Access structure

Definition 2: An access structure is a rule that returns 1 if an attribute set S satisfies (). Otherwise it returns 0. In this work, the access structure used is the ordered binary decision diagram (OBDD) access structure which is non-monotonic and non-restrictive.

3.4 OBDD access structure

Definition 3: An OBDD access structure is a rooted, directed acyclic graph (G = (V, E)) for a boolean function f(a0, ⋯, a) over a set of boolean variables {a0, ⋯, a} with a pre-defined variable ordering [52]. Where the boolean variables depict the attributes and n is the number of attributes in the set. The graph has the following properties:

There are two kinds of nodes in the graph G, i.e., V is either a terminal or a non-terminal node.

Each non-terminal node in G has two child nodes low(v) and high(v). Also, each non-terminal node is labeled with a 4-element tuple (i, id, low(v), high(v)), where i ∈ I is the serial number of the attribute represented by the node, id ∈ ID is a unique number assigned for the identification of the node, and low(v) ∈ V and high(v) ∈ V are the serial numbers of the node’s low(v) and high(v) child nodes, respectively. I is the set of attributes in the access structure and ID is the node identity universe.

There are two terminal nodes labeled as 1 and 0, and they neither represent an attribute nor have child nodes.

Each variable (attribute) appears only once along a directed path from the root node to a child node.

There are no identical non-terminal nodes, i.e., non-terminal nodes should not share the same id, low(v) and high(v) elements.

No node has identical low(v) and high(v) nodes, i.e., low(v) ≠ high(v).

OBDD access structure satisfaction

OBDD access structure satisfaction process is done recursively. Given an attribute set S, starting from the root node, S is compared with the attribute value stored in the node. If an element in S matches the current node’s attribute, S is forwarded to the high(v) child node. Otherwise, it is forwarded to the low(v) child node. This is done repeatedly until it is either forwarded to the 1 terminal node or the 0 terminal node. If the 1 terminal node is reached at the end of the process, S satisfies the OBDD access structure. Otherwise, S does not satisfy the OBDD access structure.

As an example, consider an access policy represented by the following boolean function f(a0, a1, a2) = a0.a1 + a0.a2 + a1.a2. The OBDD access structure depicting the described access policy is shown in Fig 1. All the paths from the root node to the 1 terminal node satisfy the OBDD access structure. Thus, the paths, a0 a1, and satisfy the OBDD access structure. However, the paths, , and do not satisfy the OBDD access structure as they lead to the 0 terminal node.

Fig 1

An OBDD access structure depicting the f(a0, a1, a2) = a0.a1 + a0.a2 + a1.a2 access formula with variable ordering as: a0 < a1 < a2.

The solid arrows represent the edges leading to the nodes’ high(v) child nodes and the dotted arrows represent the edges leading to the nodes’ low(v) child nodes.

3.5 Review of the CP-ABE scheme based on the OBDD access structure

In this section, we present the summary of the conventional CP-ABE scheme [17] based on the OBDD access structure that lays the foundation for the construction of our proposed CESCR scheme and proceeds as follows:

Setup(λ)→(pp, mk): the algorithm chooses the groups and defines the bilinear map as defined in the Section 1. It then randomly chooses and computes Y = e(g, g). For each attribute in the universe, it randomly chooses and computes , where is the attribute universe. It publishes the public parameters pp as: and the master key mk as: .

KeyGen(S, mk)→(sk): It computes the secret key sk associated with the attribute set S. It first randomly chooses and computes D = g and . The secret key sk is (D, D).

Encrypt(M, pp)→(CT): The data owner first defines an OBDD access structure. The Encrypt algorithm then randomly chooses and generates the ciphertext CT as: (). Where I is the attribute set in the OBDD access structure and R is the set of paths that satisfy the OBDD access structure.

Decrypt(CT, sk)→M/⊥: If the user attribute set S satisfies the OBDD access structure, the algorithm computes, The user then recovers M by computing C1/Y. Otherwise, the algorithm returns ⊥.

4 System architecture, formal definition and security model

In this section, we present the system architecture, the formal definition of the CESCR scheme and the security model.

4.1 System architecture

Shown in Fig 2 is the system architecture depicting the main entities in our scheme which are described as follows:

Fig 2

An architecture of our scheme depicting the entities involved.

Trusted Authority (TA). The TA is a trusted entity that is in-charge of the system initialization, and it also authorizes the data users and the data owner. The TA initializes the system by generating the system public parameters which are made available to all the other entities, and the master key which is kept secret. It authorizes data users through issuing keys associated with user attribute sets. If necessary, the TA also issues a key to the data owner. Additionally, the TA generates attribute group information which it shares with the cloud. We assume the TA is mostly online.

Data Owner (DO). The DO is an entity that owns and manages the outsourced data in the form of ciphertexts. The DO can be a patient or a hospital responsible for managing the patient’s data. The outsourced data can be medical recordings obtained from a hospital or health data obtained from health sensors attached to the patient. The DO has either a local server or a smart device that is used to perform partial encryption tasks. Before outsourcing the health data, the DO defines an access policy which is securely sent together with the partially encrypted data to the cloud.

Data User (DU). The DU is an entity that uses the patient’s data. Doctors, researchers, pharmacists, etc., are some of the examples of DU. Each DU has a set of attributes and attribute associated keys. If the DU’s attribute set satisfies the access policy embedded in the ciphertext, he/she can successfully decrypt the ciphertext and use the patient’s data. Otherwise, the decryption fails.

Cloud. The cloud is an entity that stores and performs partial computations on the health data. In this work, we categorize the cloud into two: the encryption and storage cloud (ESC) and the decryption cloud (DC). The ESC receives the partially encrypted data from the DO, completes the generation of the ciphertext and stores it for sharing with the DUs. Meanwhile, the DC securely receives attribute associated keys from a DU and ciphertext from the ESC to perform partial decryption. We assume the cloud is honest but curious.

4.2 Formal definition of CESCR

A CESCR scheme consists of ten algorithms which are described as follows:

Setup(1λ)→(pp, mk): The Setup algorithm is executed by the TA. It takes as input the security parameter λ and generates the public parameters pp and the master key mk as its output.

KeyGen(S, uid, mk, pp)→(D, D): The KeyGen algorithm is executed by the TA. It takes the public parameters pp, the master key mk, a user identity uid and a set of attributes S as inputs. It generates the decryption keys (D, D) associated with the attributes in S as its output.

KEKGen(i, k, v, uid, mk, pp)→(KEK): The KEKGen algorithm is executed by the TA. The algorithm takes the public parameters pp, the master key mk, a user identity uid, a minimum cover node v, an attribute group key k and an attribute i as its inputs. It outputs a key encryption key (KEK) associated with the attribute i.

Encrypt(OBDD, M, pp)→(CT): The Encrypt algorithm is executed by the DO. The algorithm takes the DO defined access policy OBDD, the data to be encrypted M and the public parameters pp as its inputs. It generates a partial ciphertext CT as its output.

CldEncrypt(CT, k, v, pp)→(CT): The CldEncrypt is executed by the ESC. It takes as input the public parameters pp, the partial ciphertext CT, attribute group keys k(s) and the minimum cover nodes v associated with each attribute in the access structure, and generates a complete ciphertext CT as its output.

CldDecrypt(CT, D, D, KEK, pp)→(C/⊥): The CldDecrypt algorithm is executed by the DC. The algorithm takes as input the public parameters pp, a DU’s decryption key elements D and D, a DU’s key encryption key KEK and a ciphertext CT. If the set of the DU’s attributes satisfy the access structure OBDD, the algorithm generates a token C as its output. Otherwise, it generates ⊥.

Decrypt(C, CT, pp)→(M): The Decrypt algorithm is executed by the DU. It takes the public parameter pp, the ciphertext CT and the token C as its inputs. It recovers M as its output.

UpInfo(i, pp)→(uk): The UpInfo algorithm is executed by the TA after an attribute revocation. It takes as input the public parameters pp and a revoked attribute i. The algorithm outputs an update key uk for the revoked attribute i.

CTUpdate(CT, uk, i, pp)→(CT′): The CTUpdate algorithm is executed by the ESC after an attribute revocation. It takes the public parameters pp, the revoked attribute i, an update key uk and the ciphertext CT as its inputs. It outputs an updated ciphertext CT′.

KeyUpdate(i, uk, KEK, pp)→(): The KeyUpdate algorithm is executed by the DU who bears a revoked attribute i. The algorithm takes the revoked attribute i, an update key uk, a key encryption key KEK and the public parameters pp as its inputs. It outputs an updated key encryption key associated with the revoked attribute i.

4.3 Security model

In this subsection, we give a security model for the CESCR scheme. The security model is described as a CPA game played between a probabilistic polynomial time (PPT) adversary and a challenger, and proceeds as follows:

Init: The adversary declares a challenge access structure and an attribute i* to the challenger.

Setup: The challenger runs the (pp, mk)←Setup(1λ) algorithm. The challenger forwards the public parameters pp to the adversary and keeps the master key mk.

Phase 1: The adversary issues polynomially bounded series of key queries by each time submitting an attribute set S and a user identity uid to the challenger. S satisfies the challenge access structure but the attribute i* is revoked. The challenger executes the (D, D)←KeyGen(S, uid, mk, pp) and KEK←KEKGen(i, k, v, uid, mk, pp) algorithms, and gives D, D and KEK to adversary . The adversary may also decide to ask for update key for an attribute i ≠ i*. The challenger executes the uk←UpInfo(i, pp) algorithm and sends to the update key uk.

Challenge: Once the adversary decides that Phase 1 is over, it submits two messages M0 and M1 of equal lengths to the challenger and sets as the access structure and i* as the revoked attribute. The challenger flips a coin μ ∈ {0, 1} and encrypts M by executing the CT←Encrypt() algorithm. The challenger then completes the encryption by running the CT←CldEncrypt(CT, k, v, pp) algorithm to generate the ciphertext CT. The challenger further updates the ciphertext by executing the CT′←CTUpdate(CT, uk, i*, pp) algorithm to generate CT′. The challenger then sends to the CT′ as its challenge ciphertext.

Phase 2: The adversary continues to adaptively issue key queries to the challenger with the restriction that the submitted attribute sets satisfy the access structure but i* is revoked.

Guess: then outputs a guess μ′ ∈ {0, 1}. The adversary wins the game if μ = μ′. wins the game with an advantage defined as .

Definition 4: A CP-ABE scheme with attribute revocation, and outsourced encryption and decryption is selective secure if all PPT adversaries have at most a negligible advantage in winning the defined CPA security game.

5 CESCR scheme construction

In this section, we present a concrete construction of the CESCR scheme. The construction is divided into five phases and proceed as follows:

Setup

The setup phase initializes the system through the Setup algorithm. Let and be two cyclic multiplicative groups of prime order p, g be the generator of , and be a bilinear map as defined in Section 3. A hash function is also defined. Let the attribute universe be .

Setup(1λ)→(pp, mk): The setup algorithm randomly chooses . It then computes h1 = g1/, h2 = g and defines Y = e(g, g). It publishes the public parameters pp as, and keeps the secret master key mk as, mk = (α, y).

Key generation

The key generation phase comprises two algorithms: KeyGen and KEKGen algorithms which are both executed by the TA.

KeyGen(S, uid, mk, pp)→(D, D): The KeyGen algorithm generates the user secret key (D, D). To generate the secret key for a user uid with attribute set S = {a1, a2, ⋯, a}, where n is the number of attributes in S, the algorithm first randomly chooses and computes z as . Also for each attribute in S, the algorithm randomly chooses . It then computes the user secret key (D, D) with respect to the attribute set S as:

KEKGen(i, k, v, uid, mk, pp)→KEK: The KEKGen algorithm is used to generate the key encryption key KEK associated with an attribute i. To generate the KEK, the TA first creates an attribute group G whose members are users bearing the attribute i. As in [24], the TA then establishes a binary tree to manage the members of G as shown in Fig 3. The leaf nodes of the tree represent users. Each node in the tree holds a unique value . The path from the root node to a leaf node forms the path key pkey of a user. For example, the pkey for user uid5 is {v12, v6, v3, v1}. Also, for each attribute group G, there is a set of minimum cover nodes min(G). For instance, suppose the members of the attribute group G are, [uid1, uid2, uid3, uid4, uid5, uid6]. The min(G) for this list of members is {v2, v6}. As seen, there is an intersection v between min(G) and pkey for each member of G. For example the intersection v for uid5 is at node v6. In addition, each attribute group G is given a unique key . TA then computes attribute group information as GI = k/v, which is used during ciphertext generation. To generate a KEK associated with a group G for a user uid, the KEKGen algorithm computes KEK as follows: Note that, this is computed for every attribute group the user belongs to.

Fig 3

A binary tree to manage attribute group members.

Encryption

The encryption phase consists of two sub-phases. The local encryption phase and the cloud encryption phase.

Local encryption: The local encryption phase has one algorithm, the Encrypt algorithm which is executed by the DO. To encrypt data M, the DO first defines an OBDD access structure and uses the Encrypt algorithm to complete the local encryption.

Encrypt(OBDD, M, pp)→CT: The Encrypt algorithm randomly chooses and computes: , C0 = g and . The partial ciphertext CT produced as output by the Encrypt algorithm is: The CT is then sent to the ESC for the cloud encryption and storage.

Cloud encryption: The cloud encryption has one algorithm, the CldEncrypt algorithm executed by the ESC. Upon receiving the CT from the data owner, the ESC requests for attribute group information from TA for each attribute in the OBDD access structure. The TA sends to the ESC. Using the CldEncrypt algorithm, the ESC then securely generates the complete ciphertext of the data M by computing a header C associated with each attribute in the access structure.

CldEncrypt(CT, k, v, pp)→CT: The CldEncrypt algorithm computes the header as follows: Where, I is the attribute set of the OBDD access structure embedded in CT. After generating the headers associated with the ciphertext attributes, the ESC stores the ciphertext CT as: Note that even without a dummy attribute, the ESC does not still obtain any information about the data M during the header generation as it does not know the value of s.

Decryption

To minimize the high computation demand on the DUs, we propose an outsourced partial decryption of the data. Thus, the data decryption phase consists of the outsourced decryption and the local decryption sub-phases.

Outsourced decryption: The outsourced decryption phase is executed by the DC through the CldDecrypt algorithm. To decrypt the ciphertext CT, the DU first blinds his/her keys. The DU randomly chooses and blinds the keys as: The DU then sends the blinded keys to the DC. The DU also requests the ESC to send CT to DC. The ESC responds by sending the C0 and C parts of CT to DC, and the part to the DU. Upon receiving the required CT parts from the ESC, DC executes the CldDecrypt algorithm.

CldDecrypt(CT, D, D, KEK, pp)→C/⊥: The CldDecrypt algorithm checks whether DU’s attribute set satisfies the OBDD access structure in the ciphertext. If it does, it computes a token C as: The generated C is then sent to the DU. Otherwise, it returns ⊥.

Local decryption: Upon receiving C from DC and from the ESC, DU executes the Decrypt algorithm.

Decrypt(C, CT, pp)→(M): The Decrypt algorithm recovers M as:

Revocation

When a user is revoked of an attribute i, the TA updates the attribute group from G to . For example, from Fig 3, if users uid3 and uid4 (the blue leaf nodes) are revoked of the attribute i, the new minimum cover node set associated with the updated group is {v4, v6} which does not now intersect with uid3 and uid4’s pkeys. TA also chooses a new group key for . TA then executes the UpInfo algorithm to generate the update key uk used for updating the ciphertext and the user keys.

UpInfo(i, pp)→uk: The UpInfo algorithm computes the update key uk as: where for updating the ciphertext and where for updating keys of non-revoked users. The TA updates the attribute group information to GI′ as: The TA then sends to the ESC to update the ciphertext and uses uk to update the keys of all the non-revoked DUs in the group.

Ciphertext update: Upon receiving the updated attribute group information, the ESC executes the CTUpdate algorithm to update the ciphertext.

CTUpdate(CT, uk, i, pp)→CT′: The CTUpdate algorithm first randomly selects and updates CT as: Note that, for the revoked attribute, the ESC then uses the newly received and h( to compute the new header. ESC replaces CT with CT′.

Key update: In this work, it is only the KEK key that is updated. The KEK is updated for each non-revoked DU in the group by executing the KeyUpdate algorithm.

KeyUpdate(i, uk, KEK, pp)→: The KeyUpdate algorithm updates the KEK associated with revoked attribute i for each non-revoked DU to as:

6 Security analysis

In this section, we present a security proof of the CESCR scheme.

Theorem 1: Suppose there is a PPT adversary that can win our CPA security game with a non-negligible advantage ε, we can construct a simulator that solves the DBDH problem with a non-negligible advantage.

Proof: Let and be two multiplicative cyclic groups of prime order p. Let g be the generator of and be a bilinear map. The DBDH challenger sends the tuple (g, A = g, B = g, C = g, Z), where to and is asked to output ν. If ν = 0, Z = e(g, g). Otherwise, Z is a random value in . plays the role of the challenger in the CPA security game as follows:

Initialization: Adversary declares a challenge access structure and attribute i* to .

Setup: first sets y = ab. Then, sets h1 = g1/, h2 = g, where , and defines Y = e(g, g) = e(g, g) = e(A, B). sends the public keys to .

Phase I: submits secret key and KEK queries to . requests the secret keys by submitting the attribute set S belonging to a user uid to . S satisfies but i* is revoked. creates a list HL: and a table which are initially empty. checks the HL to confirm whether the pair exists and does the following:

If the pair exists, responds by sending H which is the hash value associated with uid to .

Otherwise, generates H for uid as follows: Where .

stores the pair in HL and sends H to . Note that, can query for H at any time and responds as the same.

Then, checks T to confirm whether the tuple exists. If it exists, sends the associated KEK and () to . Otherwise, does the following:

First, checks HL for the hash value associated with uid. If it exists, extracts it for usage during key generations. Else, uses the above hash generation steps to generate H for uid. Then, for each i ∈ S, randomly chooses and sets , where n = |S| and . Then, uses the ()←KeyGen(S, uid, mk, pp) algorithm to generate the secret key

then randomly chooses and minimum cover node for each i ∈ S∧i ≠ i*. also randomly chooses and as the minimum cover node and group key for i*, respectively. It then sets attribute group key k as follows: then uses the KEK←KEKGen(i, k, v, uid, mk, pp) algorithm to generate the key encryption key KEK for each attribute as:

adds the KEK and () in a tuple and stores it in the table T. sends the , and KEK values to .

may decide to ask for an update key for another revoked attribute i ≠ i*, randomly chooses and using uk←UpInfo(i, pp) algorithm, it generates an update key . then computes a new KEK′ using the KeyUpdate algorithm and submits it to .

Challenge: Once adversary decides Phase 1 is over, it submits two messages M0 and M1 of equal length to and set the access structure as and i* as a revoked attribute. randomly flips a coin μ ∈ {0, 1} and encrypts M as CT using the CT←Encrypt() algorithm. CT is generated as: , C0 = g = C and . Then, for each i ∈ I*, I* is the set of attributes in , generates group attribute information as: then generates headers associated with the ciphertext attributes using the CT←CldEncrypt(CT, k, v, pp) algorithm as: The generated CT is: then updates the ciphertext using the CT′←CTUpdate(CT, uk, i*, pp) algorithm. first randomly chooses and updates the ciphertext as: For i*, generates , where and uses it together with the updated C1 to generate the C. sets CT′ as the challenger ciphertext CT* and sends it to .

Phase II: continues to adaptively submit key queries as in phase I.

Guess: Adversary then outputs a guess μ′ for μ. If μ′ = μ, outputs ν′ = 0, i.e., Z = e(g, g). Otherwise, outputs ν′ = 1, i.e., Z is a random number in .

In the case ν = 1, the adversary gains no information about M. Thus, . randomly guesses ν′ for ν when μ′ ≠ μ with a probability .

If ν = 0, the adversary sees encryption of the message M. By definition, the advantage of the adversary in this situation is ε. Thus, .

Therefore, the overall advantage of in winning the above game is:

7 Simulation and performance analysis

7.1 Performance analysis

In this section, we analyze and compare our scheme with CP-ABE schemes in [17, 18, 24, 25, 49] in terms of revocation, boundedness, expressiveness and efficiency features. As shown in Table 1, all the schemes including ours are built using the prime order groups except the Zhang et al.’s scheme [49] which uses the composite order group. The schemes [17, 18] and ours are unrestricted and more expressive as they are based-on the non-monotonic and non-restrictive OBDD access structure. Meanwhile, the [18, 24] schemes which are based on the access tree access structure and the [49] scheme which is based on the LSSS access structure are less expressive. Our scheme and the Li et al.’s scheme [25] partially outsource their encryption and decryption tasks and thus, they are computationally more efficient on the data owner and user side. The computation tasks during encryption and decryption in the rest of the schemes are entirely performed by the data owners and data users and hence computationally more demanding on the data owner and data user sides. All the CP-ABE schemes except the [24] scheme are collusion resistant. Immediate attribute/user revocation is achieved in [24, 25] and our schemes, meanwhile, the rest of the schemes do not include an attribute/user revocation mechanism. Only the [17, 18] schemes are bounded, the rest of the CP-ABE schemes including ours are unbounded.

Table 1

Feature and storage comparison of CP-ABE schemes.

	Schemes
	[49]	[24]	[17]	[25]	[18]	CESCR
Key size	|k| + 2	2|k| + 1 + |pk|	2	3|k| + 6	2	3|k|
Ciphertext size	3|l| + 4 + |A|	3|l| + 2 + |A|	2 + |R| + |A|	2|l| + 7 + |A|	2 + |R| + |A|	|l| + 3 + |A|
Unbounded	✔	✔	×	✔	×	✔
Revocation	×	✔	×	✔	×	✔
Coll-Resist	✔	×	✔	✔	✔	✔
Encryption	DO	DO	DO	Par-out	DO	Par-out
Decryption	DU	DU	DU	Par-out	DU	Par-out
Expressiveness	LSSS	Access tree	OBDD	Access tree	OBDD	OBDD
Group Order	Composite	Prime	Prime	Prime	Prime	Prime

*|pk| is path key size, Coll-Resist is collusion resistance, Par-out is partially outsourced, DO is data owner, DU is data user.

In the same Table 1, we present the storage comparison of the CESCR scheme in relation to the other CP-ABE schemes. We use |k| to denote the number of user attributes, |l| to denote the number of attributes in the ciphertext, |A| to denote the size of the access structure and |R| is the number of routes that satisfy an OBDD access structure. Note that the same attribute can be repeated across multiple routes that satisfy the OBDD access structure. It can be observed that the CESCR scheme has optimal ciphertext storage efficiency only bettered by the [17, 18] schemes. This is because the only attribute element included in the CESCR’s ciphertext is the one associated with the attribute group keys. However, the CESCR scheme performs slightly worse than the other schemes except the Li et al.’s scheme [25] in key storage. This is because all the key components are interlinked for each attribute, which helps in preventing collusion attacks.

The computational comparisons are presented in Table 2. The comparison is done in terms of encryption, decryption and key generation costs. The encryption and decryption costs are analyzed on both the data owner and cloud sides. Here, we use |d| to denote the number of attributes involved in satisfying an access structure or simply the number of attributes involved in decryption. The [25] scheme and our scheme outsource the attribute operations during encryption and decryption to the cloud. For the rest of the schemes, the encryption and decryption tasks are entirely performed by the data owner and data user, respectively. Thus, on the DO side, the CESCR scheme has the least computation demand during encryption, as it requires only one multiplication and three exponentiation operations which are independent of the number of attributes in the ciphertext. Zhang et al.’s [49] scheme is the most demanding on the DO side computationally. Unlike the scheme [25] which performs 2 pairing and 2|l| exponentiation operations in the cloud during encryption, our scheme only performs |l| multiplications, which also makes it more efficient on the cloud side during encryption. Similarly, during decryption, our scheme is computationally the least demanding on the DU side as it requires only one multiplication and four exponentiation operations and the Zhang et al.’s [49] scheme is still the most demanding. However, on the cloud side during decryption, our scheme is slightly bettered by the Li et al.’s [25] scheme, this is because our scheme requires more pairing operations. In key generation, though our scheme is computationally more demanding due to its linking of all the key components for all the user attributes, it still performs better than the Li et al.’s scheme [25].

Table 2

Computation comparison of CP-ABE schemes.

			Schemes
			[49]	[24]	[17]	[25]	[18]	CESCR
Encryption Cost	Mult	DO	11|l| + 2	1	|l|	2	|l|	1
		Cloud	n/a	|l|	n/a	n/a	n/a	|l|
	Expo	DO	7|l| + 4	2|l| + 2	|l| + 2	6	|l| + 2	3
		Cloud	n/a	|l|	n/a	2|l|	n/a	n/a
	Pair	DO	n/a	n/a	n/a	2	n/a	n/a
Decryption Cost	Mult	DU	4|d| − 2	≥|d| + 2	2	4	2	1
		Cloud	n/a	n/a	n/a	≥|d| + 2	n/a	2|d|
	Expo	DU	3|d| + 1	1	n/a	4	n/a	4
	Pair	DU	2|d| + 3	≥2|d| + 1	2	n/a	2	n/a
		Cloud	n/a	n/a	n/a	≥2|d| + 4	n/a	3|d|
Key Gen Cost	Mult		2|k| + 4	|k| + 1	1	4|k| + 10	1	|k|
	Expo		2|k| + 3	3|k| + 1	2	4|k| + 6	2	4|k|
	Pair		n/a	n/a	n/a	1	n/a	n/a

*Multi, Expo and Pair represent the multiplication, exponentiation and pairing operations, respectively. DO is data owner and DU is data user.

7.2 Experimental analysis

To explicitly demonstrate the efficiency of the CESCR scheme, we simulated the scheme in comparison with the [25, 24] schemes which we refer to in the experiment as the “LZQH scheme” and “H-N scheme”, respectively. The implementation was done using the Charm crypto framework [53]. We used the “SS512” curve which is a super-singular symmetric elliptic curve over 512-bit base field having a 160-bit curve group order. The experiment was carried out on a desktop computer with a 3.20GHz processor and 4.0 GB RAM running the Ubuntu 12.04 operating system. Each experiment was repeated 20 times, and we averaged the results and are shown in Fig 4.

Fig 4

Simulation results of the CESCR scheme in comparison with the LZQH [25] and H-N [24] schemes.

Fig 4(a) shows the setup computation time against the size of the attribute universe. It can be observed that all the schemes have constant computation time against the number of attributes. The schemes are all unbounded schemes and thus the number of parameters generated at setup does not depend on the size of the attribute universe. Our scheme generates more parameters and thus takes more computation time at setup as compared to the LZQH and H-N schemes. The LZQH scheme generates the least number of parameters during setup and hence the low computation time.

In Fig 4(b), we show the variation of computation time against the number of user attributes during key generation. Our scheme outperforms the LZQH scheme because of its fewer key elements. However, the H-N scheme exhibits the best performance during key generation because of its low exponentiation operation requirements.

Fig 4(c) and 4(d) show the variation of computation time in local and cloud encryptions against the number of attributes in the ciphertext. For our scheme and the LZQH scheme, since they both outsource their attribute operations to the Cloud, the computation time is constant against the varying ciphertext attribute number during the local encryption. For the H-N scheme, the computation time during local encryption increases with the increase in the number of attributes in the ciphertext. However, the computation time increases with the increasing ciphertext attribute number during the cloud encryption for all the schemes. In both cases, our scheme generally performs better than the LZQH and H-N schemes because of having fewer elements and exponentiation operations to be computed by the Cloud. Also, during local encryption, unlike the LZQH scheme, our scheme does not perform any pairing operations and there are no operations associated with a dummy attribute as in the LZQH scheme.

We show the decryption computation times against the varying number of attributes involved during decryption in Fig 4(e) and 4(f). For the cloud decryption, the computation time increases with an increase in the number of attributes involved in decryption for all the schemes except the H-N scheme that does not perform cloud decryption. Meanwhile, all the schemes except the H-N scheme exhibit constant computation times during the local decryption which are 0.02 ms and 0.08 ms for our scheme and the LZQH scheme, respectively. For local decryption, our scheme performs fewer multiplication and exponentiation operations as compared to the LZQH scheme, and thus the low computation time. All the attribute operations associated with decryption are performed by the user for the H-N scheme and hence the increase in computation time against the increase in number of attributes involved in decryption. In the cloud decryption, the difference in computation time between our scheme and the LZQH scheme is minimal.

In Fig 4(g) and 4(h), we show the variation of computation time for ciphertext update and key update against the number of revoked ciphertext and user attributes, respectively. For the ciphertext update, the computation time for our scheme and the H-N scheme increase with the increase in the number of revoked ciphertext attributes but remains constant for the LZQH scheme. This is because our scheme and the H-N scheme update the attribute elements associated with the revoked attributes. Meanwhile, in the LZQH scheme, only two ciphertext elements not related to the revoked attributes get updated and thus the constant computation time. However, unlike the H-N scheme that independently encrypts the header message, our scheme achieves better performance. For the key update, the computation time increases with the increase in the number of revoked user attributes for all the schemes. However, our scheme performs better, since it has fewer key elements that get updated as compared to the LZQH scheme and there is no independent decryption of group keys as compared to the H-N scheme.

In general, the proposed CESCR scheme is more expressive as it can handle the non-monotonic access policies without restrictions and is more efficient on the data user and data owner sides.

8 Conclusion

In this work, we focused on addressing data privacy and security concerns in collaborative ehealth systems. We proposed the CESCR scheme, which is a CP-ABE scheme whose main ingredients are, immediate attribute/user revocation, unboundedness, expressiveness, efficiency, and collusion resistance. We adapted the attribute group approach to address the immediate attribute/user revocation issues and bind the keys to the user identities to prevent collusion between data users. OBDD access structure was used to achieve expressivessness. A novel technique that limits the attribute elements in the ciphertext to only those associated with attribute group keys was proposed to achieve unboundedness and improved efficiency. The CESCR scheme further securely outsources the computationally demanding attribute operations in both encryption and decryption to the cloud without requiring a dummy attribute. We performed extensive security and performance analysis of the scheme in comparison with related CP-ABE schemes and the results show that the CESCR scheme is expressive, unbounded, secure, and efficient in comparison with the related CP-ABE schemes. The addition of traceability through the use of blockchain technology and policy hiding are interesting future considerations.

1 Mar 2021

PONE-D-21-04536

CESCR: CP-ABE for Efficient and Secure Sharing of Data in Collaborative eHealth with Revocation and no Dummy Attribute

PLOS ONE

Dear Dr. Kim,

Thank you for submitting your manuscript to PLOS ONE. After careful consideration, we feel that it has merit but does not fully meet PLOS ONE’s publication criteria as it currently stands. Therefore, we invite you to submit a revised version of the manuscript that addresses the points raised during the review process.

Please submit your revised manuscript by Apr 15 2021 11:59PM. If you will need more time than this to complete your revisions, please reply to this message or contact the journal office at plosone@plos.org. When you're ready to submit your revision, log on to https://www.editorialmanager.com/pone/ and select the 'Submissions Needing Revision' folder to locate your manuscript file.

Please include the following items when submitting your revised manuscript:

A rebuttal letter that responds to each point raised by the academic editor and reviewer(s). You should upload this letter as a separate file labeled 'Response to Reviewers'.

A marked-up copy of your manuscript that highlights changes made to the original version. You should upload this as a separate file labeled 'Revised Manuscript with Track Changes'.

An unmarked version of your revised paper without tracked changes. You should upload this as a separate file labeled 'Manuscript'.

If you would like to make changes to your financial disclosure, please include your updated statement in your cover letter. Guidelines for resubmitting your figure files are available below the reviewer comments at the end of this letter.

If applicable, we recommend that you deposit your laboratory protocols in protocols.io to enhance the reproducibility of your results. Protocols.io assigns your protocol its own identifier (DOI) so that it can be cited independently in the future. For instructions see: http://journals.plos.org/plosone/s/submission-guidelines#loc-laboratory-protocols

We look forward to receiving your revised manuscript.

Kind regards,

Pandi Vijayakumar, Ph.D

Academic Editor

PLOS ONE

Journal Requirements:

When submitting your revision, we need you to address these additional requirements.

1. Please ensure that your manuscript meets PLOS ONE's style requirements, including those for file naming. The PLOS ONE style templates can be found at

https://journals.plos.org/plosone/s/file?id=wjVg/PLOSOne_formatting_sample_main_body.pdf and

https://journals.plos.org/plosone/s/file?id=ba62/PLOSOne_formatting_sample_title_authors_affiliations.pdf

[Note: HTML markup is below. Please do not edit.]

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #1: Partly

Reviewer #2: Yes

**********

2. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #1: Yes

Reviewer #2: Yes

**********

3. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #1: Yes

Reviewer #2: Yes

**********

4. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #1: Yes

Reviewer #2: Yes

**********

5. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #1: In this paper, the authors propose the CESCR solution to solve the problem of instant attribute/user cancellation and collusion, and achieve unboundedness and expressiveness.

Although this scheme implements attribute/user revocation, there are other problems. To accept it, there is still a long way to go. We point out the specific problems:

1. The paper lacks innovative points. The fifth point of user anti-collusion is actually something that has already been mentioned in the first point, and the attribute/user cancellation mentioned by the author is only the technology of other solutions. The fourth point of innovation is also a feature of the OBDD access structure itself, rather than unique to the solution.

2. In the section of Security Analysis, the probability of challenger B's success has not been analyzed in detail. Please use the mathematical formula to analyze concretely.

3. In the section of Simulation and Performance Analysis, the authors only chose to compare with one plan, which makes the degree of persuasion was not strong.

4. The content format and reference format of this article are not accurate enough. Please double check and correct.

Reviewer #2: 1. The introduction part is well written.

2. The technical novelty of the paper is good. The research problem and research methods are described clearly. The paper is potentially worthy of publication.

3. The related work section is comprehensive. However, the authors are requested to analyse the following papers in the releted work section.

* An efficient anonymous authentication and confidentiality preservation schemes for secure communications in wireless body area networks, wireless networks.

* Efficient and secure anonymous authentication with location privacy for IoT-based WBANs, IEEE Transactions on Industrial Informatics.

4. The contribution of this paper is well.

**********

6. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #1: No

Reviewer #2: No

[NOTE: If reviewer comments were submitted as an attachment file, they will be attached to this email and accessible via the submission site. Please log into your account, locate the manuscript record, and check for the action link "View Attachments". If this link does not appear, there are no attachment files.]

While revising your submission, please upload your figure files to the Preflight Analysis and Conversion Engine (PACE) digital diagnostic tool, https://pacev2.apexcovantage.com/. PACE helps ensure that figures meet PLOS requirements. To use PACE, you must first register as a user. Registration is free. Then, login and navigate to the UPLOAD tab, where you will find detailed instructions on how to use the tool. If you encounter any issues or have any questions when using PACE, please email PLOS at figures@plos.org. Please note that Supporting Information files do not need this step.

4 Apr 2021

Our responses to the reviewers' comments are included in the 'Response to Reviewers' file.

Submitted filename: Response to Reviewers.doc

Click here for additional data file.

19 Apr 2021

CESCR: CP-ABE for Efficient and Secure Sharing of Data in Collaborative eHealth with Revocation and no Dummy Attribute

PONE-D-21-04536R1

Dear Dr. Kim,

We’re pleased to inform you that your manuscript has been judged scientifically suitable for publication and will be formally accepted for publication once it meets all outstanding technical requirements.

Within one week, you’ll receive an e-mail detailing the required amendments. When these have been addressed, you’ll receive a formal acceptance letter and your manuscript will be scheduled for publication.

An invoice for payment will follow shortly after the formal acceptance. To ensure an efficient process, please log into Editorial Manager at http://www.editorialmanager.com/pone/, click the 'Update My Information' link at the top of the page, and double check that your user information is up-to-date. If you have any billing related questions, please contact our Author Billing department directly at authorbilling@plos.org.

If your institution or institutions have a press office, please notify them about your upcoming paper to help maximize its impact. If they’ll be preparing press materials, please inform our press team as soon as possible -- no later than 48 hours after receiving the formal acceptance. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information, please contact onepress@plos.org.

Kind regards,

Pandi Vijayakumar, Ph.D

Academic Editor

PLOS ONE

Additional Editor Comments (optional):

The paper can be accepted in the present format.

Reviewers' comments:

Reviewer's Responses to Questions

Comments to the Author

1. If the authors have adequately addressed your comments raised in a previous round of review and you feel that this manuscript is now acceptable for publication, you may indicate that here to bypass the “Comments to the Author” section, enter your conflict of interest statement in the “Confidential to Editor” section, and submit your "Accept" recommendation.

Reviewer #2: All comments have been addressed

**********

2. Is the manuscript technically sound, and do the data support the conclusions?

The manuscript must describe a technically sound piece of scientific research with data that supports the conclusions. Experiments must have been conducted rigorously, with appropriate controls, replication, and sample sizes. The conclusions must be drawn appropriately based on the data presented.

Reviewer #2: Yes

**********

3. Has the statistical analysis been performed appropriately and rigorously?

Reviewer #2: Yes

**********

4. Have the authors made all data underlying the findings in their manuscript fully available?

The PLOS Data policy requires authors to make all data underlying the findings described in their manuscript fully available without restriction, with rare exception (please refer to the Data Availability Statement in the manuscript PDF file). The data should be provided as part of the manuscript or its supporting information, or deposited to a public repository. For example, in addition to summary statistics, the data points behind means, medians and variance measures should be available. If there are restrictions on publicly sharing data—e.g. participant privacy or use of data from a third party—those must be specified.

Reviewer #2: Yes

**********

5. Is the manuscript presented in an intelligible fashion and written in standard English?

PLOS ONE does not copyedit accepted manuscripts, so the language in submitted articles must be clear, correct, and unambiguous. Any typographical or grammatical errors should be corrected at revision, so please note any specific errors here.

Reviewer #2: (No Response)

**********

6. Review Comments to the Author

Please use the space provided to explain your answers to the questions above. You may also include additional comments for the author, including concerns about dual publication, research ethics, or publication ethics. (Please upload your review as an attachment if it exceeds 20,000 characters)

Reviewer #2: (No Response)

**********

7. PLOS authors have the option to publish the peer review history of their article (what does this mean?). If published, this will include your full peer review and any attached files.

If you choose “no”, your identity will remain anonymous but your review may still be made public.

Do you want your identity to be public for this peer review? For information about this choice, including consent withdrawal, please see our Privacy Policy.

Reviewer #2: No

23 Apr 2021

PONE-D-21-04536R1

CESCR: CP-ABE for Efficient and Secure Sharing of Data in Collaborative eHealth with Revocation and no Dummy Attribute

Dear Dr. Kim:

I'm pleased to inform you that your manuscript has been deemed suitable for publication in PLOS ONE. Congratulations! Your manuscript is now with our production department.

If your institution or institutions have a press office, please let them know about your upcoming paper now to help maximize its impact. If they'll be preparing press materials, please inform our press team within the next 48 hours. Your manuscript will remain under strict press embargo until 2 pm Eastern Time on the date of publication. For more information please contact onepress@plos.org.

If we can help with anything else, please email us at plosone@plos.org.

Thank you for submitting your work to PLOS ONE and supporting open access.

Kind regards,

PLOS ONE Editorial Office Staff

on behalf of

Dr. Pandi Vijayakumar

Academic Editor

PLOS ONE