基于門限代理重加密和IPFS的數據去中心化安全共享方案

喬雙全，王勁松

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

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

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

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

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

1 理論基礎

1.1 代理重加密

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

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

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

1.2 門限代理重加密

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

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

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

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

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

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

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

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

1.3 IPFS

星際文件系統（InterPlanetary File System，IPFS）是一個用于在分布式文件系統中存儲和共享數據的協議和對等網絡.它綜合了現有的對等網絡協議和系統的成功思想，包括分布式哈希表（Distributed Hash Table，DHT）、BitTorrent、Git和SFS，將這些技術融合、發展，使之成為一個擁有以上技術所有優秀特性的綜合的內聚系統.

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

2 基于門限代理重加密和IPFS的數據共享機制

2.1 數據共享模型

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

Alice：Alice是數據發送者，她用自己的公鑰加密數據文件，并為代理節點生成重加密密鑰片段.

Bob，Carl，David：Bob、Carl和David是數據接收者，他們從IPFS網絡中獲取加密的數據文件，并用各自的私鑰解密文件.

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

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

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

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

圖2數據共享模型Fig.2 File sharing model

2.2 威脅模型

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

數據發送者：本文假定數據發送者是誠實的，即數據是真實的，但是系統中存在惡意節點冒充真實數據發送者的可能性.

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

代理節點：本文假定代理節點是半可信的，他們中的某些節點可能會偷窺數據內容或者執行不誠實加密.

潛在攻擊者：潛在攻擊者是惡意的，他們在系統內部或外部并想要破化該系統.

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

2.3 數據共享流程

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

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

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

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

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

3 安全分析

本文將根據2.2節所述的威脅模型討論系統的安全問題.

3.1 身份偽造問題

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

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

3.2 共謀攻擊問題

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

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

3.3 節點作惡問題

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

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

4 實驗與結果分析

4.1 實驗環境

本次實驗的硬件環境由部署在服務器上的10臺虛擬機組成，每個節點的硬件配置細節如表1所示，實驗的軟件環境如表2所示.

專家表示，給寶寶適當地補充益生菌，可以呵護寶寶腸道健康，是預防秋冬腹瀉的有效方法之一。而寶寶已經有了腹瀉的癥狀時，也可以適當補充益生菌，可有效抑制有害致病菌、維持腸道微生態平衡、增強腸道免疫能力。

表1節點硬件配置細節Tab.1 Nodes hardware configuration details

表2系統軟件環境Tab.2 System software environment

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

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

4.2 加解密性能測試

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

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

4.3 數據傳輸性能測試

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

4.3.1 單點數據傳輸性能測試

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

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

4.3.2 多點數據傳輸性能測試

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

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

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

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

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

5 結論

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