Disabling Tracing in Black-Box-Traceable CP-ABE System: Alert Decryption Black Box

Abstract

In application scenarios such as cloud storage, a symmetric algorithm can be used to encrypt massive data. However, using the symmetric operation and keys in encryption and decryption, it is very difficult to realize an efficient access control system. The asymmetric encryption algorithm ciphertext-policy attribute-based encryption (CP-ABE), as a versatile one-to-many encryption algorithm, is considered an ideal access control tool to solve the user’s distrust of the service provider of cloud storage. However, in a traditional CP-ABE system, the malicious users may deliberately leak their attribute keys to others or build a decryption black box (DB) to provide illegal decryption services for benefits, while no one can determine their identities. To deal with the problems, especially the problem of tracing the DB builder, CP-ABE schemes with black-box traceability have been proposed in the past few years. But in this paper, we point out that for now, the tracing algorithms in all existing schemes actually work on an impractical assumption. That is, whenever a DB receives a decryption request, it always performs the decryption algorithm honestlycorrectly. We argue that if a DB finds the decryption request comes from the tracing algorithm, it may intentionally output incorrect decryption results to counter the tracing. Thus, we present the structural defect of the tracing algorithm applied to all known traceable CP-ABE schemes. We describe the construction of an alert decryption black box (ADB) that is capable of distinguishing a tracing ciphertext from a normal one. We also show how an ADB frustrates the tracing algorithm, and furthermore, malicious users can even apply an ADB to frame innocent users.

1. Introduction

In the case of data outsourcing such as cloud storage, a data user hosts their data in the cloud and usually uses the interface offered by the cloud service provider (CSP) to access or share their data. The data owner has to delegate access control of their data to the CSP while assuming the CSP is a fully trusted party. However, this assumption is not reasonable in many applications. It is more appropriate to consider the CSP as a semitrusted party, which means the CSP performs the operations honestly, whereas it may try to obtain the contents of the data. As one-to-many encryption cryptography, attribute-based encryption [1] (ABE), especially the ciphertext-policy attribute-based encryption (CP-ABE) variant [2], is viewed as an ideal approach to address the problem of distrust.

However, there exists a security obstacle in the practicality of the CP-ABE system, that is, how to prevent authorized users from abusing their privilege. The security problem can be summarized in two forms: (1) an authorized user may intentionally leak their attribute keys to others; and (2) the authorized users may build a decryption device/black box (DB) to provide a decryption service to others while keeping their keys hidden in it. The two cases are described in Figure 1a,b, respectively.

Figure 1. Security issue of privilege abuse.

To deal with privilege abuse, Li et al. [3] firstly proposed an accountable CP-ABE scheme, which inserts some user-specific information into the user’s private key during the key generation. Hence, a malicious user, who performs illegal key sharing, can be identified with his private key. However, their scheme cannot handle case (b) in Figure 1, where the private keys of malicious users are hidden. Liu et al. [4] clarified the concept of traceability and argued that there were two levels of traceability. The first level was white-box traceability, by which given a well-formed decryption key, one can find the key owner. The second level was black-box traceability, and it means that the system can identify the malicious user who builds the decryption black box even if the decryption key and decryption algorithm are all unknown. The scheme of [3] is actually a white-box-traceable scheme, as well as the schemes of [5,6,7,8,9].

Liu et al. [4] present how a decryption black box (DB) works and categorize a DB into two types: the keylike DB and the policy-specific DB. Both kinds of DB are untraceable in a conventional CP-ABE system. Thus, for financial gain or some other motivation, malicious users may build a DB to make a profit, while there is little risk of getting caught. To deal with this security vulnerability, Liu defines the traceability against a keylike DB in [4] and the traceability against a policy-specific DB in [10]. Liu also proves that an augmented CP-ABE (AugCP-ABE) system with a message-hiding property and an index-hiding property implies the traceability against the DB. So how to design a CP-ABE scheme that has a fully collusion-resistant black-box traceability against both kinds of DB has become an important part of research about CP-ABE.

The black-box traceability (BT) implies the white-box one. To completely solve the privilege-abusing problem, a system must achieve black-box traceability. However, it is much more difficult to construct a black-box-traceable scheme. Thus, it is not until 2013 that Liu et al. [4] proposed the first black-box-traceable CP-ABE scheme. Their scheme was inspired by the approach of Boneh and Waters [11], which was an augmented broadcast encryption (AugBE) scheme that provided traceability in a broadcast encryption system. Similar to [11], they built an augmented CP-ABE to allocate each key with an index in the key generation; then, the indices of the keys could be used to identify users when tracing. The further research of Liu et al. [4,10] pointed out that there could be two types of decryption black boxes: keylike decryption black box (keylike DB) and policy-specific decryption black box (policy-specific DB). A keylike DB $\mathcal{D}$, which is associated with an attribute set $S_{\mathcal{D}}$, is able to decrypt the ciphertext whose access policy can be satisfied by $S_{\mathcal{D}}$. Meanwhile, a policy-specific DB $\mathcal{D}$ can only decrypt the ciphertext with a specific access policy ${\mathbb{A}}_{\mathcal{D}}$. Liu et al. proved that the traceability for a policy-specific DB implied the traceability for a keylike DB. Hence, their research in [10] focused on building CP-ABE schemes that were traceable against a policy-specific DB. In most application scenarios of CP-ABE, traceability for DB is necessary for security. However, the schemes with traceability against DB, including the most recent research [12,13,14,15], utilize a similar approach to AugCP-ABE. In this paper, we present a new kind of DB, the alert decryption black box (ADB), which cannot be tracked by existing tracing algorithms in AugCP-ABE systems. This means the traceability of these CP-ABE schemes is not reliable. Malicious users can build an ADB to provide illegal services, and they are still untraceable.

Currently, in existing black-box-traceable CP-ABE schemes, the tracing approach follows the same principle. Tracing algorithms generate some special ciphertext (referred to as tracing ciphertext) and send it to the DB, then identify the DB’s builder by analyzing the return decryption results from the DB. However, we have to point out that these tracing approaches actually work on the assumption that the DB always performs the decryption honestly and correctly whenever it receives a decryption request. In other words, the tracing schemes assume that the DB will not try to distinguish the tracing ciphertext from the normal ciphertext. The assumption is not that reasonable. And obviously, malicious users will endeavor to construct a DB that can differentiate between the tracing ciphertext and the normal ciphertext and take this advantage to counter the tracing.

Our contribution. (1) We reveal the security vulnerability of black-box-traceable CP-ABE schemes. Using this flaw, malicious users can collaborate to frustrate the tracing of the system, while maintaining their illegal decryption service. (2) To clarify this security problem, we analyze the structural defect of the tracing mechanisms applied to existing black-box-traceable CP-ABE schemes. We show in detail how to construct a concrete ADB that can disable tracing and even frame innocent users. (3) We also present a further discussion on how to improve the tracing algorithm.

2. Background

Before presenting how the tracing algorithm fails in tracing an ADB, we need to review the necessary notions and definitions of the black-box-traceable CP-ABE system. In this section, our discussion is mainly based on the mainstream black-box tracing mechanism that is derived from [4], because most black-box tracing CP-ABE schemes apply a similar method for tracing. Note that the subsequent black-box-traceable schemes such as [10,16,17,18,19] directly leverage the tracing algorithm of [4].

We first give the formal definition of augmented CP-ABE, which is the basis of most tracing mechanisms, then we provide the definition of the keylike decryption black box and the corresponding traceability. Finally, we give the detailed tracing algorithm of [4].

2.1. Augmented CP-ABE

As conventional CP-ABE, an augmented CP-ABE (AugCP-ABE) also includes four algorithms: Setup, KeyGen, Encryption, Decryption. However, AugCP-ABE is different in encryption, because its encryption algorithm takes an extra index $\overline{k}\in \{1,\dots ,\mathcal{K}+1\}$, where $\mathcal{K}$ is the number of system users.

${\mathrm{Setup}}_{\mathrm{A}}(U,\lambda ,\mathcal{K})\to (\mathrm{PP},\mathrm{MK})$. The ${\mathrm{Setup}}_{\mathrm{A}}$ algorithm takes as inputs the attribute universe U, security parameter $\lambda$ and the number of users $\mathcal{K}$, then outputs a master secret key $\mathrm{MK}$ and the public parameter $\mathrm{PP}$.

${\mathrm{KeGen}}_{\mathrm{A}}(\mathrm{PP},S,\mathrm{MK})\to \left({\mathrm{SK}}_{k,S}\right)$. This algorithm takes as inputs the master key $\mathrm{MK}$, the public parameter $\mathrm{PP}$ and the user’s attribute set S. According to the attribute set S, the algorithm generates a private key ${\mathrm{SK}}_{k,S}$ assigned with a unique index $k\in \{1,\dots ,\mathcal{K}\}$.

${\mathrm{Encrypt}}_{\mathrm{A}}(M,\mathbb{A},\mathrm{PP},\overline{k})\to \left(CT\right)$. This algorithm encrypts a message M under an access structure $\mathbb{A}$ and an index $\overline{k}\in \{1,\dots ,\mathcal{K}\}$ by using the public parameter $\mathrm{PK}$. Note that the output ciphertext $CT$ contains the access structure $\mathbb{A}$ but does not contain the index $\overline{k}$.

${\mathrm{Decrypt}}_{\mathrm{A}}(CT,\mathrm{PP},{\mathrm{SK}}_{k,S})\to \left(M^{\prime }\right)$. This algorithm takes as input a ciphertext $CT$, a private key ${\mathrm{SK}}_{k,S}$ and the public parameter $\mathrm{PK}$. If the attribute set of ${\mathrm{SK}}_{k,S}$ satisfies the access structure $\mathbb{A}$ of $CT$, it decrypts $CT$ and outputs a message $M^{\prime }$, or it outputs ⊥.

Correctness. For any message M, attribute $S\subseteq U$, access policy $\mathbb{A}$ over U, $k\in \{1,\dots ,\mathcal{K}\}$ and $\overline{k}\in \{1,\dots ,\mathcal{K}+1\}$, suppose ${\mathrm{Setup}}_{\mathrm{A}}(U,\lambda ,\mathcal{K})\to (\mathrm{PP},\mathrm{MK})$, ${\mathrm{KeGen}}_{\mathrm{A}}(\mathrm{PP},S,\mathrm{MK})$$\to \left({\mathrm{SK}}_{k,S}\right)$ and ${\mathrm{Encrypt}}_{\mathrm{A}}(M,\mathbb{A},\mathrm{PP},\overline{k})\to \left(CT\right)$. Only if S satisfies $\mathbb{A}$ and $k\ge \overline{k}$ does ${\mathrm{Decrypt}}_{\mathrm{A}}(CT,\mathrm{PK},{\mathrm{SK}}_{k,S})=M$. That means if $k<\overline{k}$, even if S satisfies $\mathbb{A}$, the decryption results will be incorrect.

Security. The security of an augmented CP-ABE system is defined in the following three security games.

2.2. Traceability

A keylike decryption black ox (keylike DB) $\mathcal{D}$ built by an adversary is a probabilistic device that inputs a ciphertext $CT$ and outputs a decryption message M or ⊥. Usually, the adversary describes $\mathcal{D}$ with a non-negligible probability value $ϵ$$(0<ϵ\le 1)$ and a nonempty attribute set $S_{\mathcal{D}}$. If the access policy $\mathbb{A}$ of ciphertext can be satisfied by $S_{\mathcal{D}}$, $\mathcal{D}$ can decrypt the ciphertext correctly with a probability of no less than $ϵ$. Thus, if the probability value $ϵ=1$, the decryption ability of $\mathcal{D}$ is equal to that of a private key associated with the attribute set $S_{\mathcal{D}}$. In addition, ${\mathbb{K}}_{\mathcal{D}}\subseteq \{1,\dots ,\mathcal{K}\}$ denotes the index set of the private keys which are used to build the decryption black box $\mathcal{D}$.

The definition of the tracing algorithm for a keylike DB is:

${\mathbf{Trace}}^{\mathcal{D}}\{ϵ,\mathrm{PP},{\mathrm{S}}_{\mathcal{D}}\}\to {\mathbb{K}}_{\mathrm{T}}\subseteq \{1,\dots ,\mathcal{K}\}$. Trace${}^{\mathcal{D}}$ is an oracle algorithm that interacts with a keylike DB $\mathcal{D}$. By giving a public parameter $\mathrm{PP}$, the attribute set $S_{\mathcal{D}}$ and the probability value $ϵ$ associated with $\mathcal{D}$, it runs in polynomial time in $\lambda$ and $1/ϵ$ and outputs an index set ${\mathbb{K}}_T\subseteq \{1,\dots ,\mathcal{K}\}$, where $\mathcal{K}$ is the number of system users. ${\mathbb{K}}_T$ identifies the set of malicious users who build $\mathcal{D}$. Note that $\lambda$ is the security parameter of the CP-ABE scheme and $ϵ$ must be polynomially related to $\lambda$.

To produce useful results, the outputs ${\mathbb{K}}_T$ should satisfy ${\mathbb{K}}_T\ne Ø\wedge {\mathbb{K}}_T\subseteq {\mathbb{K}}_{\mathcal{D}}\wedge (\exists k_t\in {\mathbb{K}}_{T}s.t.S_{\mathcal{D}}\subseteq S_{k_t})$. ${\mathbb{K}}_T\ne Ø\wedge {\mathbb{K}}_T\subseteq {\mathbb{K}}_{\mathcal{D}}$ means that innocent users cannot be framed, and the tracing algorithm can identify at least one builder of $\mathcal{D}$. $(\exists k_t\in {\mathbb{K}}_{T}s.t.S_{\mathcal{D}}\subseteq S_{k_t})$ indicates that the Trace${}^{\mathcal{D}}$ algorithm will identify at least one critical malicious user whose private key can provide the decryption ability according to $S_{\mathcal{D}}$.

To illustrate the traceability with a formal definition that implies the notion of full collusion-resistant traceability, Liu [4] provided a tracing game that was defined between a challenger and an adversary $\mathcal{A}$. The game ${\mathrm{Game}}_{\mathrm{TR}}$ was described as follows:

Setup. The challenger runs ${\mathrm{Setup}}_{\mathrm{A}}(U,\lambda ,\mathcal{K})\to (\mathrm{PP},\mathrm{MK})$ and sends $\mathrm{PP}$ to $\mathcal{A}$.

Key Query. For $i=1$ to q, $\mathcal{A}$ adaptively makes queries according to the tuple $(k_i,S_{k_i})$, and the challenger responds with the private key ${\mathrm{SK}}_{k_i,S_{k_i}}$.

Keylike decryption black-box generation. $\mathcal{A}$ produces a decryption black box $\mathcal{D}$ associated with a nonempty attribute set $S_{\mathcal{D}}\subseteq U$ and a non-negligible probability value $ϵ$.

Tracing. The challenger runs the algorithm Trace${}^{\mathcal{D}}$ and outputs an index set ${\mathbb{K}}_T\in \{1,\dots \mathcal{K}\}$.

The adversary $\mathcal{A}$ wins the game if:

• When $S_{\mathcal{D}}$ satisfies the access policy $\mathbb{A}$, there is $\mathrm{Pr}\left[\mathcal{D}\right(\mathrm{Encrypt}(\mathrm{PP},M,\mathbb{A}))=M]\ge ϵ$, where the probability is taken over the random choices of message M and the random coins of $\mathcal{D}$. It means $\mathcal{D}$ is a useful keylike decryption black box.
• ${\mathbb{K}}_T⊈{\mathbb{K}}_{\mathcal{D}}$, or ${\mathbb{K}}_T=Ø$, or $(\forall k_t\in {\mathbb{K}}_{T}s.t.S_{\mathcal{D}}⊈S_{k_t})$.

Definition 1.

A $\mathcal{K}$-user black-box-traceable CP-ABE system is traceable if the probability of any polynomial-time adversary $\mathcal{A}$ to win the game is negligible in λ.

2.3. Tracing Algorithm

Here, we present the classic tracing approach in the work of Liu [4]. Note that the succeeding black-box-traceable schemes usually make use of the same construction or similar ones for tracing.

Suppose that ${\sum }_A=\{{\mathrm{Setup}}_{\mathrm{A}}, {\mathrm{KeGen}}_{\mathrm{A}}, {\mathrm{Encrypt}}_{\mathrm{A}}, {\mathrm{Decrypt}}_{\mathrm{A}}\}$ is an augmented CP-ABE, Liu constructed the black-box-traceable CP-ABE system $\sum =\{{\mathrm{Setup}}_{\mathrm{A}}, {\mathrm{KeGen}}_{\mathrm{A}}, \mathrm{Encrypt},$${\mathrm{Decrypt}}_{\mathrm{A}}\}$ derived from ${\sum }_A$, by defining $\mathrm{Encrypt}(M,\mathbb{A},\mathrm{PP})={\mathrm{Encrypt}}_{\mathrm{A}}(M,\mathbb{A},\mathrm{PP},1)$. For such a CP-ABE system, given a keylike DB $\mathcal{D}$ associated with a non-negligible probability value $ϵ$ and a nonempty attribute set $S_{\mathcal{D}}$, the tracing algorithm is defined as Trace${}^{\mathcal{D}}\{PP,S_{\mathcal{D}},ϵ\}\to {\mathbb{K}}_T\subseteq \{1,\dots ,\mathcal{K}\}$. To trace $\mathcal{D}$, the oracle algorithm Trace${}^{\mathcal{D}}$ works as follows:

• For $k=1$ to $\mathcal{K}+1$, do the following:

  (a)

  The algorithm repeats the following steps $8\lambda {(\mathcal{K}/ϵ)}^2$ times:

  • Select a random message M from the message space.
  • Let $CT\leftarrow {\mathrm{Encrypt}}_{\mathrm{A}}(\mathrm{PP},M,{\mathbb{A}}_{S_{\mathcal{D}}},k)$, where ${\mathbb{A}}_{S_{\mathcal{D}}}$ is the strictest access policy over $S_{\mathcal{D}}$.
  • Query oracle $\mathcal{D}$ with input ciphertext $CT$ and compare the output of $\mathcal{D}$ with M.

  (b)

  Let $\widehat{p_k}$ be the fraction of times that $\mathcal{D}$ decrypted the ciphertext correctly.

• The algorithm outputs ${\mathbb{K}}_T$ as the index set of the private decryption key of malicious users, where ${\mathbb{K}}_T$ is the set of all $k\in \{1,\dots ,\mathcal{K}\}$ for which $\widehat{p_k}-\widehat{p_{k+1}}\ge ϵ/\left(4\mathcal{K}\right)$.

Note that for an attribute set $S_{\mathcal{D}}$, the strictest access policy is ${\mathbb{A}}_{S_{\mathcal{D}}}={\wedge }_{x\in S_{\mathcal{D}}}x$.

3. How to Frustrate Tracing

Most black-box-traceable schemes such as [10,16,17,18,19] make use of the tracing algorithm Trace${}^{\mathcal{D}}$, while [20,21,22] employ other approaches for tracing. However, these tracing mechanisms in all existing traceable CP-ABE schemes follow a similar assumption that may be unreasonable.

Here, we first give a high-level analysis of the tracing mechanism in existing black-box-traceable schemes and point out the structural defect in such kinds of tracing schemes. Based on this, for the current traceable systems, we present a general approach on how to construct an untraceable keylike DB, which is referred to as an alert decryption black box (ADB) in our work. Also, we show how an ADB frustrates tracing or even frames innocent users.

3.1. Structural Defect

So far as we know, in any black-box-traceable CP-ABE scheme, the tracing algorithm needs to perform tracing for a DB by interacting with it. The tracing algorithm outputs tracing ciphertexts, which are different from the normal ciphertext, and sends them to the DB. If the DB executes decryption correctly and returns the decryption results, the tracing algorithm can analyze the results by some means and expose the private keys used in the decryption, and then find the builder of the DB. But actually, this tracing approach works on an implicit assumption that the DB must always perform the decryption honestly and correctly; only in this way can the tracing algorithm identify the malicious users who build the DB. However, if a DB can distinguish between the tracing ciphertext and the normal ciphertext, it may deliberately respond to the tracing ciphertext with incorrect decryption results or even some well-designed error message to mislead tracing. And at the same time, it keeps returning correct results for the normal ciphertext. Thus, the DB can offer its “service” as usual while countering tracing. Therefore, the traceability actually depends on whether a DB can or cannot distinguish the tracing ciphertext from the normal ones.

In fact, the decryption results of the tracing ciphertext need to differ from user to user, because if the decryption results of different users are the same, the tracing algorithm will not be able to tell who has performed the decryption. By contrast, for a normal ciphertext, the decryption results that come from the distinct authorized users, whose attributes satisfy the access policy of the ciphertext, should be the same. Since correct decryption for the normal ciphertext must recover the original plaintext, whoever performs the decryption correctly will recover the identical plaintext. We show the two decryption cases in Figure 2.

Figure 2. Decryption situations.

Due to the nature of the tracing mechanism, there must exist some differences between the tracing ciphertext and the normal ciphertext. Malicious users can always use the difference and manage to distinguish the tracing ciphertext from the normal one, so as to counter the tracing operation.

Taking use of this structural defect, malicious users can build a DB that may be untraceable in existing CP-ABE schemes. For example, suppose that a system allocates the private key for attribute set $S_A$ to user A and assigns user B the private key according to attribute set $S_B$. If $S_A\cap S_B\ne Ø$, A and B may build a keylike DB denoted by $\mathcal{D}$, which is associated with a nonempty set $S_{\mathcal{D}}\subseteq S_A\cap S_B$, by generating decryption keys $S{K}_A$ and $S{K}_B$ both according to $S_{\mathcal{D}}$ and embedding the keys in the DB. For each decryption request, $\mathcal{D}$ will use $S{K}_A$ and $S{K}_B$ to decrypt the ciphertext, respectively. If two decryption results are identical, $\mathcal{D}$ outputs the results as usual, otherwise, $\mathcal{D}$ treats the sender of the ciphertext as a tracker. For the following decryption request from the tracker, $\mathcal{D}$ can take action to counter tracing in a certain strategy, while it keeps a normal response to the normal decryption request. The operation mechanism is described in Figure 3.

Figure 3. Operation mechanism of an untraceable decryption black box.

3.2. Construction of Alert Decryption Black Box

In general, two or more private keys can be combined together to build a DB that may be capable of distinguishing between the tracing ciphertext and normal ciphertext, and the DB can perform further operations based on the type of ciphertext. It may intentionally output the incorrect decryption results if necessary or simply stop the service to prevent the snooping from tracing the algorithm. This kind of DB is referred to as an alert decryption black box (ADB) in this paper. To make it clear, we give the concrete construction of an ADB that is a keylike decryption black box and untraceable against the tracing algorithm ${\mathbf{Trace}}^{\mathcal{D}}$. In the section, we show how ${\mathbf{Trace}}^{\mathcal{D}}$ fails for tracing an ADB, while the ADB can keep its illegal decryption service “valid”. Note that such an untraceable ADB can also be built in a similar way in most black-box-traceable CP-ABE schemes.

Different from the DB described in [4], which is a device owned by the buyer, in our context, the DB is considered as a server on the network owned by its builder (a more reasonable assumption for now), and it provides a decryption service for its “subscribers”.

Our fundamental idea is to build the ADB with n decryption keys where $n\ge 2$. However, to simplify the description, we take an ADB $\mathcal{D}$ as the example, which is built with two decryption keys ${\mathrm{SK}}_{k_1,S_1}$ and ${\mathrm{SK}}_{k_2,S_2}$, for $1<k_1<k_2\le \mathcal{K}$ and $S_1\cap S_2\ne Ø$. $\mathcal{D}$ is described by the attribute set $S_{\mathcal{D}}\subseteq S_1\cap S_2$ and the probability value $ϵ$, which means $\mathcal{D}$ provides a similar ability as a decryption key associated with the attribute set $S_{\mathcal{D}}$. When $\mathcal{D}$ receives a decryption request and the access structure of cyphertext is satisfied by the attribute set $(S_1\cap S_2)$, it will apply the two keys ${\mathrm{SK}}_{k_1,S_1}$ and ${\mathrm{SK}}_{k_2,S_2}$ to decrypt the message, respectively. If the decryption results are distinct, $\mathcal{D}$ marks the message sender as a tracker. In the following interaction with this tracker, $\mathcal{D}$ will take action to mislead it and try to frustrate its tracing, meanwhile, $\mathcal{D}$ serves other normal subscribers as usual. We suppose that $\mathcal{D}$ only provides service for its valid “subscribers” and will not decrypt the message when the message sender is unknown, because that is not in the interest of the ADB’s builder.

Specifically, for each subscriber (identified with $SID$), $\mathcal{D}$ defines three parameters $mod{e}_{SID}$, $counte{r}_{SID}$ and $deco{y}_{SID}$, and $\mathcal{D}$ initializes $mod{e}_{SID}=“normal”$ for each new subscriber. When $\mathcal{D}$ receives a decryption request from any subscriber, it runs the antitracing decryption algorithm to answer it. The antitracing decryption algorithm is defined as: ${\mathbf{AntiTraDecrypt}}_{\mathcal{D}}(\mathrm{PP},CT,{\mathrm{SK}}_{k_1,S_1},{\mathrm{SK}}_{k_2,S_2},S_{\mathcal{D}},SID)\to \left(RM\right)$. This algorithm takes as inputs the public parameter $\mathrm{PP}$, a ciphertext $CT$, the secret keys ${\mathrm{SK}}_{k_1,S_1},{\mathrm{SK}}_{k_2,S_2}$, the attribute set $S_{\mathcal{D}}=S_1\cap S_2$ and the subscriber’s ID denoted by $SID$. If the attribute set $S_{\mathcal{D}}$ cannot satisfy the access structure $\mathbb{A}$ of $CT$, the algorithm outputs ⊥, or else, it outputs the return message $RM$. The algorithm follows the steps:

Now, we show how Algorithm 1 is applied to counter the tracing algorithm. Suppose a tracker, whose subscriber id is ${SID}^{*}$, applies the tracing algorithm Trace${}^{\mathcal{D}}$ to trace a DB. Trace${}^{\mathcal{D}}$ generates a tracing ciphertext to test the indices of the keys from 1 to $\mathcal{K}+1$ one by one. For an index $\overline{k}$, Trace${}^{\mathcal{D}}$ performs ${\mathrm{Encrypt}}_{\mathrm{A}}$ with $\overline{k}$ to produce the tracing ciphertext and repeats it $8\lambda {(\mathcal{K}/ϵ)}^2$ times in a round. Thus, in the previous $k_1$ rounds of the tests for the indices from 1 to $k_1$, $\mathcal{D}$ behaves as a normal DB and returns the correct decryption results, because when the index $\overline{k}\le k_1$, the two decryption results $M_1,M_2$ are identical. However, in the $(k_1+1)$th round, $SI{D}^{*}$ is marked as a “tracker” since $M_1\ne M_2$ in this round of testing. But $\mathcal{D}$ keeps returning the correct decryption results $M_2$ until it comes to the ($deco{y}_{SI{D}^{*}}+1$)th round. From this round on, the tracker receives the wrong messages in all following interactions, since the value of $counte{r}_{SI{D}^{*}}$ exceeds the limits ($8\lambda {(\mathcal{K}/ϵ)}^2\ast (deco{y}_{SID}+1-k_1)$). The tracing algorithm must observe that ${\widehat{p}}_{deco{y}_{SI{D}^{*}}}-{\widehat{p}}_{deco{y}_{SI{D}^{*}}+1}>ϵ/\left(4\mathcal{K}\right)$; then, $deco{y}_{SI{D}^{*}}$ is identified as the index of the private keys that belongs to the users who build $\mathcal{D}$. Therefore, the tracker fails to capture the real builder, and $\mathcal{D}$ remains untraceable.

Algorithm 1 ${\mathrm{AntiTraDecrypt}}_{\mathcal{D}}$

1: if $mod{e}_{SID}=“normal”$ then 2:     $M_1\leftarrow {\mathrm{Decrypt}}_{\mathrm{A}}(CT,\mathrm{PP},{\mathrm{SK}}_{k_1,S_1})$ 3:     $M_2\leftarrow {\mathrm{Decrypt}}_{\mathrm{A}}(CT,\mathrm{PP},{\mathrm{SK}}_{k_2,S_2})$ 4:     if $M_1\ne M_2$ then 5:         $mod{e}_{SID}\leftarrow “tracker”$, $counte{r}_{SID}\leftarrow 1$ 6:         $deco{y}_{SID}\leftarrow$ a random selection range from $[k_1+1,k_2-1]$ 7:     end if 8:     $RM\leftarrow M_2$ 9: else 10:     if $counte{r}_{SID}<8\lambda {(\mathcal{K}/ϵ)}^2\ast (deco{y}_{SID}+1-k_1)$ then 11:         $counte{r}_{SID}\leftarrow counte{r}_{SID}+1$ 12:         $RM\leftarrow {\mathrm{Decrypt}}_{\mathrm{A}}(CT,\mathrm{PP},{\mathrm{SK}}_{k_2,S_2})$ 13:     else 14:         $RM\leftarrow$ a message selected from the message space at random 15:     end if 16: end if 17: outputs $RM$

To illustrate the mechanism of ${\mathrm{AntiTraDecrypt}}_{\mathcal{D}}$, consider the following example. Assume the two private keys ${\mathrm{SK}}_{k_1,S_1}$ and ${\mathrm{SK}}_{k_2,S_2}$ are used to build the decryption black box $\mathcal{D}$, where $k_1=9, S_1=\{NewYorkarea, movie, music, ebook\}$ and $k_2=102,$$S_2=\{NewYorkarea, movie\}$. The attribute set $S_{\mathcal{D}}$ is $\{NewYorkarea, movie\}$. Suppose that a system manager runs the tracing algorithm and sends $\mathcal{D}$, the tracing ciphertext, which is encrypted under the policy “$NewYorkarea$ AND $movie$”. In the first 9 rounds, $\mathcal{D}$ decrypts the ciphertext correctly since the decryption results over the two keys ${\mathrm{SK}}_{k_1,S_1}$ and ${\mathrm{SK}}_{k_2,S_2}$ are equal for each ciphertext. After that, $\mathcal{D}$ finds that the decryption results under the two keys are different ($M_1\ne M_2$). Thus, $\mathcal{D}$ marks the system manager as a “tracker” and sets $deco{y}_{ID}$ as a random value from the range 10 to 102. Here, we assume that $deco{y}_{ID}$ is randomly set to 29. Thus, in the next 20 rounds, $\mathcal{D}$ counts the decryption requests from this tracker and keeps returning the correct messages produced by the key ${\mathrm{SK}}_{k_2,S_2}$ until it comes to the 30th round. From this round on, $\mathcal{D}$ returns a random message as the response to the request of the tracker. This causes the index 29 to be identified as the key of the malicious user because ${\widehat{p}}_{29}-{\widehat{p}}_{30}>ϵ/\left(4\mathcal{K}\right)$. As a result, the tracing algorithm is misled; meanwhile, $\mathcal{D}$’s illegal service is not affected by the antitracing procedure.

Thus, the ADB can be untraceable for the tracker while useful for other subscribers. Similar constructions can be applied to build such kinds of untraceable ADBs in most traceable CP-ABE systems.

3.3. Discussion

If an ADB is built by two keys with indices $k_1$ and $k_2$, the ADB can be used to frame any user with a key index between $k_1$ and $k_2$. Suppose that an ADB tries to frame the user who owns a key index $k^{*}$, where $k_1<k^{*}<k_2$. It simply sets $deco{y}_{SID}=k^{*}$ instead of a random value when it performs step 6 of the algorithm ${\mathrm{AntiTraDecrypt}}_{\mathcal{D}}$. In the following interaction with the ADB, the tracing algorithm detects that ${\widehat{p}}_{k^{*}}-{\widehat{p}}_{k^{*}+1}>ϵ/\left(4\mathcal{K}\right)$ and identifies $k^{*}$ as the key index of the ADB builder. The failure of Trace${}^{\mathcal{D}}$ can be ascribed to its deterministic testing of key indices, which strictly adheres to a sequential order ranging from 1 to $\mathcal{K}+1$. Thus, the ADB can determine the testing index of the key by counting the tracing cyphertext.

3.3.1. Improvement of Tracing Algorithm

The failure of the tracing algorithm is because it generates and sends the tracing ciphertext in a fixed sequence. Thus, it is easy for an ADB to find out the key index embedded in the tracing ciphertext. Therefore, a simple conclusion is that if a tracing algorithm tests the keys according to a certain fixed mode, the mode needs to be kept secret. Otherwise, an ADB can always use the mode to guess the test key index and take some strategies to mislead the tracing algorithm. To avoid keeping the test mode a secret, it is reasonable that the tracing algorithm tests the key indices in random order. We suggest a new tracing algorithm Trace${}_{\mathrm{random}}^{\mathcal{D}}\{PP,S_{\mathcal{D}},ϵ\}\to {\mathbb{K}}_T\subseteq \{1,\dots ,\mathcal{K}\}$ working as follows:

• Generate a sequence of integers $r{k}_1,r{k}_2,\dots ,r{k}_{\mathcal{K}+1}$. It is a random permutation of the numbers 1 to $\mathcal{K}+1$, where $1\le r{k}_i\le \mathcal{K}+1$, and $r{k}_i\ne r{k}_j$ for $i\ne j$.
• For $i=1$ to $\mathcal{K}+1$, do the following:

  (a)

  The algorithm repeats the following steps $8\lambda {(\mathcal{K}/ϵ)}^2$ times:

  • Select a random message M from the message space.
  • Let $CT\leftarrow {\mathrm{Encrypt}}_{\mathrm{A}}(\mathrm{PP},M,{\mathbb{A}}_{S_{\mathcal{D}}},r{k}_i)$, where ${\mathbb{A}}_{S_{\mathcal{D}}}$ is the strictest access policy over $S_{\mathcal{D}}$.
  • Query oracle $\mathcal{D}$ with input ciphertext $CT$ and compare the output of $\mathcal{D}$ with M.

  (b)

  Let ${\widehat{p}}_{r{k}_i}$ be the fraction of times that $\mathcal{D}$ decrypted the ciphertext correctly.

• The algorithm outputs ${\mathbb{K}}_T$ as the index set of the private decryption key of malicious users, where ${\mathbb{K}}_T$ is the set of all $k\in \{1,\dots ,\mathcal{K}\}$ for which $\widehat{p_k}-\widehat{p_{k+1}}\ge ϵ/\left(4\mathcal{K}\right)$.

Note that to keep the random permutation secure, the first step of Trace${}_{\mathrm{random}}^{\mathcal{D}}$ must equally likely produce each permutation of the numbers 1 to $\mathcal{K}+1$, and such an algorithm to generate the permutation can be found in [23]. Since the algorithm ${\mathbf{Trace}}_{\mathrm{random}}^{\mathcal{D}}$ sends the tracing ciphertext with random key indices, the ADB is not able to determine the key index of the tracing ciphertext, so it fails to frame the particular users.

3.3.2. Analysis of Traceability

In this section, we analyze the probability of identifying the malicious users who build the ADB, if the ${\mathbf{Trace}}_{\mathrm{random}}^{\mathcal{D}}$ algorithm is applied to track them. Assuming that malicious users build the ADB with their decryption keys ${\mathrm{SK}}_{k_1,S_1}$ and ${\mathrm{SK}}_{k_2,S_2}$, for $1<k_1<k_2\le \mathcal{K}$ and $S_1\cap S_2\ne Ø$, and a tracker performs ${\mathbf{Trace}}_{\mathrm{random}}^{\mathcal{D}}$ to interact with the ADB. To simplify the problem, we focus on the probability of identifying the key index of ${\mathrm{SK}}_{k_1,S_1}$. Obviously, ${\mathbf{Trace}}_{\mathrm{random}}^{\mathcal{D}}$ can identify index $k_1$ in the following two cases.

• Index $k_1$ is tested before the tracker has been marked, and index $k_1+1$ is tested when $counte{r}_{SID}\ge 8\lambda {(\mathcal{K}/ϵ)}^2\ast (deco{y}_{SID}+1-k_1)$. Therefore, the ADB returns the correct decryption for the testing of index $k_1$, and the incorrect decryption results for the testing of index $k_1+1$. The probability of this case is:

  $$Pr1=\frac{P_{k_1-1}^{k_1-1}{P}_{\mathcal{K}+1-k_1}^{\mathcal{K}+1-k_1}}{P_{\mathcal{K}+1}^{\mathcal{K}+1}}\sum _{i=1}^{k_1}\left(C_{\mathcal{K}+1-i}^{k_1-i}(1-\frac{k_2-k_1}{2(\mathcal{K}+1-i)})\right)$$

  (1)
• Index $k_1$ undergoes testing after the tracker has been marked, and this testing occurs when $counte{r}_{SID}<8\lambda {(\mathcal{K}/ϵ)}^2\ast (deco{y}_{SID}+1-k_1)$. And index $k_1+1$ undergoes an evaluation during $counte{r}_{SID}\ge 8\lambda {(\mathcal{K}/ϵ)}^2\ast (deco{y}_{SID}+1-k_1)$, leading to a distinct decryption operation for the two indices. The probability of this case is

  $$Pr2=\sum _{i=0}^{k_1}\left(\frac{P_{k_1}^i{P}_{\mathcal{K}+1-k_1}^1}{P_{\mathcal{K}+1}^{i+1}}\left(1-\frac{C_{k_2-k_1}^2+C_{\mathcal{K}-i-k_2+k_1}^2}{C_{\mathcal{K}-i}^2}\right)\right)$$

  (2)

The total probability of identifying index $k_1$ of the malicious user is

$$Pr=Pr1+Pr2$$

(3)

By setting $\mathcal{K}=5000$, we demonstrate the probability of identifying index $k_1$ belonging to the malicious user in Figure 4. This probability decreases with an increase in $k_1$ and increases with $k_2$. For $k_2-k_1=20$, the probabilities in all three cases are less than 0.008. As a result, if ADB builders select a small value of $k_2-k_1$, the probability of detecting the malicious user is only slightly better than a random guess.

Figure 4. Probability to identify $k_1$.

However, an ADB may choose to adopt an alternative strategy whereby it discontinues the decryption service provided to a “subscriber” once it has been flagged as a tracker by ${\mathbf{AntiTraDecrypt}}_{\mathcal{D}}$. In such cases, the tracker must assume a new subscriber identity to resume service from the ADB. The number of subscriber accounts required by the tracker to accomplish tracing is determined by a specific function, denoted as $8\lambda {(\mathcal{K}/ϵ)}^2\times (\mathcal{K}+1-k_1)$. In most scenarios, the cost of tracing is prohibitively high, particularly in large-scale systems with a substantial user base. In fact, based on the ability to distinguish the tracing ciphertext from the normal ciphertext, other kinds of complicated DB can also be designed. For example, AI technologies can be applied to design a smart DB, which can even take an adaptive strategy to counter the tracing algorithm.

4. Conclusions

Currently, in black-box-traceable CP-ABE schemes, the DB built by malicious users is assumed to be a device that always performs the decryption honestly and correctly. That is, a DB executes the decryption operation correctly even if it receives a tracing cyphertext. We point out the assumption about the DB is too simple and idealistic. Malicious users who build decryption black boxes must try to get benefits while keeping themselves secure against tracking. The DB they build may choose to output incorrect decryption results to mislead the tracker when it detects tracing cyphertext sent by the tracker. Thus, we analyzed the structural defect of the tracing mechanism in most black-box-traceable systems. It means that the decryption result of the tracing cyphertext varies from user to user, but for a normal cyphertext, different users obtain the same decryption results. Making use of the structural defect, two or more malicious users may collaborate together to build a DB. This kind of DB can distinguish the tracing cyphertext from the normal cyphertext; then, it can take certain strategies to counter tracing. Based on that, we presented an example of an ADB that can mislead the tracing algorithm of AugCP-ABE systems. Similar constructions can also be applied to disable the tracking of most black-box-traceable CP-ABE schemes. Finally, we discussed the improvement of the tracing algorithm and proposed the ${\mathbf{Trace}}_{\mathrm{random}}^{\mathcal{D}}$ algorithm. But we proved that the new algorithm could only prevent innocent users from being framed, and it is still difficult to identify the malicious users who build ADBs, which means ADBs are still untraceable for now. To achieve traceability against ADBs, we believe that future research should focus on modifying the tracing mechanism so that a DB cannot distinguish the tracing ciphertext from the normal ciphertext.