喬雙全，王勁松

（天津理工大學(xué)計算機科學(xué)與工程學(xué)院，天津300384）

隨著信息技術(shù)的發(fā)展，大數(shù)據(jù)的量級正以指數(shù)級的速度增長，數(shù)據(jù)已經(jīng)成為促進產(chǎn)業(yè)發(fā)展的重要驅(qū)動力.但是當(dāng)前大數(shù)據(jù)產(chǎn)業(yè)面臨著“人人有數(shù)據(jù)，人人缺數(shù)據(jù)”的“數(shù)據(jù)孤島”式困境，將這些分散的大數(shù)據(jù)互連共享，從而獲得數(shù)據(jù)中潛在的巨大價值，是科研、政務(wù)、商業(yè)、公共服務(wù)等領(lǐng)域共同存在的迫切需求[1].傳統(tǒng)的多方數(shù)據(jù)共享方案大多是基于第三方云存儲系統(tǒng)的，這種模式依賴于中心化的存儲服務(wù)，存在單點故障和隱私安全風(fēng)險.當(dāng)數(shù)據(jù)的所有權(quán)由數(shù)據(jù)擁有者掌控轉(zhuǎn)變?yōu)橛晒性频鹊谌綄嶓w管理者所掌控時，威脅場景會發(fā)生根本變化[2].在這種情況下，數(shù)據(jù)共享者不僅面臨著來自網(wǎng)絡(luò)攻擊者對本地數(shù)據(jù)的攻擊威脅，還將承擔(dān)云存儲提供商遭受內(nèi)部或外部惡意攻擊的風(fēng)險.此外，集中式的數(shù)據(jù)存儲機制容易遭受單點故障問題，數(shù)據(jù)的可靠性完全取決于云存儲服務(wù)商的軟硬件的可靠性.應(yīng)對這些威脅的方法主要包括加強數(shù)據(jù)訪問控制策略、改進內(nèi)部監(jiān)督機制以及改進災(zāi)難恢復(fù)和數(shù)據(jù)備份機制等，但這些措施實際上僅僅將威脅轉(zhuǎn)化為信任問題.事實上，并沒有實際有效的機制來防止這些中心化的云存儲服務(wù)商無意或有意地破壞這些措施.

為了確保數(shù)據(jù)的隱私安全，在共享數(shù)據(jù)的時候，需要對數(shù)據(jù)進行加密處理.廣泛使用的公鑰加密方案提供了很好的安全性，但其加密性能不高，特別是在多方數(shù)據(jù)共享的情況下，數(shù)據(jù)發(fā)送者必須針對多個解密者使用其公鑰進行重復(fù)的加密操作.當(dāng)數(shù)據(jù)提供者是算力不足的設(shè)備時，多次重復(fù)的加密操作大大增加了設(shè)備的運算負(fù)擔(dān).

在數(shù)據(jù)共享的研究領(lǐng)域中，目前已有廣泛使用的基于點對點（Peer-to-Peer，P2P）技術(shù)的去中心化的文件共享方案，如基于BitTorrent內(nèi)容分發(fā)協(xié)議的共享方案，和基于分布式哈希表（Distributed Hash Table，DHT[3]）技術(shù)的共享方案.但這些技術(shù)僅僅做到了數(shù)據(jù)的去中心化共享，沒有使用加密技術(shù)保證數(shù)據(jù)的隱私性和安全性.基于云計算的數(shù)據(jù)共享方案中，研究人員提出了多種保護數(shù)據(jù)安全及隱私的方法.Li等人[4]提出了一種新的基于屬性的數(shù)據(jù)共享方案，適用于云計算中資源有限的移動用戶.Dong等人[5]提出了一種利用密文策略屬性加密結(jié)合身份加密的數(shù)據(jù)共享方案，來提供安全可靠的云數(shù)據(jù)共享服務(wù).Liu等人[6]提出一種利用組簽名和動態(tài)廣播加密技術(shù)的多用戶數(shù)據(jù)共享方案，允許任何云用戶匿名地與他人共享數(shù)據(jù).然而這些方案仍然依賴于云服務(wù)進行數(shù)據(jù)共享，無法從源頭上解決中心化帶來的數(shù)據(jù)安全問題和隱私問題.

本文提出一種新的去中心化的安全的數(shù)據(jù)共享方案，該方案的創(chuàng)新點如下：1）采用門限代理重加密方法解決了多方數(shù)據(jù)共享場景下加密低效的問題，可以保證數(shù)據(jù)安全并降低共謀風(fēng)險.2）采用IPFS技術(shù)解決了數(shù)據(jù)的中心化問題，并提高了多方數(shù)據(jù)共享場景下的數(shù)據(jù)傳輸效率.

1 理論基礎(chǔ)

1.1 代理重加密

代理重加密（Proxy Re-Encryption，PRE）的概念最早由Blaze、Bleumer和Strauss在文獻[7]中提出.代理重加密是一種特殊類型的公鑰加密，它允許代理將由加密者公鑰加密的密文轉(zhuǎn)換為由解密者公鑰加密的密文，在這個過程中代理無法獲取有關(guān)原始數(shù)據(jù)的任何信息.代理需要獲取擁有密文的原始加密者通過其私鑰和解密者的公鑰生成的重加密密鑰，然后使用該重加密密鑰對密文進行轉(zhuǎn)換.解密者從代理獲取重加密后的密文，然后可以使用自己的私鑰解密文件.

圖1描述了一個典型的代理重新加密模型，該模型由授權(quán)者Alice、被授權(quán)者Bob和代理Proxy組成.數(shù)據(jù)所有者Alice擁有公鑰pkA，她（或者擁有pkA的實體）可以用pkA對消息m進行加密，從而生成只有她才能使用其密鑰skA解密的密文cA.Alice決定將消息m的訪問權(quán)限委托給擁有密鑰對（pkB，skB）的Bob.為此，Alice創(chuàng)建一個重加密密鑰：rkA→B=rekey（skA，pkB）并將其發(fā)送給代理.代理用rkA→B對cA重新加密，得到用pkB加密的密文cB.Bob可以用他的密鑰skB解密cB，得到原始消息m.

圖1代理重加密Fig.1 Proxy re-encryption

1.2 門限代理重加密

門限代理重加密采用了t-of-n架構(gòu)的多代理方案，將重加密權(quán)限分散到了n個代理節(jié)點，分割了單代理節(jié)點的信任風(fēng)險，并允許在有部分代理節(jié)點發(fā)生故障的情況下，仍可完成重加密操作.每個代理節(jié)點對密文進行重加密操作生成重加密后的密文片段，解密者只要收集達到門限值t數(shù)量的重加密的密文片段后，就可以使用自己的私鑰解密密文.

門限代理重加密方案基于KEM/DEM混合加密實現(xiàn)，Cramer和Shoup[8]最早對混合加密進行了系統(tǒng)化研究，并提出密鑰封裝機制（Key Encryption Mechanism，KEM）和數(shù)據(jù)封裝機制（Data Encryption Mechanism，DEM）的概念.

在典型的門限代理重加密場景中，實體分為數(shù)據(jù)發(fā)送者Alice、n個代理節(jié)點Proxyi（i=1，2，…，n）和數(shù)據(jù)接收者（Bob）.加密、重加密和解密的過程如下：

Alice首先運行KEM的密鑰生成算法，通過自己的公鑰pkA生成一個對稱密鑰K和K的密文c1，使用K加密消息m得到密文c2，并把c1和c2發(fā)送給Bob；

Alice獲取Bob的公鑰pkB，運行KEM的密鑰生成算法，通過自己的私鑰pkA和Bob的公鑰pkB生成n個重加密密鑰片段ki（i=1，2，…，n），并把ki發(fā)送給代理節(jié)點Proxyi；

代理節(jié)點Proxyi運行KEM的密鑰生成算法，通過ki對c1進行重加密操作，生成密文片段ci，并把ci發(fā)送給Bob；

Bob從n個代理節(jié)點收集至少達到閾值t數(shù)量的有效密文片段ci，然后可以用自己的私鑰skB和至少t個有效密文片段ci將密文c1恢復(fù)成對稱密鑰K；

Bob運行DEM的數(shù)據(jù)解密算法，通過對稱密鑰K解密密文c2得到原始消息m.

1.3 IPFS

星際文件系統(tǒng)（InterPlanetary File System，IPFS）是一個用于在分布式文件系統(tǒng)中存儲和共享數(shù)據(jù)的協(xié)議和對等網(wǎng)絡(luò).它綜合了現(xiàn)有的對等網(wǎng)絡(luò)協(xié)議和系統(tǒng)的成功思想，包括分布式哈希表（Distributed Hash Table，DHT）、BitTorrent、Git和SFS，將這些技術(shù)融合、發(fā)展，使之成為一個擁有以上技術(shù)所有優(yōu)秀特性的綜合的內(nèi)聚系統(tǒng).

IPFS也是一個分布式的超媒體傳輸協(xié)議，旨在補充甚至取代傳統(tǒng)的超文本傳輸協(xié)議HTTP.傳統(tǒng)的HTTP協(xié)議是中心化的，當(dāng)你從網(wǎng)站下載文件時，HTTP協(xié)議一次只能從一臺計算機下載文件，而不是同時從多臺計算機下載文件.與HTTP協(xié)議不同，IPFS可以在對等模式下同時從多臺計算機下載相同的文件，從而可以容忍單點失效問題.IPFS的另一個重要特征是內(nèi)容尋址，這也與HTTP協(xié)議有著根本的不同（當(dāng)你使用HTTP協(xié)議訪問網(wǎng)絡(luò)上的文件時，你必須知道文件的網(wǎng)址，這意味著HTTP是通過網(wǎng)址定位互聯(lián)網(wǎng)上的文件）.當(dāng)使用IPFS添加文件時，文件以及其中的所有塊都將被賦予一個稱為加密哈希的唯一指紋，該指紋在IPFS網(wǎng)絡(luò)中唯一標(biāo)識該文件.其他節(jié)點可以通過加密哈希訪問文件.當(dāng)其他節(jié)點有相同的文件時，可以使用加密哈希同時從多個節(jié)點下載該文件.

2 基于門限代理重加密和IPFS的數(shù)據(jù)共享機制

2.1 數(shù)據(jù)共享模型

本方案的模型如圖2所示，該模型描述了多方數(shù)據(jù)共享場景下的數(shù)據(jù)的加密、重加密、解密以及傳輸?shù)倪^程.該模型中存在以下實體：

Alice：Alice是數(shù)據(jù)發(fā)送者，她用自己的公鑰加密數(shù)據(jù)文件，并為代理節(jié)點生成重加密密鑰片段.

Bob，Carl，David：Bob、Carl和David是數(shù)據(jù)接收者，他們從IPFS網(wǎng)絡(luò)中獲取加密的數(shù)據(jù)文件，并用各自的私鑰解密文件.

Proxy1～ProxyN：Proxy1～ProxyN是N個代理節(jié)點，他們使用數(shù)據(jù)接收者的公鑰對用Alice公鑰加密的文件進行重加密操作.

Eve：Eve是假想的潛在攻擊者，他可以對系統(tǒng)進行惡意攻擊.

模型中所有的實體都處于同一個IPFS私有網(wǎng)絡(luò)，數(shù)據(jù)存儲在本地，不存在中心化的存儲節(jié)點.每個實體可以通過本地的IPFS網(wǎng)關(guān)獲取IPFS網(wǎng)絡(luò)中的數(shù)據(jù)文件.數(shù)據(jù)上傳到IPFS網(wǎng)絡(luò)后會生成對應(yīng)的IPFS加密哈希地址，用于在私有網(wǎng)絡(luò)中唯一標(biāo)志該文件，私有網(wǎng)絡(luò)中任何得到該地址的實體都可以在IPFS網(wǎng)絡(luò)中下載該文件.并且在多方數(shù)據(jù)共享的場景下，如果數(shù)據(jù)被多個節(jié)點下載過，那么在新節(jié)點下載該數(shù)據(jù)時便可以在多個節(jié)點中同時下載，從而顯著提高多方數(shù)據(jù)共享時的數(shù)據(jù)傳輸效率.并且因為該方案不依賴于中心化的存儲服務(wù)，因此可以避免中心化帶來的單點故障問題和隱私泄露問題.

該模型使用門限代理重加密保證數(shù)據(jù)的隱私，在多方數(shù)據(jù)共享的場景下，數(shù)據(jù)發(fā)送者只需要使用自己的公鑰對數(shù)據(jù)進行一次加密，然后授權(quán)給解密者解密權(quán)限，多個代理節(jié)點會對加密數(shù)據(jù)進行重加密操作，生成對應(yīng)的密文片段.解密者收集到足夠的（達到門限值）密文片段后，可以使用自己的私鑰解密數(shù)據(jù).因為t-of-n架構(gòu)的代理重加密機制，本方案允許部分代理節(jié)點失效，從而在代理重加密層面避免了中心化的單點失效問題，并且多代理節(jié)點的存在，增加了解密者與代理節(jié)點共謀的難度，降低了共謀攻擊的風(fēng)險.

圖2數(shù)據(jù)共享模型Fig.2 File sharing model

2.2 威脅模型

本文通過討論系統(tǒng)中實體的威脅行為來定義系統(tǒng)的威脅模型.定義如下：

數(shù)據(jù)發(fā)送者：本文假定數(shù)據(jù)發(fā)送者是誠實的，即數(shù)據(jù)是真實的，但是系統(tǒng)中存在惡意節(jié)點冒充真實數(shù)據(jù)發(fā)送者的可能性.

數(shù)據(jù)接收者：本文假定數(shù)據(jù)接收者是惡意的，他們可以和代理節(jié)點共謀而繞過重加密的限制，并且可以在系統(tǒng)之外勒索數(shù)據(jù)提供者.

代理節(jié)點：本文假定代理節(jié)點是半可信的，他們中的某些節(jié)點可能會偷窺數(shù)據(jù)內(nèi)容或者執(zhí)行不誠實加密.

潛在攻擊者：潛在攻擊者是惡意的，他們在系統(tǒng)內(nèi)部或外部并想要破化該系統(tǒng).

本文不考慮以下問題：數(shù)據(jù)接收者主動泄露解密的數(shù)據(jù).如果他們被授予加密數(shù)據(jù)的解密權(quán)限，那么他們就被授予數(shù)據(jù)的讀取權(quán)限，因此一旦信息被發(fā)布，任何訪問控制系統(tǒng)都不能阻止它被泄露.

2.3 數(shù)據(jù)共享流程

下面根據(jù)圖2所示模型圖介紹該模型下數(shù)據(jù)共享的流程：

1Alice使用自己的公鑰pkA對文件F進行加密，生成加密文件Fe.然后將其上傳到IPFS網(wǎng)絡(luò)，生成對應(yīng)的IPFS加密哈希地址；

2Alice使用其私鑰skA，Bob的公鑰pkB、Carl的公鑰pkC以及David的公鑰pkD，分別為Bob、Carl和David生成對應(yīng)的重加密密鑰keyr，每個數(shù)據(jù)接收者對應(yīng)的重加密密鑰由N個重加密密鑰片段組成，每個密鑰片段稱為kFrag；

3Alice使用每個代理節(jié)點的公鑰對密鑰片段kFrag進行加密，然后將這N個加密后的密鑰片段發(fā)給代理節(jié)點，每個代理獲得其中一個片段.令k為密鑰片段的數(shù)量，t為門限值；

4每個代理節(jié)點Proxyi使用自己的私鑰解密kFrag，并從IPFS網(wǎng)絡(luò)中獲取加密文件Fe，并用獲得的重加密密鑰片段kFrag對該密文進行重加密操作，生成重加密后的密文片段Ci，并將其上傳到IPFS網(wǎng)絡(luò)；

3 安全分析

本文將根據(jù)2.2節(jié)所述的威脅模型討論系統(tǒng)的安全問題.

3.1 身份偽造問題

公鑰加密算法允許任何人通過A的公鑰對數(shù)據(jù)進行加密，因此存在惡意用戶冒充A用戶使用其公鑰對數(shù)據(jù)進行惡意加密的可能.為了防止該情況發(fā)生，本文采用數(shù)字簽名的方式向數(shù)據(jù)接收者驗證發(fā)送者的身份.數(shù)據(jù)簽名如果直接發(fā)送給數(shù)據(jù)接受者，存在被監(jiān)聽的可能，這會泄露數(shù)據(jù)發(fā)送者的身份隱私，因為驗證數(shù)據(jù)所有者的公共數(shù)字簽名可以直接確定數(shù)據(jù)的發(fā)送者.本文采用以下方法解決該問題將數(shù)字簽名作為共享數(shù)據(jù)的一部分，因此在密文被解密之前不可能驗證簽名.

使用不同的密鑰對進行簽名和加密（特別是考慮到共謀攻擊的可能性）.

3.2 共謀攻擊問題

在傳統(tǒng)的代理重加密方案中，由于只存在單一的代理節(jié)點，如果該代理節(jié)點和解密者串通，將重加密密鑰直接泄露給解密者，解密者就可以隨意解密數(shù)據(jù)，從而繞過基于條件或時間的任何約束，稱之為共謀攻擊.

本文采用了密鑰分段形式的門限代理重加密方法，將代理的重加密操作擴展到了多個代理節(jié)點，從而在多個代理節(jié)點之間分散了信任，解密者如果要發(fā)動共謀攻擊，需要與至少t個代理節(jié)點串通，這增加了共謀攻擊的難度.

3.3 節(jié)點作惡問題

系統(tǒng)里可能存在的攻擊者，會對系統(tǒng)進行破壞.攻擊者可能會對系統(tǒng)的代理節(jié)點進行攻擊，從而破壞加密的過程.因為本文采用的門限代理重加密方案擁有多個代理節(jié)點，允許部分代理節(jié)點失效，即使部分代理節(jié)點宕機也不會影響數(shù)據(jù)加密過程，這增強了系統(tǒng)的健壯性.攻擊者可能會通過加入IPFS私有網(wǎng)絡(luò)并監(jiān)聽網(wǎng)絡(luò)通信來竊取系統(tǒng)內(nèi)共享的數(shù)據(jù)的IPFS地址，從而從IPFS網(wǎng)絡(luò)中獲取其他節(jié)點共享的數(shù)據(jù).

但數(shù)據(jù)的共享過程都是通過加密保護的，除非數(shù)據(jù)接收者泄露自己的私鑰給攻擊者，否則攻擊者只能獲取加密后的數(shù)據(jù)而無法解密數(shù)據(jù).

4 實驗與結(jié)果分析

4.1 實驗環(huán)境

本次實驗的硬件環(huán)境由部署在服務(wù)器上的10臺虛擬機組成，每個節(jié)點的硬件配置細(xì)節(jié)如表1所示，實驗的軟件環(huán)境如表2所示.

專家表示，給寶寶適當(dāng)?shù)匮a充益生菌，可以呵護寶寶腸道健康，是預(yù)防秋冬腹瀉的有效方法之一。而寶寶已經(jīng)有了腹瀉的癥狀時，也可以適當(dāng)補充益生菌，可有效抑制有害致病菌、維持腸道微生態(tài)平衡、增強腸道免疫能力。

表1節(jié)點硬件配置細(xì)節(jié)Tab.1 Nodes hardware configuration details

表2系統(tǒng)軟件環(huán)境Tab.2 System software environment

圖3數(shù)據(jù)的加解密性能測試Fig.3 Data encryption and decryption performance test

本文構(gòu)建了一個IPFS私有網(wǎng)絡(luò)來實現(xiàn)數(shù)據(jù)的去中心化存儲和傳輸.門限代理重加密模塊通過Python3實現(xiàn)，作為對比測試用的公鑰加密工具選用了開源的eciespy，兩種加密方案都使用secp256k1橢圓曲線.

4.2 加解密性能測試

本文在10個節(jié)點上進行了加密和解密的性能測試，Node 5模擬數(shù)據(jù)發(fā)送方，Node 6、7、8、9模擬數(shù)據(jù)接收方，Node 1、2、3、4模擬代理節(jié)點.實驗對本模型采用的門限代理重加密方案和傳統(tǒng)的公鑰加密方案進行了性能比較測試.在多方數(shù)據(jù)共享的場景下，數(shù)據(jù)發(fā)送者需要針對不同的數(shù)據(jù)接收者，分別對數(shù)據(jù)進行加密.但是在解密階段，數(shù)據(jù)接收者的解密過程是相互獨立的.因此本實驗記錄了數(shù)據(jù)發(fā)送者每次加密的時間以及在解密階段花費時間最長的節(jié)點所花費的時間.門限代理重加密方案中的多個代理節(jié)點可以并行獨立地重加密數(shù)據(jù)，因此記錄了重加密過程中花費時間最長的節(jié)點所花費的時間，解密階段也記錄了花費時間最長的節(jié)點所花費的時間.

圖3顯示了在不同的數(shù)據(jù)量大小下，不同數(shù)量的數(shù)據(jù)接收者對加解密性能的影響.對比測試結(jié)果表明，相同的數(shù)據(jù)大小下，本文方案的加解密操作所耗時間與數(shù)據(jù)接收者數(shù)量關(guān)系不大，公鑰加密方案的加解密操作所耗時間隨著接收者數(shù)量的增多而以線性速度增長.實驗顯示本文采用的門限代理重加密方案的加解密性能優(yōu)于傳統(tǒng)的公鑰加密方案.特別是當(dāng)數(shù)據(jù)接收者數(shù)量越多時，兩者的性能差距越明顯.

4.3 數(shù)據(jù)傳輸性能測試

本文對系統(tǒng)中采用的基于IPFS的數(shù)據(jù)存儲和傳輸方案與基于HTTP協(xié)議的傳統(tǒng)數(shù)據(jù)傳輸方案的數(shù)據(jù)傳輸性能進行了對比測試.前者通過go-ipfs提供的命令行工具進行測試.本文在Node5上用Apachehttpd 2.4.41構(gòu)建了一個HTTP服務(wù)器來提供下載服務(wù)，其他節(jié)點使用GNU Wget從HTTP服務(wù)器下載文件來測試后者的數(shù)據(jù)傳輸性能.測試分為兩組：單點傳輸性能測試和多點傳輸性能測試.

4.3.1 單點數(shù)據(jù)傳輸性能測試

單點數(shù)據(jù)傳輸性能測試在6個節(jié)點上運行，其中Node 5作為上傳節(jié)點，Node 1、2、3、4和6作為下載節(jié)點.首先測試了基于IPFS的方案的傳輸性能.Node 5將不同大小的文件上傳到IPFS網(wǎng)絡(luò)，然后其他節(jié)點依次從IPFS網(wǎng)絡(luò)下載文件.然后測試了基于HTTP協(xié)議的數(shù)據(jù)傳輸性能.使用SCP命令將文件從其他節(jié)點上傳到Node 5，模擬傳統(tǒng)文件共享方案將文件上傳到第三方云服務(wù)器的過程，其他節(jié)點使用GNU Wget依次從Node 5下載文件.記錄了這兩種方案的上傳和下載時間，以衡量它們的傳輸性能.

圖4顯示了在不同數(shù)據(jù)大小下的上傳性能測試結(jié)果.圖5顯示了不同數(shù)據(jù)大小下的每個節(jié)點的下載性能測試結(jié)果.測試結(jié)果表明，本文采用的基于IPFS的方案在上傳性能上優(yōu)于基于HTTP協(xié)議的方案；然而，就單點下載性能而言，基于IPFS的方案比基于HTTP協(xié)議的方案慢.

4.3.2 多點數(shù)據(jù)傳輸性能測試

本文在10個節(jié)點上運行多點數(shù)據(jù)傳輸性能測試，其中Node 5作為上傳節(jié)點，Node 1、2、3、4、6、7、8、9、10作為下載節(jié)點.首先測試了本文采用的基于IPFS的方案的多點下載性能.Node 5將不同大小的文件上傳到IPFS網(wǎng)絡(luò)，其他節(jié)點通過Shell腳本并行從IPFS網(wǎng)絡(luò)下載.然后測試了基于HTTP協(xié)議的數(shù)據(jù)下載性能.使用SCP命令將文件從其他節(jié)點上傳到Node 5，并通過運行Shell腳本在其他節(jié)點上通過GNU Wget并行從Node 5服務(wù)器下載文件.

圖4上傳性能測試Fig.4 Upload performance test

圖5砂輪軸向截形Fig.5 Axial section of grinding wheel

圖6數(shù)據(jù)多點下載性能測試Fig.6 Data multi-point download performance test

圖6顯示了測試期間下載所消耗的時間.其中在大部分節(jié)點上，本文方案的數(shù)據(jù)下載性能優(yōu)于HTTP方案，在少數(shù)節(jié)點上，HTTP方案的數(shù)據(jù)下載性能略優(yōu)于本文方案.測試結(jié)果表明，在多個節(jié)點同時下載的情況下，本文采用的基于IPFS的數(shù)據(jù)數(shù)傳方案的下載性能優(yōu)于基于HTTP的方案.

5 結(jié)論

本文針對當(dāng)前多方數(shù)據(jù)共享方案中存在的數(shù)據(jù)中心化問題和加密性能低下問題，提出了一種基于門限代理重加密技術(shù)和IPFS技術(shù)的去中心化的數(shù)據(jù)共享方案.本方案采用門限代理重加密技術(shù)解決了多方數(shù)據(jù)共享情景下數(shù)據(jù)加密低效的問題，采用IPFS技術(shù)解決了數(shù)據(jù)中心化的問題，實現(xiàn)了數(shù)據(jù)去中心化存儲和傳輸.實驗結(jié)果顯示，本方案并在多方數(shù)據(jù)共享情景下提高了數(shù)據(jù)加密性能和多點下載的性能.