區(qū)塊鏈環(huán)境下基于秘密共享的數(shù)字權(quán)限管理方案

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

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

0 引言

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

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

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

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

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

1 相關(guān)工作

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

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

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

2 預(yù)備知識(shí)

2.1 Pedersen可驗(yàn)證秘密共享方案

設(shè)q是大素?cái)?shù)，E是定義在有限域GF(q)上的橢圓曲線，G是E上q階基點(diǎn)，q、E和G是公開(kāi)的。

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

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

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

2.2 屬性基加密

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

2.3 IPFS

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

3 本文方案框架

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

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

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

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

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

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

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

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

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

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

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

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

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

方案中涉及到的符號(hào)含義如表1所示。

表1 相關(guān)符號(hào)定義Tab.1 Definition of related symbols

4 本文方案協(xié)議設(shè)計(jì)

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

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

在系統(tǒng)初始化階段，屬性機(jī)構(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)容提供商隨機(jī)生成內(nèi)容加密密鑰key，用key將原始數(shù)字內(nèi)容加密并將門(mén)限數(shù)t放置在加密內(nèi)容的頭部上傳至IPFS平臺(tái)。

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

ECD=Enc(key，PCD)

CP→IPFS：(t，ECD)

IPFS →CP：hash

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

CP→AM：AP‖CID

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

CP→blockchain：hash‖CID‖PIC

設(shè)GF(q)是一個(gè)有限域，其中q是一個(gè)大素?cái)?shù)，滿足0

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

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

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

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

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

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

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

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

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

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

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

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

S→A：CID

S→Ij：CID‖PKU

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

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

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

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

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

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

5 智能合約的設(shè)計(jì)

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

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

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

2）地址類型的變量CU為消費(fèi)者的地址。

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

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

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

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

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

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

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

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

算法6 OwnersetKey。

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

算法7 SetSever。

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

算法8 Getkey。

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

算法9 Serversetkey。

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

算法10 Getkey1。

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

算法12 Getserver。

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

算法13 SetbeSevered。

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

算法14 Getinformation。

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

算法15 RequestLicense。

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

算法16 GetLicense。

6 方案分析

6.1 仿真實(shí)驗(yàn)結(jié)果分析

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

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

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

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

表2 智能合約花費(fèi)測(cè)試Tab.2 Smart contract cost test

6.2 安全性分析

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

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

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

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

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

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

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

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

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

6.3 正確性分析

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

6.4 與其他方案的比較

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

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

7 結(jié)語(yǔ)

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