龐曉瓊，楊婷，陳文俊，2，王云婷，劉天野

（1.中北大學大數(shù)據(jù)學院，太原 030051；2.中國人民銀行太原中心支行，太原 030001；3.中北大學朔州校區(qū)電氣與計算機工程管理部，山西朔州 036000）

0 引言

隨著互聯(lián)網(wǎng)技術的快速發(fā)展，網(wǎng)上交易和傳播的數(shù)字內(nèi)容越來越多，然而數(shù)字化內(nèi)容存在被惡意復制、傳播、下載等風險，這會給創(chuàng)作者帶來巨大的損失，因此防止數(shù)字內(nèi)容被非法使用是必要的［1］。

數(shù)字權(quán)限管理（Digital Rights Management，DRM）可以防止數(shù)字內(nèi)容被非法使用［2］，DRM 通過數(shù)字內(nèi)容的加密和安全許可等一系列手段防止數(shù)字內(nèi)容被非法使用，確保數(shù)字內(nèi)容在公平、合理、安全許可的條件下被使用和消費［3］。在傳統(tǒng)的DRM 中，數(shù)字內(nèi)容加密密鑰通常由許可證服務器保存和分發(fā)［4］，由于服務器的高速運算能力和強大的I/O 外部數(shù)據(jù)吞吐能力，內(nèi)容加密密鑰的獲取時間較短，然而在消費者向許可證服務器發(fā)送獲取許可請求以及許可證服務器向消費者發(fā)送許可證的過程中，為防止信息被篡改，需要對信息進行完整性驗證，這是麻煩和不便的。

幸運的是，在解決傳統(tǒng)DRM 中的問題時，區(qū)塊鏈可以作出貢獻。區(qū)塊鏈中，每一筆交易在上鏈之前由礦工來進行驗證，交易上鏈后通過SHA256 哈希存儲在二叉Merkle 樹的每個節(jié)點上，兩個子節(jié)點的值連接之后，再經(jīng)哈希運算得到父節(jié)點的值，如此反復執(zhí)行兩兩哈希，直到生成根哈希值，即交易Merkle 根。通過Merkle 根，塊內(nèi)任何交易數(shù)據(jù)的篡改都會被檢測到，從而確保交易數(shù)據(jù)的完整性；而且在區(qū)塊鏈中，每個區(qū)塊都含有上一個區(qū)塊的hash 值，如果修改其中某一個區(qū)塊，在這之后的區(qū)塊都要重新計算，除非能控制系統(tǒng)中超過51%的節(jié)點，否則單個節(jié)點對數(shù)據(jù)的修改是無效的。因此基于區(qū)塊鏈來實現(xiàn)DRM，消息接收方的驗證工作量會顯著減少，而接收者也只需執(zhí)行簡單且很少的計算［5］，可以較好地解決傳統(tǒng)DRM中消息完整性驗證較為麻煩和不便的問題。

因此，很多學者積極地將數(shù)字權(quán)限管理與區(qū)塊鏈技術結(jié)合在一起［6-12］，利用區(qū)塊鏈記錄權(quán)限交易信息，實現(xiàn)權(quán)限信息的防篡改和公開透明。然而在基于區(qū)塊鏈的DRM 解決方案中，數(shù)字內(nèi)容的安全存儲及數(shù)字內(nèi)容加密密鑰的安全有效管理也是需要考慮的關鍵問題。目前很多基于區(qū)塊鏈的DRM方案是由內(nèi)容提供商來管理內(nèi)容加密密鑰的，在消費者購買數(shù)字產(chǎn)品時，內(nèi)容提供商需實時加密內(nèi)容加密密鑰，當購買該數(shù)字產(chǎn)品的消費者顯著增加時，內(nèi)容提供商的計算量相應地也會顯著增加；對消費者來說，內(nèi)容提供商需要加密的內(nèi)容加密密鑰過多時，消費者收到密鑰的時延會過長，影響其消費體驗。因此有必要考慮將內(nèi)容提供商從加密內(nèi)容加密密鑰的任務中解放出來，同時還需確保密鑰的安全保存和有效分發(fā)。

在本文方案中，為減輕內(nèi)容提供商需實時管理內(nèi)容加密密鑰的負擔，引入了密鑰服務器，將內(nèi)容加密密鑰托管給密鑰服務器保存和分發(fā)，這樣可以有效較少消費者收到許可證的時延，增加方案的靈活性。同時，為防止內(nèi)容加密密鑰過于集中帶來的風險，根據(jù)可驗證的秘密共享方案將內(nèi)容加密密鑰分發(fā)給多個子密鑰服務器管理，少于門限值的影子密鑰得不到關于內(nèi)容加密密鑰的任何信息，保證了密鑰的安全性。此外，為防止惡意內(nèi)容提供商欺騙子密鑰服務器，進而導致消費者得到許可證后不能正常訪問所購數(shù)字內(nèi)容的情況，密鑰服務器在收到內(nèi)容提供商發(fā)送的子密鑰后，可對其正確性進行驗證。

1 相關工作

數(shù)字權(quán)限管理的核心思想是通過使用許可證來保護數(shù)字內(nèi)容的版權(quán)，即用戶得到數(shù)字內(nèi)容后，必須獲得相應的許可證才能使用該內(nèi)容。在傳統(tǒng)的DRM 系統(tǒng)中［13-15］，內(nèi)容提供商是數(shù)字內(nèi)容的所有者或作者，他對數(shù)字內(nèi)容進行加密，并將加密的內(nèi)容上載到內(nèi)容服務器，然后將加密密鑰傳輸?shù)皆S可證服務器；內(nèi)容服務器負責存儲和分發(fā)數(shù)字內(nèi)容；許可證服務器用于創(chuàng)建和傳遞許可證。消費者從內(nèi)容服務器下載數(shù)字內(nèi)容并向許可證服務器請求獲取相應的許可證。當消費者獲得受保護數(shù)字內(nèi)容的許可證時，消費者的客戶端可以解密加密內(nèi)容并強制執(zhí)行許可證中包含的權(quán)限。各角色在以上的信息交互過程中，需要多次對消息進行完整性驗證。

區(qū)塊鏈被提出以來，研究者們積極嘗試將DRM 與新興技術區(qū)塊鏈結(jié)合，以克服傳統(tǒng)DRM 的不足。文獻［6］中提出了基于區(qū)塊鏈的網(wǎng)絡媒體數(shù)字權(quán)限管理方案，該方案利用區(qū)塊鏈的特點來實現(xiàn)產(chǎn)品管理、版權(quán)管理、交易管理和用戶行為管理，但是并沒有設計出完整詳細的DRM 保護方案，并且該方案在私有鏈上實施，不具有完全去中心化的特點。文獻［7］中設計了一個基于聯(lián)盟鏈的數(shù)字版權(quán)交易系統(tǒng)模型，實現(xiàn)了版權(quán)交易和版權(quán)注冊。方案［6-7］方案均未考慮數(shù)字內(nèi)容的安全存儲及相應數(shù)字內(nèi)容加密密鑰的安全分發(fā)問題。文獻［8］中設計了一個基于區(qū)塊鏈的分布式權(quán)限管理系統(tǒng)，在該系統(tǒng)中，內(nèi)容提供商用消費者的公鑰對內(nèi)容加密密鑰加密，加密結(jié)果打包進許可證后放入交易池內(nèi)，交易被礦工挖礦成功后上鏈，消費者再從鏈上讀取許可證，并用自己的私鑰解密內(nèi)容加密密鑰，以此來使用數(shù)字內(nèi)容。在文獻［8］方案中，許可證由內(nèi)容提供商發(fā)放，若購買數(shù)字產(chǎn)品的消費者過多，這對內(nèi)容提供商來說是巨大的工作量；此外，消費者在鏈上通過交易讀取數(shù)字內(nèi)容的價格、不同使用權(quán)限對應的價格等信息，然而隨著區(qū)塊的不斷增加，交易越來越多，消費者在交易里查看信息的時間過長，影響消費體驗；而且，內(nèi)容提供商需實時對內(nèi)容加密密鑰進行加密，這種加密方式的效率顯然不高且不利于內(nèi)容提供商進行創(chuàng)作。文獻［9］中利用區(qū)塊鏈技術對數(shù)字權(quán)限進行管理，該方案中，內(nèi)容提供商在智能合約上設置不同的數(shù)字內(nèi)容使用權(quán)限對應不同價格，可供消費者查看，并且使用智能合約自動發(fā)布許可證，解決了文獻［8］中許可證由內(nèi)容提供商來發(fā)放及消費者需在鏈上讀取感興趣數(shù)字內(nèi)容的權(quán)限等信息導致的時延過長問題。但在文獻［8-9］方案中，內(nèi)容加密密鑰由內(nèi)容提供商保存，當消費者購買數(shù)字產(chǎn)品時，內(nèi)容提供商需實時用消費者公鑰加密內(nèi)容加密密鑰。顯然，當購買該數(shù)字產(chǎn)品的消費者過多時，內(nèi)容提供商的計算量將顯著增加；對消費者來說，若內(nèi)容提供商需要加密的內(nèi)容加密密鑰過多，消費者收到密鑰的時延過長，影響其消費體驗。文獻［10］中為DRM 業(yè)務模型設計并實現(xiàn)了基于區(qū)塊鏈的基礎設施服務，并在區(qū)塊鏈中構(gòu)建了內(nèi)容指紋，即內(nèi)容版權(quán)相關的信息。但是在該方案中，當消費者購買數(shù)字產(chǎn)品時，內(nèi)容提供商需根據(jù)密鑰生成算法動態(tài)生成內(nèi)容加密密鑰，用內(nèi)容加密密鑰對稱加密數(shù)字內(nèi)容，內(nèi)容加密密鑰由內(nèi)容提供商實時生成和管理。可以看出，文獻［6-10］方案均未考慮內(nèi)容加密密鑰的托管問題。文獻［11］中基于星際文件系統(tǒng)（InterPlanetary File System，IPFS）和區(qū)塊鏈技術提出了一個安全數(shù)據(jù)共享平臺，數(shù)據(jù)擁有者將未經(jīng)加密的數(shù)字內(nèi)容及其元數(shù)據(jù)存儲到IPFS，然后利用秘密共享方案對IPFS 返回的文件hash 進行分割，k份shares 用工作節(jié)點的公鑰加密后存儲至智能合約，當消費者想要獲取感興趣的內(nèi)容并支付定金后，工作節(jié)點向智能合約申請加密的shares，再利用自己的私鑰解密后發(fā)送給消費者。該方案中，一旦IPFS hash 值恢復后外泄，任何非授權(quán)者均可以直接從IPFS 上直接獲取到相應的數(shù)字內(nèi)容明文信息，此外該方案沒有考慮秘密共享參與者對收到的shares 的正確性驗證問題。文獻［12］中提出了一個基于秘密共享的社交媒體DRM 區(qū)塊鏈框架，但并未給出具體實現(xiàn)。該框架主要考慮了對社交媒體內(nèi)容的確權(quán)及權(quán)限交易，當內(nèi)容創(chuàng)作者上傳新媒體內(nèi)容時，采用唯一標識媒體內(nèi)容的hash、用戶ID，所有權(quán)ID 被記錄在公有鏈上，用于確權(quán)。此外，內(nèi)容創(chuàng)作者利用秘密共享方案對媒體內(nèi)容進行分割，分割后的shares 存儲至IPFS，并將IPFS 返回的shares 的IPFS hash 存儲至私有鏈上。當有消費者購買該媒體內(nèi)容版權(quán)時，若內(nèi)容創(chuàng)作者同意交易，智能合約從私鏈上讀取該媒體內(nèi)容shares的IPFS hash并發(fā)送給消費者，同時該筆交易會記錄在公有鏈上。該方案中，一旦交易結(jié)束，媒體內(nèi)容的使用方式就不能被直接、靈活地控制，因為消費者可以通過shares的IPFS hash獲取到該媒體內(nèi)容的明文。此外，該方案沒有考慮交易的公平性問題。

因此，本文提出了一種區(qū)塊鏈環(huán)境下具有內(nèi)容加密密鑰托管功能的數(shù)字權(quán)限保護方案，利用可驗證的秘密共享方案和屬性基加密（Attribute-Based Encryption，ABE）算法，實現(xiàn)了內(nèi)容加密密鑰的保護和分發(fā)，將內(nèi)容提供商從管理內(nèi)容加密密鑰的任務中解放出來，確保了密鑰管理的安全性和靈活性；同時本文方案支持內(nèi)容提供商在智能合約上為數(shù)字內(nèi)容設置不同的使用權(quán)限及對應的價格以供消費者快速查詢，并利用智能合約自動發(fā)放許可證，既解放了內(nèi)容提供商又確保了數(shù)字內(nèi)容交易安全、可靠、公平地執(zhí)行。

2 預備知識

2.1 Pedersen可驗證秘密共享方案

設q是大素數(shù)，E是定義在有限域GF(q)上的橢圓曲線，G是E上q階基點，q、E和G是公開的。

Pedersen［16］提出了一個可驗證秘密共享方案VSS（Verifiable Secret Sharing），可驗證是指每個共享秘密參與者在收到子密鑰時可驗證其正確性。假定可信分派者有一秘密CK∈GF()q，并通過CK?G對秘密CK進行承諾，其中q是大于n的素數(shù)，且共有共享秘密參與者n人。該方案分為三步：

1）可信分派者分發(fā)子密鑰。根據(jù)Shamir秘密共享方案在有限域中GF(q)中構(gòu)造一個k-1 次表達式，并將所要共享的秘密CK作為這個表達式的常數(shù)項，即F(x)=CK+a1x+a2x2+…+ak-1xk-1，然后計算TXi=F(x)i(1 ≤i≤n)?？尚欧峙烧甙迅鱾€TXi秘密地分發(fā)給對應的共享秘密參與者后，計算并公布Ai=aiG(0 ≤i≤k-1)。

3）共享秘密恢復。k個或k個以上的參與者合作，利用拉格朗日插值公式可以恢復出秘密CK，但少于k個參與者合作得不到關于秘密CK的任何信息。

2.2 屬性基加密

屬性基加密最初由Sahai 等［17］提出，它以屬性為公鑰，將密文和用戶私鑰與屬性關聯(lián)，能夠靈活地表示訪問策略，當用戶的私鑰與密文的訪問策略相互匹配時，該用戶才能解密密文。ABE 包括密鑰策略ABE（Key-Policy ABE，KP-ABE）以及密文策略ABE（Ciphertext-Policy ABE，CP-ABE）這2 類。其中，CP-ABE 的密文與訪問策略關聯(lián)，CP-ABE 算法包括以下4個組成部分：1）ABE.Setup()，生成系統(tǒng)公鑰PK和系統(tǒng)主密鑰MK。2）ASK=ABE.KeyGen(AS，MK)，使用用戶屬性AS和MK生成用戶的屬性私鑰ASK。3）CT=ABE.Encrypt(AP，M，PK)，使用訪問策略AP和PK將數(shù)據(jù)明文M加密為密文CT。4）M=ABE.Decrypt(ASK，CT)，如果用戶的屬性AS滿足訪問策略AP，使用屬性私鑰ASK解密密文CT得到明文M。

2.3 IPFS

星際文件系統(tǒng)（IPFS）是一個對等的分布式文件系統(tǒng)，在某種程度上，IPFS 的使用與Web 的使用方式類似。將文件上載到IPFS 系統(tǒng)將獲得唯一的文件加密哈希字符串，通過該字符串可以檢索文件。在實際應用中，由于區(qū)塊膨脹和交易費用，區(qū)塊鏈不適合存儲大文件（視頻、音頻等）。因此，本文方案中，將加密文件存儲在IPFS 中，一些元數(shù)據(jù)存儲在以太坊（ETHereum，ETH）區(qū)塊鏈上。

3 本文方案框架

本文提出了一種基于區(qū)塊鏈的數(shù)字權(quán)限保護方案，其框架如圖1 所示，包括屬性機構(gòu)、IPFS、密鑰服務器A、子密鑰服務器I1，I2，…，In和內(nèi)容提供商、消費者、智能合約等。

圖1 基于區(qū)塊鏈的DRM方案框架Fig.1 Framework of DRM scheme based on blockchain

1）屬性機構(gòu)生成系統(tǒng)屬性公鑰PK和系統(tǒng)屬性主密鑰MK，然后向內(nèi)容提供商發(fā)布PK，秘密保存主密鑰。內(nèi)容提供商設置內(nèi)容的訪問策略AP，如圖1中①②所示。

2）內(nèi)容提供商使用加密組件隨機生成長度為l的子密鑰AK和子密鑰CK，并相加得到key，內(nèi)容提供商使用key加密數(shù)字內(nèi)容，并將加密結(jié)果、內(nèi)容標識CID、門限數(shù)t發(fā)送給IPFS，IPFS 給內(nèi)容提供商返回hash值。內(nèi)容提供商將hash值、內(nèi)容標識CID、部分簡介以交易的形式放在區(qū)塊鏈上，如圖1 中③④⑤所示。

3）內(nèi)容提供商將AK用ABE 算法進行加密，即ABE.Enc(AP，AK，PK)，加密結(jié)果與CID一起發(fā)送給密鑰服務器A。內(nèi)容提供商將CK采用秘密共享方案進行分割，在GF(q)有限域里隨機選擇k-1 個大素數(shù)a1，a2，…，ak-1，并將其與CK組成如下表達式：

內(nèi)容提供商計算子密鑰TXi=F(xi)(1 ≤i≤n)，在計算出n個子密鑰后，計算出Ai=aiG(0 ≤i≤k-1)。將子密鑰TXi分別用n個密鑰服務器的公鑰進行加密，即Enc(PKi，TXi)，將其與CID發(fā)送到對應的密鑰服務器，并將Ai發(fā)送給每一個密鑰服務器。各密鑰服務器在收到TXi后，用私鑰解密出TXi并驗證以下等式，若所有的服務器都通過此公式驗證，則所有的子密鑰服務器接受內(nèi)容提供商發(fā)給自己的子密鑰，如圖1中⑥⑦所示。

4）內(nèi)容提供商在智能合約上設置A和各密鑰服務器的地址以供消費者查詢服務器的忙碌狀態(tài)從而選擇自己想要的為其服務的服務器，以及不同的內(nèi)容使用權(quán)限對應的不同價格和key的使用規(guī)則，并支付一定數(shù)量的押金，以保證交易順利完成，如圖1中⑧所示。

5）消費者從區(qū)塊鏈上瀏覽到自己感興趣的內(nèi)容，將讀取到的hash值傳給IPFS，IPFS 根據(jù)hash值給消費者返回存儲的加密的數(shù)字內(nèi)容和門限數(shù)。當消費者注冊時，屬性機構(gòu)根據(jù)訪問策略判斷消費者的屬性是否滿足訪問策略，若滿足則根據(jù)消費者的屬性AS生成屬性私鑰ASK，通過安全信道發(fā)送給消費者秘密保存。消費者從智能合約讀取服務器地址并提交許可授權(quán)請求LAQ，包括A和t個服務器Ij(1 ≤j≤t)地址、內(nèi)容標識CID、用戶使用規(guī)則REX，以及自己的公鑰PKU、購買內(nèi)容的錢包含5%的違約金。若消費者的屬性不滿足訪問策略則屬性機構(gòu)什么也不做，如圖1中⑨⑩?????所示。

6）智能合約收到許可授權(quán)請求LAQ后，提取出CID和PKU，將CID發(fā)送給A，將CID和PKU發(fā)送給t個密鑰服務器，如圖1中??所示。

7）密鑰服務器A根據(jù)收到的CID查找表中Enc(AP，AK，PK)，并將其發(fā)送給智能合約，其余被消費者選中的t個密鑰服務器根據(jù)收到的CID查找表中與之一一對應的自己存儲的子密鑰，用PKU加密子密鑰，并將加密結(jié)果返回給智能合約，如圖1中??所示。

8）智能合約打包許可證LIC，許可證中包含經(jīng)過AP加密的AK、經(jīng)過消費者公鑰加密的TXi、CID、許可證標識LID、權(quán)限使用規(guī)則REX。智能合約將許可證發(fā)送給消費者，如圖1中?所示。

9）消費者收到許可證LIC后，其客戶端用消費者屬性私鑰ASK解密出AK，利用私鑰SKU解密出TXi，再將t個TXi根據(jù)秘密共享方案恢復出F(x)，進而得到F(0)并和AK相加得到內(nèi)容加密密鑰key，使用內(nèi)容加密密鑰key解密密文。

10）消費者告知智能合約許可證已經(jīng)成功獲取并且解密成功后，交易完成，智能合約將內(nèi)容提供商的違約金和消費者的違約金退還，如圖1中所示。

方案中涉及到的符號含義如表1所示。

表1 相關符號定義Tab.1 Definition of related symbols

4 本文方案協(xié)議設計

下面介紹數(shù)字權(quán)限全生命周期保護包括的系統(tǒng)初始化、內(nèi)容加密、許可授權(quán)和內(nèi)容解密4個主要的協(xié)議。

4.1 系統(tǒng)初始化協(xié)議

在系統(tǒng)初始化階段，屬性機構(gòu)根據(jù)系統(tǒng)需求定義用戶全部屬性集L={L1，L2，…，Ln}，并生成系統(tǒng)屬性公鑰PK和系統(tǒng)屬性主密鑰MK，然后向內(nèi)容提供商發(fā)布PK，秘密保存屬性主密鑰。

4.2 數(shù)字內(nèi)容加密協(xié)議

在數(shù)字內(nèi)容加密階段，內(nèi)容提供商隨機生成內(nèi)容加密密鑰key，用key將原始數(shù)字內(nèi)容加密并將門限數(shù)t放置在加密內(nèi)容的頭部上傳至IPFS平臺。

步驟1 內(nèi)容提供商的加密組件使用key加密PCD，并將門限數(shù)t放在加密內(nèi)容的頭部后上傳至IPFS 平臺，IPFS 返回給內(nèi)容提供商hash值。

ECD=Enc(key，PCD)

CP→IPFS：(t，ECD)

IPFS →CP：hash

步驟2 內(nèi)容提供商設置該內(nèi)容的訪問策略AP，并與內(nèi)容標識CID一起發(fā)送給屬性機構(gòu)AM。

CP→AM：AP‖CID

步驟3 內(nèi)容提供商在區(qū)塊鏈上設置IPFS 返回的hash、數(shù)字內(nèi)容標識CID，以及內(nèi)容的部分簡介PIC以供消費者查詢。

CP→blockchain：hash‖CID‖PIC

設GF(q)是一個有限域，其中q是一個大素數(shù)，滿足0

設橢圓曲線的點構(gòu)成Abel 群Ep(a，b)，取Ep(a，b)的一個生成元G，要求G的階是一個非常大的素數(shù)，G的階是滿足nG=O的最小正整數(shù)n，G為公開參數(shù)。

步驟4 內(nèi)容提供商根據(jù)Pedersen 可驗證的秘密共享方案，在GF(q)有限域里隨機選擇k-1 個大素數(shù)a1，a2，…，ak-1，并將其與CK組成表達式F(x)=ak-1xk-1+…+a2x2+a1x+CK，F(xiàn)(x)的計算過程如算法1所示。

步驟6 內(nèi)容提供商將Enc(AP，AK，PK)發(fā)送給密鑰服務器A，將其余n個子密鑰TXi(1 ≤i≤n)用各密鑰服務器的公鑰進行加密，加密結(jié)果和Ai(1 ≤i≤n)分別發(fā)送給各密鑰服務器。各密鑰服務器對收到的子密鑰密文解密得到TXi，然后驗證以下等式TXi G=是否成立，驗證過程如算法4 所示。若所有密鑰服務器都通過此公式驗證，則接收；否則拒絕接收。

步驟7 內(nèi)容提供商在智能合約上設置A和各密鑰服務器的地址、不同的內(nèi)容使用權(quán)限對應的價格和key使用規(guī)則，以供消費者查詢，并支付一定數(shù)量的押金以保證交易順利完成。

4.3 許可授權(quán)協(xié)議

消費者通過IPFS 獲得加密的內(nèi)容后，向智能合約詢問該內(nèi)容不同使用規(guī)則的相應價格，根據(jù)自己的需求向智能合約申請許可證LIC，智能合約打包好LIC并發(fā)送給消費者。

步驟1 消費者U從區(qū)塊鏈上讀取到感興趣的內(nèi)容簡介，讀取其hash值，將其交給IPFS，IPFS 根據(jù)hash將其存儲的加密數(shù)字內(nèi)容和門限數(shù)發(fā)送給消費者。

步驟2 消費者U向?qū)傩詸C構(gòu)提交自己的身份信息及感興趣的CID，供屬性機構(gòu)判斷其屬性是否滿足訪問策略，若滿足，屬性機構(gòu)給消費者返回屬性私鑰。

步驟3 消費者U得到屬性私鑰并提取出加密文件頭部的門限數(shù)t，選擇t個服務器；向智能合約S詢問該內(nèi)容的不同使用規(guī)則的相應售價；消費者根據(jù)自己的需求制定許可授權(quán)請求LAQ。

步驟4 消費者U向智能合約S提交許可授權(quán)請求LAQ，包括密鑰服務器A的地址ADA和t個密鑰服務器Ij（1 ≤j≤t）的地址ADIj（1 ≤j≤t）、內(nèi)容標識CID、用戶使用規(guī)則REX，以及自己的公鑰PKU、購買內(nèi)容的錢包含5%的違約金。

U→S：LAQ=ADA‖ADIj‖CID‖REX‖PKU‖money

步驟5 智能合約S收到LAQ以后，提取出CID和PKU，將CID發(fā)送給A，將CID和PKU發(fā)送給t個密鑰服務器。

S→A：CID

S→Ij：CID‖PKU

步驟6 密鑰服務器A根據(jù)收到的CID查找對應的Enc(AP，CK，PK)，將其與CID一起發(fā)送給智能合約，其余被用戶選中的t個密鑰服務器根據(jù)收到的CID查找表中對應的子密鑰TXi，并用PKU加密子密鑰TXi，將加密結(jié)果與CID一起返回給智能合約。

步驟7 智能合約打包許可證LIC并發(fā)送給消費者，許可證中包含經(jīng)過AP加密的AK，經(jīng)過消費者公鑰加密的TXi、CID、許可證標識LID和權(quán)限使用規(guī)則REX。

4.4 內(nèi)容解密協(xié)議

消費者使用內(nèi)容時，根據(jù)秘密共享方案恢復出CK，再用屬性私鑰ASK解密出AK，二者相加得到內(nèi)容加密密鑰key，再對密文解密即可。

步驟1 消費者收到智能合約發(fā)給自己的LIC后，用屬性私鑰ASK解密出AK，再用自己的私鑰SKU解密出TXi，將t個TXi根據(jù)秘密共享方案恢復出F(x)，恢復過程如算法5 所示，進而得到F(0)即CK，將CK和AK相加得到內(nèi)容加密密鑰key，再對密文解密即可。

步驟2 消費者能根據(jù)收到許可證正常使用數(shù)字內(nèi)容后，通知智能合約，智能合約退還內(nèi)容提供商的違約金和消費者的違約金，交易完成。

5 智能合約的設計

以太坊中智能合約是用solidity 語言編寫的，一些特殊的變量存在于全局命名空間中，主要用于提供區(qū)塊鏈的信息。在本文方案中使用了特殊變量Msg.sender，表示消息或交易的發(fā)送方。

本文方案設計了兩個智能合約，分別為CopyrightOwner合約和Consumer 合約。CopyrightOwner 合約由內(nèi)容提供商部署，Consumer合約由消費者部署。在智能合約創(chuàng)建的過程中，有以下變量：

1）地址類型的變量CO為內(nèi)容提供商的地址。

2）地址類型的變量CU為消費者的地址。

3）keyList為映射類型變量，定義了數(shù)字內(nèi)容標識CID到加密內(nèi)容密鑰relatedkey的映射集合。內(nèi)容提供商可以添加、修改和刪除集合。

4）serverList為映射類型變量，定義了數(shù)字內(nèi)容標識CID到代理加密節(jié)點relatedserver的映射集合。內(nèi)容提供商可以添加、修改和刪除集合。

5）relatedkey為結(jié)構(gòu)體類型變量，用于存儲內(nèi)容提供商分發(fā)給各密鑰服務器的密鑰。

6）relatedserver為結(jié)構(gòu)體類型變量，用于存儲各密鑰服務器的地址。

7）relatedserverkey為結(jié)構(gòu)體類型變量，用于存儲各密鑰服務器發(fā)送給消費者的密鑰。

8）licenseResult為結(jié)構(gòu)類型變量，定義了一組變量作為其成員，包括加密密鑰enckey1、加密密鑰enckey2、加密密鑰enckey3和加密密鑰enckeyA。

本文方案中智能合約主要包括以下11 個函數(shù)，分別對應算法6～算法16。

1）內(nèi)容提供商設置密鑰，如算法6 所示。該函數(shù)只能被內(nèi)容提供商執(zhí)行。內(nèi)容提供商將密鑰CK分為若干份，在本文方案具體實現(xiàn)中將密鑰CK分割為5 份，分別用密鑰服務器的公鑰加密，加密結(jié)果存儲在智能合約上。同時將密鑰AK用密鑰服務器A的公鑰加密，加密結(jié)果也存儲在智能合約上。

算法6 OwnersetKey。

2）內(nèi)容提供商設置密鑰服務器的地址，如算法7 所示。該函數(shù)只能被內(nèi)容提供商執(zhí)行，內(nèi)容提供商設置密鑰服務器的地址以供消費者查看。

算法7 SetSever。

3）密鑰服務器獲取已加密的密鑰，如算法8 所示。密鑰服務器讀取用自己公鑰加密的密鑰，并用自己的私鑰解密并存儲，根據(jù)ipfs返回密鑰集relatedkey。

算法8 Getkey。

4）各密鑰服務器設置已加密的密鑰，如算法9 所示。該函數(shù)只能被相應的密鑰服務器調(diào)用，在收到消費者指定自己為其服務時，各密鑰服務器用消費者的公鑰加密自己保存的部分密鑰，并將加密結(jié)果發(fā)送給智能合約。以密鑰服務器1為例，其余密鑰服務器類似。

算法9 Serversetkey。

5）智能合約打包許可證。消費者通過Getkey查看自己指定的所有密鑰服務器是否已將加密好的部分密鑰發(fā)送到智能合約，如算法10 所示；待全部密鑰服務器均已發(fā)送后，智能合約開始打包許可證，如算法11所示。以密鑰服務器1舉例，其余密鑰服務器類似。

算法10 Getkey1。

6）消費者詢問密鑰服務器的地址，如算法12 所示。消費者選到自己感興趣的數(shù)字內(nèi)容后，根據(jù)ipfs查看各密鑰服務器地址。

算法12 Getserver。

7）消費者讀取感興趣的文件頭部的門限數(shù)t，本文方案實現(xiàn)中t取3。消費者根據(jù)服務器的忙碌狀態(tài)選擇3 個服務器，并將此3個服務器的地址、服務器A的地址、自己的公鑰、感興趣內(nèi)容的CID發(fā)送給智能合約，如算法13所示。

算法13 SetbeSevered。

8）服務器從區(qū)塊鏈上讀取消費者設置的為其進行密鑰托管的服務器，如算法14 所示。被選中的t個服務器獲取消費者的公鑰及其感興趣數(shù)字內(nèi)容的CID。

算法14 Getinformation。

9）消費者請求許可證，如算法15 所示。該函數(shù)只能被智能合約的創(chuàng)建者即消費者執(zhí)行。

算法15 RequestLicense。

10）消費者獲得許可證，如算法16 所示。該函數(shù)只能被智能合約的創(chuàng)建者即消費者執(zhí)行。

算法16 GetLicense。

6 方案分析

6.1 仿真實驗結(jié)果分析

通過仿真實驗分析方案的實用性。PC 硬件配置為Inter-Core-i5 處理器，4 GB RAM，操作系統(tǒng)為64 位。程序設計語言為C語言和solidity。

以太坊區(qū)塊鏈在以太坊虛擬機（Ethereum Virtual Machine，EVM）中運行交易觸發(fā)的代碼，EVM 中的每一步操作都有一個特定的消耗，用gas來計算，每一步操作消耗的gas記為gas used，gas 的價格記為gas price，二者的乘積為每筆交易的交易費，本文方案在2020 年8 月15 日進行仿真實驗，以太坊（ETH）的價格是1ether=436 USD，gas 的價格是1 Gwei，1 Gwei=109wei=10-9ether。

在本文方案中，智能合約部署在Ropsten 測試網(wǎng)絡中，內(nèi)容提供商賬戶地址為0x5e8558cf584c92979b723f793e0bb0b307ce3299，CopyrightOwner 合約地址為0xb7569aaa3210afe50fc3 e7faf7675e1dc85ba462，消費者賬戶地址為0xce54173faD2236856B1350c0E27088015Eb14eAb，Consumer 的合約地址為0x94e7d4894d1cb8ea43085f792cc7cbcc8b8ef7a5。利用智能合約分析了以下操作的花費，內(nèi)容提供商部署智能合約花費為＄1.058406568，內(nèi)容提供商設置合約地址的花費為＄0.018387428，內(nèi)容提供商將加密好的密鑰發(fā)送至智能合約即Ownersetkey 花費為＄0.108019872，內(nèi)容提供商設置服務器的地址即Ownersetsever 花費為＄0.104185252，密鑰服務器利用消費者的公鑰加密自己保存的子密鑰，并將其發(fā)送給消費者，即Serversetkey1、Serversetkey2、Serversetkey3、ServersetkeyA的花費分別為＄0.01938456、＄0.01943252、＄0.019317416、＄0.019307824，消費者部署智能合約的花費為＄0.518231344，消費者選取為自己托管密鑰的服務器即Setbeserver 的花費為＄0.0565165，消費者獲取許可證即Getlicense的花費為＄0.056895384。

從表2 數(shù)據(jù)可以看出，本文方案能夠以較低的開銷實現(xiàn)數(shù)字內(nèi)容的保護。

表2 智能合約花費測試Tab.2 Smart contract cost test

6.2 安全性分析

1）信息的存儲安全。本文方案中信息的存儲安全包括數(shù)字內(nèi)容的存儲安全、密鑰的存儲安全和交易信息的存儲安全。

a）數(shù)字內(nèi)容的存儲安全。內(nèi)容提供商在將數(shù)字內(nèi)容上傳至IPFS 前對數(shù)字內(nèi)容進行加密，沒有解密密鑰的惡意用戶無法獲取數(shù)字內(nèi)容的明文信息，保證了數(shù)字內(nèi)容的機密性。

b）數(shù)字內(nèi)容加密密鑰的存儲安全。本文方案采用密鑰分割技術對數(shù)字內(nèi)容加密密鑰進行了處理，一部分密鑰托管給密鑰服務器A，另一部分密鑰利用秘密共享方案分割為t份，并分別托管給t個密鑰服務器，只有同時得到A和t個服務器的密鑰，才能恢復出內(nèi)容加密密鑰。

c）交易信息的存儲安全。在傳統(tǒng)的DRM 中，內(nèi)容提供商通常將版權(quán)出售給媒體平臺以尋求DRM 保護，但是數(shù)字內(nèi)容的權(quán)限交易信息和許可證交易信息對他們來說都是不透明的，本文方案中利用區(qū)塊鏈技術進行數(shù)字權(quán)限交易，區(qū)塊鏈具有去中心化、公開透明、防篡改等特點，數(shù)字權(quán)限交易信息被完整地記錄在每一個節(jié)點上，上鏈后的交易信息公開透明、真實可靠，且不能被篡改。

2）交易的公平性。消費者獲得數(shù)字內(nèi)容加密密鑰之前，需向智能合約支付額外的保證金費用，用來保證交易的順利執(zhí)行；內(nèi)容提供商也需向智能合約提供保證金，只有當消費者成功收到許可證，并且成功解密，消費者將告訴智能合約，內(nèi)容可被正確解密，此時智能合約將保證金返還給雙方。此外，本文方案具有支持子密鑰服務器驗證其收到的子密鑰是否正確的功能：一方面可以有效避免惡意內(nèi)容提供商欺騙子密鑰服務器，給子密鑰服務器發(fā)送錯誤的子密鑰，進而導致消費者收到許可證后不能正常訪問數(shù)字內(nèi)容的情況，而此情況下消費者是無法判斷哪個或哪些子密鑰服務器的子密鑰不正確；另一方面還可以避免依賴消費者的道德信譽反饋其收到的許可證能否正常使用的被動情況，因為存儲在密鑰服務器的子密鑰的正確性是可驗證的。

3）消費者只有滿足訪問策略并獲取有效的許可證后才能解密數(shù)字內(nèi)容。

內(nèi)容提供商使用key對數(shù)字內(nèi)容進行加密，并將key分為兩部分CK和AK，當消費者想要使用自己感興趣的數(shù)字內(nèi)容時，其通過智能合約申請許可證，許可證中包含了用消費者公鑰和屬性基加密的AK，消費者只有滿足訪問策略才能恢復出key的必須部分AK。

4）密鑰服務器、智能合約、區(qū)塊鏈上其他節(jié)點均無法獲得內(nèi)容加密密鑰key。

對于密鑰服務器A而言，因為AK采用AP加密，因此密鑰服務器A無法獲得AK，也就得不到內(nèi)容加密密鑰key。對于其他子密鑰服務器而言，只要多于n-t個子密鑰服務器是誠實的，便無法獲得CK，因此也得不到內(nèi)容加密密鑰key。智能合約在打包許可證時，因為AK采用了用戶公鑰和屬性基加密，t份子密鑰采用了消費者公鑰加密，只有滿足訪問策略并且擁有私鑰的消費者才能解密，因此智能合約無法獲得內(nèi)容加密密鑰。對于區(qū)塊鏈的其他節(jié)點，即使交易公開透明，因為AK和t份子密鑰都用消費者公鑰加密，因此只有消費者本人才能用自己的私鑰進行解密。因此，密鑰服務器、智能合約和區(qū)塊鏈上其他節(jié)點均無法獲得內(nèi)容加密密鑰key。

6.3 正確性分析

基于Sahai等［17］提出的屬性基加密方案可以得出，利用消費者屬性私鑰ASK可解密得到AK=ABE.Dec(ASK，ABE.Enc(AP，AK，PK))，再用其私鑰解密出t份子密鑰后，根據(jù)秘密共享方案恢復出CK，進而得到內(nèi)容加密密鑰key=CK+AK。

6.4 與其他方案的比較

將傳統(tǒng)DRM 方 案［13-14］，以及基于區(qū)塊鏈的DRM 方案［7-8，11-12］與本文方案分別從是否支持內(nèi)容加密密鑰托管、內(nèi)容加密密鑰的保護方式、是否支持訪問控制和是否考慮交易公平性四個方面進行對比分析，對比結(jié)果如表3所示。

從表3 可以看出，傳統(tǒng)的DRM 方案［13-14］都對內(nèi)容加密密鑰實施了托管，并通過加密方式對內(nèi)容加密密鑰進行了保護。在基于區(qū)塊鏈的DRM 方案中，文獻［11］方案數(shù)字內(nèi)容未經(jīng)加密直接上傳到IPFS，只對IPFS 返回的文件hash值進行分割后再加密；文獻［12］方案利用秘密共享方案對媒體數(shù)字內(nèi)容進行分割，分割后的shares 直接存儲至IPFS；文獻［7］方案未考慮數(shù)字內(nèi)容的存儲問題，僅實現(xiàn)了版權(quán)注冊和版權(quán)交易；文獻［8］方案雖然對內(nèi)容加密密鑰進行了加密保護，但未考慮內(nèi)容加密密鑰的托管；本文方案為實現(xiàn)對內(nèi)容加密密鑰的安全保存和有效分發(fā)，采用了密鑰托管方式，并通過公鑰加密和屬性基加密對其進行保護。此外，在訪問控制和交易公平性方面，僅本文方案和文獻［11］方案同時支持。綜上分析可知，在上述各功能方面，本文方案相較對比方案考慮得更全面。

7 結(jié)語

本文提出了一種基于區(qū)塊鏈的數(shù)字權(quán)限保護方案。該方案包括系統(tǒng)初始化、內(nèi)容加密、許可授權(quán)和內(nèi)容解密4 個主要的協(xié)議，將內(nèi)容提供商從加密內(nèi)容、加密密鑰的工作中解脫出來；同時，為實現(xiàn)密鑰的安全存儲，本文方案將密鑰進行分割，只有同時得到密鑰服務器A提供的子密鑰和t份子密鑰服務器提供的子密鑰才能解密出內(nèi)容加密密鑰。仿真實驗結(jié)果表明了本文方案的可行性和實用性，另外對方案的正確性和安全性也進行了分析驗證。