**5. Watermarking Protocol**

The proposed watermarking protocol is an enhancement of the buyer friendly and mediated protocols presented in [22–24]. It has been designed and developed according to what is reported in Section 3. Therefore, it exploits the blockchain technology to avoid the participation of a TTP in the core of the protection phase so as to simplify and secure the basic interaction scheme characterizing the protocols described in [22–24]. The result is an innovative watermarking protocol in which the blockchain is employed to lock in a public ledger the main tokens characterizing purchase transactions. In fact, such tokens are collected and controlled by executing a specific smart contract: if they turn out to be correct, the ongoing purchase transaction is automatically validated and completed without the direct intervention of a TTP.

Even though the proposed protocol can run without a centralized control, it still needs a TTP acting as a trusted web distributor of security tokens, such as one-time public and private key pairs and encrypted "nonces" [51], needed to complete the purchase transactions of protected digital content according to the original buyer friendly and mediated approach [22]. Moreover, the proposed protocol

needs a further TTP, called "judge". It does not participate in the phase of the protocol that applies the protection to the digital content distributed on the Internet. It only participates in the subsequent "identification and arbitration phase" needed to determine the identity of an illegal distributor of a copy of a protected digital content [22–24]. In fact, the TTP and the judge could even coincide, but conventional certification authorities do not usually implement the service performed by the judge [17,22].

More precisely, the proposed watermarking protocol is characterized by a protection scheme in which: (1) the seller or content provider CP releases content in an encrypted and watermarked form; (2) the buyer B can obtain the protected content by simply decrypting it; (3) the purchase transaction of a protected digital content occurring between the buyer and the content provider is validated by automatically executing a smart contract within a blockchain BC, which takes charge of controlling all the tokens generated by the transaction; (4) buyer and content provider take part in transactions that employ security tokens guaranteed by a "registration authority" RA [22–24]; (5) a judge J guarantees the dispute resolution protocol and determines if a buyer is guilty of having released pirated copies [22–24].

The protocol consists of two subprotocols: the *protection protocol* and the *identification and arbitration protocol*. The meanings of the symbols used to describe the protocol are reported in Table 1.


**Table 1.** Meanings of the symbols used to describe the proposed protocol.

### *5.1. Protection Protocol*

The protocol, whose scheme is reported in Table 2, starts when B visits the CP's web site, chooses the content *X*, and sends the purchase request to CP in the message *m*1.


**Table 2.** Protection protocol.

Upon receiving the purchase request, CP contacts RA, by sending the message *m*2, in order to obtain the security tokens to complete the purchase transaction. In fact, RA is a TTP that publishes a list of pairs, each including a public key *pk<sup>X</sup>* RA and an encrypted token <sup>E</sup>*pk<sup>X</sup>* RA (*N*). In particular, *pk<sup>X</sup>* RA corresponds to the secret key *sk<sup>X</sup>* RA. They represent a one-time key pair that can be used only in the current transaction [52]. *N* is a "nonce" represented by a binary string. It is encrypted by employing the public key *pk<sup>X</sup>* RA and a cryptosystem that is "privacy homomorphic" [49] with respect to the subsequent watermark insertion. In fact, the resulting token <sup>E</sup>*pk<sup>X</sup>* RA (*N*) will be then used to generate the watermark to be inserted into the content *X*.

The chosen pair (*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)) is returned by RA in the message *<sup>m</sup>*<sup>3</sup> together with the signature <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)).

Upon receiving *m*3, CP can confirm the purchase request made by B. In fact, CP generates two tokens, *Xd* and *TX*. The former is a string that identifies the requested content *X*. It includes the name of the content and further data that can unambiguously describe it. The latter is a timestamp that is referred to the ongoing transaction. Then, CP generates the signature <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*))) and sends the message *<sup>m</sup>*<sup>4</sup> to <sup>B</sup>, which includes *Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)), and <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*))).

After having confirmed the purchase request, CP can apply the protection to *X*. Therefore, CP generates its part of watermark, denoted by *W*CP, which is a fingerprinting binary code obtained as an anti-collusion code [6,7,16] concatenated with an error correcting code used to address the problems of bit errors that can arise during the watermark verification process. Then, CP encrypts *W*CP and *X* using the public key *pk<sup>X</sup>* RA and the same homomorphic cryptosystem used by RA to encrypt *<sup>N</sup>*, thus generating <sup>E</sup>*pk<sup>X</sup>* RA (*W*CP) and <sup>E</sup>*pk<sup>X</sup>* RA (*X*).

Then, according to the basics reported in Section 4, CP concatenates <sup>E</sup>*pk<sup>X</sup>* RA (*W*CP) and <sup>E</sup>*pk<sup>X</sup>* RA (*N*) to generate the encrypted watermark <sup>E</sup>*pk<sup>X</sup>* RA (*W*) according the following expression:

$$\mathbb{E}\_{pk\_{\mathcal{R},\mathcal{A}}^{X}}(\mathcal{W}) = \mathbb{E}\_{pk\_{\mathcal{R},\mathcal{A}}^{X}}(\mathcal{W}\_{\mathcal{CP}}) \| \mathbb{E}\_{pk\_{\mathcal{R},\mathcal{A}}^{X}}(\mathcal{N}) = \mathbb{E}\_{pk\_{\mathcal{R},\mathcal{A}}^{X}}(\mathcal{W}\_{\mathcal{CP}} \| \mathcal{N}) \tag{1}$$

Moreover, CP can embed the encrypted watermark <sup>E</sup>*pk<sup>X</sup>* RA (*W*) directly into the encrypted content <sup>E</sup>*pk<sup>X</sup>* RA (*X*) according to the following expression:

$$\overline{\mathbb{E}\_{pk^{X}\_{\mathcal{R},\mathcal{A}}}(X)} = \mathbb{E}\_{pk^{X}\_{\mathcal{R},\mathcal{A}}}(X) = \mathbb{E}\_{pk^{X}\_{\mathcal{R},\mathcal{A}}}(X \ominus \mathcal{W}) = \mathbb{E}\_{pk^{X}\_{\mathcal{R},\mathcal{A}}}(X) \ominus \mathbb{E}\_{pk^{X}\_{\mathcal{R},\mathcal{A}}}(\mathcal{W}) \tag{2}$$

since encryption is homomorphic with respect to watermark insertion [10,49,50]. The encrypted and watermarked content <sup>E</sup>*pk<sup>X</sup>* RA (*X*) can be thus sent by CP to <sup>B</sup> in the message *<sup>m</sup>*5.

At this point, CP and B can activate the smart contract in the blockchain BC by sending the messages *m*<sup>6</sup> and *m*7, respectively.

In particular, the message *<sup>m</sup>*<sup>6</sup> is sent by CP to BC, and contains *Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>E</sup>*pk<sup>X</sup>* RA (*N*), <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)), and the signature <sup>S</sup>CP(*Xd*, *TX*, *pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*), <sup>S</sup>*RA*(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*))).

The message *<sup>m</sup>*<sup>7</sup> is sent by <sup>B</sup> to BC, and includes *Xd*, *TX*, *pk<sup>X</sup>* RA, and <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)). In addition, B also sends *Bid* and *Bad* to BC in the message *m*7: the former is a token that unambiguously identifies B, whereas the latter represents his/her destination address. In particular,


When the messages *m*<sup>6</sup> and *m*<sup>7</sup> are received by BC, the code associated to a specific smart contract is automatically executed. The code of the contract mainly compares the tokens, verifies the signatures contained in the two received messages, and checks whether the tokens *pk<sup>X</sup>* RA and <sup>E</sup>*pk<sup>X</sup>* RA (*N*), generated by RA, have been already used in a previous purchase transaction or not. In fact, this means to check whether *pk<sup>X</sup>* RA and <sup>E</sup>*pk<sup>X</sup>* RA (*N*) have been already published in a node of the blockchain or not. If all data turn out to be correct, match, and the tokens generated by RA have not been used in previous transactions, the code enables the generation of a new node in BC, which makes some of the tokens identifying the ongoing transactions, such as *Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>E</sup>*pk<sup>X</sup>* RA (*N*), <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)), and <sup>S</sup>CP(*Xd*, *TX*, *pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*), <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*))), public. Moreover, the execution of the smart contract within BC takes also charge of implementing the payment phase. It ends by sending two messages, *m*<sup>8</sup> and *m*9, to RA and CP, respectively.

The message *m*<sup>8</sup> includes *Bad* and *pk<sup>X</sup>* RA, and enables RA to send the secret key *sk<sup>X</sup>* RA to <sup>B</sup> in the message *<sup>m</sup>*10. <sup>B</sup> can thus decrypt <sup>E</sup>*pk<sup>X</sup>* RA (*X*) and obtain the final protected content according to the following equalities:

$$\overline{\mathbb{E}\_{pk\underline{\mathbb{X}}\_{\mathcal{A}}}(X)} = \mathbb{E}\_{pk\underline{\mathbb{X}}\_{\mathcal{A}}}(\bar{X}), \qquad \bar{X} = \mathbb{D}\_{sk\underline{\mathbb{X}}\_{\mathcal{A}}}(\overline{\mathbb{E}\_{pk\underline{\mathbb{X}}\_{\mathcal{A}}}(X)}) \tag{3}$$

The message *<sup>m</sup>*<sup>9</sup> contains the security token *Epk*RA (*Bid*, *pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)). It is stored by CP in a new entry in its databases, whose search key is the watermark *W*CP. The entry also includes the following tokens: *Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>E</sup>*pk<sup>X</sup>* RA (*N*), and <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)). Such tokens are needed to prove that <sup>B</sup> is the legitimate owner of the protected content *<sup>X</sup>*¯ sold by CP through a transaction registered by a node published in the blockchain BC.

#### *5.2. Identification and Arbitration Protocol*

The protocol is run by CP to identify the responsible distributor of a pirated copy of *<sup>X</sup>*¯ , who was the legitimate copyright owner of *X*¯ , with undeniable evidence [4,5].

As shown in Table 3, the first step of the protocol consists of extracting the watermark *W*- from the pirated copy of *X*¯ , denoted as *X*- . After the extraction of *W*- = *W*- CP*N*- , CP can access its databases and use *W*- CP to search them for a match. If a possible match is found [11], CP can retrieve the tokens saved during the purchase transaction of *X*¯ , which are *Xd*, *TX*, *pk<sup>X</sup>* RA, <sup>E</sup>*pk<sup>X</sup>* RA (*N*), <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)), and *Epk*RA (*Bid*, *pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)). Then, CP can send the tokens, together with *W*- , to J in the message *m*1.



<sup>J</sup> receives *<sup>m</sup>*<sup>1</sup> and verifies the signature <sup>S</sup>RA(*pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)). Then, it searches the blockchain BC for a node using *pk<sup>X</sup>* RA and <sup>E</sup>*pk<sup>X</sup>* RA (*N*) as search keys. If a node is found, <sup>J</sup> can access the tokens published by the node, which are reported in Table 2, and compare them with those one received by CP. If all the tokens match, <sup>J</sup> can send *pk<sup>X</sup>* RA, <sup>E</sup>*pk<sup>X</sup>* RA (*N*), and *Epk*RA (*Bid*, *pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)) to RA in the message *m*2.

RA decrypts *Epk*RA (*Bid*, *pk<sup>X</sup>* RA,E*pk<sup>X</sup>* RA (*N*)) and verifies the received tokens. If all data are correct, RA decrypts <sup>E</sup>*pk<sup>X</sup>* RA (*N*) and sends *Bid* and *<sup>N</sup>* to <sup>J</sup> in the message *<sup>m</sup>*3.

Upon receiving *m*3, J compares *N* and *N*. If *N*- = *N*, the identity of the buyer *Bid* is revealed, and J can adjudicate him/her to be a traitor, thus closing the case. Otherwise, the protocol ends without exposing any identity.

#### **6. Protocol Analysis**

In the conducted analysis, the ideal behavior of the proposed watermarking protocol can be modeled as follows: a content provider CP sells the digital content *X* to a buyer B; B obtains the protected digital content *<sup>X</sup>*¯ from CP; a blockchain BC is a ledger that publishes the tokens that identify each purchase transaction of digital content distributed on the web; a registration authority RA generates some specific data that have to be used by CP to protect *X*; a judge J decides whether B is guilty of releasing pirated copies.

The ideal behavior is modeled under the following assumptions:


The assumptions reported above ensure that, if CP and B are uncorrupt, B receives a unique and personalised protected content *X*¯ during the purchase transaction. Therefore, if a pirated copy of *<sup>X</sup>*¯ is found on the web, it can be always traced back to <sup>B</sup> and to the purchase transaction. On the contrary, if CP is corrupt, <sup>B</sup> receives a protected content *<sup>X</sup>*¯ that cannot be correctly tied to any buyer. As a consequence, nobody can be adjudicated to be a traitor, and the corruption of CP ends up being useless and pernicious just for CP. Likewise, if B is corrupt, CP can abort the purchase transaction without releasing any content.

#### *6.1. Assumptions*

The proposed protocol assumes that the watermark insertion technique employed to protect a digital content is robust against the most common and nonmalevolent manipulations, and survives the most relevant and intentional attacks, such as signal processing based attacks, geometric attacks, or collusion attacks [6,7,56–60]. In fact, such an assumption is realistic since there is a vast literature on watermark insertion techniques that documents the existence of increasingly robust and secure watermarking algorithms [1,20,21,61–65] together with a promising and increasing research activity in the development of new techniques and algorithms.

The protocol also assumes that the digital encryption applied within the context of a PKI is characterized by indistinguishability under chosen plaintext attack (IND-CPA). As a consequence, an adversary cannot get any knowledge about a plaintext message *m* from the corresponding ciphertext *c*.

Finally, the protocol assumes that the adopted cryptosystem is privacy homomorphic with respect to watermark insertion according to what is specified in Section 4 [49].

#### *6.2. Analysis*

The security analysis follows the scheme adopted in [22–24], and examines the behavior of the proposed watermarking protocol when corrupt entities make their strongest attacks [46,47,66,67]. Therefore, the analysis is restricted to two main attacks, which represent the two worst cases for security: (1) when CP is corrupt and tries to cheat B; (2) when B is corrupt and attempts to cheat CP. In both cases, according to what is reported in Sections 3 and 5, the analysis is conducted by assuming the presence of an honest-but-curious BC [55,68] and of a TTP RA.
