Fine-Grained and Traceable Key Delegation for Ciphertext-Policy Attribute-Based Encryption

Abstract

Permission delegation is an important research issue in access control. It allows a user to delegate some of his permissions to others to reduce his workload, or enables others to complete some tasks on his behalf when he is unavailable to do so. As an ideal solution for controlling read access on outsourced data objects on the cloud, Ciphertext-Policy Attribute-Based Encryption (CP-ABE) has attracted much attention. Some existing CP-ABE schemes handle the read permission delegation through the delegation of the user's private key to others. Still, these schemes lack the further consideration of granularity and traceability of the permission delegation. To this end, this article proposes a flexible and fine-grained CP-ABE key delegation approach that supports white-box traceability. In this approach, the key delegator first examines the relations between the data objects, read permission thereof that he intends to delegate, and the attributes associated with the access policies of these data objects. Then he chooses a minimal attribute set from his attributes according to the principle of least privilege. He constructs the delegation key with the minimal attribute set. Thus, we can achieve the shortest delegation key and minimize the time of key delegation under the premise of guaranteeing the delegator's access control requirement. The Key Generation Center (KGC) then embeds the delegatee's identity into the key to trace the route of the delegation key. Our approach prevents the delegatee from combining his existing key with the new delegation key to access unauthorized data objects. Theoretical analysis and test results show that our approach helps the KGC transfer some of its burdensome key generation tasks to regular users (delegators) to accommodate more users.

1. Introduction

Cloud storage technology is increasingly used in the storage, management, and sharing of data. More and more users and organizations are storing their data in the cloud, and are willing to share those data with others. As users lose direct control over data, security and privacy issues are of great concern. Sahai et al. first proposed the concept of Attribute-Based Encryption (ABE)[1]to handle the security of shared data. ABE enables the data owner to specify more flexible access control policies, and is considered one of the most prominent read access control mechanisms in cloud storage systems. ABE has two extensions: Key-Policy ABE (KP-ABE)[2] and ciphertext-policy ABE (CP-ABE)[3].In CP-ABE, the access structure is embedded in the ciphertext, and the user's key is described using attributes. After a data owner encrypts the data object, the corresponding ciphertext can be decrypted when attributes in a user's attribute set satisfy the access structure of the data object. Therefore, CP-ABE is more fit for controlling the read permission in cloud storage systems.

Permission delegation [4-18], by which users shift their permissions to others, is an important research topic in access control systems. Some or all permissions can be delegated to other users, thus allowing others to be granted these permissions to perform specific tasks on behalf of the authorized user. CP-ABE is an appropriate solution for making read access control on outsourced data objects on the cloud. It handles the read permission authorization of data objects through the authorization of the user's private key. Therefore, the delegation of permissions in CP-ABE is equivalent to the delegation of the private keys of the users. In other words, the CP-ABE scheme delegatesread permissionsto data objectsthrough key delegation.

Key delegation enables users to engage in resource sharing and collaboration to complete tasks, thereby improving work efficiency. For example, if a user (delegator) is unable to complete a task due to a business trip or heavy workload, he can delegate his private key to another user so that the other user can complete some tasks on the delegator’s behalf. The CPABE [3] has a key delegation mechanism, but it only introduces how to use a subset of a user's attribute set to construct a new key for delegation. There is no detailed explanation of how to choose the attribute set to build the key, or how to delegate the key and to whom. It also lacks further consideration of the granularity and traceability of key delegation.

Generally, traceable CP-ABE schemes [19-25] have private key traceable features. In the practical application of CP-ABE, it is difficult to trace the key owner when a malicious authorized user reveals his or her key; tracing the owner of the delegation key is also difficult. Therefore, it is reasonable to embed the key (original key or delegation key) owner’s identity into the key, and add its traceability to the CP-ABE key delegation mechanism [22-25].

Because the user's private key is associated with his attributes in CP-ABE, this study proposes a flexible and fine-grained key delegation approach for the CP-ABE system, and one that supports white-box traceability. In this approach, the delegator and the key generation center (KGC) construct the delegation key together. The user is responsible for selecting the attribute set that constructs the key; the KGC embeds the identity of the delegatee into the delegation key and calculates the corresponding key components. The key delegation results in the delegation of the read permissions to some data objects. Since the KGC participates in constructing a new key by embedding the user's identity into the key, it can supervise the key delegation process and trace the identity of the user who is suspected of leaking keys. In this scheme, a user analyzes the attributes related to the access structures of the data objects to be delegated. According to the principle of least privilege, the user selects the minimal attribute set for construction of the delegation key and delegates the new key to other users. The advantage of this approach is that the user can act as an authorized institution; hence, the entire system can accommodate more users, which helps reduce the workload of KGC. The KGC only generates keys for senior users, whereas the data owner and KGC jointly construct the delegation key. Because the KGC does not need to generate the delegation key from scratch, its workload can be significantly reduced. Our key delegation includes the feature of anticollusion, which prevents a user from combining his existing keys (original key or delegation keys) to access unauthorized data. It also prevents a user from colluding his keys (original key or delegation keys) with those of other users to access unauthorized data.

The remainder of this article is organized as follows. Section 2 describes related works. Section 3 describes background knowledge related to key delegation, and the components of the key delegation model for CP-ABE. In Section 4, we discuss how to select the minimal attribute set of the key. We introduce the key delegation scheme in Section 5. Section 6 compares different approaches and uses a test to verify the feasibility of the key delegation scheme. Section 7 offers our conclusions, and outlines future research directions.

2. Related work

Many studies on permission delegation in the area of access control research have been conducted [4-18]. [4-14] proposed permission delegation by delegating roles. A role-based delegation model was proposed in [4], which supports hierarchical roles and multistep delegation. [5-8] considered permission delegation of Role-Based Access Control (RBAC) from different perspectives. [9-13] extended RBAC and proposed flexible authorization delegation approaches via role delegation. In [14], a delegation model was proposed to control delegation depth and role scope by establishing a delegation tree. Meanwhile, [15] focused on the permission delegation of identity-based access control, while [16,17] investigated permission delegation based on attribute-based access control. In the new ID-based access control model [15], authority delegation was realized by creating a delegation token on the delegatee's identity. The relation between delegation and revocation was discussed in detail in the attribute delegation model [16,17]. [18] presented a non-monotonic multistep permission delegation protocol about workflow and introduced the general characteristics of authorization delegation. Our work is inspired by the permission delegation in access control. We proposed a key delegation approach of CP-ABE in which the read permission of data objects can be delegated through key delegation.

The CP-ABE scheme [3] was proposed by Bethencourt et al. As a seemingly ideal solution for controlling read access on the outsourced data, it has attracted much attention. In CP-ABE, the access structure is embedded in the ciphertext, and the user's key is described using attributes. A ciphertext can be decrypted when the attributes in the user's key satisfy the access structure of the ciphertext. In addition, a key delegation mechanism is supported in this scheme. However, although a set of attributes is chosen to construct the delegation key, the granularity of the key delegation is not considered. In our proposed method, our main goal is to delegate read permission of data in CP-ABE access control. We establish a fine-grained key delegation relying on attribute selection to meet the specific permission delegation needs of the delegator. A user analyzes the attributes related to the access structures of given ciphertext; then, adhering to the principle of least privilege, the user selects a minimal set of attributes that satisfy the access structures of these data objects to construct a new key for delegation.

[19-25] proposed CP-ABE schemes with the feature of traceability. However, these existing traceable CP-ABE schemes have less expressive access control policies; furthermore, the works in [19-25] are limited to “AND” gates. Ning et al. [20,21] proposed a white-box traceable CP-ABE scheme based on flexible properties. The scheme in [22] has white-box traceability and supports the Linear Secret Sharing Scheme (LSSS) access structure. It is more intuitive than the attribute access structure used in this article. [23-25] proposed CP-ABE schemes to prevent users from abusing delegated keys, but [24,25] are limited to supporting “AND” gates. Our paper supports arbitrary thresholds and achieves similar traceability with [20,21] via the same Shamir threshold scheme. The cost of traceable storage does not grow linearly with the growth of the number of users. Moreover, [19-25] do not support key delegation, and users must apply for their unique keys directly from the KGC. Key traceability has more practical applications [26-31] in specific environments.

Guan Z et al. proposed a traceable CP-ABE system and enforced key delegation with traceability [32]. However, fine-grained key delegation is not supported in their work. Our CPABE key delegation scheme has fine granularity. The basic unit of delegation in this model is ciphertext. The delegatee can only decrypt the delegator's part of ciphertexts with the corresponding delegation key. The delegator aims to control which ciphertexts, within his decryption ability, are to be delegated while under some restrictions. Controlling the delegatee's decryption ability through the delegation key provides flexibility and fine granularity to access control.

[33] proposed an attribute-based proxy re-encryption scheme. It considered re-encrypting a ciphertext with different access policies and assigning the new keys associated with these new ciphertexts to different users. However, the solution in [33] does not support key traceability. Compared to [33], in our work, the KGC embeds the user identity into the key component so that the KGC can trace the identity of the user who possibly leaked the key. In addition, our key delegation scheme is monotonic. The decryption ability of the delegatee with the delegation key will not exceed that of the delegator. We note here that monotonicity of decryption ability is not guaranteed in [33].

[34-35] proposed a CP-ABE scheme with anti-collusion black-box traceability. Our work adds white-box traceability to the CP-ABE key delegation and supports any monotonic access structure. The KGC and the delegator jointly construct the delegation key. Therefore, in our solution, the KGC can not only trace the route of the delegation key but also monitor the key delegation process.

3. Background

3.1 Preliminaries

Access structure: Let set \(\left\{P_{1}, P_{2}, \ldots, P_{n}\right\}\) represent a set of entities. For ∀B C, , if B∈ A and B C ⊆ , there is C ∈ A ; then, the set \(\boldsymbol{A} \subseteq 2^{\left\{P_{1}, P_{2}, \ldots, P_{n}\right\}}\) is monotonic. \(\boldsymbol{A} \subseteq 2^{\left\{R, P_{2}, \ldots, P_{n}\right\}} \backslash\{\varnothing\}\), a non-empty monotonic subset of \(\left\{P_{1}, P_{2}, \ldots, P_{n}\right\}\), is called a monotonic access structure.

In this article, entities represent attributes, and thus our access structure is the set of authorized attribute sets. There are two common access structures in CP-ABE: the tree access structure, and LSSS. We choose a tree access structure [3]. We use T to denote the access tree. Root nodes and internal nodes support logical operations such as OR, AND, and k of n (n>k).

Definition 1( Minimal attribute set): Given a tree access structure T of ciphertext, if an attribute set A satisfies the following conditions, then A is called the minimal attribute set of the tree access structure T :

(1) A ≠ ∅ ;

(2) A satisfies T ;

(3) ∀ ≠∅ A' and A' ⊂ A , T is not satisfied by A' . In other words, A is the smallest set of attributes that meets the access structure T .

We see that there can be multiple minimal attribute sets satisfying a tree access structure T .

Bilinear pair: Let G and G_T be the prime order (p -order) multiplicative cyclic groups with generator g . The mapping e is a bilinear pair if it has the following characteristics:

(1) \(\forall u, v \in G \text { and } \forall x, y \in Z_{p}, e\left(u^{x}, v^{y}\right)=e(u, v)^{x y} ;\)

(2) Non-degeneration: e(g,g) 1 ≠ ;

(3) Computability: It is effective to calculate bilinear maps e:G×G → G_T.

Decisional Bilinear Diffie–Hellman (DBDH) assumption: Given elements \(\left(g, g^{a}, g^{b}, g^{c}, z\right)\), where \(\forall a, b, c \in Z_{p}\) and unknown,\(z \in G_{T}, g\) is a generator of the cyclic group, determine whether \(z=e(g, g)^{a b c}\).

Definition 2(Key delegation): A user (delegator) builds a new key and provides it to other users (delegatees); we call this process key delegation. The new key is either created by the delegator's original key or is a key he received from others.

Key delegation allows the delegatee to complete certain tasks on behalf of the delegator with the delegation key. Generally, a delegator performs key delegation when he is unavailable to do these tasks, or if he needs to transfer his tasks to a colleague.

3.2 CP-ABE Key Delegation Scheme and Security Model

3.2.1 CP-ABE Key Delegation Scheme

The traditional CP-ABE scheme [3] has five basic algorithms: Setup , Encrypt , KeyGen , Decrypt , and Delegate . In a basic CP-ABE key delegation scenario, a delegator simply selects certain attributes for constructing a delegation key. In some situations, the route of a delegation key needs to be traced for security reasons. In this proposed method, we mainly consider a flexible, fine-grained CP-ABE scheme with traceability. First, we list the algorithms in this scheme in Table 1.

Table 1. Algorithms in CP-ABE key delegation scheme

3.2.2 Security Model and Tracing Model

Security Model: We define a security model through interactive security games between an adversary and challenger. The game is an indistinguishability chosen plaintext attack (INDCPA) game under the selective access policy. CPA are powerful types of attack, and if an algorithm can resist this type of attack, it can also resist other types of attack.

Our security model is similar to that in [25], but instead of only supporting the “AND” gate access structure, this model supports an arbitrary threshold.

Definition 3 We call the traceable key delegation scheme selectively secure and the INDCPA secure if in the security game the adversary has at most a negligible advantage in polynomial time.

Tracing Model: The key tracing model of the CP-ABE key delegation scheme that supports dynamic attribute space traceability is similar to the tracing model of [32]. However, in this article, the threshold scheme is used to record user identity.

Definition 4 We call the solution in this article traceable if the advantage obtained by the adversary in the traceability game in any polynomial time is negligible relative to the security parameter λ .

3.3 CP-ABE Key Delegation Model

We note that in CP-ABE, the delegation of the read permission of a data object is achieved through key delegation. We consider the key delegation of the CP-ABE based on permission delegation and provide a formal definition to the key delegation model. We design the key delegation model according to the requirements that follow.

(1) The delegation is monotonic key delegation. The decryption ability of the delegatee with his delegation key, which originated from a key of the delegator, does not exceed that of the delegator with the very same key.

(2) The model supports multistage key delegation. If the delegatee wants to further delegate the key to other users, he can act as a delegator and initiate key delegation with his delegation key.

(3) The model supports flexible and fine-grained delegation. The basic unit of delegation is essentially the ciphertext. The delegatee can only decrypt specific ciphertexts with the delegation key. The delegator aims to control which ciphertexts, within his decryption ability, are to be decrypted by the delegatee, under the premise that some other ciphertexts are not to be decrypted.

(4) The model prevents the delegatee from combining the delegation keys with any keys he owns to access additional data objects.

In addition, we have the following assumptions:

(1) To ensure security, a user cannot directly deliver his key to others as a delegation key without going through the delegation key generation process.

(2) The delegator is unaware of the original decryption ability of the delegatee. The delegator only cares about the decryption ability of the delegatee with the delegation key.

We first establish the key delegation model of CP-ABE as follows:

(1) U , A, K , and CT represent users, attribute sets, keys, and ciphertext sets, respectively;

(2) \(U A \subseteq U \times 2^{A}\) : a mapping user-to-attribute set assignment relation;

(3) \(U A K \subseteq U A \times K\) : a mapping of users (associated with attribute sets) to private keys;

(4)\(K H \subseteq K \times K\) is a partial order on K named the key hierarchy relation and is recorded as ≥ . For two given keys \(S K, S K^{\prime} \in K, S K\) is constructed by attribute set S , and SK ' constructed by attribute set \(S^{\prime} ; S K \geq S K^{\prime}\) only if \(S^{\prime} \subseteq S\) for SS \(S, S' \subseteq A\), and SK ' is generated from SK . Ciphertexts that can be decrypted by SK ' can also be decrypted by SK ;

(5) \(D K=\left\{\left\langle\left(u_{0}, S, S K\right),\left(u_{1}, S^{\prime}, S K^{\prime}\right)\right\rangle \mid S K \geq S K^{\prime},\left(u_{0}, S, S K\right),\left(u_{1}, S^{\prime}, S K^{\prime}\right) \in U A K\right\}\) represents a mapping key-to-key delegation relation.

Fig. 1 illustrates the components of the CP-ABE key delegation model. Suppose a user (delegator) u₀ possesses attributes S , that is, \(\left(u_{0}, S\right) \in U A\) . The KGC generates an original key SK for the delegator 0 u according to his attribute set S ; then, there is a key assignment relationship \(\left(u_{0}, S, S K\right) \in U A K . u_{0}\) can decrypt all the ciphertexts in \(\boldsymbol{C T}=\left\{C T_{1}, C T_{2}, \ldots, C T_{n}\right\}\)with SK since his attributes match access structures of ciphertexts in CT . u₀ selects some attributes \(S^{\prime}\left(S^{\prime} \subseteq S\right)\) to construct the key SK ' according to the access structures of the ciphertext in \(C T^{\prime}\left(C T^{\prime} \subseteq C T\right)\), and delegates SK ' to the user (delegatee) u₁ . Then, we have the key assignment relation \(\left(u_{1}, S^{\prime}, S K^{\prime}\right) \in U A K\).

Fig. 1. Key delegation model for CP-ABE

Consequently, the key delegation relation \(\left\langle\left(u_{0}, S, S K\right),\left(u_{1}, S^{\prime}, S K^{\prime}\right)\right\rangle \in D K\) is established. Since S is associated with SK and S' is associated with SK' and \(S^{\prime} \subseteq S\), there is a key hierarchy relation \(\left(S K, S K^{\prime}\right) \in K H\) between SK and SK'. The ciphertext in \(C T^{\prime}\left(C T^{\prime} \subseteq C T\right)\) can be decrypted with SK ' .

This key delegation model supports multistage delegation. User 1 u receiving delegation key SK' can still be a delegator to forward the delegation key SK' to other users with certain alternations. When a user acts as a delegator, he can delegate a key to multiple users.

The key delegation path starts from a primary user, and after multiple delegation steps, it can form a delegation tree as in Fig. 2. Multiple delegation paths are reflected in the delegation tree, such as

\(\begin{aligned} \left(u_{0}, S, S K\right) & \rightarrow\left(u_{1}, S^{\prime}, S K^{\prime}\right) \rightarrow\left(u_{3}, S^{(3)}, S K^{(3)}\right) \rightarrow \ldots \\ \left(u_{0}, S, S K\right) & \rightarrow\left(u_{1}, S^{\prime}, S K^{\prime}\right) \rightarrow\left(u_{4}, S^{(4)}, S K^{(4)}\right) \rightarrow \ldots \\ \left(u_{0}, S, S K\right) & \rightarrow\left(u_{2}, S^{\prime \prime}, S K^{\prime \prime}\right) \rightarrow\left(u_{5}, S^{(5)}, S K^{(5)}\right) \rightarrow \ldots \\ \left(u_{0}, S, S K\right) & \rightarrow\left(u_{2}, S^{\prime \prime}, S K^{\prime \prime}\right) \rightarrow\left(u_{6}, S^{(6)}, S K^{(6)}\right) \rightarrow \ldots \end{aligned}\)

Fig. 2. Example of key delegation paths

In the key delegation tree, the attribute set on each node is a subset of the attribute set of its parent node, e.g., \(S^{\prime} \subseteq S, S^{\prime \prime} \subseteq S, \text { and } S^{(3)} \subseteq S^{\prime}\). There are also key hierarchy relations between the key of a parent node and the key of its child nodes, e.g., \(S K \geq S K^{\prime}, S K^{\prime} \geq S K^{(3)}\), and \(S K^{\prime} \geq S K^{(4)}\) . The ciphertexts with the key on the child node can also be decrypted by the key on its parent node. The delegation tree also reflectsthe fact that the key delegation supports monotonic multistage delegation. That is to say, the decryption ability of the delegatee with the delegation key SK' does not exceed the decryption ability of the delegator with the original key SK .

4. Attribute extraction for key delegation

In a CP-ABE key delegation scenario, a key delegator wants a delegatee to decrypt certain ciphertexts using the delegation key. In this section, we present how the delegator selects the minimal set of attributes that satisfies ciphertext access structures in a given ciphertext set by following the principle of least privilege.

4.1 Minimal Attribute Set Family of a Ciphertext

We first consider minimal attribute sets for a ciphertext. Here, we design an algorithm to generate a minimal attribute set family that meets the tree access structure of a ciphertext. The algorithm is shown in Table 2.

Table 2. Algorithm for selecting the minimal attribute set family

Table 2 shows the algorithm for calculating the minimal attribute set family according to the access structure. In this algorithm, lines 2–8 handle the root node; different nodes receive a different minimal attribute set family. Lines 9–27 traverse the internal nodes in the set family. If the node is "AND", lines 11–13 will be executed. If the node is "OR", lines 14–19 will be executed. If the node is "k of n", lines 20–25 will be executed. All of the nodes are traversed until all of the sets are only composed of attributes, and then the minimal attribute set family will be constructed.

We further illustrate this algorithm with the example in Fig. 3.

Fig. 3. Example of tree access structures

The algorithm calculates the minimal attribute set family \(S=\left\{\left\{a_{1}, a_{2}, a_{4}\right\},\left\{a_{1}, a_{2}, a_{5}\right\}\right., \)\(\left.\left\{a_{2}, a_{3}, a_{4}\right\},\left\{a_{2}, a_{3}, a_{5}\right\},\left\{a_{1}, a_{3}, a_{4}\right\},\left\{a_{1}, a_{3}, a_{5}\right\}\right\}\)for the access structure shown in Fig. 3.

4.2 Attribute selection for delegation key establishment

Based on minimal attribute sets of a ciphertext, we now discuss how to determine a set of attributes that is most suitable for the delegation key establishment.

Suppose delegator Alice’s private key SK is constructed with S , and S satisfies access structures of all of the ciphertexts in \(\boldsymbol{C T}=\left\{C T_{1}, C T_{2}, \ldots, C T_{n}\right\}\) . That is, Alice can decrypt all of the ciphertexts in CT with SK .

Now Alice wants delegatee Bob to decrypt ciphertexts in \(\boldsymbol{C T}^{\prime}=\left\{C T_{1}, C T_{2}, \ldots, C T_{k}\right\}\) by using the delegation key to complete some job tasks on her behalf. This is Alice’s primary intention. However, Alice may also have additional restrictions on the delegation key. For example, due to a security concern, Alice may not want Bob to decrypt any ciphertext in CT'' \(C T^{\prime \prime} \subseteq C T \backslash C T^{\prime}\) , or she may follow the least privilege principle. That is, a few of the remaining ciphertexts in CT_r = CT/CT'  can be decrypted as possible by the decryption key. Therefore, according to her specific access control requirement, Alice tries to construct a key SK' for delegation.

Since CT' is Alice’s primary concern, she needs to determine a set of attributes that satisfies all access structures of ciphertexts in CT'. Alice connects the access structures of all of the ciphertexts in CT' with an "AND" gate to obtain a new access tree T'. We denote the access structure corresponding to each ciphertext , \(C T_{i} \in \boldsymbol{C} \boldsymbol{T}^{\prime}, i=1,2, \ldots, k \text { as } T_{i}, i=1,2, \ldots, k\) . The new access tree T' obtained is shown in Fig. 4.

Fig. 4. New access structure T'

Alice calculates the minimal attribute sets for T' using the algorithm in Table 2. We denote minimal attribute sets as \(\mathbf{A}_{1}^{\prime}, \mathbf{A}_{2}^{\prime}, \ldots, \mathbf{A}_{n_{k}}^{\prime} .\) From the construction of T' , we can see that each , \(\mathbf{A}_{j}^{\prime}, j \in\left\{1,2, \ldots, n_{k}\right\}\) meets the access structures of all of the ciphertexts in CT' . Here, we discuss different cases, taking into account Alice’s additional concerns.

Case 1: Decryption of all of the ciphertexts in CT' must be guaranteed. Bob must have the privilege to decrypt all of the ciphertexts in CT' . Alice does not care if Bob can decrypt the remaining ciphertexts in CT . Alice chooses the smallest set from \(\mathbf{A}_{1}^{\prime}, \mathbf{A}_{2}^{\prime}, \ldots, \mathbf{A}_{n_{k}}^{\prime}\) , and assigns it to S '. She uses S ' to construct a new key.

The key constructed by S ' ensures that Bob can decrypt all of the ciphertexts in CT' . Because Alice selects the smallest set from \(\mathbf{A}_{1}^{\prime}, \mathbf{A}_{2}^{\prime}, \ldots, \mathbf{A}_{n_{k}}^{\prime}\) n to assign to S ', she achieves the smallest size delegation key.

Case 2: Decryption of all of the ciphertexts in CT' must be guaranteed; the number of ciphertexts from the remaining set \(C T_{r}=C T \backslash C T^{\prime}\) can be decrypted as little as possible.

On the basis of Case 1, Alice further checks which , \(\mathbf{A}_{j}^{\prime}, j \in\left\{1,2, \ldots, n_{k}\right\}\) is most suitable for key construction. For each , \(\mathbf{A}_{j}^{\prime}, j \in\left\{1,2, \ldots, n_{k}\right\}\), she examines ciphertexts in CT_r access structures thereof that can be satisfied by A \(l_{j}, j \in\left\{1,2, \ldots, n_{k}\right\}\) be the number of ciphertextsin CT_r , and accesss tructures there of can be met by A_j' . Alice sets S' = A_*' , where \(l_{*}=\min \left(l_{1}, l_{2}, \ldots, l_{n_{k}}\right) . \text { If } \exists l_{j}=l_{*},\left|\mathbf{A}_{j}^{\prime}\right| \neq\left|\mathbf{A}_{*}^{\prime}\right|\) , then Alice chooses a smaller set from \(\mathbf{A}_{*}{ }^{\prime}\) and \(\mathbf{A}_{j}{ }^{\prime}\) , and assigns it to S'. Alice then uses S' to construct a new key.

Using S' to construct a key can not only guarantee that Bob is able to decrypt all of the ciphertexts in CT' , but that he can only decrypt the least amount of ciphertexts in CT_r . Alice also obtains the smallest size delegation key.

Case 3: Decryption of all ciphertexts in CT' must be guaranteed; must not decrypt any ciphertext in CT'' , CT'' ⊆ CT_r.

On the basis of Case 1, Alice further checks if there exists , \(\mathbf{A}_{j}^{}{\prime}, j \in\left\{1,2, \ldots, n_{k}\right\}\) that is suitable for key construction. For each , {\(\mathbf{A}_{j}^{}{\prime}, j \in\left\{1,2, \ldots, n_{k}\right\}\), she examines ciphertexts in CT'' access structures thereof that can be satisfied by \(\mathbf{A}_{j}{ }^{\prime}\) . Let , \(l_{j}, j \in\left\{1,2, \ldots, n_{k}\right\}\) be the number of ciphertexts in CT'' , and access structures thereof can be met by \(\mathbf{A}_{j}{ }^{\prime}\). Alice sets \(S^{\prime}=\mathbf{A}_{*}^{\prime}\) , where \(l_{*}=0 . \text { If } \exists l_{j}=l_{*}=0,\left|\mathbf{A}_{j}^{\prime}\right| \neq\left|\mathbf{A}_{*}^{\prime}\right|\), then Alice chooses a smaller set from \(\mathbf{A}_{*}{ }^{\prime}\) and \(\mathbf{A}_{j}{ }^{\prime}\), and assigns it to S' . Alice uses S' to construct a new key. If \(l_{*}=\min \left(l_{1}, l_{2}, \ldots, l_{n_{k}}\right) \neq 0\), then key delegation cannot be performed.

In this way, the key constructed with S', if possible, can not only guarantee that Bob is able to decrypt all of the ciphertexts in CT' but also that he cannot decrypt the ciphertexts in CT'' . In addition, Alice obtains the smallest size delegation key.

As an example, assume that Alice can decrypt ciphertexts in 1234 \(\boldsymbol{C \boldsymbol { T }}=\left\{C T_{1}, C T_{2}, C T_{3}, C T_{4}\right\}\) with her private key. Access structures of ciphertexts \(C T_{1}, C T_{2}, C T_{3}\), and \(C T_{4}\) are as follows:

\(\begin{gathered} T_{1}=a_{1} A N D\left(a_{2} O R a_{3}\right), \\ T_{2}=\left(a_{4} A N D a_{5}\right) \text { OR } a_{6}, \\ T_{3}=a_{1} A N D\left(a_{3} O R a_{5}\right), \\ T_{4}=a_{4} A N D a_{5} . \end{gathered}\)

As her primary concern, Alice wants Bob to decrypt ciphertexts in \(\boldsymbol{C \boldsymbol { T }}^{\prime}=\left\{C T_{1}, C T_{2}\right\}\) through key delegation.

Alice uses the "AND" gate to connect T₁ and T₂ to get T' ; then, she inputs T' , and executes the algorithm in Table 2 to find the minimal attribute sets. The minimal attribute sets are \(\mathbf{A}_{1}{ }^{\prime}=\left\{a_{1}, a_{2}, a_{4}, a_{5}\right\}, \mathbf{A}_{2}{ }^{\prime}=\left\{a_{1}, a_{3}, a_{4}, a_{5}\right\}, \mathbf{A}_{3}{ }^{\prime}=\left\{a_{1}, a_{2}, a_{6}\right\}, \text { and } \mathbf{A}_{4}{ }^{\prime}=\left\{a_{1}, a_{3}, a_{6}\right\} .\)

Case 1. Since \(\left|\mathbf{A}_{1}{ }^{\prime}\right|=\left|\mathbf{A}_{2}{ }^{\prime}\right|>\left|\mathbf{A}_{3}{ }^{\prime}\right|=\left|\mathbf{A}_{4}{ }^{\prime}\right|\), Alice chooses \(\mathbf{A}_{3}^{\prime} \text { or } \mathbf{A}_{4}^{\prime}\), assigns it to S' , and uses S' to construct the key. The delegation key ensures that Bob is able to decrypt ciphertexts in CT' .

Case 2. According to the minimal attribute sets, Alice uses these four attribute sets to match access structures of CT₃ and CT₄ , and obtains \(l_{1}=2, l_{2}=2, l_{3}=0, \text { and } l_{4}=1\). Then, Alice obtains \(\text { Alice obtains } l_{*}=\min \left(l_{1}, l_{2}, l_{3}, l_{4}\right)=l_{3}=0 . \mathbf{A}_{3}{ }^{\prime}\) meets the requirements of Case 2. Then, we set \(S^{\prime}=\mathbf{A}_{3}{ }^{\prime} \text {. Alice }\) uses S' to construct the key.

Case 3. Alice has an additional requirement: she does not want Bob to decrypt 3 4 \(\boldsymbol{C} \boldsymbol{T}^{\prime \prime}=\left\{C T_{3}, C T_{4}\right\}\). According to Case \(2, \quad l_{1}=2 \quad, \quad l_{2}=2, \quad l_{3}=0, \quad l_{4}=1,\)\(l_{5}=\min \left(l_{1}, l_{2}, l_{3}, l_{4}\right)=l_{3}=0, \text { and }\left|\mathbf{A}_{1}{ }^{\prime}\right|=\left|\mathbf{A}_{2}{ }^{\prime}\right|>\left|\mathbf{A}_{3}{ }^{\prime}\right|=\left|\mathbf{A}_{4}{ }^{\prime}\right|\). Therefore, \(\mathbf{A}_{3}^{}{\prime}\)meets the requirements of Case 3. Finally, Alice chooses \(\mathbf{A}_{3}^{}{\prime}\), and assigns it to S ' to construct the key.

5. CP-ABE Key delegation scheme

5.1 Scheme Construction

In this section, we describe the fine-grained, traceable CP-ABE key delegation scheme. The KGC and the delegator construct the delegation key. We go through a key delegation process between two users who play the roles of the delegator and the delegatee, respectively. The framework of our scheme, including the key delegation process, is shown in Fig. 5.

Fig. 5. Framework of our scheme

Fig. 5 depicts the proposed scheme, which consists of six algorithms. The KGC performs Setup to generate PK and MK for the whole system. Then, according to the attribute set S and user id of the user (delegator), KeyGen generates key SK for the delegator; meanwhile, the data owner executes Encrypt to encrypt data objects and shares the ciphertexts on the cloud server. The delegatee sends a request with his identity request \(\| i d^{\prime}\) for the delegated key. The delegator and KGC jointly execute Delegate . The KGC receives request \(\left\|S^{\prime}\right\| i d^{\prime} \| D^{\prime}\) from the delegator, embeds the identity of the delegatee into the delegation key, calculates the corresponding key component, and returns it to the delegator. The delegator uses the selected minimal attribute set and \(D^{*} \| D^{\prime \prime} \| r^{\prime}\) provided by the KGC to create the delegation key SK ' , and sends it to the delegatee. This delegation allows the delegatee to use Decrypt to decrypt the ciphertexts in the CT' with the delegated key SK ' . The delegator decrypts ciphertexts in CT with his original key SK . If a malicious user leaks the key, the KGC executes Trace to trace the identity of the user corresponding to the leaked key. The delegator examines the attributes related to the access structures of the ciphertexts, and selects a minimal attribute set using the method presented in Section 4.2. The details of the delegation are as follows.

Setup : The algorithm Setup(λ) → (PK, MK) is executed by the KGC. First, it inputs security parameters λ to algorithm \(\left(p, g, G, G_{T}, e\right) \leftarrow g(\lambda)\) to generate groups, where G and G_T are the p -order groups with a generator g , and e: G × G → G_T is the bilinear map. We use a hash function H:{0,1}^* → G and model it as a random oracle. The KGC randomly selects α, β ∈Z_p and calculates e(g,g)^α . We use a symmetric key encryption algorithm. Let two different symmetric keys be k₁ and k₂ . The public key is \(P K=\left(G, g, g^{\beta}, e(g, g)^{\alpha}\right)\) , and the master key is \(M K=\left(g^{\alpha}, \beta, k_{1}, k_{2}\right)\) . The KGC uses a t −1 degree polynomial v = f(µ) to initialize the Shamir (t,n) threshold scheme. When the key generation algorithm is executed, the KGC processes the user identity information and achieves points {(µ_i, f(µ_i))} on the polynomial. How to achieve the points will be described in more detail in the key generation algorithm.

Encrypt : The data owner executes the encryption algorithm Encrypt(PK, T, m) → CT. He inputs the system public key PK , a data object m ∈ G_T , and an access tree T . The algorithm first chooses a polynomial q_x for each node x in the tree T . The algorithm randomly selects s ∈ Z_p starting with the root node R and makes q_R(0) = s . Y represents the set of leaf nodes for ∀y ∈ Y , and att(y) represents the attribute of node y . The algorithm outputs the following ciphertext:

\(\begin{aligned} C T=(T, \tilde{C}=& m e(g, g)^{\alpha s}, C_{0}=g^{s}, C_{0}{ }^{\prime}=g^{\beta s}, \\ &\left.\forall y \in Y: C_{y}=g^{q_{y}(0)}, C_{y}{ }^{\prime}=H(\operatorname{att}(y))^{q_{y}(0)}\right) . \end{aligned}\)       (1)

KeyGen : The KGC executes KeyGen(PK ,MK ,id ,S) → SK. It inputs PK , MK , an attribute set S , and the user's identity id . The KGC then calculates

\(\mu=E n c_{k_{1}}(i d), v=f(\mu), c=E n c_{k_{2}}(\mu \| v) .\)       (2)

The distribution of µ is indistinguishable from a random number and f is a polynomial of a linear transformation. Therefore, the distributions of ν and c are no different from random numbers. The KGC selects a random number r ∈ Z_p for the user, and for ∀a_j ∈ S it randomly selects r_j ∈ Z_p . The KGC then calculates

\(D=g^{(\alpha+r)(\beta+c)}, D_{j}=g^{r} \cdot H\left(a_{j}\right)^{r_{j}}, D_{j}^{\prime}=g^{r_{j}}\).       (3)

The key output of the algorithm is

\(S K=\left(D=g^{\frac{\alpha+r}{\beta+c}}, D^{\prime}=c, \forall a_{j} \in S: D_{j}=g^{r} \cdot H\left(a_{j}\right)^{r_{j}}, D_{j}^{\prime}=g^{r_{j}}\right)\).       (4)

From the perspective of the key delegation model, we have now the assignment relations about the delegator, such as

\(\left(u_{0}, S\right) \in U A,\left(u_{0}, S, S K\right) \in U A K\).       (5)

Delegate : The algorithm Delegate(SK, S', id') → SK' is jointly completed by the KGC and the delegator. A user (delegatee) u₁ sends a request with his identity request ||id' to the delegator u₀ . After u₀ receives it, he tries to send the delegatee a key that can only decrypt the ciphertexts in the ciphertext set CT'(CT'⊆CT) . Therefore, u₀ examines the access structures of ciphertexts in CT' , finds the minimal attribute set that satisfies access structures of ciphertexts in CT' , and records it as S'(S'⊆S) (further details for determining the minimal attribute set are provided in Section 4.2). u₀ sends request || S'|| id'|| D' to the KGC. Based on the delegation request, the KGC calculates

\(\mu^{\prime}=\operatorname{Enc}_{k_{1}}\left(i d^{\prime}\right), v^{\prime}=f\left(\mu^{\prime}\right), c^{\prime}=E n c_{k_{2}}\left(\mu^{\prime} \| v^{\prime}\right) .\)       (6)

The KGC saves point ( µ', v') and selects a random number r' for u₁ . The KGC sends \(D^{*}=g^{(\alpha+r+r) /(\beta+c)}\left\|D^{\prime}\right\| D^{\prime \prime}=c^{\prime} \| r^{\prime} \text { to } u_{0} . u_{0}\) selects a random number r_k' for ∀a_k ∈ S'. The form of the delegation key is as follows:

\(\begin{aligned} S K^{\prime}=\left(D^{*}=\right.& g^{\frac{\alpha+r+r^{\prime}}{\beta+c^{\prime}}}, D^{\prime \prime}=c^{\prime}, \\ &\left.\forall a_{k} \in S^{\prime}: D_{k}^{*}=D_{k} \cdot g^{r^{\prime}} \cdot H\left(a_{k}\right)^{r^{\prime}}, D_{k}^{\prime \prime}=D_{k}^{\prime} g^{r^{\prime}}\right) \end{aligned}\)       (7)

Finally, the assignment relation (u₁, S', SK')∈UAK is established. The key delegation relation can be expressed as <( u₀, S, SK),( u₁, S'', SK'')>∈ DK .

If u₁ wants to further delegate the key SK'' to another user u₂ to allow him to decrypt ciphertexts in CT^*(CT^*⊆CT'), u₁ acts as a delegator. The KGC helps u₁ to construct the key. Consequently, the delegation relation<( u₁, S', SK'),( u₂, S'', SK'')>∈ DK will be established. A delegation path from u₀ to u₂ will be formed as follows:

\(\left(u_{0}, S, S K\right) \rightarrow\left(u_{1}, S^{\prime}, S K^{\prime}\right) \rightarrow\left(u_{2}, S^{\prime \prime}, S K^{\prime \prime}\right)\)       (8)

The key delegation process initiated by the delegator forms multiple delegation paths after multistage and multiple delegations.

multistage and multiple delegations. Decrypt : The user executes algorithm Decrypt (PK, SK, CT) → m. If the attribute set related to SK matches the access structure T of CT , the algorithm executes the decryption process. If the node x is a leaf node, then let i = att(x) , and the recursive algorithm is as follows:

If i ∈ S , then

\(\begin{aligned} \operatorname{DecryptNode}(C T, S K, x) &=\frac{e\left(D_{i}, C_{x}\right)}{e\left(D_{i}^{\prime}, C_{x}^{\prime}\right)}, \\ &=\frac{e\left(g^{r} \cdot H(i)^{r_{i}}, g^{q_{x}(0)}\right)}{e\left(g^{r_{i}}, H(i)^{q_{x}(0)}\right)}, \\ &=e(g, g)^{r q_{x}(0)} . \end{aligned}\)       (9)

If i ∉ S, then DecryptNode(CT, SK, x) = ⊥ .

Now consider the recursive process of the internal node x . The execution of the algorithm DecryptNode(CT, SK, x) is as follows: for all nodes z that are children of x , DecryptNode(CT, SK, x) is run, and the algorithm outputs F_z .

Let S_x be a k_x -sized set of child nodes z , and let F_z ≠⊥. Then, we compute:

\(\begin{aligned} &F_{x}=\prod_{z \in S_{x}} F_{z}{ }_{i, S_{x}^{\prime}}{ }^{(0)},\\ &=\prod_{z \in S_{x}}\left(e(g, g)^{r \cdot q_{z}(0)}\right)^{\Delta_{t, s_{x}}^{(0)}},\\ &=\prod_{z \in S_{x}}\left(e(g, g)^{r \cdot q_{\text {prrart }(z)}(\operatorname{index}(z))}\right)^{\Delta_{i, s_{x}}^{(0)}},\\ &=\prod_{z \in S_{x}}\left(e(g, g)^{r-q_{x}(i)}\right)^{\Delta_{i s_{x}}^{(0)}},\\ &=e(g, g)^{r q_{x}(0)} . \end{aligned}\)       (10)

where i = index(z), and \(S_{x}^{\prime}=\left\{i n d e x(z): z \in S_{x}\right\}\) . Then returns the result above.

If S satisfies the access tree, we make

\(\begin{aligned} &A=\operatorname{DecryptNode}(C T, S K, R)=e(g, g)^{r q_{R}(0)}=e(g, g)^{r s} \\ &E=e\left(D,\left(C_{0}\right)^{D^{\prime}} C_{0}{ }^{\prime}\right) \\ &=e\left(g^{\frac{\alpha+r}{\beta+c}},\left(g^{s}\right)^{c} g^{\beta s}\right) \end{aligned}\)       (11)

\(=e(g, g)^{\alpha s} e(g, g)^{r s}\)       (12)

\(F=\frac{E}{A}=e(g, g)^{\alpha s},\)       (13)

\(m=\frac{\tilde{C}}{\bar{F}}.\)       (14)

The process of decrypting the ciphertext with the delegation key by the delegatee is similar.

The process of decrypting the ciphertext with the delegation key by the delegatee is similar.

Key integrity check: The KGC first checks the integrity of the key. First, check if D' ∈ Z_p , and D ∈ G for ∀a_j ∈ S, D_j, D_j' ∈G . Second, check if

\(\frac{e\left(D, g^{D^{\prime}} g^{\beta}\right)}{e\left(D_{j}, g\right) / e\left(D_{j}^{\prime}, H(j)\right)}=e(g, g)^{\alpha}.\)       (15)

If the key satisfies these two conditions, it is considered to be complete. Otherwise, it is incomplete, and it is unnecessary to trace the incomplete key.

Determination of the ID: If the key is complete, then the KGC executes the decryption algorithm \(\operatorname{Dec}_{k_{2}}\left(D^{\prime}\right)\) to obtain \(\mu^{*}=\mu, v^{*}=v\) . If \(\left(\mu^{*}, v^{*}\right) \in\left\{\left(\mu_{1}, v_{1}\right),\left(\mu_{2}, v_{2}\right), \ldots,\left(\mu_{\mathrm{t}-1}, v_{\mathrm{t}-1}\right)\right\}\) , then KGC calculates \(\operatorname{Dec}_{k_{1}}\left(\mu^{*}\right)\) to obtain the identity of the user who might have deliberately leaked his key. Otherwise, the KGC uses the point \(\left(\mu^{*}, v^{*}\right)\), with existing \(\left(\mu_{1}, v_{1}\right),\left(\mu_{2}, v_{2}\right), \ldots,\left(\mu_{\mathrm{t}-1}, v_{\mathrm{t}-1}\right)\) to recover the secret value \(d_{0}^{*}\) of the threshold scheme. If \(d_{0}^{*} = f(0)\) , then the KGC calculates \(\operatorname{Dec}_{k_{1}}\left(\mu^{*}\right)\) to obtain the identity of the user. Otherwise, the KGC outputs⊥ .

6. Scheme analysis

6.1 Performance analysis

With the criteria of policy expression, key delegation, traceability, and delegation granularity, Table 3 compares the presented work with some existing works. The schemes in [3], [32], [33], and our proposed scheme, each have a key delegation feature. Still, only our work supports fine-grained key delegation, which is based on ciphertext-level granularity.

Table 3. Comparison of different approaches

[3] is a pioneer work within the CP-ABE domain, while [25], [33], and [32] are all closely related to this study. [25] adds traceability to [3], while [32] does not have traceability but adds key delegation to [3]. Furthermore, [33] not only supports key delegation but also tracks delegation keys. Meanwhile, the present paper focuses on the granularity of delegation keys, in addition to having the functions of key delegation and key tracking.

Table 4 compares the size of the public parameter, private key, ciphertext, and delegation key in this scheme with those in [3], [25], [32], and [33]. It also compares the regular key/delegation key generation, and the encryption and decryption costs. We use the notations below.

exp : the number of exponential operations;

e : the number of bilinear operations;

L₀ : bit length of the elements in G ;

L₁ : bit length of the elements in G_T ;

ρ : the number of all attributes in the system;

δ : ciphertext-related attribute number;

σ : user key-related attribute number;

θ : delegation key-related attribute number, θ ≤ σ .

Table 4. Comparison of different approaches

Compared with [3], both the size of the ciphertext and the encryption cost of our scheme are larger; the main reason for this is that our scheme includes the feature of traceability. Compared with other schemes, the size of the delegation key is smallest in our scheme because we determined the least number of attributes that match the access requirement of the delegator.

6.2 Test results

The key delegation scheme was evaluated by conducting a small-scale test. We developed a prototype system of the scheme. We measured the average time cost for algorithms in this scheme. The test environment was a PC with an Intel^® Core™ i7-10510U CPU @ 1.80 GHz 2.30 GHz, with 16 GB RAM, and operating on 64-bit Linux Ubuntu 20.04.2.0. The prototype system was developed in Java and run on Java Development Kit (JDK) 15. It was based on the Java Pairing Based Cryptography (JPBC) library 1.2.0 to implement bilinear operations. We chose 128-bit AES for the symmetric encryption algorithm. We set the degree of the polynomial used in the test to be 20.

The number of attributes associated with the ciphertext, delegation key, and original key was the same for all algorithms, and keys met the ciphertext access structure. From Fig. 6, we can see the changing trend in the computation time of each algorithm in the scheme with the increase in the number of attributes. Under the same conditions, we run each algorithm 10 times, and the average time of the 10 runs was taken as our final test result.

Fig. 6. Time cost of different algorithms with varying numbers of attributes on Linux Ubuntu

It can be seen from Fig. 6 that the time cost of our scheme for Setup and Delegate (the KGC part) does not increase with the increase in the number of attributes; this is because the two algorithms are not relevant to attributes.

In the test, for the different number of attributes, we kept the Setup condition unchanged. The time cost of other algorithms rises with the increase in the number of attributes. We use the “AND” gate to define the policy to force both the delegator and the delegatee to use all attributes in the decryption process. Hence, the time cost for decryption both by the original key and the delegation key reflects the upper bound. The time cost of the KGC in the key delegation part is significantly less than its time cost for generating an original key. This shows that the key delegation scheme can enable the system to accommodate more users while reducing the workload of the KGC. We set up the attributes associated with the delegation key, which are the same as those of the original key, to reflect the upper bound of the time in Delegate (User part) and Trace .

In general, compared with [3], our scheme is slightly more efficient. The delegation key in [3] is generated independently by the KGC. It can be seen that the time cost for Delegate with the KGC in our scheme is much lower than that in [3]. As our scheme supports key traceability, the sum of the time cost of both Delegate algorithms (i.e., that of the KGC and that of the user) is higher than that in [3].

These results show that the key delegation mechanism can transfer the work of the KGC to the user, and let the user act as the authorization authority. This can not only make the whole system accommodate more users but also improve the efficiency of the system.

7. Conclusions

This article presents a fine-grained, traceable CP-ABE key delegation approach for the purpose of read permission delegation of outsourced data. In this study, based on the principle of least decryption ability comes from the principle of least privilege in access control, a minimum number of attributes corresponding to the access structures of certain ciphertexts are selected from the user’s attribute set. A delegation key is constructed by the minimal attribute set, and delegated to the delegatee to decrypt these ciphertexts. In this way, the generation time of the delegation key is the minimum, and the length of this key is the shortest. Controlling the delegatee's decryption ability through the delegation key provides flexibility and fine granularity of access control. An anti-collision feature prevents the delegatee from combining his ordinary key with the delegation key or combining several delegation keys that he possesses, to access data objects that he is not authorized to access. The KGC associates the user's identity with the key component so that the delegation key has traceable characteristics. Users complete the key delegation process under the participation and supervision of the KGC. The proposed approach supports multistage delegation, meaning that the delegatee can further delegate the key to other users. Furthermore, the time cost of the KGC to generate the delegation key is low, and it will not increase with an increase in the number of attributes. Therefore, our approach enables the system to accommodate more users to improve the efficiency of the system. The key delegation has practical implications. From the information sharing point of view, a user may not possess attributes associated with a delegation key, but he has the chance to access some data objects using the delegation key without having related attributes. Consequently, information sharing can be improved. From the scalability point of view, both original and delegation key owners can bring others into the system to access data. Additionally, permission delegation is one of the important issues in the access control scenario, and our approach enables key owners to delegate some of the read permissions to other users via key delegation.

However, our approach is not capable of controlling the width and depth of the key delegation. Black-box traceability is better than white-box traceability and it is more efficient and scalable. The white-box traceable CP-ABE scheme can only trace users possessing complete keys. It cannot trace users possessing incomplete keys. On the contrary, the blackbox traceable CP-ABE can trace users possessing both complete and incomplete keys. In the future, we will investigate a more flexible and discretionary key delegation approach. A more discretionary but still secure key delegation scheme without the involvement of the KGC will reduce the computational cost of the KGC and communication costs between the KGC and users.

Appendix