Abstract
Attribute based encryption (ABE) is a cryptographic technique allowing fine-grained access control by enabling one-to-many encryption. Existing ABE constructions suffer from at least one of the following limitations. First, single point of failure on security meaning that, once an authority is compromised, an adversary can either easily break the confidentiality of the encrypted data or effortlessly prevent legitimate users from accessing data; second, the lack of user and/or attribute revocation mechanism achieving forward and backward secrecy; third, a heavy computation workload is placed on data user; last but not least, the lack of adaptive security in standard models.
In this paper, we propose the first single-point-of-failure free multi-authority ciphertext-policy ABE that simultaneously (1) ensures robustness for both decryption key issuing and access revocation while achieving both backward and forward secrecy; (2) enables outsourced decryption to reduce the decryption overhead for data users that have limited computational resources; and (3) achieves adaptive (full) security in standard models. The provided theoretical complexity comparison as well as the conducted experiments show that our construction introduces linear storage and computation overheads that occurs only once during its setup phase, which we believe to be a reasonable price to pay to achieve all previous features.
Introduction
Cloud computing enables the on-demand provision of various resources, such as computing power and storage over the Internet, freeing companies from maintaining IT infrastructure and managing data centers so they can focus on their core business. In addition, cloud computing enables users to take advantage of a variety of powerful resources on a pay-as-you-go basis. Nevertheless, security and privacy issues have become the main obstacle to the wider adoption of cloud computing. According to Techfunnel’s top five cloud computing predictions for 2020 [40], security tops the list of the biggest cloud challenges. Hence, users/companies are reluctant to outsource their important data to non fully-trusted Cloud server.
In a non fully trusted cloud environment, preserving data confidentiality, making appropriate decisions about data access, and enforcing fine-grained access policies are major challenges. Hence, many cryptography-based system models and techniques have been proposed to enable efficient and secure cloud access control. Among the previous, ABE [35]. The latter allows to ensure simultaneously confidentiality preservation and fine-grained access control. ABE has succeeded in attracting considerable research efforts [2,18,48] which allows to define additional cryptographically functional features, such as access revocation, accountability, and robustness to the basic construction. Unfortunately, all the proposed ABE constructions suffer from at least one of the following limitations. First, the lack of robustness meaning that once the authority responsible of issuing decryption keys to data users is compromised, an adversary can either easily break the confidentiality of the encrypted data or effortlessly prevent legitimate users from accessing data. Second, the lack of access revocation making the concerned approaches inflexible. Third, most of the proposed ABE constructions require heavy computation workload to be performed by data user at access time. Last but not least, the lack of security in standard models. We provide a full comparison with related literature in Section 2.
In [5], we propose a new multi-authority ciphertext-policy ABE (CP-ABE) scheme with some interesting features. First, it ensures robustness for both decryption key issuing and access revocation processes. That is, an adversary needs to compromise several authorities to be able either to break the confidentiality of the outsourced data or to prevent authorized users from accessing outsourced data. Second, our construction enable attribute revocation while achieving forward secrecy. Third, it enables to outsource most part of the decryption process to the cloud server while ensuring that the latter learns nothing about the partially decrypted data. Fourth, our construction achieves adaptive security in standard models. The construction we propose in [5] is – to our knowledge – the first to provide all previously mentioned features. Finally, we conduct theoretical comparison with similar constructions to show that ours introduces linear storage and computation overheads that occur only once during its setup phase.
In this paper, we extend our construction proposed in [5] in three directions. First, we improve the propose construction to ensure backward secrecy. Second, we propose a framework implementing the different capability of our construction. Finally, we provide an extensive experimental analysis to evaluate the efficiency of our construction.
The paper is organized as follows. Section 2 reviews related work and provides a comprehensive comparison with our construction. Sections 3 and 4 present the assumptions and the adversary model we are considering to achieve provable security. Section 5 formalizes our primitive. Then, in Section 6, we provide the security results. In Section 7, we discuss the complexity of our construction. Section 8 details the implementation of our construction. Section 9 presents the obtained experimental results. Finally, Section 10 concludes.
Related work
Revocable ABE. Several researchers have been devoted to build ABE constructions allowing access revocation. Liang et al. [24] introduce a provably selectively secure CP-ABE construction that enables access revocation through proxy re-encryption. Using the latter technique, Luo et al. [28] designed a selectively secure and small attribute universe based CP-ABE supporting policy updating. Always relying on proxy re-encryption, Yu et al. [47] propose an AND-gate policy based ABE construction enabling attribute and user revocation. The proposed construction is proved to be selectively secure under the decisional bilinear Diffie–Hellman (DBDH) assumption. To allow the enforcement of non-monotonic access structures, Lewko et al. [19] propose a selectively secure in the standard model ABE construction that enables attribute revocation. Hur and Noh [14] rely on a stateless group key distribution method based on binary trees to define a CP-ABE solution enabling efficient attribute revocation. The authors claimed that the proposed scheme achieves backward secrecy and forward secrecy without providing formal security analysis. Yang et al. [44] propose a CP-ABE construction enabling attribute and user revocation based on a ciphertext re-encryption mechanism performed by a third-party honest-but-curious server. The proposed construction is proved to be selectively secure under the q-type assumption. In [45], Yang et al. propose a multi-authority CP-ABE supporting revocation process. The latter is performed mainly by attribute authorities which are responsible of computing an updated decryption key for each non-revoked user. Relying on binary trees, Cui et al. [7] propose a CP-ABE scheme that enables attribute revocation where most of the related computations are delegated to an untrusted server. Similarly to [14], the authors of [7] claim that their construction is both backward and forward secure without providing any formal proofs. Liu et al. [27] propose a large universe CP-ABE construction enabling both user revocation and accountability. The authors show that the proposed construction is selectively secure in standard models. Li et al. [22] propose a new multi-authority CP-ABE scheme enabling attribute revocation while being adaptively secure in the setting of bilinear groups with composite order. Relying on an untrusted server, Qin et al. [34] design an adaptively secure CP-ABE scheme enabling attribute revocation. In the proposed scheme, the untrusted server is used to help non-revoked users to decrypt ciphertexts. Very recently, Xiong et al. [41] propose an adaptively secure CP-ABE scheme allowing attribute revocation. It uses monotonic span program [17] as an access structure to reduce the number of pairing and exponentiation operations required during data encryption and decryption.
Outsourced decryption-based ABE. To mitigate the burden of decryption for data user, Yang et al. [45] propose a construction that outsource most part of the computations to the cloud server. The same idea was later used in [7,34,41,46]. A common weakness of the previously mentioned ABE constructions is that they all include a single point of failure on security. That is, as soon as an attribute authority is compromised by an adversary, the latter can easily break the confidentiality of the outsourced data by issuing valid secret decryption keys.
Robust ABE. To mitigate the single-point-of-failure weakness, Li et al. [23] propose a multi-authority CP-ABE called TMACS. In contrast to previously mentioned approaches, in TMACS, the set of attribute authorities are collaboratively managing the whole set of attributes and no one of them can have full control over any specific attribute. The construction relies on a
Table 1 presents a comprehensive feature comparison of the (most) related CP-ABE schemes. According to it, the construction we propose in this paper is the only one that achieves simultaneously robustness, access revocation, outsourced decryption, and adaptive security.
Feature comparaison of (most) related CP-ABE constructions. We use FS and BS to denote respectively the forward and backward secrecy properties
Feature comparaison of (most) related CP-ABE constructions. We use FS and BS to denote respectively the forward and backward secrecy properties
In this section, we give background information on bilinear maps and the security assumption we are considering. Then, we give a brief description of the trusted third party free secret sharing method proposed by Pedersen in [32].
Bilinear maps
Let Symmetric bilinearity: Non-degeneracy: The group operations in
The security of our construction holds as long as
We prove the security of the proposed construction under a non-interactive Generalized Diffie–Hellman Exponent assumption (GDHE) which has been proved to be a hard problem in [6]. That is, according to Definitions 1 and 2, as long as the challenge polynomial f that denotes the secret information we want to protect is independent of Let p be some large prime, r, s, t, and c be positive integers. Let Let (Independence [6]).
(GDHE assumption [6]).
Trusted third party free threshold secret sharing
In a secret sharing scheme, a secret is distributed among several participants organized in an access structure listing all groups that can access the secret. The objective is to provide information specific to each participant so that only a specific group of participants can reconstruct the secret. Several practical secret sharing schemes have been proposed [3,15,32,36]. In this work, we use the trusted third party free threshold secret sharing construction proposed in [32], which we briefly describe as following.
Consider a system involving a set
System and security models
In this section, we introduce the system model we are considering. Then, we define the scheme we are proposing, the considered threat model, and the security requirements we aim to ensure.

System model.
The system we consider to build our scheme is depicted in Fig. 1. It is composed of five entities: A decentralized certificate authority, multiple attribute authorities, data providers, data users, and a cloud server provider.
The decentralized certificate authority (DCA) is a consortium blockchain-based PKI management system e.g., [1,42] which is responsible of setting up of the system by choosing its parameters such as, the set of attributes as well as the bilinear environment to be used. It is also in charge of registering data users and attribute authorities. Finally, DCA is responsible of choosing the robustness level that should be satisfied, i.e., the number of attribute authorities that should be compromised to break the confidentiality of the shared data. We stress that the DCA is not involved in decryption key issuing and access revocation. Attribute authorities (AAs) are a set of entities that collaboratively control the access to the shared data by cooperatively issuing decryption keys to data users, and revocation key to the cloud server provider. Cloud storage provider (CSP) is responsible of providing data storage and computation capabilities such as outsourced decryption and ciphertext re-encryption. The data provider (DP) is the entity that aims to share its data. It encrypts his/her data using a chosen access policy that specifies who can get access to his/her data. The data user (DU) represents an entity that will access and use the shared data. A DU is labeled by a set of attributes. It is supposed to be able to download any encrypted (shared) data from the CSP. However, only DUs who are labeled with proper attributes can successfully decrypt the retrieved encrypted data.
Definition of our construction
Our construction consists of eight algorithms:
Threat model
In our scheme, as the DCA capabilities are supposed to be provided by a blockchain-based PKI management system, then we fairly assume that the DCA is a trusted single point of failure-free entity. Hence, DCA is supposed to issue correct signed certificates to the different registered entities involved in the system.
Attribute authorities involved in the system are considered as honest-but-curious entities. They are honest in the sense that they are supposed to correctly perform the different operations of our construction, but we suppose that some of them can be corrupted by an adversary who aims to learn as much information as possible about the data. Similarly, we assume that the CSP is also honest-but-curious as it will correctly follow the proposed protocol, yet may try to lean information about the shared data.
Data consumers are considered to be malicious entities that can collude with each other and/or with compromised attribute authorities.
Finally, we suppose that the CSP will not collude with data users to infer more information about the shared data. We believe that this last assumption is fairly reasonable since, in a free market environment, an open dishonest behavior will result in considerable damages for the involved entities.
Security requirements
Four security requirements are considered in our construction. Collusion resistance, robustness, as well as forward and backward secrecy.
Collusion resistance
Since we suppose that multiple malicious data users may collude to gain access to an encrypted data that none of them can access alone, we require our construction to be secure against such collusion attack as formalized by the following definition. Let λ be the security parameter, Setup: Query – Phase 1: Challenge: Query – Phase 2: Guess: (Collusion Resistance).
We define
Robustness
According to the threat model we are considering (Section 4.3), we suppose that a subset of attribute authorities can be compromised by an adversary. Hence, we require our construction to be robust. That is, any encrypted data item remains fully protected against unauthorized entities as far as no more than Let λ be the security parameter, Compromise: In this step, Guess: (
We define
Forward secrecy
Forward secrecy is a mandatory property for enabling secure revocation. In the context of attribute based encryption, forward secrecy requires that it should not be feasible for a data user to decrypt previous and subsequent ciphertexts, if a subset of his/her attributes required for decryption are revoked. This requirement is formalized using the following definition.

Outsourced pre-decryption.
Let λ be the security parameter, Query – Pre revocation: this phase is carried out according to the following two steps. Revocation: Query – Post revocation: Challenge: Guess:
We define
We want to emphasize that in the previous security game, the adversary
Backward secrecy property means that a new added data user should be unable to decrypt data items that are created prior to his/her/its introduction to the system. This property is formalized using the following definition. Let λ be the security parameter, Time slot incrementation – Once the query phase is finished, the challenger Query – Phase 2: Guess: (Backward Secrecy).
We define
Our proposed scheme
We now present the detailed construction. We emphasis that, since the DCA capabilities are provided by a consortium blockchain-based PKI management system, we use the same blockchain as a trusted shared storage to store the different public elements exchanged between the different parties that compose our system. Hence, the consortium blockchain is supposed to be accessible to all the entities involved in the system. In the sequel, we refer to the consortium blockchain as
System initialization
The initialization of the system is performed as described in the following.
GlobalSetup
Let
System initialization
The system is initialized using the following steps.
Select four random scalars
After receiving
For each attribute
For each attribute
It is worth motioning that
Data sharing
The data encryption operation The data provider starts by defining a monotone boolean formula involving a subset of attributes The data provider chooses the access policy to be enforced and transforms it into a Linear Secret Sharing Scheme (LSSS) access structure
User registration and key generation
When a user First, Once
Access revocation
Our construction aims to achieve robust fine-grained and on-demand access revocation. That is, to prevent a compromised AA from prohibiting authorized users from accessing the outsourced data by revoking them, our construction requires the collaboration of t out of the n (
Collaborative revocation request
The access revocation process is triggered by an attribute authority
Afterwards, each of the attribute authorities that participates to the previous collaborative revocation request will update locally the list of revoked user for each attribute as following:
Revocation enforcement
Once more than
Then, CSP generates a random scalar
Secret decryption key updating
Once an access revocation request is performed, each data user needs to request a fresh secret decryption key as described in Section 5.3.
Outsourced pre-decryption and user decryption
Our construction enables a data user to outsource most part of the decryption computation to CSP. The main objective of this feature is to allow a data user to shift expensive computations, i.e., pairing operations to CSP without disclosing any information about the encrypted data to CSP. Outsourced pre-decryption is performed according to the following steps.
Secret decryption key randomization
The data user u starts by randomizing its secret decryption key as follows. It picks a random scalar
Outsourced pre-decryption
After receiving (
It is important to note that backward secrecy is maintained by the CSP (Cloud Service Provider), which updates the shared ciphertext only between the timestep when the secret decryption key is generated and the current system timestep. Therefore, if the ciphertext is shared during a timestep before the secret decryption key is generated for the user, the updated ciphertext cannot be decrypted correctly by the user.
User decryption
Once the user retrieves the pre-decrypted symmetric key
Security results
This section presents the security results of our construction. First, in Theorem 1, we show that our construction provides a correct revocable fine-grained access control capabilities. Then, we prove the collusion resistance, the robustness, the forward and backward secrecy properties in Theorems 2, 3, 4, and 5 respectively.
Given a data user u to whom a set of attributes
The proof is by contradiction. Suppose, contrary to the statement of the theorem, that there exists a timestep π of the system on which the user u cannot recover the plaintext of As described in Section 5.1, CSP’s secret key is initially empty ( Let us now suppose that m access revocations are performed in the system, each revokes the set of attributes Let us denote by According to Section 5.3, at any timestep
Our construction is collusion resistant under the GDHE assumption.
We prove the collusion resistance property using the security game Let us denote by Afterwards, during the first phase of the query step, each secret decryption request query Hence, to prove the theorem we need to show that the advantage of
Our construction is
According to Definition 4, to prove the robustness of our construction, we need to show that the advantage of the adversary Similarly, we use
α is a root of non-zero polynomial of degree one Now let us focus on Equation (ii) and consider it as a polynomial in s, then we get
Now let us focus on Equation (ii.2). Since
Our construction is forward secure under the GDHE assumption.
According to Definition 5, to prove that our scheme ensures forward secrecy, we need to show that Similarly to previous proofs, let us denote by
Our construction is backward secure under the GDHE assumption.
According to Definition 6, to prove that our scheme ensures backward secrecy, we need to show that Similarly, we use In the step four of the security game, the challenger In step five of the considered security game, In order to establish the theorem, it is necessary to demonstrate that the advantage of To establish the theorem, we must demonstrate that it is impossible for any combination of elements from sets R, S, and T to exist with a non-negligible probability, where certain constants First, let us consider Equation (14) as a polynomial in μ. By regrouping the monomials according to their degree, we have:
(Correctness).
First, let us focus on Equation (i). If the latter holds, then this means that one of the following condition also holds:
Since α and
From equation (ii.1), since
Let us now focus on Equation (i) by considering it as a polynomial on a. By regrouping the monomials according to their degree, we have:
At this level, by considering Equation (i.1) as polynomial is s, we get
At this level, we showed that
which concludes the proof. □
In this section, we analyze the practicability of our construction regarding several properties. We evaluate the storage and communication overheads, as well as the computation cost of the different operations used by our construction. We also evaluate compare the sizes of the different cryptographic keys to be used by the entities involved in our construction. For a better understanding of the evaluation results, we conduct a comparative analysis between our construction and TMACS [23]. Both schemes are achieving robustness while providing ABE-based fine-grained access control. The notations we used in the complexity evaluation are described in Table 2.
Notations used in the conducted evaluation
Notations used in the conducted evaluation
In Table 3, we compare the storage complexity of our construction and TMACS on the different entities. Specifically, we quantify the storage complexity in terms of the size of elements (e.g., group elements, certificates, etc.) that are to be stored by each entity. Compared to TMACS, our construction requires less information to be stored by DCA and AA. In addition the size of an encrypted data item in our scheme is smaller than the one of TMACS. On the DU side, no more information needs to be stored compared to TMACS. When comes to CSP, our construction requires the CSP to store a revocation key of size linear to the number of performed revocation operations. While the latter can be large in some use cases, we stress that the CSP is supposed to have unlimited storage space. Note that the TMACS scheme does not require the CSP to store any revocation key as it does not enable access revocation.
Comparison of the storage complexity
Comparison of the storage complexity
The sign (-) is used to indicate that no storage is required.
In Table 4, we provide a comparison of the theoretical communication complexities incurred by the different processes involved in our construction and TMACS. Specifically, we quantify the amount of information (in terms of the sizes of used group elements) exchanged by each entity during the different processes.
Comparison of the communication complexity
Comparison of the communication complexity
The items in bold represents the smallest communication complexity of two compared schemes, the sign (-) is used to indicate that no communication is required by an entity, and we used (N/A) to indicate that the process is not supported by a scheme.
As illustrate in the table, our construction does not include any communication overhead compared to TMACS, except for (i) AA during the setup process and (ii) DU during the data decryption process. However, we stress that both (linear) overheads can be tolerated since the first occurs only once during the setup phase, while the second permits the DU to considerably reduce the amount of computations required for data decryption (Table 5) by using the outsourced pre-decryption. Besides, our construction slightly reduces the communication complexity for DCA and CSP during the setup and the data decryption processes respectively.
In this section, we give a comparative analysis of the computational complexity of our scheme and TMACS. Table 5 shows, for the two constructions, the computational complexities for the different entities of the system when performing the different processes. The processes complexities are expressed mainly in terms of the number of group exponentiations and pairings. We note here that we ignore computations related to certificate generation and signature as they are performed by most existing ABE schemes.
Comparison of the computation complexity
Comparison of the computation complexity
The items in bold represents the smallest communication complexity of two compared schemes, the sign (-) is used to indicate that no communication are required by an entity, and we used (N/A) to indicate that the process is not supported by a scheme.
The comparison shows that our construction does not include any computation overhead compared to TMACS for performing data encryption and decryption key generation processes. Thanks to the outsourcing pre-decryption, our construction drastically reduces the amount of computations required to be performed by DU for decrypting a data item. However, our construction requires linearly in the number of attributes more group exponentiations than TMACS to perform the setup process. Again, we stress that this latter computation overhead can be tolerated as it occurs only once during the setup phase.
Figure 2 gives an overview of the framework implementing our construction. To implement the capabilities of the different components of our ABE construction and to allow them to communicate, we used a java-based framework called Spring Boot [39] (Spring Boot Framework). Each component exposes a Rest API in charge of processing over components’ queries and send returning responses. To ensure the confidentiality of the exchanged information between the different components, communications are performed over HTTPS. Moreover, to authenticate the data exchanged between the different components, we use the open, industry standard RFC 7519 JSON Web Tokens [16].

Overview of the implementation framework.
The functionalities provided by our decentralized ABE (e.g., encryption, decryption, etc.) requires mathematical operations underlying pairing-based cryptosystems such as, bilinear pairings, cyclic groups elements exponentiation and multi-exponentiation, etc. In our implementation, these mathematical operations are provided by the jPBC library [8]. As storage infrastructure, we use MinIO [29], a High-Performance Object Storage compatible with Amazon S3 cloud storage service.
Experimental setup
The features of our construction are evaluated on a Linux server having 2ÕIntel(R) Xeon(R) CPU E5-2695 v3 @ 2.30 GHz, 2Õ14/14 cores; 28 threads. During the conducted evaluations, each entity is deployed in a virtual machine having 4 vCPUs,2
Our implementation is not multi-threaded, however, we stress that most operations (e.g., encryption, decryption, and revocation) are embarrassingly parallelizable.
In this section, we give the timing performance of four functions from our construction, namely: Setup function regarding the number of involved attribute authority; Encryption function regarding the number of attributes in the access policy; Decryption key generation time regarding the number of attributes associated to the data and the robustness level; and finally, decryption function regarding the number of attributes in the access policy (with and without ciphertext update).

System initialization time as a function of the number of involved attribute authorities.
Figure 3 illustrates the execution time of the system initialization function according to the number of involved attribute authorities. As described previously, this function is composed of two phases, the entity registration phase, which is shown in blue in the plot, and the public master key generation phase, shown in red. The x-axis represents the numbers of involved attribute authorities and the y-axis represents execution time in seconds, and we can clearly see that the time required for system initialization grows linearly according to the number of involved attribute authorities.

Time required for encryption as a function of the number of attributes in the access policy.
Figure 4 depicts the execution time of the encryption function according to the number of attributes in the access policy, this time the duration is represented in milliseconds on the x-axis and the y-axis represents the number of attributes of the access policy.
Figure 5 show the execution time of the decryption key generation according to two parameters, the first on is the number of attributes associated to the consumer data and the second one is the robustness level t (we remember that t is the minimum number of attribute authorities that must collaborate together to generate the secret decryption key). In this figure, we have used a colour codification to vary the parameter level of robustness t, and keep the same graduation for the parameter number of attributes, namely the execution time in milliseconds on the x-axis and number of attributes on the x-axis.

Secret decryption key generation time as the number of attributes associated to the data consumer and the robustness level t.

Decryption evaluation.
Figure 6 consists on the evaluation of the decryption function, it is composed of two graphs “a” and “b”. Graph a shows the execution time of the ciphertext updating according to the number of revoked attributes, and graph b represent the execution time of the decryption function according to the number of required attributes. In both graphs, the y-axis represents the execution time in milliseconds and the x-axis represents respectively the number of revoked attributes for “a” and then the number of required attributes for “b”.
Moreover, we assess the functionality of the outsourced decryption feature when executed by the aforementioned Multos Smartcard. The evaluation results are represented in the Table 6. The latter report the time required by the smart card to randomize the secret decryption key.
Outsourced decryption latency on constrained device
Finally, we evaluated the quantity of information exchanged between the various entities during the different operations of our scheme. The results are presented in Table 7. During the system setup phase, we measured the quantity of data exchanged between the attribute authorities as they collaboratively generated the master public key, as a function of the number n of involved AAs. For access revocation, we quantified the information exchanged between the AAs and the CSP. For encryption and decryption, we measured the quantity of data exchanged as a function of the number of attributes in the enforced access policy (denoted by l) and in secret decryption key (denoted by
Data exchanged between entities during various operations of the scheme
In this work, we propose the first CP-ABE fine-grained access control construction for outsourced data that enables the following features simultaneously. First, it ensures robustness for both decryption key issuing and access revocation while achieving both forward and backward secrecy. Second, it enables outsourced decryption to reduce the decryption overhead for data users that have limited computational resources. Third, it achieves adaptive security in standard models. In the future, it will be interesting to investigate whether we can extend the construction to ensure backward secrecy. In addition, we provide an overview of the framework implementing our ABE construction and conduct several experimentations to study the efficiency of our ABE construction.
