FairCMS: Cloud Media Sharing with Fair Copyright Protection

As illustrated in Fig. 1, our system model mainly consists of four entities: the owner, the cloud, users, and the judge. Their roles are elaborated as follows.

• •

  Owner. The owner, who might be a media producer or trader, plans to store the media content in the cloud and let the cloud do the content distribution. First, the owner requires that the cloud not be able to obtain the plaintext about the media content and the LUTs, and that access to the media content is controlled by his/her authorization. Second, the owner asks for significant overhead savings from cloud media sharing. Third, the owner demands traitor tracing of users who violate copyright. If a suspicious redistributed copy of the media content is found, the owner can file an arbitration claim with the judge.

• •

  Cloud. The cloud has a wealth of hardware, software, and bandwidth resources, part of which are lent to the owner through a pay-per-use way to help the owner carry out media sharing.

• •

  Users. Users want to access the owner's media content. To this end, users request authorization from the owner, for example by paying for purchases. If successful, users can get the desired shared media content from the cloud. Users require that the plaintext of their fingerprints not be accessed by the owner or the cloud, to prevent malicious framing by the owner.

• •

  Judge. The judge is a trusted entity who is only responsible for arbitration in the case of illegal redistribution, as in existing traitor tracing systems [10, 11, 12, 13, 14, 3]. After receiving the owner's request for arbitration, the judge makes a fair judgment based on the evidence provided by the owner. Although only the encrypted version of the user's watermark is disclosed, the encrypted watermark can be converted into a ciphertext that can be decrypted by the judge based on PRE (for details, please see Figs. 3 and 4), thus enabling traitor tracing. Once the judge detects a copyright infringement, the unfaithful user will be prosecuted in accordance with the law.

The threats considered in this paper come from three entities: users, the owner, and the cloud. First, users are assumed to be malicious, who could illegally redistribute the owner's media content with the hope that this behavior will not be detected. Second, the owner is also assumed to be malicious, who may try to obtain the users' fingerprints and maliciously embed the fingerprints into any media content to frame honest users for copyright infringement. Third, the cloud is assumed to be honest-but-curious, which is the same as other privacy-preserving cloud media sharing schemes based on ABE or PRE [7, 21, 23, 29, 15]. Although the honest-but-curious cloud faithfully performs its assigned duties, he/she could try to steal the plaintext about the owner's media content. Moreover, the cloud is also curious about other information it encounters, including the users' fingerprints and the LUTs. Finally, as in [28], we assume that there may exist collusion among individual users and collusion between the owner and the cloud, while there is no collusion between users and the cloud.

Under the above system model and threat model, we summarize the design goals as follows.

• •

  Implement privacy-preserving access control. On the one hand, the cloud should be prevented from obtaining the private plaintext of the data it encounters, including the owner's media content, the users' fingerprints, and the LUTs. On the other hand, only users authorized by the owner can access the media content.

• •

  Protect the owner's copyright. We need to embed the user's fingerprint in the owner's media content to enable traitor tracing. As long as an unfaithful user makes an unauthorized redistribution, he/she can be detected by the embedded fingerprint in the media content.

• •

  Protect the user’s right. We need to prevent the owner from framing an honest user for copyright infringement by embedding this user's fingerprint in any media content.

• •

  Ensure efficiency gains and scalability. For one thing, we need to carefully control the owner-side overhead to ensure that the owner can gain significant local resource savings from cloud media sharing. For another, we need to ensure that the two proposed schemes are scalable to handle real-time requests from users.

• •

  TTP-free. The two proposed schemes should not require any TTP to participate in the media sharing process. The TTP mentioned here does not cover the judge, who is only responsible for handing down sentences in cases of suspected redistribution and is not involved in the media sharing process. The judge is an indispensable participant. In contrast, the existing schemes [26, 27, 3] that are not TTP-free all require a TTP to remain online during media sharing to generate watermarks for users.

For better understanding, we start with the introduction of a LUT-based watermarking scheme [30, 31], which is the basis of the AFP scheme proposed by Bianchi et al. [10].

Given the above arithmetics of the LUT-based user-side embedding in the plaintext domain, the additive homomorphism is used to implement the secure distribution of D-LUTs in the ciphertext domain [10].

The lifted-ElGamal based PRE scheme [16, 17, 18, 19, 20] is summarized as follows.

Let $G_{1}$, $G_{2}$ be two multiplicative cyclic groups of prime order $q$ with a bilinear map $e:~{}{G_{1}}\times{G_{1}}\to{G_{2}}$, and $g$ be a random generator of $G_{1}$. The mapping $e$ has three properties. 1) Bilinearity: for any $a,b\ {\in}\ \mathbb{Z}_{q}$, $e(g^{a},g^{b})=e(g,g)^{ab}$. 2) Non-degeneracy: $e(g,g)\ {\neq}\ 1$. 3) Computability: $e$ can be efficiently computed.

With bilinear pairing, the lifted-ElGamal based PRE technique is comprised of the following algorithms by using the public parameters $G_{1},G_{2},q,e,g$ and $Z=e(g,g)\ {\in}\ G_{2}$.

• •

  Key Generation ($KG$). A user $A$’s key pair is of the form $PK_{A}=(Z^{a_{1}},g^{a_{2}})$ and $SK_{A}=(a_{1},a_{2})$, and a user $B$'s key pair is of the form $PK_{B}=(Z^{b_{1}},g^{b_{2}})$ and $SK_{B}=(b_{1},b_{2})$.

• •

  Re-encryption Key Generation ($RG$). A user $A$ authorizes $B$ access to $A$'s data by publishing the re-encryption key $rk_{A{\rightarrow}B}=(g^{b_{2}})^{a_{1}}=g^{a_{1}b_{2}}\ {\in}\ G_{1}$, computed from $A$’s private key and $B$’s public key¹¹1One single user $A$ can also generate a re-encryption key for himself to change the second-level ciphertext into the first-level, we denote this key as $rk_{A^{2}{\rightarrow}A^{1}}=(g^{a_{2}})^{a_{1}}=g^{a_{1}a_{2}}$..

• •

  First-Level Encryption ($E^{1}$). To encrypt a message $m\in Z_{q}$ under $PK_{A}$ in such a way that it can only be decrypted by the holder of $SK_{A}$, the scheme computes $E^{1}_{PK_{A}}(m)=(Z^{a_{1}r},Z^{m}Z^{r})$, where $r$ is a random num-ber from $Z_{q}$.

• •

  Second-Level Encryption ($E^{2}$). To encrypt a message $m\in Z_{q}$ under $PK_{A}$ in such a way that it can be decrypted by $A$ and his/her delegatees, the scheme outputs $E^{2}_{PK_{A}}(m)=(g^{r},Z^{m}Z^{a_{1}r})$.

• •

  Re-encryption ($R$). Anyone can change a second-level ciphertext for $A$ into a first-level ciphertext for $B$ with $rk_{A{\rightarrow}B}=g^{a_{1}b_{2}}$. From $E^{2}_{PK_{A}}(m)=(g^{r},Z^{m}Z^{a_{1}r})$, the scheme computes $e(g^{r},g^{a_{1}b_{2}})=Z^{b_{2}a_{1}r}$ and publishes $E^{1}_{PK_{B}}(m)=(Z^{b_{2}a_{1}r},Z^{m}Z^{a_{1}r})=(Z^{b_{2}{r^{\prime}}},Z^{m}Z^{r^{\prime}})$.

• •

  Decryption ($D^{1},D^{2}$). To decrypt a first-level ciphertext $E^{1}_{PK_{A}}(m)=(Z^{a_{i}r},Z^{m}Z^{r})=(\alpha,\beta)$ with private key $a_{i}\ {\in}\ SK_{A}$, the scheme computes $m^{\prime}=Z^{m}=\frac{\beta}{\alpha^{1/a_{i}}}$ for $i\ {\in}\ \{1,2\}$. To decrypt a second-level ciphertext $E^{2}_{PK_{A}}(m)=(g^{r},Z^{m}Z^{a_{1}r})=(\alpha,\beta)$ with secret key $a_{1}\ {\in}\ SK_{A}$, the scheme outputs $m^{\prime}=Z^{m}=\frac{\beta}{e(\alpha,g)^{a_{1}}}$.

To get the plaintext $m$, the above mentioned PRE scheme requires computing the discrete logarithm of $m^{\prime}$ in the base $Z$, i.e., $m=\log_{Z}m^{\prime}$. Although this sounds restrictive, there is no limitation to the use of the lifted-ElGamal based PRE scheme as long as the plaintext space is small, as also pointed out by many other literature works [17, 18, 19, 20]. In our experiment, the lookup table method [34] is used to solve the discrete logarithm. It is worth emphasizing that the private key is still secure because of its huge value space. For example, in the experiment we quantify the plaintext to $20$ bits, whereas the private key is typically $1,024$ bits or longer. Note that the value space doubles for each additional bit.

The most important feature of this PRE scheme is that both the first-level ciphertext and the second-level ciphertext satisfy the property of additive homomorphism, i.e.,

where $r_{1}$ and $r_{2}$ are random numbers in $Z_{q}$, and $i\ {\in}\ \{1,2\}$. In addition, we emphasize that the second line in Eq. (6) is also satisfied, and the verification is similar to the above.

In the user-side embedding AFP, since the encrypted media content shared with different users is the same, the encryption of the media content is only executed once. In contrast, due to the personalization of D-LUTs, once a new user initiates a request, the owner must interact with this user to securely distribute the D-LUT under the support of homomorphic en-cryption. This cost scales linearly with the number of users. It is clear that the biggest source of overhead for the owner is the management and distribution of LUTs. Therefore, the focus of implementing resource-saving cloud media sharing is to find ways to transfer this overhead to the cloud. Based on this observation, the first scheme is as follows.

Based on the lifted-ElGamal based PRE scheme introduced in Section IV-C, the $k$-th user $U_{k}$ generates his/her public key $PK_{U_{k}}=(Z^{a_{1}},g^{a_{2}})$ and private key $SK_{U_{k}}=(a_{1},a_{2})$. In addition, the owner $O$ generates his/her own public key $PK_{O}=(Z^{b_{1}},g^{b_{2}})$ and private key $SK_{O}=(b_{1},b_{2})$, and the judge $J$ also generates the key pair as $PK_{J}=(Z^{c_{1}},g^{c_{2}})$ and $SK_{J}=(c_{1},c_{2})$. Moreover, the $k$-th user generates his/her private fingerprint $\mathbf{b}_{k}$ locally, and the owner generates a E-LUT $\mathbf{E}$ and a encoding matrix $\mathbf{G}$ locally.

The $k$-th user encrypts his/her private fingerprint $\mathbf{b}_{k}$ into a second-level ciphertext $E_{PK_{U_{k}}}^{2}(\mathbf{b}_{k})$ using his/her public key $Z^{a_{1}}$, namely $E_{PK_{U_{k}}}^{2}(\mathbf{b}_{k})=[(g^{r_{0}},Z^{b_{k,0}}Z^{a_{1}r_{0}}),\cdots,(g^{r_{L-1}},$ $Z^{b_{k,L-1}}Z^{a_{1}r_{L-1}})]$, and then sends $E_{P{K_{{U_{k}}}}}^{2}({{{\mathbf{b}}_{k}}})$ to the cloud. In addition, the $k$-th user also generates a re-encryption key $rk_{{U_{k}^{2}}\to{U_{k}^{1}}}=g^{a_{1}a_{2}}$ with his/her private key $SK_{U_{k}}=a_{1}$ and his/her public key $PK_{U_{k}}=g^{a_{2}}$, and generates another re-encryption key $r{k_{{U_{k}}\to J}}=g^{a_{1}c_{2}}$ with his/her private key $SK_{U_{k}}=a_{1}$ and the judge's public key $PK_{J}=g^{c_{2}}$, then sends the two re-encryption keys to the cloud.

The owner encrypts the E-LUT $\mathbf{E}$ into a second-level ciphertext $E^{2}_{PK_{O}}(\mathbf{E}(t))~{}(0\leq t\leq T-1)$ using his/her public key $PK_{O}=Z^{b_{1}}$, i.e., $E^{2}_{PK_{O}}(\mathbf{E}(t))=(g^{r},Z^{\mathbf{E}(t)}Z^{b_{1}r})$, and sends $E^{2}_{PK_{O}}(\mathbf{E}(t))$ together with $\mathbf{G}$ to the cloud, who then stores $E_{P{K_{O}}}^{2}({{\mathbf{E}}(t)})$ and $\mathbf{G}$. In addition, the owner $O$ generates a re-encryption key $rk_{O\to{U_{k}}}$ under his/her private key $S{K_{O}}{\rm{=}}{b_{1}}$ and the $k$-th user’s public key $P{K_{{U_{k}}}}{\rm{=}}{g^{a_{2}}}$, i.e., $r{k_{O\to{U_{k}}}}={g^{b_{1}a_{2}}}$, and then sends $r{k_{O\to{U_{k}}}}$ to the cloud.

The cloud uses the re-encryption key $rk_{O\to{U_{k}}}$ to change the received encrypted E-LUT under the owner's key, i.e., $E^{2}_{PK_{O}}({{\mathbf{E}}(t)})$, into $E^{1}_{PK_{U_{k}}}({{\mathbf{E}}(t)})$, which is the first-level ciphertext of the $k$-th user. Furthermore, the cloud changes $E_{PK_{U_{k}}}^{2}(\mathbf{b}_{k})$ into $E_{PK_{U_{k}}}^{1}(\mathbf{b}_{k})$ using $rk_{{U^{2}_{k}}\to{U^{1}_{k}}}$ and changes $E_{PK_{U_{k}}}^{2}(\mathbf{b}_{k})$ into $E^{1}_{PK_{J}}(\mathbf{b}_{k})$ using $rk_{{U_{k}}\to J}$, and then stores $E_{PK_{J}}^{1}(\mathbf{b}_{k})$ into a set $\mathcal{F}$. Subsequently, the cloud calculates $E_{PK_{U_{k}}}^{1}(\mathbf{D}_{k}(t))$ with $E_{PK_{U_{k}}}^{1}(\mathbf{E}(t))$, $E^{1}_{PK_{U_{k}}}(\mathbf{b}_{k})$, and $\mathbf{G}$ by Eqs. (7) and (8). We emphasize that this process can be performed successfully because the first level ciphertext of the lifted-ElGamal based PRE scheme satisfies the property of additive homomorphism. Finally, the cloud sends $E^{1}_{PK_{U_{k}}}(\mathbf{D}_{k}(t))$ back to the $k$-th user, who acquires his/her personalized D-LUT $\mathbf{D}_{k}$ through decryption with his/her private key $SK_{U_{k}}=a_{2}$.

The owner encrypts the media content collection $\{\mathbf{m}\}$ to be shared using the single-value alteration method and sends the resulting encrypted media content collection $\{\mathbf{c}\}$ to the cloud, who then stores the encrypted media content collection. In addition, the owner sends the binary matrix collection $\{\mathbf{B}^{m}\}$ used in the encryption process to the cloud, which is generated locally by the owner based on the session keys and is utilized for encrypting each media content.

The cloud calculates the secret matrix collection $\{\bar{\mathbf{G}}\}$ with the binary matrix collection $\{\mathbf{B}^{m}\}$ and the encoding matrix $\mathbf{G}$, and then stores the secret matrix collection and the binary matrix collection. Suppose the $k$-th user expects to access one of the owner's media content ${\mathbf{m}}$. The cloud then extracts the encryption result $\mathbf{c}$ of the media content ${\mathbf{m}}$ from the encrypted media content collection, i.e., ${\mathbf{c}}={\mathbf{m}}+{{\mathbf{B}}^{m}}{\mathbf{E}}$, and sends $\mathbf{c}$ to this user. Meanwhile, the corresponding binary matrix $\mathbf{B}^{m}$ is also extracted from the binary matrix collection by the cloud and sends to the $k$-th user. Finally, the $k$-th user decrypts $\mathbf{c}$ with his/her personalized D-LUT $\mathbf{D}_{k}$ and the binary matrix ${\mathbf{B}}^{m}$ based on Eq. (3) to get the fingerprint embedded media content ${\mathbf{m}}^{k}$.

Upon the detection of a suspicious media content copy $\tilde{\mathbf{m}}^{k}$, the owner resorts to the judge for violation identification. To this end, the proofs that the owner needs to provide the judge includes the original media content $\mathbf{m}$ with no fingerprints embedded, the corresponding secret matrix $\bar{\mathbf{G}}$, and the set $\mathcal{F}$ that holds all the users' fingerprints. Among them, $\bar{\mathbf{G}}$ and $\mathcal{F}$ is available for download by the owner from the cloud. It is worth mentioning that the fingerprints stored in set $\mathcal{F}$ are encrypted by the judge's public key $PK_{J}$, so the user's fingerprint will not be leaked to the owner and the cloud, but the plaintext of the fingerprints can be decrypted by the judge with his/her own private key $SK_{J}=c_{2}$. With these materials, the judge can make a fair judgment by Eq. (4) or (5).

The whole FairCMS-I scheme is summarized as follows. First, suppose an owner rents the cloud's resources for media sharing, the owner and the cloud execute Part 1 as shown in Fig. 2. Then, suppose the $k$-th user makes a request indicating that he/she wants to access one of the owner’s media content $\mathbf{m}$, the involved entities execute Part 2 after the $k$-th user is authorized by the owner as shown in Fig. 3. Once a suspicious media content copy ${\tilde{\mathbf{m}}}^{k}$ is detected, the owner resorts to the judge for violation arbitration, i.e., the owner and the judge jointly execute Part 3 as shown in Fig. 4.

We emphasize that Part 1 is just an initialization step that only needs to be executed once before media sharing begins, while Part 2 is executed upon requesting of media content copy from each authorized user. Part 3 is only executed for each detected suspicious media content copy. Therefore, in the case of a large number of users, the owner's overhead in Part 2 should be the primary concern for a media sharing system. Fortunately, in our design, by delegating the operations securely to the cloud, now in Part 2 the owner only needs to calculate and send a re-encryption key, which only incurs negligible overhead. As a result, this scheme well solves the bottleneck caused by insufficient owner-side resources. Also, since Part 2 is executed online for each user, this scheme clearly meets the scalability requirements. The achievement of the three security goals of FairCMS-I will be discussed in detail in Section VI.

In addition, it is noted that two re-encryption keys $rk_{U^{2}_{k}\to U^{1}_{k}}$ and $rk_{U_{k}\to J}$ are used in the scheme to protect the users' fingerprints. Among them, $rk_{U^{2}_{k}\to U^{1}_{k}}$ is used to change $E^{2}_{PK_{U_{k}}}(\mathbf{b}_{k})$ into $E^{1}_{PK_{U_{k}}}(\mathbf{b}_{k})$, and $rk_{U_{k}\to J}$ is used to change $E^{2}_{PK_{U_{k}}}(\mathbf{b}_{k})$ into $E^{1}_{PK_{J}}(\mathbf{b}_{k})$. In comparison, the method adopted in [3] is that the $k$-th user encrypts his/her fingerprint $\mathbf{b}_{k}$ with his/her public key $PK_{U_{k}}$ and judge's public key $PK_{J}$ respectively, and then sends the two results $E^{1}_{PK_{U_{k}}}(\mathbf{b}_{k})$ and $E^{1}_{PK_{J}}(\mathbf{b}_{k})$ to the cloud. However, in this case, an unfaithful user can evade traitor tracing by producing two different fingerprints, i.e., a $\mathbf{b}^{{}^{\prime}}_{k}$ is used to produce $E^{1}_{PK_{U_{k}}}(\mathbf{b}^{{}^{\prime}}_{k})$ and another $\mathbf{b}^{{}^{\prime\prime}}_{k}$ is used to produce $E^{1}_{PK_{J}}(\mathbf{b}^{{}^{\prime\prime}}_{k})$. Our proposed scheme avoids this vulnerability because the user only has freedom to generate one fingerprint $\mathbf{b}_{k}$, and $E^{1}_{PK_{U_{k}}}(\mathbf{b}_{k})$ (for fingerprint embedding) and $E^{1}_{PK_{J}}(\mathbf{b}_{k})$ (for traitor tracing) are re-encryption results of the same second-level ciphertext $E^{2}_{PK_{U_{k}}}(\mathbf{b}_{k})$.

Moreover, FairCMS-I does not perform any processing on the encrypted media content stored in the cloud, but only performs homomorphic operations and re-encryption operations on the encrypted LUT and fingerprint that are much smaller in size, which results in outstanding cloud-side efficiency. In contrast, the two schemes proposed by Zhang et al. [3] both require homomorphic operations and re-encryption operations on the media content, which obviously consumes a lot more cloud resources. This means that FairCMS-I can save users a large amount of cost of renting cloud resources, thus achieving one of the prominent advantages of our work.

Finally, we emphasize that the attack from the communication channel is not considered in the adopted threat model, so $\mathbf{B}^{m}$, $\mathbf{G}$, and $\bar{\mathbf{G}}$ are all transmitted in plaintext. In practical applications, if the communication channel does not meet this assumption, simple modifications can be made to the proposed scheme. On the one hand, we can use public key cryptography to encrypt the transmitted plaintext. For example, in Part 1 the owner can encrypt $\mathbf{G}$ with the cloud's public key $PK_{C}$ before sending it to the cloud, who then decrypts $E_{PK_{C}}(\mathbf{G})$ with his/her own private key $SK_{C}$. On the other hand, the same $\mathbf{B}^{m}$ can be generated on different entities by sharing the session key $SK_{m}$, in the same way as in the AFP scheme. Meanwhile, bandwidth savings can also be obtained by transferring $SK_{m}$ instead of $\mathbf{B}^{m}$. Apart from the above, message authentication code and digital signature can also be added if integrity and source authentication are needed.

The encryption and decryption on the media content $\mathbf{m}$ in FairCMS-I are essentially symmetric-key cipher although the E-LUT and D-LUT used are different, so it is highly efficient since only the single-value additive operation is used in this cipher. However, the IND-CPA security of the encrypted media content collection $\{\mathbf{c}\}$ stored in the cloud cannot be achieved [30]. In applications with high media privacy requirements, a more secure cloud media sharing scheme is desired. In this concern, we propose the second cloud media sharing scheme FairCMS-II, in which all media content stored in the cloud are encrypted by the lifted-ElGamal based encryption scheme.

In FairCMS-II, the key, fingerprint, E-LUT, and encoding matrix are all generated in the same way as in FairCMS-I. In addition, the calculation and management process for D-LUTs is also the same as in FairCMS-I, except that there is no need to distribute the resulting D-LUTs to users. That is, the cloud is not required to send the last calculated $E^{1}_{PK_{U_{k}}}(\mathbf{D}_{k}(t))$ (Part 2 of FairCMS-I) to the $k$-th user, but instead storing it in a set $\mathcal{D}$. As will be shown in the following detailed discussion, this trick will enable the full usage of the computational power of the cloud and reduce bandwidth usage.

The owner encrypts the media content collection $\{\mathbf{m}\}$ to be shared with his/her public key $PK_{O}=Z^{b_{1}}$, and then sends the resulting encrypted media content collection $\{E^{2}_{PK_{O}}(\mathbf{m})\}$ $=\{(g^{r},Z^{\mathbf{m}}Z^{b_{1}r})\}$ to the cloud. In addition, the owner use the session keys he/she selects to generate the binary matrix collection $\{\mathbf{B}^{m}\}$, which is then sent to the cloud.

The cloud calculates the secret matrix collection $\{\bar{\mathbf{G}}\}$ with $\{\mathbf{B}^{m}\}$ and $\mathbf{G}$, and then stores $\{\bar{\mathbf{G}}\}$ and $\{\mathbf{B}^{m}\}$. In addition, the cloud calculates the encrypted ciphertext media content collection $\{E^{2}_{PK_{O}}(\mathbf{c})\}$ from $\{E^{2}_{PK_{O}}(\mathbf{m})\}$, $E^{2}_{PK_{O}}(\mathbf{E}(t))$, and $\{\mathbf{B}^{m}\}$ by

where $c_{i}$ (resp. $m_{i}$) is the $i$-th element of $\mathbf{c}$ (resp. $\mathbf{m}$) and $i\in\{0,2,...,M-1\}$. We emphasize that this process can be accomplished successfully as the second-level ciphertext of the lifted-ElGamal based PRE scheme satisfies the property of additive homomorphism. Afterwards, the cloud stores $\{E^{2}_{PK_{O}}(\mathbf{c})\}$.

Suppose the $k$-th user want to acquire one of the owner's media content $\mathbf{m}$. The cloud then extracts the corresponding encrypted ciphertext media content $E^{2}_{PK_{O}}(\mathbf{c})$ from the encrypted ciphertext media content collection. Subsequently, the cloud converts $E^{2}_{PK_{O}}(\mathbf{c})$ into $E^{1}_{PK_{U_{k}}}(\mathbf{c})$ with the received re-encryption key $rk_{O\to{U_{k}}}$ using the PRE technique. Joint decryption and fingerprinting is then processed by the cloud in the ciphertext domain as follows:

The cloud then sends the resulting $E^{1}_{PK_{U_{k}}}(\mathbf{m}^{k})$ to the $k$-th user, who decrypts $E^{1}_{PK_{U_{k}}}(\mathbf{m}^{k})$ with his/her own private key $SK_{U_{k}}=a_{2}$ to obtain the media content $\mathbf{m}^{k}$ embedded with his/her personal fingerprint. We emphasize that the cloud cannot get the plaintext version $\mathbf{m}^{k}$ of the watermarked media content as the cloud does not have the private key $SK_{U_{k}}$ of the $k$-th user to decrypt the resulting $E^{1}_{PK_{U_{k}}}(\mathbf{m}^{k})$.

The whole FairCMS-II scheme is summarized as follows. First, suppose an owner rents the cloud's resources for media sharing, the owner and the cloud execute Part 1 as shown in Fig. 5. Then, suppose the $k$-th user makes a request indicating that he/she wants to access one of the owner’s media content $\mathbf{m}$, the entities execute Part 2 after the $k$-th user is authorized by the owner as shown in Fig. 6. Finally, the arbitration and traitor tracing process follows the same approach of FairCMS-I and is thus omitted here.