6.2.2. B is Corrupt

Consider the execution of the proposed protocol when the involved parties are a corrupt buyer <sup>B</sup>*<sup>c</sup>* and an honest CP.

Suppose that <sup>B</sup>*<sup>c</sup>* contacts CP in order to buy the content *<sup>X</sup>*. <sup>B</sup>*<sup>c</sup>* receives the confirmation message *<sup>m</sup>*<sup>4</sup> from CP, which contains the following tokens: *Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)), <sup>S</sup>CP(*Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*))) (see Table 2).

**Lemma 3** (Basic Lemma)**.** *Under the basic assumptions reported in Section 6.1, if* <sup>B</sup>*<sup>c</sup> tries to complete the purchase transaction by employing a corrupt content identifier X<sup>c</sup> <sup>d</sup> in order to impair the piracy tracing mechanism implemented by* CP*, such a corruption is disclosed and the purchase transaction is aborted.*

**Proof.** Suppose that <sup>B</sup>*<sup>c</sup>* wants to use a corrupt identifier *<sup>X</sup><sup>c</sup> <sup>d</sup>* to conduct the purchase transaction. Under the assumptions reported in Section 6.1, such a goal can be achieved only if <sup>B</sup>*<sup>c</sup>* can obtain the generation of a node in the blockchain BC which contains *<sup>X</sup><sup>c</sup> <sup>d</sup>*. This occurs only when BC can certify consistency between the security tokens sent by CP and <sup>B</sup>*<sup>c</sup>* in the messages *<sup>m</sup>*<sup>6</sup> and *<sup>m</sup>*<sup>7</sup> respectively (see Table 2). This also means that, if <sup>B</sup>*<sup>c</sup>* wishes to include the corrupt identifier *<sup>X</sup><sup>c</sup> <sup>d</sup>* in the message *m*7, the buyer must ensure that the corresponding signature <sup>S</sup>CP(*Xd*, ...) is included in the message *<sup>m</sup>*6. However, it is worth noting that, under the assumptions reported in Section 6.1:


As a consequence, <sup>B</sup>*<sup>c</sup>* cannot employ arbitrary content identifiers in the protection protocol, but he/she can, at the most, exploit pairs (*Xd*, <sup>S</sup>CP(*Xd*, ...)) generated by CP in other previous, incomplete purchase transactions. In fact, such pairs must not be already included in nodes of the blockchain.

Suppose that <sup>B</sup>*<sup>c</sup>* can get two distinct content identifiers *Yd* and *Zd*, together with the corresponding signatures <sup>S</sup>CP(*Yd*, ...) and <sup>S</sup>CP(*Zd*, ...), from CP. The two identifiers refer to the content *<sup>Y</sup>* and *<sup>Z</sup>* distributed by CP.

Suppose that <sup>B</sup>*<sup>c</sup>* starts a transaction with CP to purchase *<sup>X</sup>*. <sup>B</sup>*<sup>c</sup>* receives *Xd* and <sup>S</sup>CP(*Xd*, ...) from CP in the message *<sup>m</sup>*4. This also means that BC will receive *Xd* and <sup>S</sup>CP(*Xd*, ...) from CP in the subsequent message *<sup>m</sup>*6, and this will prevent <sup>B</sup>*<sup>c</sup>* from using any other pair of content identifier and signature in the message *m*7. In fact, if this happens, BC can always disclose the mismatch between the tokens included in the message *m*<sup>6</sup> and those ones included in the message *m*7, according to what is reported above. As a consequence, every attempt of <sup>B</sup>*<sup>c</sup>* to conduct a purchase transaction by employing corrupt content identifiers causes the purchase transaction to abort.

**Lemma 4.** *Under the assumptions reported in Section 6.1, if* <sup>B</sup>*<sup>c</sup> tries to corrupt the tokens needed to run the protection protocol in order to impair the piracy tracing mechanism implemented by the watermarking protocol, such a corruption is directly disclosed by* BC *and the purchase transaction is aborted.*

**Proof.** This lemma is an extension of the basic lemma, which has proved that <sup>B</sup>*<sup>c</sup>* cannot deceive BC by proposing arbitrary content identifiers or identifiers that are incoherent with the corresponding signatures. The trivial reason is that BC accepts the tokens sent by <sup>B</sup>*<sup>c</sup>* in the message *<sup>m</sup>*<sup>7</sup> only if they are consistent with those ones sent by CP in the message *<sup>m</sup>*6. Therefore, every attempt of <sup>B</sup>*<sup>c</sup>* to corrupt

the tokens generated by CP during a purchase transaction causes the protection protocol to abort without releasing any protected content.

The lemmas reported above prove that the corrupt entity <sup>B</sup>*<sup>c</sup>* cannot cheat CP in order to release a piece of content not tied to any buyer, because every attempt to corrupt the tokens managed by the protection protocol is always disclosed by BC, which can thus abort the purchase transaction.

## **7. Implementation**

The first prototype implementation of the proposed protocol is mainly based on the experiences documented in [22,24]. It consists of two parts.

The former comprises the same set of C++ separate programs that implement B, CP, RA, and J in [22,24]. The programs run on Linux operating system and communicate via TCP implemented by standard socket library. They implement the encryption/decryption and watermark insertion algorithms by exploiting the NTL library and the GNU Multi Precision Arithmetic library. In particular, watermark insertion is based on the "Quantization Index Modulation" algorithm [61] extended to the homomorphic cryptosystem proposed by Paillier [69] according to the main ideas reported in [9,63]. It follows the indications reported in [42], which successfully address a number of problems that tend to make watermark insertion directly into the encrypted domain inefficient. In this regard, in order to reduce both the number of encryptions and the operations performed on encrypted values, watermark insertion is carried out in the encrypted domain by exploiting the specific technique of the "composite signal representation" described in [42], also called "efficient composite embedding" [50].

The latter implements the blockchain BC according to the Figure 1. In particular, the blockchain can be classified as "public", with a fully decentralized architecture, and based on the classic "proof of work" consensus algorithm [27]. Furthermore, the nodes of the blockchain are implemented in Ethereum [70], whereas the smart contract employed by the proposed protocol is written in Solidity [71].

**Figure 1.** The blockchain within the proposed watermarking protocol.

The performance of the proposed prototype implementation mainly depends on both the basic operations characterizing watermarking protocols and the overhead induced by the blockchain management. In fact, the former are the classic encryption/decryption and watermark insertion operations. Their performances are omitted because, as reported above, they are well documented by the results published in [22,24]. On the contrary, the latter depends on a number of factors, such as, for example, the Ethereum node implementation, the adopted consensus algorithm, and the number of nodes averagely involved in the blockchain, which are essentially independent of proposed watermarking protocol [28,29]. In this regard, it is worth noting that an Ethereum, public and decentralized blockchain, based on the "proof of work" consensus algorithm, is characterized by undoubted advantages, such as decentralization, lack of trusted third parties, and immutability [27–29], but it is also affected by low performance and efficiency levels caused by the time needed for propagating, processing, and validating the purchase transactions [72]. In fact, the higher the number of nodes participating in the blockchain is, the more limiting power consumption and block generation rate become. However, the main goals of the proposed protocols are to achieve high levels of robustness and security without reducing simplicity of the protection scheme. After all, it is not wrong to think that the proposed watermarking protocol will be able to take advantage of the next generation blockchains, which promise to achieve higher performance and efficiency levels, particularly in terms of power consumption, due the development of new consensus algorithms. Nevertheless, such performance aspects have not been investigated because they are out of the scope of this paper.

#### **8. Conclusions**

The main goal in developing the proposed protocol has been to simplify the basic interaction scheme that characterizes the previous protocols that adopt a "buyer friendly" and "mediated" design approach without compromising on their relevant achievements [22–24]. The solution has been found in the smart contracts to be exploited within the blockchain technology. In fact, a smart contract has been employed to simply validate the security tokens generated during purchase transactions and then published as immutable purchase information in the blocks maintained by the blockchain [27–29,31]. It has made it possible to avoid the direct involvement of a TTP in the protection scheme without forcing buyers to carry out complex actions to participate in the purchase transactions. In this way, the interaction scheme turns out to be simple while, at the same time, it strongly reduces the possibility of collusion actions among the parties participating in the protocol, thus making the protocol secure and suited to the current web context.

The proposed protocol also confirms the security achievements characterizing the previous similar protocols [22–24]: (1) CP keeps control on the content that it distributes on the Internet, since it never releases them in unprotected forms; (2) B is the only entity that gets access to the final watermarked content *<sup>X</sup>*¯ , and this makes it possible to trace back pirated copies of *<sup>X</sup>*¯ to <sup>B</sup>; (3) *<sup>X</sup>* is never released in a partially protected form, thus solving the specific problem arisen in the watermarking protocol proposed in [11] and discussed in [22,23]; (4) a suspected buyer is not required to cooperate in the "identification and arbitration protocol" to make appropriate adjudications.

Finally, it is worth noting that the adoption of blockchain technology represents a relevant step in the direction of secure and simplified buyer friendly and mediated watermarking protocols. Moreover, the performance achieved by the prototype implementation of the proposed protocol is overall good, even though it is penalised by the adopted consensus algorithm. However, this cannot be considered an actual problem, since next generations of blockchains will be able to implement improved algorithms and to provide better and better performances [73,74].

**Funding:** This research received no external funding.

**Acknowledgments:** The author wishes to thank Domenico Di Pietro for his good advice.

**Conflicts of Interest:** The author declares no conflict of interest.
