Confidential Smart Contracts and Blockchain to Implement a Watermarking Protocol

Abstract

Watermarking protocols represent a possible solution to the problem of digital copyright protection of content distributed on the Internet. Their implementations, however, continue to be a complex problem due to the difficulties researchers encounter in proposing secure, easy-to-use and, at the same time, “trusted third parties” (TTPs)-free solutions. In this regard, implementations based on blockchain and smart contracts are among the most advanced and promising, even if they are affected by problems regarding the performance and privacy of the information exchanged and processed by smart contracts and managed by blockchains. This paper presents a watermarking protocol implemented by smart contracts and blockchain. The protocol uses a “layer-2” blockchain execution model and performs the computation in “trusted execution environments” (TEEs). Therefore, its implementation can guarantee efficient and confidential execution without compromising ease of use or resorting to TTPs. The protocol and its implementation can, thus, be considered a valid answer to the “trilemma” that afflicts the use of blockchains, managing to guarantee decentralization, security, and scalability.

1. Introduction and Motivations

Digital copyright protection is one of the most pressing needs of the current Internet due to the economic losses it causes to companies that produce multimedia content. The enormous investments made in developing tools for protecting content distributed on the Internet are nullified mainly by the growing and rapid evolution of network and multimedia technologies through which it is possible to easily duplicate and distribute on the network originally protected content without reducing its perceived quality. Added to this problem is the more current one relating to the need to identify the creators of multimedia content present on the Internet so as to be able to distinguish such original content from that illegally created through the use of artificial intelligence.

Many of the solutions proposed to solve the problem of digital copyright are based on the use of “digital rights management” (DRM) systems [1,2,3], which try to limit the use of digital content only to those who have regularly purchased it. However, these systems cannot prevent legitimate purchasers of content from downloading and spreading it online, thus making the protection system ineffective.

On the other hand, content providers use watermarking protocols to discourage legitimate buyers of content from spreading it online [4]. These protocols implement digital copyright protection by exploiting the principle of deterrence. They are based on inserting a digital watermark in each document sold. The inserted watermark is imperceptible and represents a fingerprint uniquely linked to the seller of the content, the buyer, and the purchase transaction. The watermark thus ensures that the content represents a personalized and unique copy for the buyer. The protocol then defines the purchase transaction scheme capable of guaranteeing that only that buyer obtains his personalized copy of the purchased content. In this way, if such protected content is found in the possession of a user without the relative purchase title, it is possible to trace its legitimate buyer who has made an illegal sharing. The deterrent action, therefore, consists in the fact that the greater the sharing of protected content on the network, the greater the possibility that an illegally distributed copy will be found and allow its owner, the only one who can have done the initial sharing, to be punished.

Watermarking protocols developed in recent years mostly follow the “buyer-seller” scheme [4,5]. They try to guarantee the security of purchase transactions between buyers and sellers and the protection of digital copyright without having to resort to a “trusted third party” (TTP) and without having to request complex cryptographic actions from buyers. In this sense, an innovative solution is now represented by protocols based on blockchains and smart contracts [6]. Blockchains can be used in place of TTPs as distributed ledgers capable of publishing data on digital content purchase transactions, guaranteeing their immutability and verifiability [7,8]. Smart contracts, for their part, can be used to execute the code that defines the scheme of interactions envisaged by watermarking protocols. Also in this case, the code included in smart contracts, once published by the blockchain, becomes de facto immutable and is executed automatically when predefined conditions occur [9,10].

Although promising and able to satisfy the main requirements of use and security [4], watermarking protocols based on blockchains and smart contracts suffer from the main limitations exhibited by these technologies [11,12,13,14,15,16,17]. These limitations mainly concern the following:

• The poor performance in terms of the number of transactions that a blockchain can validate in the unit of time;
• The lack of confidentiality in the execution of smart contracts, which makes the input/output parameters, the state, and the code of smart contracts accessible to blockchain nodes;
• The impossibility of smart contracts to execute complex code due to the economic execution models implemented by blockchains.

Such limitations end up, in fact, making the use of blockchains and smart contracts in the implementation of watermarking protocols difficult and disadvantageous.

This paper presents an evolution of the watermarking protocol described in [18]. The new version was necessary to better adapt the protocol to an implementation that follows the “layer-2” blockchain-based execution scheme, in which the execution of smart contracts is separated from the achievement of consensus for the generated transactions [8,13,19,20]. In particular, the execution of smart contracts occurs “off-chain”, within “trusted execution environments” (TEEs), while the achievement of consensus is guaranteed by the blockchain, to which the results of the execution of smart contracts are sent in terms of transactions to be validated [19]. In this way, the off-chain execution of smart contracts within TEEs allows both to achieve the objective of confidentiality and to drastically reduce the execution costs, in terms of “gas”, to those related solely to the achievement of consensus, while increasing the number of transactions that can be validated in the unit of time [8,13,16,17,21].

2. Limitations of Smart Contracts and Blockchains

Smart contracts are increasingly used today in developing so-called decentralized applications (dApps) in finance, insurance, industry, and IoT, according to the “Blockchain 3.0” model [8]. They can contain Turing-complete code automatically executed on blockchains when pre-set conditions occur (see Figure 1). They are particularly useful for implementing protocols between distrusting parties since blockchains guarantee code immutability and integrity of execution through the consensus mechanism. However, the strengths of smart contracts bring several limitations in the implementation of watermarking protocols.

The first concerns the poor performance that generally characterizes a blockchain. A blockchain uses the consensus technique to establish the validity of the transactions registered in its public ledger. Such a peculiarity allows, on the one hand, the avoidance of using TTPs in watermarking protocols; on the other hand, it requires that the “miners” participating in the blockchain replicate entirely and independently the execution of smart contracts to reach consensus and validate individual transactions. Consequently, standard blockchains, such as Ethereum, can only guarantee a low number of validated transactions per unit of time (throughput), thus severely limiting their use in watermarking protocol implementation. Such protocols are called upon to generate protected and personalized copies of the contents distributed on the network at the time of their purchase [3]. This means that a low throughput of the blockchain translates into poor performance of the watermarking protocol, with consequent damage to content providers [11,12,14,15].

The second limitation concerns the lack of confidentiality in executing smart contracts. In fact, both the variables and the code of the contracts, as well as the related input/output and state information, are accessible to the processing nodes that execute the contracts. Such a condition makes it almost impossible to use smart contracts in the case of watermarking protocols, where data privacy is required, or it is necessary to implement applications in which the code and transaction data, if public, can be exposed to attacks from malicious users. This condition is quite realistic, especially in the case of public blockchains in which the participating nodes may not be trusted [13,16,17,19].

The third limitation concerns the impossibility of smart contracts to execute complex computations due to the need to keep the cost associated with executing the related code low. This limitation is made necessary by the economic model of execution of blockchains, which provides an incentive for nodes to execute a smart contract. The incentive represents a maximum cost of execution and is expressed in terms of a maximum number of “gas” units, for example, in the case of the Ethereum blockchain, multiplied by the current unit cost of each gas unit. Consequently, executing smart contracts that include complex cryptographic primitives, as frequently happens in the case of watermarking protocols, becomes expensive or not convenient for miners in the case of inadequate compensation [11,12,14,15,20].

3. Design Choices

The limitations reported in the previous section have pushed researchers to identify possible solutions for designing watermarking protocols that ensure adequate performance, scalability, confidentiality, and low execution costs of smart contracts on blockchains. In particular, the solution used to implement the watermarking protocol proposed in this article is based on the “layer-2” execution scheme, in which smart contracts are executed outside the blockchain [8,19]. In this scheme, the execution system is organized into two independent layers. The first is made up of an environment that is responsible for the execution of smart contracts only, while the second is made up of the blockchain that validates the results produced by the execution of smart contracts by reaching consensus on the generated transactions (see Figure 2). In this way, it is possible to use an execution environment that is specific for smart contracts and efficient and scalable, able to avoid both cost limits and the replication of the execution of smart contracts on all blockchain nodes. In addition, the fact that the execution of smart contracts is separated from the consensus reached by the blockchain nodes on the generated transactions allows the implementation of an execution environment capable of guaranteeing confidentiality for smart contracts. For this purpose, the proposed solution is based on Trusted Execution Environments (TEE)s [19]. A TEE can create a completely isolated execution environment on a processing node in which the operating system software or applications cannot interfere, corrupt, or even know the information related to the execution of a smart contract (see Figure 3). It thus represents a secure and private “enclave” in which the code execution is confined. In addition, a TEE can prove the correct execution of the code through specific attestations and without performance degradation compared to an execution outside the TEE.

4. The Execution Model

The proposed watermarking protocol is based on the confidential execution of smart contracts according to a layer-2 scheme, in which the blockchain is used solely to validate the transactions produced by the smart contracts [14,19] (see Figure 4). In this scheme, it is necessary to differentiate the processing nodes that are responsible for the execution of the smart contracts, and which must therefore be equipped with TEE, from the blockchain nodes, which instead act as simple “validators” of the generated transactions and which can be common processing nodes capable of executing the consensus algorithm implemented by the blockchain.

The execution model, therefore, provides for two types of entities: TEE nodes and validator nodes.

The former execute the contracts in the TEE and generate the appropriate attestations of correct execution and generation of results. The only requirement is that they can implement the TEE. Some of them are also expected to act as servers to manage the encryption keys used by the TEE nodes. In particular, these nodes implement specific distributed protocols for key management.

The latter are the blockchain nodes responsible for managing the public ledger and executing the implemented consensus algorithm. They are part of a public blockchain and validate the transactions generated by the execution of smart contracts.

The proposed protocol is then implemented by executing a smart contract. The contract is initially registered in the blockchain after some preliminary actions between the smart contract developer and one of the TEE nodes. These actions are necessary to guarantee the confidentiality of the execution of the contract. They are performed in the TEE and allow the following:

• Generation of the public-private key pair with which to encrypt the input/output parameters of the contract;
• Generation of the symmetric key with which to encrypt the state information produced by the execution of the contract;
• Generation of the attestation of the correct execution of the previous actions.

At the end of this phase, the smart contract is published on the blockchain, with the information necessary for the invocation, such as the public key associated with the contract.

To invoke the contract, users first retrieve from the blockchain the information needed to encrypt the parameters to be passed to the contract, such as the previously generated public key. They then invoke the contract by passing the invocation parameters encrypted with the public key. These parameters include, among others, the symmetric keys with which the contract can encrypt any output parameters to be returned to users.

The contract is then executed confidentially on one or more TEE nodes. At the end of the execution, the TEE nodes involved generate the results, status information, and attestations of correct execution. The formers are encrypted with the symmetric keys previously sent by the users, while the latter are encrypted with the symmetric key generated in the initial phase by the TEE node. Everything is passed to the blockchain, which publishes the information received once the validator nodes have reached consensus.

5. Basics Assumptions

The proposed watermarking protocol is based on the following assumptions.

First, the entities participating in the protocol and all communications among them are secured using a public key infrastructure (PKI) and Transport Layer Security (TLS).

Digital contents and watermarks are represented according to block diagrams of the type $X=\{x_1,x_2,\dots x_l\}$ and $W=\{w_1,w_2,\dots w_l\}$, respectively. The elements of W are binary values that usually represent fingerprinting anti-collusion codes [22,23,24].

Encryption and watermarking processes are represented by block-wise functions. As a consequence, the encryption E of a content $X=\{x_1,x_2\dots x_l\}$ under the key k can be calculated as

$$E_k\left(X\right)=E_k(x_1,x_2\dots x_l)=(E_k\left(x_1\right),E_k\left(x_2\right)\dots E_k\left(x_l\right))$$

Likewise, the insertion of the watermark W into the content can be calculated as

$$X\oplus W=\{x_1\oplus w_1,x_2\oplus w_2,\dots x_l\oplus w_l\}=\overline{X}$$

in which $\overline{X}$ is the watermarked content, and the symbol ⊕ represents the insert function [22].

Furthermore, $\mathbb{E}$ denotes an encryption function “homomorphic” with respect to the watermark insertion [25]. Therefore, the watermark can be directly inserted into the encrypted domain according to the following formula [26]:

$${\mathbb{E}}_k(X\oplus W)={\mathbb{E}}_k\left(X\right)\oplus {\mathbb{E}}_k\left(W\right)={\mathbb{E}}_k\left(\overline{X}\right)$$

In particular, the function $\mathbb{E}$ has to be “probabilistic” and “semantically secure”. This means that the knowledge of a ciphertext does not provide any useful information on the plaintext to an adversary having only a reasonably restricted computational power represented by polynomial resources. Furthermore, $\mathbb{E}$ can be limited to homomorphic encryption schemes that support addition or multiplication since such operations are functionally complete sets over finite sets and are sufficient to implement the most common and safe watermarking algorithms [25]. Therefore, if x is an element of X and w is an element of W, the multiplicatively homomorphic encryption schemes ensure that [27]

$${\mathbb{E}}_k(x·w)={\mathbb{E}}_k\left(x\right)·{\mathbb{E}}_k\left(w\right)$$

whereas the additively homomorphic encryption schemes ensure that [28,29]

$${\mathbb{E}}_k(x+w)={\mathbb{E}}_k\left(x\right)·{\mathbb{E}}_k\left(w\right)$$

Finally, nodes that execute smart contracts must provide a CPU-based implementation of the TEE, such as the one provided by INTEL Software Guard eXtensions (SGX) [30,31,32]. This implementation must guarantee the confidentiality and integrity of the computation performed and must also be able to provide proof, in the form of attestations, of its correctness. To this end, following the example of the INTEL SGX system, a TEE node must generate an attestation each time it executes a smart contract. Then, the TEE node obtains proof of the validity of the attestation by contacting a specific service, such as the INTEL Attestation Service (IAS). The IAS receives the attestation and verifies it. If the attestation received is considered valid, the IAS returns a certification $\Pi$ consisting of the attestation itself digitally signed by the IAS.

6. The Protocol

The proposed watermarking protocol is of the “buyer-seller” type and is based on a “buyer-friendly” approach [4]. It is implemented by a smart contract executed by TEE nodes. The execution result is then validated by the blockchain nodes (miners) according to the layer-2 scheme described in Section 4. In particular, the execution of the smart contract consists of two phases.

In the first phase, the smart contract is activated by the content provider and the buyer and generates the tokens needed to start inserting the watermark into the content to be protected. This phase ends with publishing a series of information preparatory to activating the next phase. All information is exchanged and published in encrypted form to guarantee complete confidentiality.

In the second phase, the smart contract generates the final information constituting the content purchase license published in the blockchain ledger. This phase can be activated only if the information sent as input to the smart contract by the buyer and the content provider is consistent with that published previously, downstream of the first phase.

The proposed protocol does not employ any TTP and, thanks to the layer-2 execution scheme, executes the smart contract entirely “off-chain”, within the enclave provided by the TEE. It can be described at a high level as follows: (1) the protocol is implemented by a smart contract that is published by a blockchain ($\mathcal{BC}$); (2) the protocol can be used by any seller or content provider ($\mathcal{CP}$) who wishes to protect its content distributed on the web; (3) by activating the smart contract, $\mathcal{CP}$ and the buyer ($\mathcal{B}$) enable the execution of the watermarking protocol, after which the purchased content is released in encrypted form and protected by the watermark; (4) $\mathcal{B}$, at the end of the execution of the smart contract, decrypts the received content, obtaining its version with the customized protection; (5) the smart contract takes care of generating all the tokens and information needed to protect the content without resorting to TTP; (6) $\mathcal{CP}$s are able, once they have found a suspicious copy of their content sold on the Internet, to trace it back to the original purchaser and establish whether there has been illicit distribution.

The proposed protocol comprises the protection protocol and the identification and arbitration protocol.

Table 1. Symbols used in the protocol.

Symbols	Meaning
$\mathcal{B}$	buyer
$\mathcal{CP}$	content provider or seller
$\mathcal{BC}$	blockchain
$\mathcal{CN}$	computation node equipped with TEE
${\mathcal{CN}}_{TE{E}_{D\left|1\right|2}}$	$\mathcal{CN}$ executes in TEE the deployment, first or second phase of the smart contract
$COD{E}_{sc}$	code of the smart contract $sc$
$KMS$	key management server
X	digital content purchased by $\mathcal{B}$
$X_d$	information used by $\mathcal{CP}$ to unambiguously identify X
$T_X$	timestamp referred to the transaction by which $\mathcal{B}$ buys X
$B_{id}$	information used to identify $\mathcal{B}$
$c_{id}$	smart contract identifier
$i{n}_{cid}$	initial state of the smart contract
N	nonce used to mark the watermarking transaction
W	watermark
$W_{Ent.}$	part of the watermark W generated by the entity $Ent.$
$\overline{X}$	watermarked X
$p{k}_{id}$	public key referred to $id$
$s{k}_{id}$	secret key referred to $id$
$p{k}^X$	one-time public key used to watermark X
$s{k}^X$	one-time secret key used to watermark X
$K_{c_{id}}^{st}$	symmetric key used by the contract indicated by $c_{id}$ to encrypt state information
$K_{Ent.}^X$	symmetric key of the entity $Ent.$ used in the transaction to watermark X
$E_{key}(\dots )$	token encrypted with the key $key$
$H(\dots )$	hash function
$\Pi$	certification of correct execution attestation in TEE
$\sigma \left(X\right)$	payment specification to purchase X
${\mathbb{E}}_{key}(\dots )$	token encrypted with the key $key$ and using a privacy homomorphic cryptosystem with respect to the watermark insertion
${\mathbb{D}}_{key}(\dots )$	decryption function inverse of the function ${\mathbb{E}}_{key}(\dots )$

defines the symbols used to describe the protocol.

6.1. The Protection Protocol

The protection protocol consists of a preliminary phase through which the smart contract that implements the protocol is deployed on $\mathcal{BC}$. The deployment can be performed by $\mathcal{CP}$ and makes the smart contract code immutable and public so that anyone can evaluate its correctness and the level of security offered. This phase makes the contract available for subsequent invocations through which the watermarking protocol is executed to protect the contents distributed by $\mathcal{CP}$.

6.1.1. Deployment

The deployment phase, whose scheme is shown in

Table 2. Deployment phase.

Entities and Interactions	Actions and Messages
$\mathcal{CP}\stackrel{m_1}{\to }\mathcal{CN}$	:	$m_1=\left\{COD{E}_{sc}\right\}$
${\mathcal{CN}}_{TE{E}_D}\stackrel{m_2}{\to }\mathcal{KMS}$	:	$m_2=\left\{c_{id}\right\}$
$\mathcal{KMS}\stackrel{m_3}{\to }{\mathcal{CN}}_{TE{E}_D}$	:	$m_3=\{p{k}_{c_{id}},s{k}_{c_{id}},K_{c_{id}}^{st}\}$
${\mathcal{CN}}_{TE{E}_D}$	:	generates $i{n}_{c_{id}}$ and obtains $\Pi \left[AttD[c_{id},p{k}_{c_{id}}]\right]$
${\mathcal{CN}}_{TE{E}_D}\stackrel{m_4}{\to }\mathcal{BC}$	:	$m_4=\{c_{id},COD{E}_{sc},E_{K_{c_{id}}^{st}}\left(i{n}_{c_{id}}\right),\Pi \left[AttD[c_{id},p{k}_{c_{id}}]\right],p{k}_{c_{id}}\}$
$\mathcal{BC}$	:	publishes $c_{id}$, $COD{E}_{sc}$, $E_{K_{c_{id}}^{st}}\left(i{n}_{c_{id}}\right)$, $\Pi \left[AttD[c_{id},p{k}_{c_{id}}]\right]$, $p{k}_{c_{id}}$

, starts with $\mathcal{CP}$ contacting one of the computation nodes equipped with TEE ($\mathcal{CN}$). This node is part of the computation structure and is responsible for executing off-chain the smart contract that implements the watermarking protocol. The structure must be composed of computation nodes, all equipped with TEE. Some of these nodes exclusively perform the functions of servers to manage the keys necessary for the confidential execution of the smart contract (see Figure 4). The nodes, similarly to those of a public blockchain, participate voluntarily and are remunerated during the execution phase of the smart contract. It is important to note that it is possible to carry out multiple deployments of the smart contract on the blockchain. This makes it possible to have multiple concurrent executions of the same copy of the smart contract, thus increasing the number of purchase transactions in the unit of time depending on the available TEE nodes.

$\mathcal{CP}$ initially sends the contract code $COD{E}_{sc}$ to a $\mathcal{CN}$ in message $m_1$, which loads it into its secure enclave. $\mathcal{CN}$ then creates the contract identifier $c_{id}$ and sends it to one of the TEE nodes that manage the encryption keys, indicated by $KMS$, in the message $m_2$. This node generates three keys: a first public-private key pair ($p{k}_{c_{id}}$, $s{k}_{c_{id}}$) to be used to exchange encrypted data with the contract when it is executed in the TEE; and a secret key $K_{c_{id}}^{st}$ used by the contract to encode the state information generated by the execution.

Upon receiving the keys in message $m_3$, $\mathcal{CN}$ generates the initial state $i{n}_{c_{id}}$ associated with the contract and encrypts it, creating the token $E_{K_{c_{id}}^{st}}\left(i{n}_{c_{id}}\right)$. Then, $\mathcal{CN}$ generates an attestation, denoted by $AttD[c_{id},p{k}_{c_{id}}]$, that proves both the correct initialization of the contract and the association of the public key $p{k}_{c_{id}}$ to the contract.

At this point, $\mathcal{CN}$ obtains a proof of correctness of $AttD[c_{id},p{k}_{c_{id}}]$ by contacting a specific official attestation service, such as the Intel Attestation Service (IAS) for SGX-based TEE systems, which performs the $AttD$ verification and returns a digitally signed certification of correct execution attestation in TEE, denoted by $\Pi \left[AttD[c_{id},p{k}_{c_{id}}]\right]$.

The deployment phase ends with $\mathcal{CN}$ sending message $m_4$ and obtaining the publication on $\mathcal{BC}$ of the contract, together with the $c_{id}$, its initial encrypted state $E_{K_{c_{id}}^{st}}\left(i{n}_{c_{id}}\right)$, the certification of the correct execution of the deployment $\Pi \left[AttD[c_{id},p{k}_{c_{id}}]\right]$, and the public key $p{k}_{c_{id}}$ associated with the contract.

6.1.2. Protection

This phase, whose scheme is shown in

Table 3. Protection protocol.

Entities and Interactions	Actions and Messages
$\mathcal{B}\stackrel{m_1}{\to }\mathcal{CP}$	:	$m_1=\{$request for $X,B_{id}\}$
$\mathcal{CP}\stackrel{m_2}{\to }\mathcal{CN}$	:	$m_2=\{c_{id},E_{p{k}_{c_{id}}}(B_{id},X_d,T_X,K_{\mathcal{CP}}^X,\sigma (X))\}$
$\mathcal{CP}\stackrel{m_3}{\to }\mathcal{B}$	:	$m_3=\{\mathcal{CN},X_d,T_X,c_{id},p{k}_{c_{id}}\}$
$\mathcal{B}\stackrel{m_4}{\to }\mathcal{CN}$	:	$m_4=\{c_{id},E_{p{k}_{c_{id}}}(B_{id},X_d,T_X,K_{\mathcal{B}}^X)\}$
${\mathcal{CN}}_{TE{E}_1}$	:	starts the execution in TEE of the smart contract identified by $c_{id}$ and fetches from $\mathcal{BC}$ the contract code and $E_{K_{c_{id}}^{st}}(i{n}_{c_{id}})$, $\Pi [AttD]$ and $p{k}_{c_{id}}$
${\mathcal{CN}}_{TE{E}_1}\stackrel{m_5}{\to }KMS$	:	request for keys
$KMS\stackrel{m_6}{\to }{\mathcal{CN}}_{TE{E}_1}$	:	$m_6=\{K_{c_{id}}^{st},s{k}_{c_{id}}\}$
${\mathcal{CN}}_{TE{E}_1}$	:	generates $p{k}^X,s{k}^X,N,{\mathbb{E}}_{p{k}^X}(N)$
${\mathcal{CN}}_{TE{E}_1}$	:	generates $Block=[B_{id},X_d,T_X,p{k}^X,s{k}^X,N,{\mathbb{E}}_{p{k}^X}(N),K_{\mathcal{B}}^X,K_{\mathcal{CP}}^X]$
${\mathcal{CN}}_{TE{E}_1}$	:	generates $E_{K_{c_{id}}^{st}}(Block)$, $H(Block)$, and obtains $\Pi [Att1]$
${\mathcal{CN}}_{TE{E}_1}$	:	publishes $T_X$, $E_{K_{c_{id}}^{st}}(Block)$, $H(Block)$, $\Pi [Att1]$
${\mathcal{CN}}_{TE{E}_1}\stackrel{m_7}{\to }\mathcal{CP}$	:	$m_7=\{E_{K_{\mathcal{CP}}^X}(T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}(N),H(Block))\}$
${\mathcal{CN}}_{TE{E}_1}\stackrel{m_8}{\to }\mathcal{B}$	:	$m_8=\{E_{K_{\mathcal{B}}^X}(T_X,H(Block))\}$
$\mathcal{CP}$	:	generates $W_{\mathcal{CP}},{\mathbb{E}}_{p{k}^X}(W_{\mathcal{CP}}),{\mathbb{E}}_{p{k}^X}(X)$
$\mathcal{CP}$	:	generates ${\mathbb{E}}_{p{k}^X}(W)={\mathbb{E}}_{p{k}^X}(W_{\mathcal{CP}},N)={\mathbb{E}}_{p{k}^X}(W_{\mathcal{CP}}),{\mathbb{E}}_{p{k}^X}(N)$
$\mathcal{CP}$	:	generates $\overline{{\mathbb{E}}_{p{k}^X}(X)}={\mathbb{E}}_{p{k}^X}(X)\oplus {\mathbb{E}}_{p{k}^X}(W)$
$\mathcal{CP}\stackrel{m_9}{\to }\mathcal{B}$	:	$m_9=\{\overline{{\mathbb{E}}_{p{k}^X}(X)}\}$
$\mathcal{CP}\stackrel{m_{10}}{\to }{\mathcal{CN}}_{TE{E}_2}$	:	$m_{10}=\{c_{id},B_{id},T_X,E_{K_{\mathcal{CP}}^X}(T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}(N),H(Block))\}$
$\mathcal{CP}$	:	saves $B_{id}$, $X_d$, $T_X$, $p{k}^X$, ${\mathbb{E}}_{p{k}^X}(N)$, and $K_{\mathcal{CP}}^X$ in its database, associating $W_{\mathcal{CP}}$ as the lookup key
$\mathcal{B}\stackrel{m_{11}}{\to }{\mathcal{CN}}_{TE{E}_2}$	:	$m_{11}=\{c_{id},B_{id},T_X,E_{K_{\mathcal{B}}^X}(T_X,H(Block))\}$
${\mathcal{CN}}_{TE{E}_2}$	:	accesses $\mathcal{BC}$ and fetches $E_{K_{c_{id}}^{st}}(Block)$ and $H(Block)$
${\mathcal{CN}}_{TE{E}_2}$	:	compares tokens with those received in $m_{10}$ and $m_{11}$
${\mathcal{CN}}_{TE{E}_2}$	:	publishes the purchase license represented by
	:	$X_d$, $T_X$, $H(B_{id},X_d,T_X,p{k}^X,K_{\mathcal{CP}}^X,{\mathbb{E}}_{p{k}^X}(N),N)$
${\mathcal{CN}}_{TE{E}_2}\stackrel{m_{12}}{\to }\mathcal{B}$	:	$m_{12}=\{s{k}^X\}$
$\mathcal{B}$	:	$\overline{X}={\mathbb{D}}_{s{k}^X}(\overline{{\mathbb{E}}_{p{k}^X}(X)})$

, starts when $\mathcal{B}$ requests the purchase of content X from $\mathcal{CP}$ in message $m_1$, also sending its unique identifier $B_{id}$. In particular, $B_{id}$ can be a personal digital certificate, an anonymous digital certificate, a credit card reference, or any other document that can refer to $\mathcal{B}$ unambiguously [18].

$\mathcal{CP}$ generates a unique descriptor of X, denoted by $X_d$, and a timestamp $T_X$ needed to identify the ongoing transaction. Then, $\mathcal{CP}$ generates a secret key $K_{\mathcal{CP}}^X$ to be used only in this transaction, which must be used by the smart contract to encrypt the output data to be returned to $\mathcal{CP}$. $\mathcal{CP}$ also reads from $\mathcal{BC}$ the identifier $c_{id}$ and the corresponding public key $p{k}_{c_{id}}$ relating to the previously deployed contract that implements the watermarking protocol. Finally, $\mathcal{CP}$ chooses one or more TEE nodes to which to delegate the execution of the contract. Assuming, for simplicity, that the contract is executed by a single TEE node, indicated by $\mathcal{CN}$, $\mathcal{CP}$ sends it the message $m_2$, which contains two tokens: the $c_{id}$ and the set of $B_{id}$, $X_d$, $T_X$, $K_{\mathcal{CP}}^X$, and the payment specification $\sigma \left(X\right)$, all encrypted with the contract’s public key $p{k}_{c_{id}}$. In particular, the specification $\sigma \left(X\right)$ allows $\mathcal{CN}$ to be remunerated for the execution activity performed. $\mathcal{CP}$ then sends the reference of $\mathcal{CN}$, $X_d$, $T_X$, $c_{id}$, and $p{k}_{c_{id}}$ to $\mathcal{B}$ in message $m_3$.

Similarly to $\mathcal{CP}$, $\mathcal{B}$ generates its secret key $K_{\mathcal{B}}^X$ to be used only in this transaction and needed to receive the encrypted output data of the smart contract. Then, $\mathcal{B}$ encrypts $B_{id}$, $X_d$, $T_X$, and $K_{\mathcal{B}}^X$ with the key $p{k}_{c_{id}}$, and sends the encrypted token and $c_{id}$ to $\mathcal{CN}$ in message $m_4$.

Once messages $m_2$ and $m_4$ are received, $\mathcal{CN}$ starts the execution in TEE of the contract identified by $c_{id}$. $\mathcal{CN}$ fetches the contract from $\mathcal{BC}$, together with the associated information $E_{K_{c_{id}}^{st}}\left(i{n}_{c_{id}}\right)$, $\Pi \left[AttD[c_{id},p{k}_{c_{id}}]\right]$, and $p{k}_{c_{id}}$, and loads them into its TEE. $\mathcal{CN}$ sends message $m_5$ to $KMS$. Then, $\mathcal{CN}$ receives in response message $m_6$, which contains the keys $K_{c_{id}}^{st}$ and $s{k}_{c_{id}}$, which can be used to decrypt the current state and the information received as input related to the contract.

$\mathcal{CN}$, once decrypted, checks the consistency of the information contained in messages $m_2$ and $m_4$. If the check is passed, $\mathcal{CN}$ continues the execution of the contract in its secure enclave. $\mathcal{CN}$ generates three tokens: (1) a public-private key pair ($p{k}^X$, $s{k}^X$) to be used exclusively in the current transaction; (2) a “nonce” N consisting of a binary string; and (3) the token ${\mathbb{E}}_{p{k}^X}\left(N\right)$ obtained by encrypting N with $p{k}^X$ and a “privacy homomorphic” cryptosystem with respect to the watermarking algorithm used.

At this point, $\mathcal{CN}$ generates the block

$$Block=[B_{id},X_d,T_X,p{k}^X,s{k}^X,N,{\mathbb{E}}_{p{k}^X}\left(N\right),K_{\mathcal{B}}^X,K_{\mathcal{CP}}^X]$$

and encrypts it with the key $K_{c_{id}}^{st}$, generating $E_{K_{c_{id}}^{st}}\left(Block\right)$. Then, $\mathcal{CN}$ calculates the digest of $Block$, denoted by $H\left(Block\right)$, and obtains the certification of the correct execution of this first computational phase, denoted by $\Pi \left[Att1\right]$.

$\mathcal{CN}$ concludes this phase by publishing on $\mathcal{BC}$ the information generated and represented by $T_X$, $E_{K_{c_{id}}^{st}}\left(Block\right)$, $H\left(Block\right)$, and $\Pi \left[Att1\right]$. Then, $\mathcal{CN}$ sends two messages, $m_7$ and $m_8$, to $\mathcal{CP}$ and $\mathcal{B}$, respectively. In the first one it includes the tokens $T_X$, $p{k}^X$, ${\mathbb{E}}_{p{k}^X}\left(N\right)$, $H\left(Block\right)$ encrypted with the symmetric key $K_{\mathcal{CP}}^X$ of $\mathcal{CP}$; in the second one it includes the tokens $T_X$ and $H\left(Block\right)$ encrypted with the symmetric key $K_{\mathcal{B}}^X$ of $\mathcal{B}$. In this way, $\mathcal{CP}$ and $\mathcal{B}$ obtain the output information generated by executing this first phase of the contract in confidential form.

$\mathcal{CP}$ receives in $m_7$ the information needed to create the customized protection of X to be associated with $\mathcal{B}$ and the current transaction. For this purpose, $\mathcal{CP}$ generates the watermark $W_{\mathcal{CP}}$, which consists of the union of an anti-collusion code and an error-correcting code needed to correct any errors that may occur while extracting the watermark from X. Then, $\mathcal{CP}$ encrypts X and $W_{\mathcal{CP}}$ with the key $p{k}^X$ and with the same homomorphic encryption system used to obtain ${\mathbb{E}}_{p{k}^X}\left(N\right)$. Once the tokens ${\mathbb{E}}_{p{k}^X}\left(X\right)$ and ${\mathbb{E}}_{p{k}^X}\left(W_{\mathcal{CP}}\right)$ have been generated, $\mathcal{CP}$ can proceed to insert the watermark directly into the encrypted domain as indicated in the previous Section 5. In particular, the watermark W to be inserted is given by the union of the two binary strings $W_{\mathcal{CP}}$ and N and can be represented with $W=(W_{\mathcal{CP}},N)$, according to a block diagram. Therefore,

$${\mathbb{E}}_{p{k}^X}\left(W\right)={\mathbb{E}}_{p{k}^X}(W_{\mathcal{CP}},N)={\mathbb{E}}_{p{k}^X}\left(W_{\mathcal{CP}}\right),{\mathbb{E}}_{p{k}^X}\left(N\right)$$

The insertion of W into X is done according to the following expression:

$$\overline{{\mathbb{E}}_{p{k}^X}\left(X\right)}={\mathbb{E}}_{p{k}^X}\left(\overline{X}\right)={\mathbb{E}}_{p{k}^X}(X\oplus W)={\mathbb{E}}_{p{k}^X}\left(X\right)\oplus {\mathbb{E}}_{p{k}^X}\left(W\right)$$

$\mathcal{CP}$ sends the encrypted and protected content $\overline{{\mathbb{E}}_{p{k}^X}\left(X\right)}$ to $\mathcal{B}$ in message $m_9$. Then, $\mathcal{CP}$ starts the second phase of contract execution by sending message $m_{10}$ to $\mathcal{CN}$, which includes $c_{id}$, $B_{id}$, $T_X$, and the encrypted token $E_{K_{\mathcal{CP}}^X}(T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}\left(N\right),H\left(Block\right))$. After sending the message, $\mathcal{CP}$ saves the tokens $B_{id}$, $X_d$, $T_X$, $p{k}^X$, ${\mathbb{E}}_{p{k}^X}\left(N\right)$, and $K_{\mathcal{CP}}^X$ in its database, associating $W_{\mathcal{CP}}$ as the lookup key.

Also $\mathcal{B}$, after receiving the message $m_9$, sends to $\mathcal{CN}$ the message $m_{11}$, which contains $c_{id}$, $B_{id}$, $T_X$, and the encrypted token $E_{K_{\mathcal{B}}^X}(T_X,H\left(Block\right))$.

Once messages $m_{10}$ and $m_{11}$ are received, $\mathcal{CN}$ starts the execution of the contract in its TEE. It accesses $\mathcal{BC}$ with the $c_{id}$ and $T_X$ related to the ongoing transaction and collects the tokens $E_{K_{c_{id}}^{st}}\left(Block\right)$ and $H\left(Block\right)$. Then, $\mathcal{CN}$ extracts the information contained in $Block$ and compares it with that received in messages $m_{10}$ and $m_{11}$. If the information matches, $\mathcal{CN}$ will allow the completion of the payment phase and publish the final license for the purchase of content X by $\mathcal{B}$ on $\mathcal{BC}$. This license is represented by the tokens $X_d$ and $T_X$, and the digest $H(B_{id},X_d,T_X,p{k}^X,K_{\mathcal{CP}}^X,{\mathbb{E}}_{p{k}^X}\left(N\right),N)$. Finally, $\mathcal{CN}$ obtains a proof of correctness of $Att2$ by contacting IAS and sends the private key $s{k}^X$ to $\mathcal{B}$ so as to enable the decryption of $\overline{{\mathbb{E}}_{p{k}^X}\left(X\right)}$ and the consequent generation of the personalized content $\overline{X}$ according to the following expression:

$$\overline{{\mathbb{E}}_{p{k}^X}\left(X\right)}={\mathbb{E}}_{p{k}^X}\left(\overline{X}\right),\overline{X}={\mathbb{D}}_{s{k}^X}\left(\overline{{\mathbb{E}}_{p{k}^X}\left(X\right)}\right)$$

6.1.3. The Identification and Arbitration Protocol

This protocol can be executed by $\mathcal{CP}$ whenever it detects a copy of its content X suspected of having been illegally distributed on the Internet (see

Table 4. Identification and arbitration protocol.

Entities and Interactions	Actions and Messages
$\mathcal{CP}$	:	finds $X^{\prime }$ in the market and extracts $W^{\prime }=(W_{\mathcal{CP}}^{\prime },N^{\prime })$
$\mathcal{CP}$	:	searches its databases for a possible match on $W_{\mathcal{CP}}^{\prime }$
$\mathcal{CP}$	:	retrieves $B_{id}$, $X_d$, $T_X$, $p{k}^X$, ${\mathbb{E}}_{p{k}^X}\left(N\right)$, and $K_{\mathcal{CP}}^X$ from its databases
$\mathcal{CP}$	:	calculates $H^{\prime }(B_{id},X_d,T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}\left(N\right),K_{\mathcal{CP}}^X,N^{\prime })$
$\mathcal{CP}$	:	retrieves from $\mathcal{BC}$ the digest corresponding to $T_X$,
	:	equal to $H(B_{id},X_d,T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}\left(N\right),K_{\mathcal{CP}}^X,N)$
$\mathcal{CP}$	:	compares H with $H^{\prime }$ and adjudicates

). In this way, $\mathcal{CP}$ can identify, with statistical certainty, the legitimate purchaser of X who has illegally distributed the purchased copy.

$\mathcal{CP}$ extracts the watermark $W^{\prime }=(W_{\mathcal{CP}}^{\prime },N^{\prime })$ from the suspicious copy, indicated by $X^{\prime }$. It uses $W_{\mathcal{CP}}^{\prime }$ as a search key and, if it finds a match [33], it obtains the corresponding tokens $B_{id}$, $X_d$, $T_X$, $p{k}^X$, ${\mathbb{E}}_{p{k}^X}\left(N\right)$, and $K_{\mathcal{CP}}^X$. At this point, $\mathcal{CP}$ calculates the digest $H^{\prime }(B_{id},X_d,T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}\left(N\right),K_{\mathcal{CP}}^X,N^{\prime })$ and accesses $\mathcal{BC}$ to obtain the digest corresponding to the transaction $T_X$, equal to $H(B_{id},X_d,T_X,p{k}^X,{\mathbb{E}}_{p{k}^X}\left(N\right),K_{\mathcal{CP}}^X,N)$. If the two digests coincide, then it turns out that $N==N^{\prime }$ and that $\mathcal{B}$, identified through his reference $B_{id}$, can be considered guilty of having illicitly distributed his regularly purchased copy.

7. Security Analysis

Analyzing the security of the proposed protocol is very difficult due to the many components used. However, leaving aside the most common ones, such as the TLS protocol for communications, the symmetric or public-key encryption algorithms considered “semantically secure”, or the common PKI based on digital certificates, it is evident that the level of security that the protocol can achieve depends directly on three basic components that enable its implementation: the watermark insertion technique, the CPU-based implementation of the TEE, and the key management system used by the smart contracts. In the following, their impact on the protocol’s security is preliminarily discussed.

7.1. Basic Components and Their Impact on Security

The first component that directly influences the level of security the protocol can reach is represented by the watermark insertion technique. In fact, $\mathcal{CP}$’s ability to identify a dishonest buyer depends on the ability of the watermark inserted in the content to resist both attacks by malicious users and manipulations conducted legitimately by the buyer himself. In this regard, it is possible to hypothesize the use of sufficiently secure and robust watermark insertion techniques, for which the removal, even partial, of the watermark determines an evident degradation of the perceived quality of the protected content, so much so as to render it substantially devoid of economic value. Insertion techniques with such characteristics are those, for example, based on ”spread spectrum” (SS) algorithms or based on “quantization index modulation” (QIM), which have shown overall positive results [22,34,35].

Another critical component for the security of the proposed protocol is represented by the CPU-based implementation of the TEE, which, as reported in Section 5, must guarantee confidentiality, integrity, and proof of correctness in the form of attestations of the computation performed. In this regard, it is important to note that current implementations of the TEE, such as that provided by INTEL SGX [31], are characterized by several security problems [19,30,32].

For example, the first problem is represented by the possibility of a malicious $\mathcal{CN}$ to interrupt the execution in TEE of the smart contract that implements the proposed protocol. In this case, the purchase transaction in progress is canceled and must be repeated. This is because the protocol considers transactions to have no internal state. They are complete only with publishing the final purchase license on the blockchain. Such a condition may seem penalizing from the point of view of the protocol’s efficiency because it does not allow recovery actions. On the other hand, it constitutes a valid security countermeasure because it prevents the malicious acquisition of information relating to the interrupted transition.

Other problems may arise from the manipulation of I/O operations through which data is transferred to and from the TEE’s enclave. In fact, the exchanged information could be acquired or modified illegally by the processes running on $\mathcal{CN}$. However, even in this case, the protocol is not vulnerable because all data entering or leaving the enclave are always encrypted, and their freshness is ensured by the transaction identifiers managed by the protocol.

In addition, several security problems caused by side-channel attacks are documented in the literature. These are specific problems caused by malicious users who try to manipulate the data managed by the TEE. However, it is impossible to identify generalized solutions for these problems, but ad hoc solutions are needed, mostly based on using cryptographic primitives.

In reality, it is necessary to observe that the proposed protocol can correctly complete a content purchase transaction in the presence of at least one honest $\mathcal{CN}$. In this hypothesis, the validator nodes can certify the correct execution of the transaction by executing a specific algorithm usually present in the “layer-2” execution models (see Section 4 and Figure 4). Such an algorithm is executed before reaching consensus in the blockchain and allows comparing the results of the $\mathcal{CN}$s’ executions in order to identify any malicious behavior [12,14,36]. In fact, the presence of at least one honest $\mathcal{CN}$ allows validator nodes to highlight discrepancies in the different executions and thus to identify the correct execution. However, to minimize the risk of incorrect executions by $\mathcal{CN}$s, two useful measures can be adopted.

The first is based on implementing an economic model that incentivises honest $\mathcal{CN}$s and imposes penalties on malicious ones. In this way, the participation of malicious $\mathcal{CN}$s would be discouraged or make them less numerous than honest ones. Such a condition would make it easy to produce correct transactions and identify incorrect ones, thus eliminating malicious $\mathcal{CN}$s from the pool of those available to execute the protocol.

The second provides a “permissioned” approach for $\mathcal{CN}$s, which can join the protocol execution pool only after their honesty has been assessed. In this case, the risks of possible attacks on the TEE’s enclave would be drastically reduced, even if this approach is more restrictive than the “permissionless” one used for blockchain nodes.

As it appears from the considerations reported so far, the proposed protocol still manages to be immune to attacks on the TEE’s enclave, although the proposed measures can improve its execution and mitigate the consequences of the attacks. Moreover, despite the large attack surfaces, TEEs are still considered the basis for confidential executions in secure enclaves [19,30,32], and several important companies, such as INTEL and AMD, are investing in this area. Therefore, the next proposed implementations will likely be characterized by increasingly limited attack surfaces, so as to make such implementations substantially secure [17,31,32].

The last critical component is represented by the system of servers responsible for managing the keys used by the smart contract that implements the proposed protocol. By virtue of the importance of the function performed, these servers should be correctly managed $\mathcal{CN}$s with a good reputation. However, the protocol is not based on specific assumptions, and only assumes that the servers implement the protocol described in [14], or at least an equivalent one, so as to satisfy the security, confidentiality, and availability requirements that enable the watermarking protocol to be executed in a secure manner.

7.2. Assumptions

Limiting the analysis to the watermarking protocol only and based on what is reported above, it is possible to assume the following description:

• $\mathcal{CP}$ sells X to $\mathcal{B}$;
• $\mathcal{BC}$ implements the ledger that publishes the smart contract responsible for executing the watermarking protocol;
• $\mathcal{CN}$ is a computation node equipped with TEE in whose enclave it executes the smart contract that implements the off-chain protocol in confidential form;
• The results of the execution of the protocol are published in encrypted form on $\mathcal{BC}$;
• $\mathcal{CP}$ can autonomously ascertain whether $\mathcal{B}$ has illegally distributed the copy received with his/her personalized protection.

Furthermore, the entities participating in the protocol are assumed to have the following behavior:

• $\mathcal{B}$ and $\mathcal{CP}$ do not distribute pirated copies of the contents in their possession when they are not corrupted;
• $\mathcal{BC}$ is considered an “honest-but-curious” entity [37] whose nodes (miners), while being able to access some of the information managed by the protocol, are still forced to follow the rules set by the protocol in accordance with the concept of a public blockchain;
• $\mathcal{CN}$, when executing the smart contract in its TEE, guarantees correctness, integrity, and confidentiality, and it is supposed to be incorruptible;
• $KMS$ correctly executes the key management protocol in its TEE without compromising the keys;
• $\mathcal{CP}$ and $\mathcal{B}$ can be corrupted only “statically”, i.e., deciding which of the two entities is corrupt is made before running the protocol and can no longer be changed [37].

Consistent with what has been reported and in the absence of corrupt entities, the protocol allows $\mathcal{B}$ to receive from $\mathcal{CP}$ the chosen content X protected by the insertion of a personalized watermark. Once extracted from a copy of X, the watermark allows the link of the content to the legitimate purchaser, the content provider, and the purchase transaction, thus carrying out a deterrent action against the illegal sharing of content on the network.

If $\mathcal{B}$ or $\mathcal{CP}$ are corrupted, the protocol can always take appropriate countermeasures. In particular, if $\mathcal{B}$ is corrupted, the protocol aborts the ongoing transaction, preventing the release of the content X requested by $\mathcal{B}$. On the contrary, if $\mathcal{CP}$ is corrupted, then the content X is released to $\mathcal{B}$ incorrectly protected by inserting a watermark that is not correctly linked to $\mathcal{B}$. The result is as if X had been released without being protected, and this damages $\mathcal{CP}$ itself.

Starting from what has been exposed so far, a brief series of considerations on the security of the protocol are reported below. A specific protocol analysis was conducted using the AVISPA tool (Automated Validation of Internet Security Protocols and Applications) [38]. This analysis, which is not reported here for brevity, highlighted how the tool failed to document successful attacks.

7.3. Analysis

The security analysis of the protocol can be conducted by mainly focusing on the specific functions performed by the smart contract and the blockchain, leaving aside the contract deployment phase, the outcome of which can be verified directly by $\mathcal{CP}$ by accessing the information published on $\mathcal{BC}$.

As reported in Section 6, the smart contract is executed by $\mathcal{CN}$ in two phases.

In the first phase of contract execution, schematized in Figure 5, $\mathcal{CN}$ receives from $\mathcal{CP}$ and $\mathcal{B}$ in $m_2$ and $m_4$ the preliminary encrypted information relating to the transaction by which $\mathcal{B}$ wishes to purchase X from $\mathcal{CP}$. $\mathcal{CN}$ performs the first check and, if the received tokens are consistent, continues the execution of the contract, generating all the information and tokens necessary to protect X correctly. Then, $\mathcal{CN}$ publishes on $\mathcal{BC}$ two tokens, among others, $E_{K_{c_{id}}^{st}}\left(Block\right)$ and $H\left(Block\right)$: the first contains the encrypted information to be used for the protection of X and also represents the current state reached by the execution of the smart contract; the second represents a summary of this state. Both tokens can be generated and are accessible only to $\mathcal{CN}$. Finally, $\mathcal{CN}$ sends two messages, $m_7$ and $m_8$, to $\mathcal{CP}$ and $\mathcal{B}$, respectively. In them, it includes, in the form of tokens encrypted with the secret keys of $\mathcal{CP}$ and $\mathcal{B}$, part of the information published on $\mathcal{BC}$ and necessary to start phase 2 of the execution of the smart contract.

Phase 2 of contract execution, shown in Figure 6, is started by $\mathcal{CN}$ after $\mathcal{CP}$ has released the watermarked content X to $\mathcal{B}$, still in encrypted form. $\mathcal{CN}$ retrieves the encrypted information from $\mathcal{BC}$ related to the ongoing transaction. It checks and, if the encrypted information sent by $\mathcal{CP}$ and $\mathcal{B}$ is consistent with that published on $\mathcal{BC}$, $\mathcal{CN}$ generates the license to purchase X sold by $\mathcal{CP}$ to $\mathcal{B}$ and publishes it on $\mathcal{BC}$. Then, $\mathcal{CN}$ sends the private key $s{k}^X$ to $\mathcal{B}$, with which $\mathcal{B}$ can decrypt $\overline{{\mathbb{E}}_{p{k}^X}\left(X\right)}$ and obtain his protected and personalized accessible copy of $\overline{X}$.

From what has been reported so far, it emerges that the security of the proposed watermarking protocol depends on the following factors:

• As reported in the preliminary assumptions, the execution of $\mathcal{CN}$ in TEE ensures the correctness, integrity, and confidentiality of the computation performed.
• All tokens and information in messages exchanged between $\mathcal{CN}$, $\mathcal{CP}$, $\mathcal{B}$, and $\mathcal{BC}$ are always encrypted and accessible only to the entities responsible for managing them.
• The watermarking phase of X implemented by $\mathcal{CP}$ uses the security tokens generated during the first phase of smart contract execution. This phase can trigger the second phase of smart contract execution, which leads to the generation of the license to purchase X only if the information generated in the first phase by $\mathcal{CP}$, $\mathcal{B}$, and $\mathcal{CN}$ is confirmed by $\mathcal{CN}$ in the second phase.
• The security tokens generated and used in the first phase of execution of the smart contract are fixed by the publication on the blockchain. By accessing $\mathcal{BC}$, $\mathcal{CN}$ is responsible for ensuring that these tokens are also used in the second execution phase of the smart contract.

Suppose that $\mathcal{B}$ is corrupt. Following the “buyer-friendly” approach, $\mathcal{B}$ participates in the protocol without generating tokens or security information except for $B_{id}$, which qualifies its identity. In fact, $B_{id}$ is assumed to be valid since the problems resulting from false identities are not considered in this analysis. Therefore, the tokens that $\mathcal{B}$ exchanges in messages are generated by other entities and can only be confirmed by $\mathcal{B}$, under penalty of interrupting the purchase transaction as a result of the checks performed at the end of the first or second phase of execution of the smart contract. Consequently, in this hypothesis, no content is released by $\mathcal{CP}$ in accordance with the provisions of Section 7.

Suppose that $\mathcal{CP}$ is corrupt. In this case, $\mathcal{CP}$, which is responsible for inserting the watermark into X, can maliciously generate or attempt to alter the tokens it is responsible for, such as $X_d$ and $T_X$, or the tokens to be used to protect X. However, the checks performed by the two phases of execution of the smart contract, as reported above, force $\mathcal{CP}$ to behave as follows:

• $\mathcal{CP}$ cannot reuse tokens already used in previous transactions;
• $\mathcal{CP}$ cannot modify or change the part of the watermark generated during the first phase of the smart contract execution, nor reuse watermarks used to protect other content.

This is because all tokens validly used in previous purchase transactions are published on $\mathcal{BC}$. In detail, $X_d$ and $T_X$ are published in clear text, and any previous duplication can be directly verified by the smart contract. As regards tokens for which only the digest is published, it is necessary to observe that they are generated by the smart contract during the first execution phase, are published in the form of an encrypted state on the blockchain, and must be confirmed by $\mathcal{B}$ and $\mathcal{CP}$ during the second execution phase of the smart contract. Therefore, any watermark generated or reused independently by $\mathcal{CP}$ to protect X that is different from the one generated by the smart contract during the first execution phase can never be inserted in the purchase license downstream of the second execution phase of the smart contract. Such a condition can only lead to the generation of protected content $\overline{X}$ that cannot be validly linked to any buyer since no valid purchase license can be associated with it. This result would end up damaging $\mathcal{CP}$ itself, which would release incorrectly protected content.

In essence, the immutability of the smart contract code, its secure execution in TEE, and the exchange and publication of tokens and security information always in encrypted form on blockchain guarantee the security of the proposed protocol both with respect to corrupt entities and to “honest-but-curious” ones.

8. Implementation and Performance

The implementation of the described protocol consists of two main parts: the first concerns the watermark insertion algorithm, while the second concerns the execution model of the smart contract that is responsible for running the protocol.

As for the first part, two different watermark insertion algorithms are available: one based on the SS insertion technique [22] and the other based on QIM [34]. Both are used in conjunction with the Paillier homomorphic cryptosystem [29], as described in [39,40,41], and exploit the optimizations, described in [26,42], capable of improving the watermark insertion directly in the encrypted domain.

The SS insertion algorithm is based on the following formula:

$$\overline{x}=x+\alpha (2b-1)s$$

in which x is a host signal feature obtained by calculating the cosine discrete transform, $\overline{x}$ is the corresponding watermarked feature, $b\in \{0,1\}$ is the bit to embed, s is the component of a spreading sequence, and $\alpha$ is a scaling factor that controls the watermark’s strength. Therefore, inserting the watermark into the encrypted domain employs the following formula [26,39,40]:

$$E\left[\overline{x}\right]=E\left[x\right]·E{\left[b\right]}^{2\alpha s}·E{\left[\alpha s\right]}^{-1}$$

The insertion algorithm using QIM is based on the following formula [26]:

$$\overline{x}=f\left(x\right)+b\Delta \left(x\right)$$

where x, $\overline{x}$, and b have the same meaning reported above, while $f\left(x\right)$ and $\Delta \left(x\right)$ denote a function of the original signal features and a signal-dependent quantization step, respectively [4,34]. Consequently, the insertion of the watermark into the encrypted domain uses the following formula [26,40,41]:

$$E\left[\overline{x}\right]=E\left[f\left(x\right)\right]·E{\left[b\right]}^{\Delta \left(x\right)}$$

As for the second part, the smart contract execution model has been implemented using the Oasis Network [43], a blockchain based on the “layer-2” architecture adopted by the proposed protocol. Oasis is, in fact, composed of a layer dedicated to reaching consensus and an off-chain execution layer of smart contracts (see Figure 7).

In particular, the consensus layer is implemented by validator nodes that maintain the integrity of the blockchain by running the Tendermint BFT (Byzantine Fault Tolerance) protocol and employing a proof-of-stake as the block proposer protocol.

The execution layer of smart contracts is implemented by execution nodes hosting the so-called “paratimes” (parallel runtimes), which represent the environments dedicated to executing smart contracts. In this regard, the proposed protocol uses a specific paratime made available by Oasis, called Sapphire, which supports the confidential execution of EVM-compatible smart contracts in TEE, just like the one implementing the proposed protocol, which was written in Solidity (see Figure 8).

Sapphire leverages INTEL SGX as a TEE, which ensures that all input, output, intermediate, and final states of smart contracts are always encrypted and managed securely, even with respect to the nodes hosting the TEEs. As a confidential paratime, Sapphire provides a key manager that can guarantee the generation, storage, distribution, and revocation of the keys needed for execution in TEE. In addition, Sapphire ensures the integrity of the computation performed in TEE through the “discrepancy-detection” algorithm. This algorithm provides that the results of the execution in TEE of the same smart contract by multiple execution nodes are sent to a “committee” of nodes in the form of “cryptographic commitment”. The nodes of the committee then execute the discrepancy-detection algorithm and, if they reach an agreement, they declare the smart contract execution as complete and send the result to the consensus layer for finalization on the blockchain. Otherwise, the committee nodes run the more expensive “discrepancy-resolution” algorithm to identify the correct result of the smart contract execution. In this way, Sapphire guarantees high scalability to the off-chain execution of smart contracts, which is penalized only in case of a lack of agreement between the committee nodes.

As for the performance of the proposed protocol, it is important to note that the time T needed to complete a purchase transaction of X is given by the sum of the following contributions:

$$T=T_{sc}+T_w+T_{dd}+T_{bc}$$

where $T_{sc}$ is the time taken by a TEE-equipped node to execute the smart contract implementing the protocol, $T_w$ is the time taken by $\mathcal{CP}$ to secure the content X, $T_{dd}$ is the time taken by the committee of TEE nodes to evaluate the integrity of the computation performed to execute the smart contract, and $T_{bc}$ is the time taken to finalize the purchase transaction on the blockchain.

In particular, thanks to the layer-2 execution paradigm, $T_{sc}$ and $T_{dd}$ are related to an off-chain execution. They mainly depend (1) on the power and number of TEE nodes involved in executing the smart contract and (2) on the discrepancy-detection protocol. Therefore, the higher the degree of replication of the smart contract execution and the number of nodes involved in the integrity committee, the higher the recorded times will be.

$T_w$, instead, depends on the computing power used by $\mathcal{CP}$: the greater this power, the less time will be required to protect X.

$T_{bc}$ coincides with the so-called “time to finality” that characterizes $\mathcal{BC}$, that is, the time needed to confirm a transaction completely [8]. It measures the time that elapses between sending the transaction to $\mathcal{BC}$ and its confirmation, by publication in one of the $\mathcal{BC}$ blocks, with a guarantee of irreversibility. This time is a very variable value and difficult to obtain because it depends on many factors, such as, for example, the consensus algorithm used, the block propagation method, the number of validator nodes used, the speed of their network interconnection, and the finality method. In essence, it is possible to reduce $T_{bc}$ by using a reduced number of validator nodes, but this expedient ends up also reducing the level of security implemented by $\mathcal{BC}$, as foreseen by the so-called “trilemma” of blockchains, according to which the classic objectives of a blockchain, such as decentralization, scalability, and security, are substantially conflicting [8].

In the preliminary tests conducted, three TEE nodes (Intel(R) Core(TM) i7-10870H with a frequency up to 4.8 GHz and 16 GB of RAM) and three validator nodes (Intel(R) Core(TM) i5-12450HX with a frequency up to 4.4 GHz and 16 GB of RAM) were used. All nodes are connected by a Gb Ethernet. As for $\mathcal{CP}$, an Intel(R) Core(TM) i5-12450HX compute node with a frequency up to 4.4 GHz and 16 GB of RAM was used.

With these limited hardware resources, $T_{sc}$ varies approximately between 12 and 14 s, mainly due to the operations needed to generate encryption keys, encrypt tokens, and calculate hashes.

$T_w$ was found to vary between 29–41 s and 107–145 s, depending on the size of the protected image, 512 $\times$ 512 or 1024 $\times$ 1024 pixels, and the watermarking algorithm used, such as SS or QIM [18].

$T_{dd}$ was calculated using all three nodes in the committee to evaluate the integrity of the computation performed by the smart contract. It was found to vary approximately between 1 and 1.5 s when no discrepancy was detected. On the contrary, the discrepancy-resolution algorithm takes approximately between 5 and 6 s in case of no agreement.

Finally, $T_{bc}$ was calculated using all three available execution nodes as validators. The result obtained was approximately between 6 and 7 s.

It is important to note that $T_{sc}$, $T_w$, and $T_{dd}$ values are independent of the blockchain used since they are obtained, as previously mentioned, by exploiting a layer-2 execution paradigm. Such a condition guarantees scalability to the proposed solution since, by increasing the number of TEE nodes used as well as their power, these times can be drastically reduced without undermining the security of the protocol. As for the value of $T_{bc}$, it can be reduced by adopting a more efficient consensus algorithm. However, the one used by Oasis still guarantees good performance in relation to other solutions documented in the literature, with a maximum theoretical value of TPS (transactions per second) equal to 1000.

Finally, the adoption of the layer-2 execution paradigm allows the execution of the smart contract that implements the watermarking protocol to be moved off-chain, thus overcoming the gas limits imposed by layer-1 blockchains without having to give up the advantages of immutability, automation, and decentralization of smart contracts on blockchains.

9. Related Work

The evolution of watermarking protocols has led to “buyer-seller” solutions that leverage public key infrastructures, asymmetric fingerprinting, and “privacy homomorphic” encryption for watermark insertion. Such solutions effectively address classic issues documented in the literature, such as the “unbinding problem” and the “customer’s right problem” [4]. In these solutions, the seller inserts a watermark encrypted with the buyer’s public key directly into the content, which is also encrypted using the same public key. Consequently, the buyer can access the content with personalized protection by decrypting it with his/her private key. However, many existing protocols rely on TTPs as “watermark certification authorities” or agents essential for ensuring the correctness and security of the protection transactions executed. Such a situation has prompted researchers to seek new solutions that eliminate TTPs from the developed protocols, all while avoiding complex actions for buyers during the content purchase transactions from sellers. According to such an approach, watermarking protocols that utilize blockchain technology and smart contracts to bypass TTPs represent one of the most advanced and promising solutions in the literature.

Y-DWMS [44] adopts the aforementioned approach and leverages blockchain technology and smart contracts to deliver traditional services such as watermark verification for disclosed copies, authentication of informers’ reports, and traceability of infringements. In addition to these classic services, Y-DWMS introduces specific functionalities to reward informers, penalize infringers, and mitigate losses incurred by copyright holders. Despite these innovative services, Y-DWMS is affected by specific problems, particularly concerning privacy, and its security level has not been validated.

SBBC (Secret Block-Based Blockchain) [45] exploits blockchain technology and smart contracts to create a digital content trading system. It comprises both off-chain and on-chain components. The off-chain components implement an initial authentication phase, enabling users to engage in digital content transactions. Digital fingerprints are embedded in the traded content to monitor any illegal leaks. Additionally, the content is encrypted, ensuring that only authorized users can access it, thereby safeguarding the income of legitimate content creators. The on-chain components provide licensing services. Specifically, authorized users run smart contracts to initiate the licensing process, generating secret blocks representing their transactions and recording them on the blockchain. Following verification and agreement from all blockchain nodes, public blocks are added to the blockchain to finalize purchase licenses. SBBC also addresses performance issues that typically affect blockchain-based systems by proposing an efficient consensus algorithm. However, it lacks a thorough security analysis and has yet to demonstrate resilience against the traditional challenges faced by watermarking protocols [4,46].

FingerChain [47] is a multi-owner media-sharing system focused on digital copyright protection, built on a consortium blockchain network. It employs smart contracts and asymmetric fingerprinting to allow authorized owners to share their media for a fee. This system benefits from the absence of a TTP to implement the protection protocol and a high efficiency level on the owner’s side due to the “client-side embedding” technique for watermark insertion [48]. However, the watermarking scheme used requires clients to eliminate noise sequences from the purchased content and generate secret fingerprints. These security measures can be complex for ordinary web users [4].

While the systems discussed above present innovative approaches to watermarking protocols, they exhibit certain limitations that the protocol outlined in this article aims to address.

For instance, Y-DWMS is characterized by many innovative aspects, but there is no information about the performance offered or the level of security achieved.

FingerChain employs a watermarking insertion technique that is significantly more efficient than those assessed for the proposed protocol; specifically, the “client-side embedding” watermark insertion technique requires at least an order of magnitude less time than the SS or QIM techniques when processing the same content. However, FingerChain necessitates that buyers execute complex security primitives, which represent a fundamental limitation of its protection scheme.

Conversely, SBBC is the first system to divide the execution of the watermarking protocol into both off-chain and on-chain components. Nonetheless, the on-chain component relies on the execution of smart contracts, which exposes SBBC to the issues outlined in Section 2. From a performance perspective, SBBC surpasses the proposed protocol in efficiency due to two primary factors: (1) its “permissioned” execution model does not mandate the implementation of the discrepancy-detection algorithm prior to achieving consensus among blockchain nodes, and (2) it utilizes more efficient consensus algorithms than that employed by the Oasis Network, resulting in a reduction in execution time of around 10% on average, which increases up to 20% when the number of nodes in the blockchain reaches the maximum tested value of 50. Therefore, SBBC provides a more overall efficient solution than the proposed protocol, although it still suffers notable limitations related to both the execution on-chain of smart contracts and the lack of adequate security analysis. On the contrary, the solution proposed in this paper marks a pioneering instance of a watermarking protocol built on a layer-2 confidential execution model based on TEE.

10. Conclusions

Implementing watermarking protocols in the form of dApps without resorting to TTPs and based on blockchain and smart contracts is undoubtedly a complex challenge. The lack of confidentiality, the low efficiency and the constraints imposed by gas limits in executing smart contracts make the possible implementations difficult in practice.

The layer-2 execution model, together with the use of processing nodes equipped with TEE, makes efficient, scalable, and secure solutions based on smart contracts and blockchain possible. An example of this is the solution proposed in this article, which presents a watermarking protocol expressly designed to be implemented by smart contracts and blockchains executed according to the layer-2 model. In fact, the presented prototype guarantees confidentiality, security, and good performance overall without resorting to TTP, thus representing a first example of a dApp for digital copyright protection based on the “Blockchain 3.0” model.