A Digital Media Subscription Management System Combined with Blockchain and Proxy Re-Encryption Mechanisms

Abstract

The subscription economy was born because the relationship between creators and customers is different than it used to be. The era of the creator economy seems to be filled with boundless promise, but at the end of the day, creators are just slaves to tech giants. Neither the control of the content created, nor the money made in their pockets is in complete control of the creator. The blockchain can completely solve these injustices monopolized by enterprises. In the blockchain era, all kinds of creations from music, and video-to-text can be turned into assets that can be purchased and traded through smart contracts. In the music industry, for example, creators do not need to share profits with streaming platforms and record labels and get all the benefits directly. In addition, when the content created is on the chain, every transaction will be recorded on the blockchain, and everyone can inquire about it, avoiding opacity or causing disputes in the future. However, with the structure of the standard blockchain, as long as the registration is successful, each role in the chain will have permanent data access rights, and the flexibility of access control is poor. Therefore, this study proposes a digital media subscription mechanism based on the Hyperledger blockchain architecture combined with proxy re-encryption. We use symmetric and asymmetric cryptography, smart contracts, and algorithms to design our protocol. When the licensee violates the agreement with the creator, the creator can revoke the access rights to the digital media of the licensee at any time, to realize more secure and convenient digital media transmission. The proposed scheme meets various security requirements of blockchain architecture, and we have also applied the BAN logic proof model to evaluate the correctness of the proposed scheme. This study also proposes an arbitration mechanism when the dispute occurs, and performed well in terms of communication and computational costs.

1. Introduction

1.1. Background

According to PwC’s “Global Entertainment and Media Outlook 2020–2024” report, the output value of global digital media in 2020 has exceeded 2 trillion US dollars and is still growing [1]. In the early days, digital media needed to be transmitted through physical media such as optical discs, but now the Internet can transmit all digital media, which was completely unimaginable by previous humans. Because digital media no longer needs to be delivered through a carrier, the provision of digital content can be more flexible, such as customers can buy a song individually, or pay to watch a movie only once [2,3,4,5].

The subscription economy was born because the relationship between creators and customers was different than before. Looking at the international scene, many companies use the subscription model to take a leading position in the industry, such as Netflix, Spotify, Microsoft, and Amazon Prime, these subscription economy businesses can often cultivate a group of subscribers with high loyalty, high repurchase or long-term renewal [6,7]. The stable and harmonious relationship creates continuous growth performance for the enterprise, and at the same time attracts many new start-up teams or enterprise managers to try to follow suit, expecting to achieve recurring profits through the subscription model [8,9].

The era of the creator economy seems to be full of infinite hope, but in the end, creators are just slaves of tech giants. Whether it is the control of the content created or the money earned in the pocket, it is not the creator who has full control. This is a common problem faced in today’s Internet age. Let us take the music streaming subscription mechanism as an example. For just a few dollars a month, customers can listen to unlimited music. Streaming music platforms are very convenient for users, but not fair to creators [10,11,12,13].

Most platforms will distribute profits to singers according to the number of times each song is played. According to statistics, each time a song is played on Spotify, the creator can only allocate about 0.005 U.S. dollars, and the platform has eaten most of the revenue. Under this, users gain convenience, but musicians suffer, and the two ends of the scale are obviously out of balance.

The blockchain can completely solve these injustices monopolized by enterprises. In the era of the blockchain, all kinds of creations from music, and video-to-text can be turned into assets that can be purchased and traded through smart contracts [14,15,16]. Taking the music industry as an example, creators do not need to share profits with streaming platforms and record companies and can directly get all the benefits. In addition, when the content of creation is on the chain, every transaction will be recorded on the blockchain, and everyone can query it, avoiding opacity or causing disputes in the future [17,18].

The blockchain is a technical system jointly maintained by multiple parties [19,20]. Cryptography technology is applied to ensure the security of access and transmission, and it can also achieve consistent data storage, non-tampering, and non-repudiation. The hash algorithm is used to ensure that the digital media data on the chain cannot be tampered with, and the creator’s works are guaranteed with electronic authentication technology. Decentralized database technology enables secure storage and traceability of data. It can effectively solve the problems of digital media data transmission, data authenticity and security, digital media data protection, and real-time supervision [21,22,23].

However, even with blockchain architecture applied, the cloud can still be subject to Sybil attacks and thus can only be considered a semi-trust role. In addition, with the structure of the standard blockchain, each role in the chain will enjoy permanent data access rights as long as the registration is successful, and the flexibility of access control is poor [24,25,26,27,28,29,30]. Therefore, this study proposes a digital media subscription mechanism based on the Hyperledger blockchain architecture combined with proxy re-encryption. When the authorized person violates the agreement with the creator, the creator can revoke the authorized person’s access rights to the digital media at any time, to realize more secure and convenient digital media transmission.

1.2. Research Goals and Threat Model

This study will use blockchain and proxy re-encryption technology to propose a digital media subscription management system. Like many blockchain-related studies proposed by previous researchers [31,32,33,34,35], the proposed scheme achieves the following research goals:

(1)

Decentralization for information sharing: In the blockchain network architecture, decentralized bookkeeping and storage are adopted. All nodes have the same rights and obligations. Therefore, any error or shutdown of any node will not affect the operation of the entire blockchain network.

(2)

Openness and privacy: The sharing of digital media and the protection of the interests of creators, at first glance, are opposite things. By using the ECDSA-based blockchain mechanism combined with the encryption mechanism of the public key system, in addition to the encrypted private information of the transaction subject, the signature data information stored in the blockchain is also open and transparent. All members of the same alliance can verify the correctness of the message and reduce the asymmetry of data, which is the openness of the blockchain system. In addition, the plaintext of the message is also encrypted by the public key, and only the members of the alliance with the corresponding private key can decrypt the message settings to achieve privacy protection.

(3)

Proxy re-encryption for access control: Behind the alliance chain combined with blockchain technology, different creators can store their works on the digital media cloud. Blockchain technology can protect data security in the blockchain through a public key system. The system not only allows authorized parties to access encrypted data through their private keys, but also ensures that the database and the core data will not be leaked. To protect the interests of creators, a proxy re-encryption mechanism can also be applied. Only parties can view individual contracts, and the key lies in the hands of media creators. Licensees can access digital media through keys issued by the media creator only if authorized by the media creator. When the licensee arbitrarily shares the digital media with others, the media creator can revoke the access right of the licensee at any time. Through the proxy re-encryption mechanism, the access rights of alliance members can be effectively controlled to achieve access control.

(4)

Verifiable: The sender’s message will be signed by the sender, and the receiver can verify the authenticity of the signature. The message sender will sign with his/her private key, and the message receiver will verify with the message sender’s public key.

(5)

Traceable: Blockchain technology ensures that all parties have equal rights to choose and know, anything exchanged between two roles is auditable. All transaction information is accessible to all participants in the alliance. Due to the distributed storage and verification feature, the blockchain system will synchronize all changed records. In the event of disputes in the future, there is data to prove that the rights and interests of any two roles are protected.

(6)

Mutual authentication: The legality of the sender’s and receiver’s identity must be able to be verified. The BAN logic proof is applied to determine whether mutual authentication is achieved between the two parties. Mutual authentication is achieved once the sender and receiver mutually verify the legality of each other’s identities.

(7)

Integrity and unforgery: The timestamp and signature mechanism is applied to ensure the transmitted message is not tampered with; it can also ensure the integrity of the message in the communication process.

(8)

Non-repudiation: The data is stored forever once it is verified and added to the blockchain, and the inherent time stamping feature of the blockchain system records the time of creation. Modifying the content of messages that have been uploaded to the Blockchain Center requires the control of more than 51% of the consortium members, which will be difficult to achieve.

(9)

Resist Sybil attacks: The transmitted messages can be intercepted by an attacker, and the attacker will send illegitimate messages to legal users. To protect transmitted messages, the ECDSA system can be applied. Therefore, an attacker cannot properly intercept important information when conducting a Sybil attack.

The organization of the rest of the paper is as follows. Section 2 provides the preliminary. Section 3 present the proposed protocol. In Section 4, we analyze the related security issues of our proposed scheme. In Section 5, we discuss the computation cost and communication cost. Finally, Section 6 concludes the paper.

2. Preliminary

2.1. Smart Contract

A smart contract means a transaction agreement, or a computer program designed to automatically execute, control or record legal-related events and behaviors in accordance with the terms of the agreement or contract. Smart contracts intend to decrease the need for trusted intermediaries, arbitration and enforcement costs, and fraud losses and also reduce malicious and unexpected anomalies [36,37].

Smart contracts are programs stored on the blockchain and are executed when predetermined conditions are met. Smart contracts are usually used to do the execution of the agreement automatically so that all parties can determine the result immediately without the involvement of any intermediary or loss of time. They can also automate the workflow and trigger the next action when the conditions are met.

2.2. ECDSA

Vanstone proposed the Elliptic Curve Digital Signature Algorithm (ECDSA) in 1992. The proposed scheme uses elliptic curve cryptography (ECC), which is a variant of the Digital Signature Algorithm (DSA). The Digital Signature Algorithm (DSA) is a Federal Information Processing Standard for digital signatures, which is based on the mathematical theory of the discrete logarithm problem and modular exponentiation [38,39].

Elliptic curve cryptography (ECC) is an approach to public-key cryptography based on the algebraic structure of elliptic curves over finite fields. Compared to non-EC cryptography, ECC allows smaller keys to provide equivalent security. ECDSA requires a significantly smaller key size and achieves the same security level, thereby providing less storage space and faster calculations. The security of ECDSA is based on the discrete logarithm problem.

Next, we briefly describe the three phases of ECDSA key generation for verification:

Key generation phase: We assume that any participant must apply to our Blockchain Center for public and private keys, the key generation with ECDSA is as follows: Q_x = d_xG, where x is the participant ID, Q_x is the public key, d_x is the private key, G is a generating point based on the elliptic curve. The public key Q_x and private key d_x are sent to the participant and stored. Q_x is also stored in the Blockchain Center.

Signature phase: There is a message needed to be sent by participant x to y. x chooses a random number k between 1 and n−1, a point on the curve is calculated as follows, $(x,y)=k\times G$. Then, $r_x=x\mathrm{mod}n$ is calculated. Next, x signs a message m as follows: $si{g}_x=k^{-1}(h(m)+r_x{d}_x)$, and sends $(m,r_x,si{g}_x)$ to y.

Verification phase: When y receives $(m,r_x,si{g}_x)$, the parameters are calculated as follows: $(x’,y’)=(h(m)si{g}_x^{-1}\mathrm{mod}n)G+(r_{x}si{g}_x^{-1}\mathrm{mod}n)Q_x$. Then, $x^{\prime }\stackrel{?}{=}{r}_x\mathrm{mod}n$ is verified to determine if the signature is valid.

2.3. Hyperledger Fabric

Hyperledger Fabric is a permissioned blockchain infrastructure. Hyperledger Fabric was originally contributed to the Hyperledger project by Digital Asset and IBM. Hyperledger Fabric provides a modular architecture that combines the nodes in the architecture, the execution of smart contracts is called “chaincode” in the Fabric project. A Fabric network includes peer nodes that execute chaincode contracts and access the ledger data, endorsement transactions, and is called application program interface. The ordering node is responsible for ensuring the consistency of the blockchain and conveying the endorsed transactions to peers in the network, and the MSP service, which is mainly used as a certificate authority to manage X.509 certificates to verify membership and roles [40,41,42].

3. The Proposed Scheme

3.1. System Architecture

This research proposed a digital media subscription management system combined with blockchain and proxy re-encryption mechanisms. The main parties of the system include the Blockchain Center (BCC), Certificate Authority (CA), Digital Media Cloud (DMC), Owner (OR), Licensee (LE), and Bank (BK). The system architecture is shown in Figure 1.

Step 1:

Certificate Authority (CA), Digital Media Cloud (DMC), Owner (OR), Licensee (LE), and Bank (BK) must register with the Blockchain Center to obtain public and private keys for message encryption/decryption, and ECDSA signature key.

Step 2:

Media-related institutions form the Digital Media Cloud, and the media-related data of each institution will be stored in the Digital Media Cloud, and access rights will be controlled through the access control mechanism. All relevant information is also uploaded to the Blockchain Center through Certificate Authority.

Step 3:

If the Licensee wishes to purchase digital media content from the Owner, the Owner will inform the Licensee of the fees and payment methods for the digital media. Licensee goes to the Bank for payment. After the payment is completed, Licensee will get a payment receipt. The licensee provides proof of payment to the Owner, who in turn provides the Licensee with the right to use the digital media. All relevant information is also uploaded to the Blockchain Center through the Certificate Authority.

Step 4:

The Owner uploads the digital content purchased by the Licensee to the Digital Media Cloud for proxy re-encryption. Licensee can obtain the re-encrypted media data through the Digital Media Cloud and obtain the relevant content for research after decryption. All relevant information is also uploaded to the Blockchain Center through the Certificate Authority.

3.2. Notation

The notation of this article is as follows:

q	A q-bit prime number
GF(q)	Finite group q
E	The elliptic curve defined on finite group q
G	A generating point based on the elliptic curve E
IDx	A name representing identity x
kx-y	A random value on the elliptic curve of x to y
(rx-y, sx-y)	Elliptic curve signature value of x to y
Mx-y	A message from x to y
IDBC	An index value of blockchain message
BCx-y	Blockchain message of x to y
TSx-y	Timestamp message of x to y
ΔT	Checks if the difference between two timestamps is less than a specified timestamp
$E_{P{K}_x}(M)$	Encrypt a message M using the asymmetric public key of x
$D_{S{K}_x}(M)$	Decrypt a message M using the asymmetric private key of x
Encx-y	Encrypted message using the asymmetric key of x to y
Certx	The certificate of role x conforms to the X.509 standard
c1, c2	The proxy re-encryption message content
a, b	The private key pair for proxy re-encryption
keyx_y	The proxy re-encryption session key of roles x and y
h(.)	Hash function
$A\stackrel{?}{=}B$	Verify whether A is equal to B

3.3. Registration Phase

The system role X can represent the Certificate Authority (CA), Digital Media Cloud (DMC), Owner (OR), Licensee (LE), and Bank (BK), which registers with the Blockchain Center (BCC). These parties also obtain a digital certificate of identity and a relative public/private key pair from the Blockchain Center through a secure channel. The flowchart of the registration phase is shown in the following Figure 2.

Step 1:

Role X generates an identity ID_x, and sends it to the Blockchain Center.

Step 2:

The Blockchain Center generates an ECDSA private key d_x based on the role X, calculating

$$Q_X=d_{X}G.$$

(1)

If the identity of the registered role is verified, the smart contract Xins is triggered, the Algorithm 1 is presented as follows:

Algorithm 1. Smart contract Xins of the proposed scheme.

function inserted X smart contract Xins ( string X_id, string X_detail) {   count++;   X[count].id = id;   X[count].detail = detail; } string X_keypairs;

Then, the Blockchain Center will transmit $I{D}_X,(d_X,Q_X),P{K}_X,S{K}_X,Cer{t}_X$ to role X.

Step 3:

The role X stores $(d_X,Q_X,P{K}_X,S{K}_X,Cer{t}_X)$.

3.4. Smart Contract Initialization

Blockchain technology was applied in the proposed architecture. During the authorization and authentication process, some key information is stored and verified via the Blockchain Center. This key information is defined in the smart contract. Figure 3 is the blockchain smart contract structure of the proposed scheme:

The proposed smart contract developed key information that is stored in the blockchain. The basic fields of ID (identification), transaction detail, certificate, and timestamp are presented in each smart contract. The subscription negotiation and confirmation contract are added in the LE_ORinf/OR_LEinf smart contract, while the bank payment contract is added in the LE_BKinf/BK_LEinf smart contract. Additionally, the proxy re-encryption contract is shown in the OR_DMCinf/DMC_ORinf smart contract. At last, the digital media streaming contract is shown in the LE_DMCinf/DMC_LEinf smart contract. The Blockchain Center also issues the public and private key pairs for all roles in the registration phase.

3.5. ECDSA Authentication Process

Before starting communication, party A and party B in the system must first confirm the legitimacy of the identities of both parties through the ECDSA mechanism. Party A or party B in the system can be the Certificate Authority (CA), Digital Medical Cloud (DMC), Owner (OR), Licensee (LE), and Bank (BK). The flowchart of the ECDSA authentication process is shown in Figure 4. The ECDSA process is shown in Algorithm 2, and the ECDSA verification process is shown in Algorithm 3.

Step 1: Role A generates a random value $k_{A-B}$, calculating

$$token=h(I{D}_A,M_{A-B},T{S}_{A-B}),$$

(2)

Calls for the signature process as Algorithm 2 by $(token,k_{A-B},d_A)$, gets $(r_{A-B},s_{A-B})$, calculates

$$En{c}_{A-B}=E_{P{K}_B}(I{D}_A,M_{A-B},T{S}_{A-B}),$$

(3)

And sends $I{D}_A,En{c}_{A-B},(r_{A-B},s_{A-B})$ to Role B.

Algorithm 2. ECDSA process between role A and role B.

string token, kA − B, dA; function ECDSA process (token, kA − B, dA)   zA − B = token;   (XA − B, yA − B) = kA − BG   rA − B = XA − B mod n   SA − B = kA − B−1 (zA − B + rA − B dA) mod n   return (rA − B, sA − B);

Step 2: Role B first calculates

$$(I{D}_A,M_{A-B},T{S}_{A-B})=D_{S{K}_B}(En{c}_{A-B}),$$

(4)

Uses $T{S}_{NOW}-T{S}_{A-B}\le \Delta T$ to confirm whether the timestamp is valid, and then verifies the correctness of the ECDSA signature, and then calculates

$$token=h(I{D}_A,M_{A-B},T{S}_{A-B}),$$

(5)

Calls for the ECDSA verification process as by $(token,r_{A-B},s_{A-B},Q_A)$ and is validated/invalidated.

Algorithm 3. ECDSA verification process between role A and role B

string token, rA − B, sA − B, QA; function ECDSA verification process (rA − B, sA − B, QA)   zA − B’ = token;   (uA − B1 = zA − B’ sA − B−1 mod n   uA − B2 = rA − B sA − B−1 mod n;   (xA − B’, yA − B’) = uA − B1G + uA − B2 QA;   check if xA − B’ = rA − B mod n;   return valid/invalid;

Role B generates a random value $k_{B-A}$ and calculates

$$token=h(I{D}_B,M_{B-A},T{S}_{B-A}),$$

(6)

Calls for the ECDSA process by $(token,k_{B-A},d_B)$, receives $(r_{B-A},s_{B-A})$, and calculates

$$En{c}_{B-A}=E_{P{K}_A}(I{D}_B,M_{B-A},T{S}_{B-A}),$$

(7)

And sends $I{D}_B,En{c}_{B-A},(r_{B-A},s_{B-A})$ to Role A.

Step 3: Role A first calculates

$$(I{D}_B,M_{B-A},T{S}_{B-A})=D_{S{K}_A}(En{c}_{B-A}),$$

(8)

Uses $T{S}_{NOW}-T{S}_{B-A}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_B,M_{B-A},T{S}_{B-A}),$$

(9)

Calls for the verification process by $(token,r_{B-A},s_{B-A},Q_B)$ and is validated/invalidated.

3.6. CA Communication Process

The blockchain architecture of the Hyperledger is applied in the proposed scheme, which adds the role of the CA, reduces the burden of the BCC, and also allows more flexible access controls. The data will be sent to their respective CAs after verifying communication between each role, and then the blockchain data will be transmitted to the BCC through each CA. For example, all Digital Media Clouds have their own CA, which can ensure the data sharing of each CA member, as well as cross-CA access control, taking into account privacy and efficiency. The Access Party (AP) can represent different members of the Digital Media Clouds. The flowchart of the CA communication process is shown in Figure 5.

Step 1: The AP generates a random value $k_{AP-CA}$, and calculates

$$token=h(I{D}_{AP},M_{AP-CA},Cer{t}_{AP},T{S}_{AP-CA},I{D}_{BC}),$$

(10)

Calls for the ECDSA process by $(token,k_{AP-CA},d_{AP})$ receives $(r_{AP-CA},s_{AP-CA})$, and calculates

$$En{c}_{AP-CA}=E_{P{K}_{CA}}(I{D}_{AP},M_{AP-CA},Cer{t}_{AP},T{S}_{AP-CA},I{D}_{BC}),$$

(11)

And sends $I{D}_{AP},En{c}_{AP-CA},(r_{AP-CA},s_{AP-CA})$ to the CA.

Step 2: The CA first calculates

$$(I{D}_{AP},M_{AP-CA},Cer{t}_{AP},T{S}_{AP-CA},I{D}_{BC})=D_{S{K}_{CA}}(En{c}_{AP-CA}),$$

(12)

Uses $T{S}_{NOW}-T{S}_{AP-CA}\le \Delta T$ to confirm whether the timestamp is valid, verifies $Cer{t}_{AP}$ with $P{K}_{AP}$, and then verifies the correctness of the ECDSA signature, then calculates

$$token=h(I{D}_{AP},M_{AP-CA},Cer{t}_{AP},T{S}_{AP-CA},I{D}_{BC}),$$

(13)

Calls for the ECDSA verification process by $(token,r_{AP-CA},s_{AP-CA},Q_{AP})$ and is validated/invalidated. If the verification is passed, the CA will get the message from the AP and trigger the smart contracts AP_CAins and AP_CAchk. Algorithm 4 is as follows:

Algorithm 4. Smart contract AP_CAins and AP_CAchk of the proposed scheme.

function insert smart contract AP_CAins (string AP_id, string AP_detail, string AP_cert, string AP_tsp) {   count++;   AP[count].id = id;   AP[count].detail = detail;   AP[count].cert = cert;   AP[count].tsp = tsp; }   sign string AP_key (AP_id, AP_detail, AP_cert, AP_tsp);   verify string AP_key (AP_id, AP_detail, AP_cert, AP_tsp);   function check smart contract AP_CAchk (string AP_id, string AP_detail, string AP_cert, string AP_tsp) {   return AP_id.exist;   return AP_detail.exist;   return AP_cert.exist;   return AP_tsp.exist; }

CA calculates

$$B{C}_{AP-CA}=h(r_{AP-CA},s_{AP-CA}),$$

(14)

where $(I{D}_{BC},B{C}_{AP-CA})$ is uploaded to the Blockchain Center. Then, the CA generates a random value $k_{CA-AP}$ and calculates

$$token=h(I{D}_{CA},M_{CA-AP},Cer{t}_{CA},T{S}_{CA-AP},I{D}_{BC}),$$

(15)

Calls for the ECDSA process by $(token,k_{CA-AP},d_{CA})$, receives $(r_{CA-AP},s_{CA-AP})$, and calculates

$$En{c}_{CA-AP}=E_{P{K}_{AP}}(I{D}_{CA},M_{CA-AP},Cer{t}_{CA},T{S}_{CA-AP},I{D}_{BC}),$$

(16)

And sends $I{D}_{CA},En{c}_{CA-AP},(r_{CA-AP},s_{CA-AP})$ to the AP.

Step 3: The AP first calculates

$$(I{D}_{CA},M_{CA-AP},Cer{t}_{CA},T{S}_{CA-AP},I{D}_{BC})=D_{S{K}_{AP}}(En{c}_{CA-AP}),$$

(17)

Uses $T{S}_{NOW}-T{S}_{CA-AP}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{CA},M_{CA-AP},Cer{t}_{CA},T{S}_{CA-AP},I{D}_{BC}),$$

(18)

Calls for the ECDSA verification process by $(token,r_{CA-AP},s_{CA-AP},Q_{CA})$ and is validated/invalidated. If the verification is passed, the CA will receive the message from the AP and the smart contracts CA_APins and CA_APchk will be sent. Algorithm 5 is as follows:

Algorithm 5. Smart contract CA_APins and CA_APchk of the proposed scheme.

function insert smart contract CA_APins (string CA_id, string CA _detail, string CA _cert, string CA _tsp) {   count++;   CA[count].id = id;   CA[count].detail = detail;   CA[count].cert = cert;   CA[count].tsp = tsp; } sign string CA_key (CA_id, CA _detail, CA _cert, CA _tsp); verify string CA _key (CA _id, CA _detail, CA _cert, CA _tsp); function check smart contract CA_APchk (string CA _id, string CA _detail, string CA _cert, string CA _tsp){   return CA_id.exist;   return CA_detail.exist;   return CA_cert.exist;   return CA_tsp.exist; }

AP calculates

$$B{C}_{CA-AP}=h(r_{CA-AP},s_{CA-AP}),$$

(19)

where $(I{D}_{BC},B{C}_{CA-AP})$ is uploaded to the Blockchain Center.

3.7. Subscription Negotiation Phase

When the Licensee (LE) wants to purchase or subscribe to digital content, the Owner (OR) can be asked. If a purchase or subscription is confirmed, the Owner (OR) will provide the Licensee (LE) with the transaction number and payment information. The flowchart of the subscription negotiation phase is shown in Figure 6.

Step 1: The LE generates a random value $k_{LE-OR}$, and calculates

$$token=h(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},T{S}_{LE-OR},I{D}_{BC}),$$

(20)

Calls for the ECDSA process by $(token,k_{LE-OR},d_{LE})$, receives $(r_{LE-OR},s_{LE-OR})$, and calculates

$$En{c}_{LE-OR}=E_{P{K}_{OR}}(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},T{S}_{LE-OR},I{D}_{BC}),$$

(21)

And sends $I{D}_{LE},En{c}_{LE-OR},(r_{LE-OR},s_{LE-OR})$ to the OR.

Step 2: The OR first calculates

$$(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},T{S}_{LE-OR},I{D}_{BC})=D_{S{K}_{OR}}(En{c}_{LE-OR}),$$

(22)

And uses $T{S}_{NOW}-T{S}_{LE-OR}\le \Delta T$ to confirm whether the timestamp is valid, verifies $Cer{t}_{LE}$ with $P{K}_{LE}$, and then verifies the correctness of the ECDSA signature, and then calculates

$$token=h(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},T{S}_{LE-OR},I{D}_{BC}),$$

(23)

Calls for the ECDSA verification process by $(token,r_{LE-OR},s_{LE-OR},Q_{LE})$ and is validated/invalidated. If the verification is passed the OR will get the message from the LE and trigger the smart contracts LE_ORins and LE_ORchk. Algorithm 6 is as follows:

Algorithm 6. Smart contract LE_ORins and LE_ORchk of the proposed scheme

function insert smart contract LE_ORins (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   count++;   LE[count].id = id;   LE[count].detail = detail;   LE[count].cert = cert;   LE[count].tsp = tsp; } sign string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); verify string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); function check smart contract LE_ORchk (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   return LE_id.exist;   return LE_detail.exist;   return LE_cert.exist;   return LE_tsp.exist; }

OR calculates

$$B{C}_{LE-OR}=(r_{LE-OR},s_{LE-OR}),$$

(24)

where $(I{D}_{BC},B{C}_{LE-OR})$ is uploaded to the Blockchain Center. Then, OR generates a random value $k_{OR-LE}$ and calculates

$$token=h(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},TI{D}_{OR-LE},T{S}_{OR-LE},I{D}_{BC}),$$

(25)

Calls for the ECDSA process by $(token,k_{OR-LE},d_{OR})$, receives $(r_{OR-LE},s_{OR-LE})$, and calculates

$$En{c}_{OR-LE}=E_{P{K}_{LE}}(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},TI{D}_{OR-LE},T{S}_{OR-LE},I{D}_{BC}),$$

(26)

Calls for the CA communication process and sends $I{D}_{OR},En{c}_{OR-LE},(r_{OR-LE},s_{OR-LE})$ to the LE.

Step 3: The LE first calculates

$$(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},TI{D}_{OR-LE},T{S}_{OR-LE},I{D}_{BC})=D_{S{K}_{LE}}(En{c}_{OR-LE}),$$

(27)

Uses $T{S}_{NOW}-T{S}_{OR-LE}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, calculates

$$token=h(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},TI{D}_{OR-LE},T{S}_{OR-LE},I{D}_{BC}),$$

(28)

Calls for the ECDSA verification process by $(token,r_{OR-LE},s_{OR-LE},Q_{LE})$ and is validated/invalidated. If the verification is passed, the LE will get the message from the OR and the smart contracts OR_LEins and OR_LEchk will be sent. Algorithm 7 is as follows:

Algorithm 7. Smart contract OR_LEins and OR_LEchk of the proposed scheme

function insert smart contract OR_LEins (string OR_id, string OR_detail, string OR_cert, string OR_tsp) {   count++;   OR[count].id = id;   OR[count].detail = detail;   OR[count].cert = cert;   OR[count].tsp = tsp; } sign string OR_key (OR_id, OR_detail, OR_cert, OR_tsp); verify string OR_key (OR_id, OR_detail, OR_cert, OR_tsp); function check smart contract OR_LEchk (string OR_id, string OR_detail, string OR_cert, string OR_tsp) {   return OR_id.exist;   return OR_detail.exist;   return OR_cert.exist;   return OR_tsp.exist; }

The LE calculates

$$B{C}_{OR-LE}=(r_{OR-LE},s_{OR-LE}),$$

(29)

where $(I{D}_{BC},B{C}_{OR-LE})$ is uploaded to the Blockchain Center.

3.8. Bank Payment Phase

The Licensee (LE) makes payment to the Bank (BK) based on the transaction number and payment information. After successful payment, Bank (BK) will reply to the receipt to Licensee (LE). The flowchart of the bank payment phase is shown in Figure 7.

Step 1: the LE generates a random value $k_{LE-BK}$, calculates

$$token=h(I{D}_{LE},M_{LE-BK},Cer{t}_{LE},TI{D}_{OR-LE},T{S}_{LE-BK},I{D}_{BC}),$$

(30)

Calls for the ECDSA process by $(token,k_{LE-BK},d_{LE})$, receives $(r_{LE-BK},s_{LE-BK})$, and calculates

$$En{c}_{LE-BK}=E_{P{K}_{BK}}(I{D}_{LE},M_{LE-BK},Cer{t}_{LE},TI{D}_{OR-LE},T{S}_{LE-BK},I{D}_{BC}),$$

(31)

And sends $I{D}_{LE},En{c}_{LE-BK},(r_{LE-BK},s_{LE-BK})$ to the BK.

Step 2: The BK first calculates

$$(I{D}_{LE},M_{LE-BK},Cer{t}_{LE},TI{D}_{OR-LE},T{S}_{LE-BK},I{D}_{BC})=D_{S{K}_{BK}}(En{c}_{LE-BK}),$$

(32)

Uses $T{S}_{NOW}-T{S}_{LE-BK}\le \Delta T$ to confirm whether the timestamp is valid, verifies $Cer{t}_{LE}$ with $P{K}_{LE}$, and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{LE},M_{LE-BK},Cer{t}_{LE},TI{D}_{OR-LE},T{S}_{LE-BK},I{D}_{BC}),$$

(33)

Calls for the ECDSA verification process by $(token,r_{LE-BK},s_{LE-BK},Q_{LE})$ and is validated/invalidated. If the verification is passed, the BK will get the message from the LE and trigger the smart contracts LE_BKins and LE_BKchk. Algorithm 8 is as follows:

Algorithm 8. Smart contracts LE_BKins and LE_BKchk of the proposed scheme

function insert smart contract LE_BKins (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   count++;   LE[count].id = id;   LE[count].detail = detail;   LE[count].cert = cert;   LE[count].tsp = tsp; } sign string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); verify string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); function check smart contract LE_BKchk (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   return LE_id.exist;   return LE_detail.exist;   return LE_cert.exist;   return LE_tsp.exist; }

The BK calculates

$$B{C}_{LE-BK}=(r_{LE-BK},s_{LE-BK}),$$

(34)

where $(I{D}_{BC},B{C}_{LE-BK})$ is uploaded to the Blockchain Center. Then, the BK generates a random value $k_{BK-LE}$ and calculates

$$token=h(I{D}_{BK},M_{BK-LE},Cer{t}_{BK},TI{D}_{BK-LE},T{S}_{BK-LE},I{D}_{BC}),$$

(35)

Calls for the ECDSA process by $(token,k_{BK-LE},d_{BK})$, gets $(r_{BK-LE},s_{BK-LE})$, calculates

$$En{c}_{BK-LE}=E_{P{K}_{LE}}(I{D}_{BK},M_{BK-LE},Cer{t}_{BK},TI{D}_{BK-LE},T{S}_{BK-LE},I{D}_{BC}),$$

(36)

Calls for the CA communication process and sends $I{D}_{BK},En{c}_{BK-LE},(r_{BK-LE},s_{BK-LE})$ to the LE.

Step 3: The LE first calculates

$$(I{D}_{BK},M_{BK-LE},Cer{t}_{BK},TI{D}_{BK-LE},T{S}_{BK-LE},I{D}_{BC})=D_{S{K}_{LE}}(En{c}_{BK-LE}),$$

(37)

Uses $T{S}_{NOW}-T{S}_{BK-LE}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{BK},M_{BK-LE},Cer{t}_{BK},TI{D}_{BK-LE},T{S}_{BK-LE},I{D}_{BC}),$$

(38)

Calls for ECDSA verification process by $(token,r_{BK-LE},s_{BK-LE},Q_{LE})$ and is validated/invalidated. If the verification is passed, the LE will get the message from the BK and the smart contracts BK_LEins and BK_LEchk will be sent. Algorithm 9 is as follows:

Algorithm 9. Smart contract BK_LEins and BK_LEchk of the proposed scheme.

function insert smart contract BK_LEins (string BK_id, string BK_detail, string BK_cert, string BK_tsp) {   count++;   BK[count].id = id;   BK[count].detail = detail;   BK[count].cert = cert;   BK[count].tsp = tsp; } sign string BK_key (BK_id, BK_detail, BK_cert, BK_tsp); verify string BK_key (BK_id, BK_detail, BK_cert, BK_tsp); function check smart contract BK_LEchk (string BK_id, string BK_detail, string BK_cert, string BK_tsp) {   return BK_id.exist;   return BK_detail.exist;   return BK_cert.exist;   return BK_tsp.exist; }

The LE calculates

$$B{C}_{BK-LE}=(r_{BK-LE},s_{BK-LE}),$$

(39)

where $(I{D}_{BC},B{C}_{BK-LE})$ is uploaded to the Blockchain Center.

3.9. Subscription Confirmation Phase

The Licensee (LE) submits the payment receipt to the Owner (OR), and the Owner (OR) returns the decoding parameters to the Licensee (LE), which can be used to obtain the digital content purchased or subscribed by the Licensee (LE). The flowchart of the subscription confirmation phase is shown in Figure 8.

Step 1: The LE generates a random value $k_{LE-OR}$, calculates

$$token=h(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},TI{D}_{BK-LE},T{S}_{LE-OR},I{D}_{BC}),$$

(40)

Calls for the ECDSA process by $(token,k_{LE-OR},d_{LE})$, gets $(r_{LE-OR},s_{LE-OR})$, calculates

$$En{c}_{LE-OR}=E_{P{K}_{OR}}(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},TI{D}_{BK-LE},T{S}_{LE-OR},I{D}_{BC}),$$

(41)

And sends $I{D}_{LE},En{c}_{LE-OR},(r_{LE-OR},s_{LE-OR})$ to the OR.

Step 2: The OR first calculates

$$(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},TI{D}_{BK-LE},T{S}_{LE-OR},I{D}_{BC})=D_{S{K}_{OR}}(En{c}_{LE-OR}),$$

(42)

Uses $T{S}_{NOW}-T{S}_{LE-OR}\le \Delta T$ to confirm whether the timestamp is valid, verifies $Cer{t}_{LE}$ with $P{K}_{LE}$, and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},TI{D}_{BK-LE},T{S}_{LE-OR},I{D}_{BC}),$$

(43)

Calls for the ECDSA verification process by $(token,r_{LE-OR},s_{LE-OR},Q_{LE})$ and is validated/invalidated. If the verification is passed the OR will get the message from the LE and trigger the smart contracts LE_ORins and LE_ORchk. Algorithm 10 is as follows:

Algorithm 10. Smart contract CA_APins and CA_APchk of the proposed scheme.

function insert smart contract LE_ORins (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   count++;   LE[count].id = id;   LE[count].detail = detail;   LE[count].cert = cert;   LE[count].tsp = tsp; } sign string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); verify string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); function check smart contract LE_ORchk (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   return LE_id.exist;   return LE_detail.exist;   return LE_cert.exist;   return LE_tsp.exist; }

The OR calculates

$$B{C}_{LE-OR}=(r_{LE-OR},s_{LE-OR}),$$

(44)

where $(I{D}_{BC},B{C}_{LE-OR})$ is uploaded to the blockchain center. Then, the OR generates a random value $k_{OR-LE}$ and calculates

$$b=h(Cer{t}_{LE},Vtim{e}_{LE}),$$

(45)

$$token=h(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},b,T{S}_{OR-LE},I{D}_{BC}),$$

(46)

Calls for the ECDSA process by $(token,k_{OR-LE},d_{OR})$, receives $(r_{OR-LE},s_{OR-LE})$, and calculates

$$En{c}_{OR-LE}=E_{P{K}_{LE}}(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},b,T{S}_{OR-LE},I{D}_{BC}),$$

(47)

Calls for the CA communication process and sends $I{D}_{OR},En{c}_{OR-LE},(r_{OR-LE},s_{OR-LE})$ to the LE.

Step 3: The LE first calculates

$$(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},b,T{S}_{OR-LE},I{D}_{BC})=D_{S{K}_{LE}}(En{c}_{OR-LE}),$$

(48)

Uses $T{S}_{NOW}-T{S}_{OR-LE}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},b,T{S}_{OR-LE},I{D}_{BC}),$$

(49)

Calls for the ECDSA verification process by $(token,r_{OR-LE},s_{OR-LE},Q_{LE})$ and is validated/invalidated. If the verification is passed, the LE will get the message from the OR and the smart contracts OR_LEins and OR_LEchk will be sent. Algorithm 11 is as follows:

Algorithm 11. Smart contract OR_LEins and OR_LEchk of the proposed scheme.

function insert smart contract OR_LEins (string OR_id, string OR_detail, string OR_cert, string OR_DCkey, string OR_tsp) {   count++;   OR[count].id = id;   OR[count].detail = detail;   OR[count].cert = cert;   OR[count]. DCkey = DCkey;   OR[count].tsp = tsp; } sign string OR_key (OR_id, OR_detail, OR_cert, OR_DCkey, OR_tsp); verify string OR_key (OR_id, OR_detail, OR_cert, OR_DCkey, OR_tsp); function check smart contract OR_LEchk (string OR_id, string OR_detail, string OR_cert, string OR_DCkey, string OR_tsp) {   return OR_id.exist;   return OR_detail.exist;   return OR_cert.exist;   return OR_DCkey;   return OR_tsp.exist; }

The LE calculates

$$B{C}_{OR-LE}=(r_{OR-LE},s_{OR-LE}),$$

(50)

where $(I{D}_{BC},B{C}_{OR-LE})$ is uploaded to the Blockchain Center.

3.10. Proxy Re-Encryption and Proxy-Key Update Phase

The Owner (OR) transmits the digital content purchased or subscribed to by the Licensee (LE) to the Digital Media Cloud (DMC) through proxy re-encryption. The Licensee (LE) can then obtain the digital content through the Digital Media Cloud (DMC). In addition, when the Owner (OR) deems it necessary, it can update the proxy key to the Digital Media Cloud (DMC) at any time. The Licensee (LE) must obtain a new proxy key through the Digital Media Cloud (DMC) to decrypt the content continuously. The flowchart of the proxy re-encryption and proxy-key update phase is shown in Figure 9.

Step 1: The OR generates a random value $k_{OR-DMC}$, calls for the proxy-key process by $(ke{y}_{OR-LE},a,g^k)$, and receives $(c_1,c_2)$ through the following Algorithm 12:

Algorithm 12. Proxy-key generation process between role A and role B.

string keyX − Y, a, gk function proxy-key process (keyX − Y, a, gk)   c1 = keyX − Y gak mod p;   c2 = gk mod p;   return (c1, c2);

The OR calculates

$$token=h(I{D}_{OR},M_{OR-DMC},Cer{t}_{OR},c_1,c_2,b/a,T{S}_{OR-DMC},I{D}_{BC}),$$

(51)

Calls for the ECDSA process by $(token,k_{OR-DMC},d_{OR})$, receives $(r_{OR-DMC},s_{OR-DMC})$, and calculates

$$En{c}_{OR-DMC}=E_{P{K}_{DMC}}(I{D}_{OR},M_{OR-DMC},Cer{t}_{OR},c_1,c_2,b/a,T{S}_{OR-DMC},I{D}_{BC}),$$

(52)

And sends $I{D}_{OR},En{c}_{OR-DMC},(r_{OR-DMC},s_{OR-DMC})$ to the DMC.

Step 2: The DMC first calculates

$$(I{D}_{OR},M_{OR-DMC},Cer{t}_{OR},c_1,c_2,b/a,T{S}_{OR-DMC},I{D}_{BC})=D_{S{K}_{DMC}}(En{c}_{OR-DMC}),$$

(53)

Uses $T{S}_{NOW}-T{S}_{OR-DMC}\le \Delta T$ to confirm whether the timestamp is valid, verifies $Cer{t}_{OR}$ with $P{K}_{OR}$, and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{OR},M_{OR-DMC},Cer{t}_{OR},c_1,c_2,b/a,T{S}_{OR-DMC},I{D}_{BC}),$$

(54)

Calls for the ECDSA verification process by $(token,r_{OR-DMC},s_{OR-DMC},Q_{OR})$ and is validated/invalidated. If the verification is passed, the DMC will get the message from the OR and trigger the smart contracts OR_DMCins and OR_DMCchk. Algorithm 13 is as follows:

Algorithm 13. Smart contract OR_DMCins and OR_DMCchk of the proposed scheme.

function insert smart contract OR_DMCins (string OR_id, string OR_detail, string OR_cert, string OR_DCkey, string OR_tsp) {   count++;   OR[count].id = id;   OR[count].detail = detail;   OR[count].cert = cert;   OR[count].DCkey = DCkey;   OR[count].tsp = tsp; } sign string OR_key (OR_id, OR_detail, OR_cert, OR_DCkey, OR_tsp); verify string OR_key (OR_id, OR_detail, OR_cert, OR_DCkey, OR_tsp); function check smart contract OR_DMCchk (string OR_id, string OR_detail, string OR_cert, string OR_DCkey, string OR_tsp) {   return OR_id.exist;   return OR_detail.exist;   return OR_cert.exist;   return OR_DCkey.exist;   return OR_tsp.exist; }

The DMC calculates

$$B{C}_{HP-MC}=(r_{HP-MC},s_{HP-MC}),$$

(55)

where $(I{D}_{BC},B{C}_{OR-DMC})$ is uploaded to the Blockchain Center. Then, the DMC generates a random value $k_{DMC-OR}$ and calculates

$$token=h(I{D}_{DMC},M_{DMC-OR},Cer{t}_{DMC},T{S}_{DMC-OR},I{D}_{BC}),$$

(56)

Calls for the ECDSA process by $(token,k_{DMC-OR},d_{DMC})$, receives $(r_{DMC-OR},s_{DMC-OR})$, and calculates

$$En{c}_{DMC-OR}=E_{P{K}_{OR}}(I{D}_{DMC},M_{DMC-OR},Cer{t}_{DMC},T{S}_{DMC-OR},I{D}_{BC}),$$

(57)

Calls for the CA communication process and sends $I{D}_{DMC},En{c}_{DMC-OR},(r_{DMC-OR},s_{DMC-OR})$ to the OR.

Step 3: The OR first calculates

$$(I{D}_{DMC},M_{DMC-OR},Cer{t}_{DMC},T{S}_{DMC-OR},I{D}_{BC})=D_{S{K}_{OR}}(En{c}_{DMC-OR}),$$

(58)

Uses $T{S}_{NOW}-T{S}_{DMC-OR}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{DMC},M_{DMC-OR},Cer{t}_{DMC},T{S}_{DMC-OR},I{D}_{BC}),$$

(59)

Calls for the ECDSA verification process by $(token,r_{DMC-OR},s_{DMC-OR},Q_{DMC})$ and is validated/invalidated. If the verification is passed the OR will get the message from the DMC and the smart contracts DMC_ORins and DMC_ORchk will be sent. Algorithm 14 is as follows:

Algorithm 14. Smart contract DMC_ORins and DMC_ORchk of the proposed scheme.

function insert smart contract DMC_ORins (string DMC_id, string DMC_detail, string DMC_cert, string DMC_tsp) {   count++;   DMC[count].id = id;   DMC[count].detail = detail;   DMC[count].cert = cert;   DMC[count].tsp = tsp; } sign string DMC_key (DMC_id, DMC_detail, DMC_cert, DMC_tsp); verify string DMC_key (DMC_id, DMC_detail, DMC_cert, DMC_tsp); function check smart contract DMC_ORchk (string DMC_id, string DMC_detail, string DMC_cert, string DMC_tsp) {   return DMC_id.exist;   return DMC_detail.exist;   return DMC_cert.exist;   return DMC_tsp.exist; }

The OR calculates

$$B{C}_{DMC-OR}=(r_{DMC-OR},s_{DMC-OR}),$$

(60)

where $(I{D}_{BC},B{C}_{MC-HP})$ is uploaded to the Blockchain Center.

3.11. Digital Media Browsing Phase

After the above phases, the Licensee (LE) can obtain the digital content through the Digital Media Cloud (DMC). The Licensee (LE) can use the decryption parameters of the proxy re-encryption operation to view the digital content. The flowchart of the digital media browsing phase is shown in Figure 10.

Step 1: LE generates a random value $k_{LE-DMC}$, and calculates

$$token=h(I{D}_{LE},M_{LE-DMC},Cer{t}_{LE},T{S}_{LE-DMC},I{D}_{BC}),$$

(61)

Calls for the ECDSA process by $(token,k_{LE-DMC},d_{LE})$, receives $(r_{LE-DMC},s_{LE-DMC})$, and calculates

$$En{c}_{LE-DMC}=E_{P{K}_{DMC}}(I{D}_{LE},M_{LE-DMC},Cer{t}_{LE},T{S}_{LE-DMC},I{D}_{BC}),$$

(62)

And sends $I{D}_{LE},En{c}_{LE-DMC},(r_{LE-DMC},s_{LE-DMC})$ to the DMC.

Step 2: The DMC first calculates

$$(I{D}_{LE},M_{LE-DMC},Cer{t}_{LE},T{S}_{LE-DMC},I{D}_{BC})=D_{S{K}_{DMC}}(En{c}_{LE-DMC}),$$

(63)

Uses $T{S}_{NOW}-T{S}_{LE-DMC}\le \Delta T$ to confirm whether the timestamp is valid, verifies $Cer{t}_{LE}$ with $P{K}_{LE}$, and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{LE},M_{LE-DMC},Cer{t}_{LE},T{S}_{LE-DMC},I{D}_{BC}),$$

(64)

Calls for the ECDSA verification process by $(token,r_{LE-DMC},s_{LE-DMC},Q_{LE})$ and is validated/invalidated. If the verification is passed, the DMC will get the message from the LE and trigger the smart contracts LE_DMCins and LE_DMCchk. Algorithm 15 is as follows:

Algorithm 15. Smart contract LE_DMCins and LE_DMCchk of the proposed scheme.

function insert smart contract LE_DMCins (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   count++;   LE[count].id = id;   LE[count].detail = detail;   LE[count].cert = cert;   LE[count].tsp = tsp; } sign string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); verify string LE_key (LE_id, LE_detail, LE_cert, LE_tsp); function check smart contract LE_DMCchk (string LE_id, string LE_detail, string LE_cert, string LE_tsp) {   return LE_id.exist;   return LE_detail.exist;   return LE_cert.exist;   return LE_tsp.exist; }

The DMC calculates

$$B{C}_{LE-DMC}=(r_{LE-DMC},s_{LE-DMC}),$$

(65)

where $(I{D}_{BC},B{C}_{LE-DMC})$ is uploaded to the Blockchain Center. Then, the DMC generates a random value $k_{DMC-LE}$ and calculates

$$c_1{}^{\prime }=c_1{}^{(b/a)},$$

(66)

$$token=h(I{D}_{DMC},M_{DMC-LE},Cer{t}_{DMC},c_1{}^{\prime },c_2,T{S}_{DMC-LE},I{D}_{BC}),$$

(67)

Calls for the ECDSA process by $(token,k_{DMC-LE},d_{DMC})$, receives $(r_{DMC-LE},s_{DMC-LE})$, and calculates

$$En{c}_{DMC-LE}=E_{P{K}_{LE}}(I{D}_{DMC},M_{DMC-LE},Cer{t}_{DMC},c_1{}^{\prime },c_2,T{S}_{DMC-LE},I{D}_{BC}),$$

(68)

Calls for the CA communication process and sends $I{D}_{DMC},En{c}_{DMC-LE},(r_{DMC-LE},s_{DMC-LE})$ to the LE.

Step 3: The LE first calculates

$$(I{D}_{DMC},M_{DMC-LE},Cer{t}_{DMC},c_1\prime ,c_2,T{S}_{DMC-LE},I{D}_{BC})=D_{S{K}_{LE}}(En{c}_{DMC-LE}),$$

(69)

Uses $T{S}_{NOW}-T{S}_{DMC-LE}\le \Delta T$ to confirm whether the timestamp is valid and then verifies the correctness of the ECDSA signature, and calculates

$$token=h(I{D}_{DMC},M_{DMC-LE},Cer{t}_{DMC},c_1\prime ,c_2,T{S}_{DMC-LE},I{D}_{BC}),$$

(70)

Calls for the ECDSA verification process by $(token,r_{DMC-LE},s_{DMC-LE},Q_{LE})$ and is validated/invalidated. If the verification is passed, the LE will get the message from the DMC and the smart contracts DMC_LEins and DMC_LEchk will be sent. Algorithm 16 is as follows:

Algorithm 16. Smart contract DMC_LEins and DMC_LEchk of the proposed scheme.

function insert smart contract DMC_LEins (string DMC_id, string DMC_detail, string DMC_cert, string DMC_DCkey, string DMC_tsp) {   count++;   DMC[count].id = id;   DMC[count].detail = detail;   DMC[count].cert = cert;   DMC[count].DCkey = DCkey;   DMC[count].tsp = tsp; } sign string DMC_key (DMC_id, DMC_detail, DMC_cert, DMC_ DCkey, DMC_tsp); verify string DMC_key (DMC_id, DMC_detail, DMC_cert, DMC_ DCkey, DMC_tsp); function check smart contract DMC_LEchk (string DMC_id, string DMC_detail, string DMC_cert, string DMC_DCkey, string DMC_tsp) {   return DMC_id.exist;   return DMC_detail.exist;   return DMC_cert.exist;   return DMC_DCkey.exist;   return DMC_tsp.exist; }

The LE calculates

$$B{C}_{DMC-LE}=(r_{DMC-LE},s_{DMC-LE}),$$

(71)

where $(I{D}_{BC},B{C}_{DMC-LE})$ is uploaded to the Blockchain Center. Finally, the LE calculates

$$ke{y}_{OR\_LE}=c_1\prime /c_2{}^{(b)},$$

(72)

and the session key $ke{y}_{OR\_LE}$ is established successfully. At this time, the LE can browse the digital media through the media playback application.

3.12. Arbitration Mechanism Phase

When there is a dispute between the DMC, OR, LE, and BK, it is conducted through the arbitration mechanism. When the LE requests arbitration from the Arbitration Institution (AI), the AI compares blockchain data through the signature message to confirm the subscription contract. The arbitration mechanism verification phase is shown in Figure 11.

Step 1: AI can download the certificate, signature, and blockchain data of the package through $I{D}_{BC}$, and then the AI verifies

$$B{C}_{LE-OR}\stackrel{?}{=}h(r_{LE-OR},s_{LE-OR})$$

(73)

And

$$B{C}_{OR-LE}\stackrel{?}{=}h(r_{OR-LE},s_{OR-LE}).$$

(74)

If the verification fails, there is no subscription contract between the LE and OR, thus, the OR does not need to provide the digital content to the LE.

Step 2: If the signature between the LE and OR, and the blockchain data are verified, the AI will verify

$$B{C}_{LE-BK}\stackrel{?}{=}h(r_{LE-BK},s_{LE-BK})$$

(75)

And

$$B{C}_{BK-LE}\stackrel{?}{=}h(r_{BK-LE},s_{BK-LE}).$$

(76)

If the verification fails, the LE has applied to the OR for subscription digital content but has not paid for the subscription, thus, the OR does not need to provide digital content to the LE.

Step 3: If the signature between the LE and BK, and the blockchain data are verified, the AI will verify

$$B{C}_{LE-DMC}\stackrel{?}{=}h(r_{LE-DMC},s_{LE-DMC})$$

(77)

And

$$B{C}_{LE-DMC}\stackrel{?}{=}h(r_{LE-DMC},s_{LE-DMC}).$$

(78)

If the verification fails, the LE has attempted to obtain unauthorized digital content, thus, the OR does not need to provide digital content to the LE.

Step 4: If the signature between the LE and DMC, and the blockchain data are verified, the blockchain data has been fully verified, and the AI can confirm that the subscription contract is valid. Therefore, the OR should provide the digital content to the LE in accordance with the subscription contract.

4. Security Analysis

4.1. Decentralization and Information Sharing

The information is processed by each party and signed by each party with his/her private key in the proposed scheme. We adopt the blockchain architecture of Hyperledger. Under the Hyperledger structure, alliance members must first register with the Blockchain Center before they can communicate. The structure of the Hyperledger allows roles of the same nature to form alliances, and a single Hyperledger structure can have multiple alliances. The circulation of all information is transparent and open for members within the same alliance. Based on the blockchain architecture, one node is unable to deceive other nodes. For the members of the same alliance, this realizes the trust relationship between the members and further constitutes the trust relationship between multiple alliances. Therefore, the solution proposed in this article realizes the decentralization and information sharing of alliance members under the blockchain Hyperledger structure.

4.2. Openness and Privacy

This article uses the ECDSA-based blockchain mechanism, combined with the encryption mechanism of the public key system. The message is signed by the private key and uploaded to the blockchain Center, that is, all members of the same alliance can be verify the correctness of the message, demonstrating the openness of the blockchain system. In addition, the plain text of the message is also encrypted by the public key, and only the alliance members with the corresponding private key can decrypt the message settings, achieving privacy protection. Through blockchain technology, seemingly contradictory medical record sharing and privacy protection can be realized at the same time.

4.3. Proxy Re-Encryption for Access Control

This paper adopts the blockchain architecture based on Hyperledger. Hyperledger adopts the structure of a consortium chain. Only members of the consortium can verify the data on the blockchain. This article is structured primarily to share digital content. To prevent digital content from being freely shared without authorization, various encryption techniques are used to protect the digital content. Only if the licensee has purchased or subscribed to the digital content, the licensee can access the digital content through the key issued by the owner. Through the proxy re-encryption mechanism, when the licensee illegally shares digital content, the owner can revoke the licensee’s access rights at any time. Through the ECDSA of the blockchain system combined with proxy re-encryption to achieve access control, messages can be exchanged with alliance members safely and conveniently.

4.4. Verifiable

This paper achieves several verifiability goals through the architecture of the blockchain. First, digital certificate verification can be publicly used to verify the legitimacy of each role’s identity, and each role’s public key and signature information are also open to alliance members. In addition, based on the characteristics of the blockchain, the process of purchasing or subscribing to digital content from the licensee to the owner also needs to be uploaded to the blockchain and is subject to public supervision.

Let us take the message transmitted by the LE and OR as an example. When the LE sends an ECDSA signed message to the OR. The OR must first verify the correctness of the timestamp and signature, then generate blockchain data $B{C}_{LE-OR}=(r_{LE-OR},s_{LE-OR})$, and upload the blockchain data to the certification authority ID_BC as an index. In other words, after verifying the correctness of the timestamp and signature of each role receiving the message, the correctness of the blockchain data generated by the previous role is also verified. Thus, the characteristics of public verification through ECDSA digital signature and blockchain technology are achieved in the proposed scheme.

4.5. Traceable

The data block containing the transaction information is permanently stored on the blockchain and is unable to be tampered with after the message is uploaded to the blockchain. For example, when we want to verify and trace the legality of the blockchain data between the LE and BK in the bank payment phase, we can compare and verify $B{C}_{LE-BK}=(r_{LE-BK},s_{LE-BK})$ and $B{C}_{BK-LE}=(r_{BK-LE},s_{BK-LE})$. When we want to verify and track whether the blockchain data between the LE and DMC is legal in digital media streaming, we can compare and verify $B{C}_{LE-DMC}=(r_{LE-DMC},s_{LE-DMC})$ and $B{C}_{DMC-LE}=(r_{DMC-LE},s_{DMC-LE})$.

4.6. Mutual Authentication

The main goal of the scheme is to authenticate the private key of role A and role B in each communication phase of the proposed scheme. System role A or role B can represent the Certificate Authority (CA), Digital Medical Cloud (DMC), Owner (OR), Licensee (LE), and Bank (BK).

$$\begin{array}{c}G1:A|\equiv A\stackrel{x_{B-A}}{\leftrightarrow }B\\ G2:A|\equiv B|\equiv A\stackrel{x_{B-A}}{\leftrightarrow }B\\ G3:B|\equiv A\stackrel{x_{B-A}}{\leftrightarrow }B\\ G4:B|\equiv A|\equiv A\stackrel{x_{B-A}}{\leftrightarrow }B\\ G5:A\equiv I{D}_B\\ G6:A|\equiv B|\equiv I{D}_B\\ G7:B|\equiv I{D}_A\\ G8:B|\equiv A|\equiv I{D}_A\end{array}$$

According to the proposed scheme, BAN logic is applied to produce an idealized form as follows:

$$\begin{array}{c}M1:(<I{D}_A,k_{A-B},T{S}_{A-B}{>}_{P{K}_B},<H(I{D}_A,k_{A-B},T{S}_{A-B}){>}_{x_{A-B}})\\ M2:(<I{D}_B,k_{B-A},T{S}_{B-A}{>}_{P{K}_A},<H(I{D}_B,k_{B-A},T{S}_{B-A}){>}_{x_{B-A}})\end{array}$$

To analyze the proposed scheme, the following assumptions are made:

$$\begin{array}{c}A1:A|\equiv \#\left(k_{A-B}\right)\\ A2:B|\equiv \#\left(k_{A-B}\right)\\ A3:A|\equiv \#\left(k_{B-A}\right)\\ A4:B|\equiv \#\left(k_{B-A}\right)\\ A5:A|\equiv B|\Rightarrow A\stackrel{x_{B-A}}{\leftrightarrow }B\\ A6:B|\equiv A|\Rightarrow A\stackrel{x_{B-A}}{\leftrightarrow }B\\ A7:A|\equiv B|\Rightarrow I{D}_B\\ A8:B|\equiv A|\Rightarrow I{D}_A\end{array}$$

According to these assumptions and rules of BAN logic, the main proof of each communication phase is as follows:

• Role B authenticates role A.

We derive the following statement by M1 and the seeing rule:

$$B⊲(<I{D}_A,k_{A-B},T{S}_{A-B}{>}_{P{K}_B},<H(I{D}_A,k_{A-B},T{S}_{A-B}){>}_{x_{A-B}}) (Statement 1)$$

We derive the following statement by A2 and the freshness rule:

$$B|\equiv \#(<I{D}_A,k_{A-B},T{S}_{A-B}{>}_{P{K}_B},<H(I{D}_A,k_{A-B},T{S}_{A-B}){>}_{x_{A-B}}) (Statement 2)$$

We derive the following statement by (Statement 1), A4, and the message meaning rule:

$$B|\equiv A|~(<I{D}_A,k_{A-B},T{S}_{A-B}{>}_{P{K}_B},<H(I{D}_A,k_{A-B},T{S}_{A-B}){>}_{x_{A-B}}) (Statement 3)$$

We derive the following statement by (Statement 2), (Statement 3), and the nonce verification rule:

$$B|\equiv A|\equiv (<I{D}_A,k_{A-B},T{S}_{A-B}{>}_{P{K}_B},<H(I{D}_A,k_{A-B},T{S}_{A-B}){>}_{x_{A-B}}) (Statement 4)$$

We derive the following statement by (Statement 4) and the belief rule:

$$B|\equiv A|\equiv A\stackrel{x_{A-B}}{\leftrightarrow }B (Statement 5)$$

We derive the following statement by (Statement 5), A6, and the jurisdiction rule:

$$B|\equiv A\stackrel{x_{A-B}}{\leftrightarrow }B (Statement 6)$$

We derive the following statement by (Statement 6) and the belief rule:

$$B|\equiv A|\equiv I{D}_A (Statement 7)$$

We derive the following statement by (Statement 7), A8, and the jurisdiction rule:

$$B|\equiv I{D}_A (Statement 8)$$

Role A authenticates role B.

We derive the following statement by M2 and the seeing rule:

$$A⊲(<I{D}_B,k_{B-A},T{S}_{B-A}{>}_{P{K}_A},<H(I{D}_B,k_{B-A},T{S}_{B-A}){>}_{x_{B-A}}) (Statement 9)$$

We derive the following statement by A1 and the freshness rule:

$$A|\equiv \#(<I{D}_B,k_{B-A},T{S}_{B-A}{>}_{P{K}_A},<H(I{D}_B,k_{B-A},T{S}_{B-A}){>}_{x_{B-A}}) (Statement 10)$$

We derive the following statement by (Statement 9), A3, and the message meaning rule:

$$A|\equiv B|~(<I{D}_B,k_{B-A},T{S}_{B-A}{>}_{P{K}_A},<H(I{D}_B,k_{B-A},T{S}_{B-A}){>}_{x_{B-A}}) (Statement 11)$$

We derive the following statement by (Statement 10), (Statement 11), and the nonce verification rule:

$$A|\equiv B|\equiv (<I{D}_B,k_{B-A},T{S}_{B-A}{>}_{P{K}_A},<H(I{D}_B,k_{B-A},T{S}_{B-A}){>}_{x_{B-A}}) (Statement 12)$$

We derive the following statement by (Statement 12) and the belief rule:

$$A|\equiv B|\equiv A\stackrel{x_{B-A}}{\leftrightarrow }B (Statement 13)$$

We derive the following statement by (Statement 13), A5, and the jurisdiction rule:

$$A|\equiv A\stackrel{x_{B-A}}{\leftrightarrow }B (Statement 14)$$

We derive the following statement by (Statement 14) and the belief rule:

$$A|\equiv B|\equiv I{D}_B (Statement 15)$$

We derive the following statement by (Statement 15), A7, and the jurisdiction rule:

$$A|\equiv I{D}_B (Statement16 )$$

By (Statement 6), (Statement 8), (Statement 14), and (Statement 16), it can be proved that, in the proposed scheme, role A and role B authenticate each other. Moreover, it can also be proved that the proposed scheme can authenticate the private key of role A and role B.

We take the proxy re-encryption and proxy-key update phase of the proposed scheme, for example, the digital media cloud authenticates the owner by $x_{OR-DMC}\prime \stackrel{?}{=}{r}_{OR-DMC}\mathrm{mod}n$. If it passes the verification, the digital media cloud authenticates the legality of the owner. The owner authenticates the digital media cloud by $x_{DMC-OR}\prime \stackrel{?}{=}{r}_{DMC-OR}\mathrm{mod}n$. If it passes the verification, the owner authenticates the legality of the digital media cloud. The proxy re-encryption and proxy-key update phase of the proposed scheme thus guarantee mutual authentication between the owner and the digital media cloud.

4.7. Integrity and Unforgery

To ensure the integrity of the message and avoid being modified by counterfeiting, this article uses a timestamp and signature mechanism to irreversibly generate a string of random numbers and letters for the data placed in each block. The attacker cannot infer the original text from the string so that the transmitted message can be fully trusted. After the hash function operation, the message is described as follows.

$$\begin{array}{c}token=h(I{D}_{AP},M_{AP-CA},Cer{t}_{AP},T{S}_{AP-CA},I{D}_{BC})\\ token=h(I{D}_{CA},M_{CA-AP},Cer{t}_{CA},T{S}_{CA-AP},I{D}_{BC})\\ token=h(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},T{S}_{LE-OR},I{D}_{BC})\\ token=h(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},TI{D}_{OR-LE},T{S}_{OR-LE},I{D}_{BC})\\ token=h(I{D}_{LE},M_{LE-BK},Cer{t}_{LE},TI{D}_{OR-LE},T{S}_{LE-BK},I{D}_{BC})\\ token=h(I{D}_{BK},M_{BK-LE},Cer{t}_{BK},TI{D}_{BK-LE},T{S}_{BK-LE},I{D}_{BC})\\ token=h(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},TI{D}_{BK-LE},T{S}_{LE-OR},I{D}_{BC})\\ token=h(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},b,T{S}_{OR-LE},I{D}_{BC})\\ token=h(I{D}_{OR},M_{OR-DMC},Cer{t}_{OR},c_1,c_2,b/a,T{S}_{OR-DMC},I{D}_{BC})\\ token=h(I{D}_{DMC},M_{DMC-OR},Cer{t}_{DMC},T{S}_{DMC-OR},I{D}_{BC})\\ token=h(I{D}_{LE},M_{LE-DMC},Cer{t}_{LE},T{S}_{LE-DMC},I{D}_{BC})\\ token=h(I{D}_{DMC},M_{DMC-LE},Cer{t}_{DMC},c_1{}^{\prime },c_2,T{S}_{DMC-LE},I{D}_{BC})\end{array}$$

The hash value cannot be reversely restored to the original content, so this protocol implements the feature that the message cannot be tampered with.

4.8. Non-Repudiation

In the proposed scheme, the content of the message sent by each party will be signed by the sender using his/her own ECDSA private key. The receiver will verify the message with the public key of the sender after receiving the message from the sender. If the message is verified successfully, the sender is unable to deny the content of the transmitted message. Then, the message is uploaded to the Blockchain Center, and the inherent timestamp function of the blockchain records the creation time. To modify the content of the message that has been uploaded to the Blockchain Center, it is necessary to control more than 51% of the members of the alliance, which will be very difficult to achieve.

Table 1. Non-repudiation of the proposed scheme.

Item	Signature	Sender	Receiver	Signature Verification
Phase
CA communication process	$(r_{AP-CA},s_{AP-CA})$	AP	CA	$x_{AP-CA}{}^{\prime }\stackrel{?}{=}{r}_{AP-CA}\mathrm{mod}n$
	$(r_{CA-AP},s_{CA-AP})$	CA	AP	$x_{CA-AP}{}^{\prime }\stackrel{?}{=}{r}_{CA-AP}\mathrm{mod}n$
Subscription negotiation/confirmation phase	$(r_{LE-OR},s_{LE-OR})$	LE	OR	$x_{LE-OR}{}^{\prime }\stackrel{?}{=}{r}_{LE-OR}\mathrm{mod}n$
	$(r_{OR-LE},s_{OR-LE})$	OR	LE	$x_{OR-LE}{}^{\prime }\stackrel{?}{=}{r}_{OR-LE}\mathrm{mod}n$
Bank payment phase	$(r_{LE-BK},s_{LE-BK})$	LE	BK	$x_{LE-BK}{}^{\prime }\stackrel{?}{=}{r}_{LE-BK}\mathrm{mod}n$
	$(r_{BK-LE},s_{BK-LE})$	BK	LE	$x_{BK-LE}{}^{\prime }\stackrel{?}{=}{r}_{BK-LE}\mathrm{mod}n$
Proxy re-encryption and proxy-key update phase	$(r_{OR-DMC},s_{OR-DMC})$	OR	DMC	$x_{OR-DMC}{}^{\prime }\stackrel{?}{=}{r}_{OR-DMC}\mathrm{mod}n$
	$(r_{DMC-OR},s_{DMC-OR})$	DMC	OR	$x_{DMC-OR}{}^{\prime }\stackrel{?}{=}{r}_{DMC-OR}\mathrm{mod}n$
Digital media browsing phase	$(r_{LE-DMC},s_{LE-DMC})$	LE	DMC	$x_{LE-DMC}{}^{\prime }\stackrel{?}{=}{r}_{LE-DMC}\mathrm{mod}n$
	$(r_{DMC-LE},s_{DMC-LE})$	DMC	LE	$x_{DMC-LE}\prime \stackrel{?}{=}{r}_{DMC-LE}\mathrm{mod}n$

is an undeniable description of each role in the proposed scheme.

4.9. Resist Sybil Attack

We have applied digital signature and public key technology to achieve the goals in this article. The receiver can verify whether the data has been tampered with by verifying the signature when malicious persons tamper with data. The user can then further use the public key to encrypt the transmitted data. Malicious attackers do not have the correct private key; thus they are unable to obtain the encrypted data. The data cannot be tampered with because malicious attackers cannot access it.

Scenario:

The attacker intercepts the message from the sender to the receiver and tampers with the message before sending it to the receiver.

Analysis:

The attacker will fail because our proposed method uses a public key to encrypt data as follows.

$$\begin{array}{c}En{c}_{AP-CA}=E_{P{K}_{CA}}(I{D}_{AP},M_{AP-CA},Cer{t}_{AP},T{S}_{AP-CA},I{D}_{BC})\\ En{c}_{CA-AP}=E_{P{K}_{AP}}(I{D}_{CA},M_{CA-AP},Cer{t}_{CA},T{S}_{CA-AP},I{D}_{BC})\\ En{c}_{LE-OR}=E_{P{K}_{OR}}(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},T{S}_{LE-OR},I{D}_{BC})\\ En{c}_{OR-LE}=E_{P{K}_{LE}}(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},TI{D}_{OR-LE},T{S}_{OR-LE},I{D}_{BC})\\ En{c}_{LE-BK}=E_{P{K}_{BK}}(I{D}_{LE},M_{LE-BK},Cer{t}_{LE},TI{D}_{OR-LE},T{S}_{LE-BK},I{D}_{BC})\\ En{c}_{BK-LE}=E_{P{K}_{LE}}(I{D}_{BK},M_{BK-LE},Cer{t}_{BK},TI{D}_{BK-LE},T{S}_{BK-LE},I{D}_{BC})\\ En{c}_{LE-OR}=E_{P{K}_{OR}}(I{D}_{LE},M_{LE-OR},Cer{t}_{LE},TI{D}_{BK-LE},T{S}_{LE-OR},I{D}_{BC})\\ En{c}_{OR-LE}=E_{P{K}_{LE}}(I{D}_{OR},M_{OR-LE},Cer{t}_{OR},b,T{S}_{OR-LE},I{D}_{BC})\\ En{c}_{OR-DMC}=E_{P{K}_{DMC}}(I{D}_{OR},M_{OR-DMC},Cer{t}_{OR},c_1,c_2,b/a,T{S}_{OR-DMC},I{D}_{BC})\\ En{c}_{DMC-OR}=E_{P{K}_{OR}}(I{D}_{DMC},M_{DMC-OR},Cer{t}_{DMC},T{S}_{DMC-OR},I{D}_{BC})\\ En{c}_{LE-DMC}=E_{P{K}_{DMC}}(I{D}_{LE},M_{LE-DMC},Cer{t}_{LE},T{S}_{LE-DMC},I{D}_{BC})\\ En{c}_{DMC-LE}=E_{P{K}_{LE}}(I{D}_{DMC},M_{DMC-LE},Cer{t}_{DMC},c_1{}^{\prime },c_2,T{S}_{DMC-LE},I{D}_{BC})\end{array}$$

Malicious attackers do not have the correct private key; thus they are unable to obtain the encrypted data. Even if the attacker intercepts the message, the attacker is unable to decrypt and tamper with the message. In short, the attacker is unable to modify the message and send the message to the recipient.

5. Discussions

5.1. Computation Cost

We analyzed the computational costs at each stage in

Table 2. Computation costs of the proposed scheme.

Party	LE	OR	BK	DMC
Phase
Subscription negotiation phase	2Tasy + 2Tcmp +2Th + 7Tmul	2Tasy + 2Tcmp +3Th + 7Tmul	N/A	N/A
Bank payment phase	2Tasy + 2Tcmp +2Th + 7Tmul	N/A	2Tasy + 2Tcmp +2Th + 7Tmul	N/A
Subscription confirmation phase	2Tasy + 2Tcmp +2Th + 7Tmul	2Tasy + 2Tcmp +3Th + 7Tmul	N/A	N/A
Proxy re-encryption and proxy-key update phase	N/A	2Tasy + 2Tcmp +2Th + 9Tmul	N/A	2Tasy + 2Tcmp +2Th + 7Tmul
Digital media browsing phase	2Tasy + 2Tcmp +2Th + 9Tmul	N/A	N/A	2Tasy + 2Tcmp +2Th + 8Tmul

Notes: T_asy: The time required for an asymmetrical signature/verifying a signature. T_cmp: The time required for a comparison operation. T_h: The time required for a one-way hash function. T_mul: The time required for a multiplication operation.

. We use the asymmetrical encryption technology, comparison, hash function, and multiplication operation as the basis for calculating the costs.

5.2. Communication Performance

We analyzed the communication costs of each phase in

Table 3. Communication costs of the proposed scheme.

Party	Message Length	Round	4G (100 Mbps)	5G (20 Gbps)
Phase
CA communication process	2Tsig + 2Tasy + 5Tohter = 2 * 512 + 2 * 1024+ 2 * 80 = 3232 bits	2	3232/102,400 =0.032 ms	3232/20,480,000 =0.16 us
Subscription negotiation/confirmation phase	2Tsig + 2Tasy + 5Tohter= 2 * 512 + 2 * 1024 + 2 * 80 = 3232 bits	2	3232/102,400= 0.032 ms	3232/20,480,000= 0.16 us
Bank payment phase	2Tsig + 2Tasy + 5Tohter= 2 * 512 + 2 * 1024+ 2 * 80 = 3232 bits	2	3232/102400= 0.032 ms	3232/20,480,000= 0.16 us
Proxy re-encryption and proxy-key update phase	2Tsig + 2Tasy + 5Tohter= 2 * 512 + 2 * 1024+ 2 * 80 = 3232 bits	2	3232/102,400= 0.032 ms	3232/20,480,000= 0.16 us
Digital media browsing phase	2Tsig + 2Tasy + 5Tohter= 2 * 512 + 2 * 1024+ 2 * 80 = 3232 bits	2	3232/102,400= 0.032 ms	3232/20,480,000= 0.16 us

Notes: T_sig: The time required to transmit an ECDSA signature (512 bits). T_asy: The time required to transmit an asymmetric message (1024 bits). T_ohter: The time required to transmit information (80 bits).

. The maximum transmission speed is 100 Mbps in a 4G environment. The maximum transmission speed is 20 Gbps [43] in a 5G environment. From the analysis in Table 3, we can see that our proposed scheme has an excellent performance in both 4G and 5G environments.

5.3. Characteristic Comparison

In this section, we compare our proposed scheme and existing digital media management surveys in

Table 4. Comparison of the proposed and existing digital media management surveys.

Authors	Year	Objective	1	2	3	4	5	6
Ma et al. [21]	2018	Blockchain for digital rights management	Y	NA	Y	Y	NA	Y
Ma et al. [23]	2018	A master-slave blockchain paradigm and application in digital rights management	Y	NA	Y	Y	NA	NA
Mishra et al. [24]	2021	Proposed a provably secure content distribution framework for portable DRM systems	NA	NA	Y	Y	NA	Y
Hassan et al. [25]	2020	Proposed a robust computational DRM framework for protecting multimedia content by using AES and ECC	NA	NA	Y	NA	NA	NA
Rana et al. [26]	2021	Proposed a computational efficient authenticated digital content distribution framework for DRM systems	NA	NA	Y	NA	NA	Y
Shrestha et al. [27]	2020	Using blockchain for online multimedia management: characteristics of existing platforms	Y	NA	NA	Y	NA	Y
Zhaofeng et al. [30]	2018	A new blockchain-based trusted DRM scheme for built-in content protection	Y	NA	Y	Y	NA	Y
Our scheme	2022	Proposed a digital media subscription mechanism based on the Hyperledger blockchain architecture combined with proxy re-encryption	Y	Y	Y	Y	Y	Y

Notes: 1: Blockchain-focused, 2: Arbitration mechanism, 3: Detail protocol, 4: Defend against attacks, 5: Proxy re-encryption, 6: Security analysis. NA: Not Available, Y: Yes.

.

5.4. Limitations

In the proposed scheme, all roles need to register in the Blockchain Center and obtain the public-private key pair of elliptic curve signatures to use the system. In addition, there needs to be a digital media access platform planned by the government or businesses in the environment.

6. Conclusions

Uploading digital media to the blockchain is an irresistible trend. On-chain digital media will bring great convenience to the exchange of human knowledge and spirituality. For example, in the sharing of music rights, assuming that the songwriter and the singer belong to the same music alliance, the Blockchain Center will issue authentication keys to these members. After this, alliance members can legally communicate and exchange data in the future. Through the blockchain data, the ownership status of the song will be completely recorded. In addition, there is the advantage of automatic benefit distribution. When a customer buys or subscribes to the song, the profit will be distributed through the smart contracts, and the interests of the creator of the song will be guaranteed so that the creator can have more work in the future.

While the blockchain makes it easier to transmit digital media, it also has the potential to do more harm to creators. If the licensee violates the agreement with the creator and arbitrarily resells or shares the digital media with others, the creator will no longer be willing to continue to provide high-quality work. Therefore, this study proposes a digital media subscription mechanism based on the Hyperledger blockchain architecture combined with proxy re-encryption. When the authorized person violates the agreement with the creator, the creator can revoke the authorized person’s access rights to the digital media at any time, to realize more secure and convenient digital media transmission. The scheme proposed in this study addresses the potential security issues of multiple threat models. We also applied the BAN logic analysis and proof procedure to ensure that the proposed protocol satisfies mutual authentication. Under the premise of achieving this security, excellent communication and computing costs can still be maintained. By the way, we also propose an arbitration mechanism to solve disputes between the DMC, OR, LE, and BK.