紀(jì)露生，張桂玲，楊佳潤(rùn)

（1.天津工業(yè)大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，天津 300387；2.天津市自主智能技術(shù)與系統(tǒng)重點(diǎn)實(shí)驗(yàn)室，天津 300387）

0 概述

大數(shù)據(jù)、互聯(lián)網(wǎng)和5G技術(shù)的發(fā)展，在為人類帶來發(fā)展機(jī)遇的同時(shí)，也導(dǎo)致大量數(shù)據(jù)泄露事件的發(fā)生，造成嚴(yán)重后果。2018年1月，印度10億公民身份數(shù)據(jù)庫Aadhaar遭到網(wǎng)絡(luò)攻擊，該庫除公民基本信息外還有指紋、虹膜等敏感信息。2018年8月，美國(guó)醫(yī)療收集局（AMCA）遭到黑客入侵，泄露了大量消費(fèi)者的姓名、電話、余額、信用卡賬戶等重要信息。2019年1月，美國(guó)俄勒岡州公共服務(wù)部遭到了黑客的電子郵件釣魚攻擊，泄露了大量的客戶社保信息和健康信息。這些重大泄露事件的報(bào)道，使人們對(duì)個(gè)人數(shù)據(jù)的安全更為擔(dān)憂。

新興區(qū)塊鏈和智能合約技術(shù)［1］可為數(shù)據(jù)管理提供更好的技術(shù)支持，如在醫(yī)療數(shù)據(jù)領(lǐng)域，文獻(xiàn)［2］利用區(qū)塊鏈技術(shù)實(shí)現(xiàn)了個(gè)人醫(yī)療數(shù)據(jù)的存取和管理，文獻(xiàn)［3］解決了移動(dòng)醫(yī)療數(shù)據(jù)的協(xié)同共享問題。此外，文獻(xiàn)［4］基于區(qū)塊鏈提出一種分布式個(gè)人數(shù)據(jù)和數(shù)字身份的聯(lián)邦授權(quán)框架，文獻(xiàn)［5］利用區(qū)塊鏈實(shí)現(xiàn)了個(gè)人數(shù)據(jù)分布式隱私保護(hù)，文獻(xiàn)［6-7］則從法律角度分析個(gè)人網(wǎng)絡(luò)數(shù)據(jù)的所有權(quán)問題，為個(gè)人數(shù)據(jù)保護(hù)研究提供了新的解決方案。

在個(gè)人數(shù)據(jù)管理方面，研究者基于區(qū)塊鏈和智能合約也提出了一些優(yōu)秀方案。文獻(xiàn)［8］提出一種將區(qū)塊鏈作為一個(gè)不需要可信第三方機(jī)構(gòu)的訪問控制管理器，并由事務(wù)管理權(quán)限的機(jī)制。文獻(xiàn)［9］為個(gè)人建立用戶配置文件和數(shù)據(jù)/設(shè)備，同時(shí)為服務(wù)提供訪問數(shù)據(jù)的接口，使用戶可以在服務(wù)請(qǐng)求個(gè)人數(shù)據(jù)時(shí)設(shè)置服務(wù)可以訪問的數(shù)據(jù)/設(shè)備及其訪問級(jí)別，并授予或拒絕請(qǐng)求的權(quán)限。文獻(xiàn)［10］通過設(shè)計(jì)一個(gè)個(gè)人元數(shù)據(jù)管理框架，提出SafeAnswers機(jī)制。該機(jī)制允許個(gè)人收集并存儲(chǔ)自己的元數(shù)據(jù)，并允許服務(wù)詢問根據(jù)元數(shù)據(jù)計(jì)算得出答案的問題，從而實(shí)現(xiàn)對(duì)這些元數(shù)據(jù)的細(xì)粒度訪問。

本文采用鏈下存儲(chǔ)的方式，提出一種基于區(qū)塊鏈的匿名地址管理方案，使用開源區(qū)塊鏈以太坊（Ethereum）并假設(shè)一個(gè)誠實(shí)可信的資源服務(wù)（Resource Service，RS）來共同管理用戶數(shù)據(jù)。用戶將個(gè)人數(shù)據(jù)的加密地址分享給區(qū)塊鏈的智能合約，解密私鑰則分享給RS。該方案通過智能合約建立用戶和第三方服務(wù)（Third Party，TP）之間的授權(quán)關(guān)系，使第三方服務(wù)得到用戶授權(quán)后才能獲得用戶個(gè)人數(shù)據(jù)的加密地址和訪問令牌，從而實(shí)現(xiàn)細(xì)粒度訪問控制，達(dá)到保護(hù)個(gè)人數(shù)據(jù)的目的。

1 相關(guān)理論與研究

1.1 區(qū)塊鏈與智能合約

區(qū)塊鏈源于比特幣系統(tǒng)［11］，是一個(gè)點(diǎn)對(duì)點(diǎn)的分布式系統(tǒng)，其利用獨(dú)特的共識(shí)算法［12］和激勵(lì)機(jī)制鼓勵(lì)系統(tǒng)成員維護(hù)系統(tǒng)，系統(tǒng)的每一個(gè)狀態(tài)依靠成員共同決定，而不是依靠某個(gè)單一節(jié)點(diǎn)，因此，具有偽匿名性、去中心化、不可變性、透明度和安全性高等特點(diǎn)。比特幣系統(tǒng)是目前全球最早也是規(guī)模最大的區(qū)塊鏈系統(tǒng)，被稱為區(qū)塊鏈1.0。之后發(fā)展到帶有智能合約［13］的區(qū)塊鏈，如以太坊［14］和超級(jí)賬本［15］，被稱為區(qū)塊鏈2.0。由于目前區(qū)塊鏈的效率較低，因此研究者提出構(gòu)建區(qū)塊鏈3.0的設(shè)想，目標(biāo)是實(shí)現(xiàn)更高性能和更高吞吐量。

以太坊是一個(gè)開源且具有智能合約功能的公共區(qū)塊鏈平臺(tái)，其通過圖靈完備的以太坊虛擬機(jī)（Ethereum Virtual Machine，EVM）來處理點(diǎn)對(duì)點(diǎn)合約，運(yùn)行在EVM上的程序稱為智能合約。官方發(fā)布的智能合約語言是Solidity，合約部署后發(fā)布到鏈上，并被EVM執(zhí)行其中的代碼程序。智能合約與普通程序的區(qū)別在于，其程序發(fā)布到區(qū)塊鏈上將被作為一個(gè)交易記錄永久記錄在塊中，不可更改，這類似于紙質(zhì)協(xié)議，合同雙方簽訂協(xié)議后，一經(jīng)發(fā)布則此合同將具有法律效力，不可更改。超級(jí)賬本的智能合約支持多種高級(jí)語言，運(yùn)行在Docker容器中。

1.2 相關(guān)研究

區(qū)塊鏈因具有透明性、不可變性、可追溯性和防篡改等特性被應(yīng)用于多個(gè)領(lǐng)域，如金融、供應(yīng)鏈和數(shù)據(jù)資產(chǎn)管理等。在數(shù)據(jù)資產(chǎn)管理方面，基于區(qū)塊鏈的個(gè)人數(shù)據(jù)保護(hù)方案大多采用鏈下存儲(chǔ)［16］的方式，即鏈上只保存簡(jiǎn)短的訪問地址或路徑。這種以鏈下存儲(chǔ)方式將訪問數(shù)據(jù)的關(guān)鍵路徑或關(guān)系存儲(chǔ)在鏈上而將大規(guī)模數(shù)據(jù)存儲(chǔ)在鏈下的方法，構(gòu)建了一個(gè)完整的權(quán)限控制生態(tài)，使得區(qū)塊鏈能夠通過存儲(chǔ)少量數(shù)據(jù)實(shí)現(xiàn)對(duì)大量數(shù)據(jù)的控制，極大地增強(qiáng)了區(qū)塊鏈的可擴(kuò)展性。

2018年，歐盟通過了《一般數(shù)據(jù)保護(hù)條例》（簡(jiǎn)稱GDPR），指出了個(gè)人數(shù)據(jù)處理原則，即合法性、公平性、透明性、保密性、完整性和有限控制等。

文獻(xiàn)［17］將數(shù)據(jù)分為靜態(tài)用戶數(shù)據(jù)和動(dòng)態(tài)使用服務(wù)生成的數(shù)據(jù)兩類，同時(shí)從技術(shù)角度將區(qū)塊鏈分為3層，即智能合約層（用于存儲(chǔ)用戶和第三方服務(wù)之間的合約）、接入層（利用區(qū)塊鏈不可變性和完整性特點(diǎn)保護(hù)隱私）和哈希存儲(chǔ)層（用于存儲(chǔ)數(shù)據(jù)哈希），旨在構(gòu)建一個(gè)以人為中心且符合GDPR的個(gè)人數(shù)據(jù)和身份管理系統(tǒng)。其中，鏈下數(shù)據(jù)庫存儲(chǔ)的個(gè)人數(shù)據(jù)使用對(duì)稱密鑰加密，對(duì)稱密鑰分別被擁有數(shù)據(jù)的各方持有。該方法存在的主要問題在于：只在第一次授權(quán)給第三方服務(wù)時(shí)是安全的，因?yàn)榈谝淮问跈?quán)之后，第三方服務(wù)將擁有個(gè)人數(shù)據(jù)地址和對(duì)稱密鑰，通過可解密密文得到完整的個(gè)人數(shù)據(jù)，之后即使撤銷第三方服務(wù)對(duì)個(gè)人數(shù)據(jù)的訪問，依靠個(gè)人數(shù)據(jù)地址和對(duì)稱密鑰其依然可以得到數(shù)據(jù)；此外，第三方服務(wù)也很有可能將地址和對(duì)稱密鑰泄露出去，或者將明文泄露出去，造成嚴(yán)重的數(shù)據(jù)泄漏風(fēng)險(xiǎn)。

文獻(xiàn)［18］設(shè)計(jì)了一個(gè)遵循GDPR的個(gè)人數(shù)據(jù)管理系統(tǒng)，其允許數(shù)據(jù)所有者強(qiáng)制執(zhí)行數(shù)據(jù)使用許可，確保只有指定方可以處理個(gè)人數(shù)據(jù)，并使用智能合約和加密技術(shù)將所有數(shù)據(jù)活動(dòng)記錄在一個(gè)不可變的分布式賬本中。該系統(tǒng)采用鏈下存儲(chǔ)方式，將個(gè)人元數(shù)據(jù)的訪問地址以加密的形式存儲(chǔ)在鏈上，第三方服務(wù)得到用戶授權(quán)之后將被授予訪問令牌并獲得用戶元數(shù)據(jù)的加密地址，同時(shí)得到解密此地址的私鑰。第三方服務(wù)使用用戶的個(gè)人數(shù)據(jù)地址和訪問令牌請(qǐng)求資源服務(wù)。由于個(gè)人數(shù)據(jù)地址一般情況下是不變的，因此即使用戶撤銷了對(duì)第三方服務(wù)的訪問權(quán)限，但第三方服務(wù)仍擁有用戶個(gè)人數(shù)據(jù)地址，利用此地址其仍有可能獲得個(gè)人數(shù)據(jù)，同時(shí)該地址也存在泄露風(fēng)險(xiǎn)。

2 基于區(qū)塊鏈的個(gè)人數(shù)據(jù)保護(hù)架構(gòu)

2.1 當(dāng)前架構(gòu)及存在問題

本文給出當(dāng)前個(gè)人數(shù)據(jù)保護(hù)體系的綜合性框架，如圖1所示，用以分析當(dāng)前基于區(qū)塊鏈的個(gè)人數(shù)據(jù)保護(hù)方案存在的問題。該架構(gòu)為一個(gè)通用架構(gòu)，不同的方案采用不同的算法。架構(gòu)中包含4個(gè)實(shí)體，分別為用戶（User）、管理用戶數(shù)據(jù)訪問權(quán)限的數(shù)據(jù)控制者（Data Controler，DC）、想要訪問用戶數(shù)據(jù)的第三方服務(wù)（TP）和管理鏈下數(shù)據(jù)存儲(chǔ)的資源服務(wù)（RS）。

圖1 個(gè)人數(shù)據(jù)保護(hù)體系的綜合性框架Fig.1 Comprehensive framework of personal data protection system

如圖1所示，在現(xiàn)有系統(tǒng)架構(gòu)中，一個(gè)TP想要訪問User的數(shù)據(jù)，需要經(jīng)過以下4步：

1）TP向User提出訪問其個(gè)人數(shù)據(jù)的請(qǐng)求。

2）User確認(rèn)授權(quán)，將請(qǐng)求發(fā)送給DC。

3）DC驗(yàn)證User和TP身份后，授權(quán)TP訪問User的數(shù)據(jù)，并將授權(quán)記錄在鏈上，發(fā)送User個(gè)人數(shù)據(jù)的地址或訪問令牌給TP。

4）TP利用訪問令牌或地址訪問資源服務(wù)，資源服務(wù)驗(yàn)證后，處理TP請(qǐng)求并返回?cái)?shù)據(jù)。

在第1步中，TP直接向User發(fā)送訪問請(qǐng)求，User確認(rèn)授權(quán)后提交自己的簽名和TP的簽名發(fā)送給DC驗(yàn)證，由DC處理授權(quán)，由此可減少DC的負(fù)載。在第2步中，若DC驗(yàn)證TP的身份不合法，則不會(huì)通過這一請(qǐng)求，導(dǎo)致授權(quán)失敗。因此，TP需要經(jīng)過DC驗(yàn)證和授權(quán)，在系統(tǒng)中擁有自己的身份。如果TP直接向User發(fā)送請(qǐng)求，那么這一步TP身份的合法性就無法進(jìn)行驗(yàn)證，只能等到User確認(rèn)授權(quán)后發(fā)送給SP時(shí)將TP和User的簽名一同發(fā)送給DC，再由DC驗(yàn)證。因此，應(yīng)先驗(yàn)證TP身份的合法性。

鏈下數(shù)據(jù)的存儲(chǔ)大多使用IPFS系統(tǒng)［19］，其將數(shù)據(jù)以文件的形式分散地存儲(chǔ)在系統(tǒng)中，更新文件時(shí)重新分配地址。由于是分散存儲(chǔ)，文件被散列在各處，因此只有通過創(chuàng)建文件時(shí)分配的地址才能找到分散在各處的文件。若使用傳統(tǒng)數(shù)據(jù)庫存儲(chǔ)，則一般不能更改存儲(chǔ)路徑和關(guān)系。

在圖1的第3步中，TP獲得訪問User數(shù)據(jù)的權(quán)限后，將會(huì)獲得User的個(gè)人數(shù)據(jù)地址。在這種情況下，即使User撤銷TP對(duì)其數(shù)據(jù)的訪問權(quán)限，數(shù)據(jù)地址仍然被TP持有，TP仍然有可能繼續(xù)訪問到User的數(shù)據(jù)。

針對(duì)上述問題，本文提出一個(gè)解決方案，即利用RS處理TP得到授權(quán)后分配的加密地址，而不是直接把用戶個(gè)人數(shù)據(jù)地址分配給TP。TP提交數(shù)據(jù)的加密地址和訪問令牌給RS，由RS處理TP的請(qǐng)求并返回?cái)?shù)據(jù)。

2.2 改進(jìn)的系統(tǒng)架構(gòu)設(shè)計(jì)

本文方案中改進(jìn)的系統(tǒng)架構(gòu)如圖2所示。

圖2 改進(jìn)的系統(tǒng)架構(gòu)Fig.2 Improved system architecture

從C/S模式的角度來分析，服務(wù)S幫助User管理其數(shù)據(jù)，用來處理TP的訪問請(qǐng)求和User的授權(quán)，User即數(shù)據(jù)主體（Data Subject，DS）。此時(shí)，服務(wù)S可以看作是一個(gè)服務(wù)于DS和TP的權(quán)限控制者（Authority Controller，AC）。如果TP違反協(xié)議，它將會(huì)被永久地記錄在賬本中。本文假設(shè)RS是“honest but curious”，這意味著RS誠實(shí)地執(zhí)行所需的協(xié)議，即使它可能對(duì)操作后收到的結(jié)果感到好奇。利用區(qū)塊鏈的偽匿名性，RS被假設(shè)成一個(gè)只存儲(chǔ)DS身份（以太坊地址）和解密其加密地址私鑰的資源服務(wù)，DS匿名提交自己的數(shù)據(jù)給RS，得到真正的地址，其利用第三方加密軟件對(duì)地址進(jìn)行加密得到其數(shù)據(jù)地址的加密地址和解密私鑰，原始地址由DS保存，加密地址被分享給AC，解密私鑰被分享給RS。DS的身份和私鑰以一個(gè)鍵值或表的形式存儲(chǔ)而不關(guān)聯(lián)DS的身份和地址。由此，RS沒有配套的加密地址，無法單獨(dú)查詢庫中指定用戶的數(shù)據(jù)，只有TP請(qǐng)求RS訪問DS的數(shù)據(jù)時(shí)，RS根據(jù)TP提交的加密地址和訪問令牌（訪問令牌中包含DS的身份）得到DS的身份和加密地址，使用與DS身份關(guān)聯(lián)的私鑰解密或加密地址才能返回給TP數(shù)據(jù)。

如圖2所示，在改進(jìn)的系統(tǒng)架構(gòu)中，一個(gè)TP想要訪問DS的數(shù)據(jù)，需要經(jīng)過以下5步：

1）TP向AC提出對(duì)DS數(shù)據(jù)訪問的申請(qǐng)。

2）AC驗(yàn)證TP身份后向DS發(fā)送TP的訪問請(qǐng)求，DS選擇同意或拒絕。

3）AC驗(yàn)證DS的身份并處理授權(quán)，若DS同意授權(quán)，則AC發(fā)送給TP訪問令牌和加密地址。

4）AC和RS同步訪問令牌。

5）TP將訪問令牌和加密地址作為參數(shù)提交給RS，RS驗(yàn)證令牌并使用解密算法解密地址，根據(jù)地址查找數(shù)據(jù)并返回給TP。

在改進(jìn)的系統(tǒng)架構(gòu)中，每個(gè)參與的實(shí)體都有一個(gè)以太坊地址，使用AC、DS、TP在以太坊中的地址id_AC、id_DS、id_TP來代表各個(gè)參與實(shí)體在系統(tǒng)中的身份。訪問控制列表以細(xì)粒度控制方式記錄哪些TP被授權(quán)以及被授予的操作和授權(quán)期限，其包含已經(jīng)被授權(quán)的TP集合和每個(gè)TP的授權(quán)狀態(tài)（當(dāng)前被授權(quán)的操作和訪問令牌），DS可隨時(shí)查看當(dāng)前已被授權(quán)的TP。訪問控制列表的權(quán)限被限制為只有DS才能修改，通過更改訪問控制列表中對(duì)指定TP的訪問策略可修改或移除TP的權(quán)限，DS可以隨時(shí)授權(quán)、修改和撤銷TP的訪問權(quán)限。

在初始階段，DS同意AC管理其個(gè)人數(shù)據(jù)，并將鏈下地址pointer的加密密文enc_pointer分享給AC，將解密密鑰sk_dec分享給RS。AC和DS建立一張可證明授權(quán)關(guān)系的訪問控制列表A_list，其為address地址類型到A_list的映射，即每個(gè)地址都對(duì)應(yīng)一個(gè)A_list列表，此表標(biāo)識(shí)DS、AC和TP的關(guān)系。TP是一個(gè)address地址類型到address=＞TP_policy的映射，標(biāo)識(shí)唯一當(dāng)前DS對(duì)應(yīng)TP的訪問策略。當(dāng)有TP被授權(quán)時(shí)，TP加入A_list關(guān)系表，由于DS可能授權(quán)多個(gè)TP訪問權(quán)限，因此使用一個(gè)集合tps存放已被授權(quán)的TP。根據(jù)A_lis［tDS］.tps可查詢當(dāng)前授權(quán)的TP，通過A_lis［tDS］.TP_policy［TP］可查詢當(dāng)前TP的授權(quán)狀態(tài)。A_list列表和TP列表結(jié)構(gòu)設(shè)計(jì)代碼如下：

在struct list中，mflag標(biāo)識(shí)當(dāng)前AC是否已經(jīng)請(qǐng)求AC管理其個(gè)人數(shù)據(jù)，tpsflag標(biāo)識(shí)當(dāng)前已被授權(quán)的TP數(shù)量，tpsflage標(biāo)識(shí)被授權(quán)TP的數(shù)量。在struct TP中，tpflag標(biāo)識(shí)當(dāng)前TP已被授權(quán)。

2.3 算法設(shè)計(jì)

圖3為DS同意授權(quán)TP的組件交互時(shí)序圖，具體過程如下：1）TP向AC發(fā)送訪問DS數(shù)據(jù)的請(qǐng)求；2）AC詢問DS是否同意授權(quán)；3）DS同意并向AC發(fā)送授權(quán)確認(rèn)；4）AC收到DS的確認(rèn)，更新A_list；5）AC發(fā)enc_pointer和訪問令牌，授權(quán)成功。

圖3 DS授予TP權(quán)限的組件交互時(shí)序圖Fig.3 Component interaction sequence diagram for DS granting TP permission

算法1為授予TP權(quán)限的算法。DS同意授權(quán)TP一組權(quán)限，需要提交希望授予TP的身份和訪問狀態(tài)（CURD）。AC收到授權(quán)確認(rèn)后，首先驗(yàn)證DS是否已經(jīng)授權(quán)AC管理其數(shù)據(jù)（第1行）；然后確認(rèn)DS和A_list中的DS相同并查看TP是否已經(jīng)被授權(quán)（第2行和第3行），如果條件成立，則將TP加入tps列表（第4行），更新A_list中TP的授權(quán)狀態(tài)（第5行～第10行）；最后輸出success（第11行）。

算法1授予TP權(quán)限的算法

算法2為撤銷TP訪問的算法。在DS輸入想要撤銷的TP后，首先判斷DS是否已授權(quán)AC管理其數(shù)據(jù)（第1行）；然后確認(rèn)DS和A_list中的DS相同（第2行），并遍歷列表，找到TP在tps中的索引，若沒有則返回（第3行），刪除tps列表中的TP和TP的授權(quán)列表（第4行～第6行）；最后輸出success（第7行）。

算法2撤銷已授權(quán)TP的算法

3 實(shí)驗(yàn)結(jié)果與分析

本文實(shí)驗(yàn)基于以太坊平臺(tái)，使用remix編譯器的JavaScriptVM環(huán)境部署合約，消耗2 145 356 Gas。合約控制臺(tái)界面如圖4所示，其中，reqMange為請(qǐng)求合約管理其個(gè)人數(shù)據(jù)的函數(shù)，grant和revoc分別為授予和撤銷TP訪問權(quán)限的函數(shù)。DS請(qǐng)求AC后和授權(quán)指定TP訪問權(quán)限后的響應(yīng)分別如圖5和圖6所示。

圖4 合約控制臺(tái)界面Fig.4 Contract console interface

圖5 DS請(qǐng)求AC后得到的響應(yīng)Fig.5 The response after DS requesting AC

圖6 授權(quán)指定TP訪問權(quán)限后的響應(yīng)Fig.6 The response after authorizing specified TP access rights

本文使用remix搭建的測(cè)試網(wǎng)絡(luò)，每次合約的調(diào)用時(shí)間約為2 s。由于測(cè)試網(wǎng)絡(luò)節(jié)點(diǎn)較少，因此挖礦難度低、出塊時(shí)間快。在實(shí)際應(yīng)用中，隨著節(jié)點(diǎn)數(shù)量增加，如果出塊挖礦難度低，將會(huì)導(dǎo)致同時(shí)出塊的交易過多，造成阻塞?？紤]此因素，當(dāng)前以太坊主網(wǎng)出塊的平均時(shí)間已上調(diào)至15.5 s。此外，實(shí)際應(yīng)用中還應(yīng)考慮挖礦難度、Gas價(jià)格和網(wǎng)絡(luò)阻塞程度。

通過使用Caliper［20］對(duì)合約進(jìn)行性能測(cè)試，共進(jìn)行2次測(cè)試，第1次測(cè)試分2輪，每輪500次，第2次測(cè)試分3輪，每輪50次，測(cè)試結(jié)果如表1和表2所示。

表1 合約運(yùn)行500次的性能測(cè)試結(jié)果Table 1 Performance test result after contract running 500 times

表2 合約運(yùn)行50次的性能測(cè)試結(jié)果Table 2 Performance test result after contract running 50 times

實(shí)驗(yàn)結(jié)果表明，兩次測(cè)試都執(zhí)行成功，在運(yùn)行500次的情況下，延時(shí)性能均優(yōu)于運(yùn)行50次的情況，且吞吐量比較穩(wěn)定，保持在10 TPS左右。

在本文系統(tǒng)中，DS和TP是多對(duì)多的關(guān)系，然而一個(gè)TP地址無法對(duì)應(yīng)多個(gè)DS的TP_policy。針對(duì)該問題，本文通過Solidity語言的mapping制造二級(jí)映射：mapping（address=＞mapping（address=＞TP））。通過使用DS地址所對(duì)應(yīng)TP的TP_policy來唯一標(biāo)識(shí)DS對(duì)指定TP的授權(quán)。對(duì)于DS的身份認(rèn)證，利用Solidity語言自身的特性msg.sender來保證授權(quán)等操作必定由DS發(fā)出，而如果使用超級(jí)賬本或其他編程語言，則需要編寫身份認(rèn)證的合約代碼。隨著系統(tǒng)中節(jié)點(diǎn)數(shù)目的增多，分布式賬本的數(shù)量也相應(yīng)增加，只篡改少量節(jié)點(diǎn)的數(shù)據(jù)無法發(fā)起51%攻擊，由此可逐步提高篡改區(qū)塊鏈數(shù)據(jù)的難度。

4 結(jié)束語

在現(xiàn)有基于區(qū)塊鏈的個(gè)人數(shù)據(jù)保護(hù)方案中，存在個(gè)人數(shù)據(jù)地址無法收回的問題。本文提出一種匿名地址管理方案，將個(gè)人數(shù)據(jù)的控制分權(quán)，由AC管理加密地址，由RS管理解密私鑰，但雙方都沒有獲得真正的地址，只有在授權(quán)TP訪問后，TP提交加密地址給RS并由其解密地址，才能得到真正的地址并執(zhí)行TP的數(shù)據(jù)請(qǐng)求，以此實(shí)現(xiàn)對(duì)個(gè)人數(shù)據(jù)的有效保護(hù)。后續(xù)將結(jié)合區(qū)塊鏈3.0的發(fā)展趨勢(shì)對(duì)本文方案進(jìn)行優(yōu)化，進(jìn)一步提高出塊速度和吞吐率。