【應用】運用Re-Encryption技術對你的IPFS網路數據進行多重保護

來自專欄 IPFS指南10 人贊了文章

大家好，我叫戴嘉樂，很榮幸，然後今天能站在這裡跟大家一起分享。首先感慨兩句，這個《中國IPFS開發者圓桌沙龍》系列活動，到今天，在北京已經舉辦了兩期了，其實第一期到第二期時間並不長，但是在這個過程中得到了很多開發者以及圈裡前輩的幫助和支持，才有了今天這樣一個氛圍。今天看到這麼多人願意前來，真的心裡特別開心，做為這個活動的發起人，特別想借著今天這個520這樣比較特殊的日子，給所有幫助這個活動的一線工作人員，以及在場的所有的嘉賓，還有媒體以及好友們表一個白，真的特別謝謝你們：我愛你們！

我們回到正題，今天我帶來的內容是IPFS和Re-Encryption技術的結合思考，今天給大家從五個角度去詮釋一下我這塊的研究成果。然後第一個角度，從為什麼要去研究這樣的一個方向聊起，主要有三個誘因：

第一個誘因，就是從HTTP到HTTPS的一個變遷來看這個問題：網路中明文傳輸問題，多年以來，都給大家帶來一種不安全感，不管是用戶還是企業，因而，HTTP協議逐漸過度升級為HTTPS。據我所知，2015年開始，然後大部分的互聯網巨頭公司基本上都強制要求各個業務產品線去切換HTTPS服務。IPFS如果要對標HTTP協議，協議傳輸層的加密屬性肯定少不了。不然我覺得大家也沒有理由去擁抱一個這樣一個新的技術。

第二個誘因其實是從IPFS網路的局限性來看這個問題：IPFS目前在我們的區塊鏈領域是被寄予厚望的。大家都覺得他很有潛力去成為區塊鏈領域很棒的超級內容分發網路，那麼很多在做類似這樣事情的人也願意去參考它。雖然IPFS本身帶有了一些這樣的加密特性，但是他沒有辦法照顧到所有各種各樣的業務，因為我們的業務其實都是跟著人的創意去走，IPFS作為一個底層基礎設施，肯定有很多東西是沒辦法照顧到所有人的，因此存在一定的局限性。當然，他們沒想到，並不代表我們做不到，自己動手豐衣足食。研究和涉獵這樣的一個方向的話，我覺得對我們以後做很多設計用戶隱私場景下的方案都是有幫助的，而且可以側面地去提高我們的業務在這個網路下對於用戶的一個安全性，讓更多的企業或者說用戶更願意去用我們的業務。

第三個誘因就是從行業內的安全形度來看這個問題：行業內的安全形度指的是之前頻繁發生過一些合約漏洞的事情，大家關注新聞的話肯定也都耳濡目染了，而且我覺得這是在區塊鏈圈每個開發者都應該重視的一個這樣的問題，我們不能只顧著去開發業務，因為趕市場行情，或者說一些市場熱度，我們就忽略了用戶和投資者的切身利益，讓他們承受被黑客攻擊的風險和隱患。區塊鏈市場在不斷的擴大，可以說每天應該都會有幾百個新的想法出現，然後每個月都有幾十個新的項目產出。每個公司和創業團隊的水平真的是參差不齊，項目方做事的態度可能也褒貶不一。所以不靠譜區塊鏈項目和合約的漏洞其實是與日俱增的，類似美圖這樣的大公司也因此吃過一些虧。我覺得作為一個合格的開發者，在我們去選用一些技術方案，或者說去做一些技術創業的時候應該兼具一份責任感，就是儘可能地在做技術選型的時候去重視安全這塊的問題，尤其是像以太坊，EOS，IPFS這樣還處在早期的技術。

接下來，給大家介紹下IPFS網路本身的加密層設計。我總結的第一點：具有PKI特性。

玩密碼學的朋友其實應該都不會陌生，PKI：Public Key Infrastructure，也叫公鑰基礎設施，是一種遵循標準的利用公鑰加密技術為電子商務的開展提供一套安全基礎平台的技術和規範。一個典型的PKI系統包括PKI策略、軟硬體系統、證書機構CA、註冊機構RA、證書發布系統和PKI應用等。HTTP協議中PKI的使用也有很多，最典型的就是HTTPS。而IPFS協議中的PKI特性和使用場景，我目前發現最明顯的有三個：1.Node ID生成，2.IPNS掛載，3.私有集群網路搭建 ，下面具體展開來講：

PKI特性之一：NodeID的生成：這段代碼是IPFS白皮書裡面的初始化生成NodeID的一段偽代碼。我們可以看到，在創建過程中將通過PKI.genKeyPair()(默認用的RSA非對稱加密演算法)生成一套公鑰（n.PubKey）和私鑰（n.PrivKey），NodeId 將通過hash(n.PubKey)演算法，對公鑰進行簽名。這樣做的好處是節點在第一次連接對等方的時候，可以通過互相交換公鑰，來驗證hash(other.PublicKey) = other.NodeId是否成立 ，如果成立，則確定可信身份，保持通信，否則連接終止，防範網路中的一些嗅探攻擊。（這和我們在做後端微服務之前的介面通信時，常設置變數參數參與的對稱加密簽名來防止網路攻擊一樣）。如何查看我們節點的私鑰和公鑰？在本地，我們可以通過ipfs id隨時來查看我們的公鑰（PublicKey）和其對應的NodeID。也可以通過vim ~/.ipfs/config 來進行私鑰（PrivKey）的查看。

PKI特性之二：IPNS掛載,這裡要提一下之前搬山工童鞋在小密圈發起的一個提問： 如何在不同節點中更新同一個IPNS Hash的內容？的問題。我們一般使用的

ipfs name publish 命令是默認掛載一個文件空間到的ipns/nodeID上，回歸本質，是因為在初始化節點後，公鑰文件來自我們本地最初的那一份生成NodeID的Self公鑰，但是我們可以繼續生成新公鑰，通過新生成一份代理公鑰來實現不同節點中同一份IPNS地址的內容更新，過程如PPT所示。

通過查閱Core層源碼，我們可以看到，加密方法Type是可選的，默認是RSA，但也支持ed25519。關於ED25519演算法的使用，有個比較熱點的話題，最近新出的一個基於IPFS的移動端項目：Textile Photos ，通過在移動端利用用戶Id或者Cuid（設備ID）來進行ED25519生成PKI密鑰對，使用公鑰來啟用外部應用程序和服務的授權，以向私人錢包添加內容，這塊十分巧妙。

其次，Ed25519是一個數字簽名演算法，簽名和驗證的性能都極高，一個4核2.4GHz 的 ARM CPU，每秒可以驗證 10000+簽名，安全性極高，且簽名過程不依賴隨機數生成器，不依賴hash函數的防碰撞性，沒有時間通道攻擊的問題，並且簽名很小，只有64位元組，公鑰也很小，只有32位元組，選用該方法，在速度和性能上對移動設備上是非常友好的。然後底下的開發者也可以去那個就是根據自己的業務需求，靈活選用。

PKI特性之三，就是私有網路的搭建。在這個搭建過程中需要在集群節點之間共享一個密鑰。

這一段代碼是來自官方的一個密鑰生成器，通過定義一個32比特的數組，隨機生成數字，壓縮，貝葉斯轉換為16位的一個密鑰，輸出為一份公共的swarm.key，存儲在不同節點的上~/.ipfs/根目錄下，在我們更換完各個節點的bootstrap地址後，執行ipfs swarm connect操作構建私有集群連接時，會對公共密鑰swarm.key進行再校驗。

雖然以上三個過程沒有像HTTPS一樣引入數字證書，但是也足夠詮釋了 PKI 的設計機制。

IPFS網路本身的加密層設計，第一點是具有PKI特性，第二點是文件定址加密。Hash指紋應該用過IPFS的朋友都不陌生，我們所添加文件的地址+名稱都將通過Multihash模塊加密，這是我們在執行add操作文件的go源碼實現，可以看到目前release環境下，系統默認均採用SHA2-256演算法，這邊我也查閱了multihash 的源碼，顯示支持多達10餘種哈希演算法，但目前只在IPFS Debug測試環境下才可配置進add操作。

第三點就是 DAG分片，這塊應該是IPFS內容定址的設計精髓，當然，IPFS採用Merkle DAG技術對整個系統帶來的優點有很多，今天這裡我們只討論DAG分片對文件的安全保護屬性：這是我之前上傳的 自己的頭像數據：Qmdv...：DAG分片之後：QmVo...,QmYG...，QmdF...，QmXA...，QmSN...。打開其中一個QmYG...文件我們試試，拿到分片文件是RAW格式（原始圖像編碼數據編碼）的碎片，只獲取其中的幾個碎片數據是無法通過DAG解析器拼合成原圖像的，一定意義上提升了網路中文件的安全性。

觀察IPFS的Core層源碼可以了解到：DAG 解析器這部分，還專門適配了四種常見數據格式，分別有：

• Json：這個不解釋了，最流行的數據傳輸交換格式

• Raw：無損圖像.

• Cbor：簡明二進位對象數據格式，具有一定的壓縮特性。

• Protobuf：Google的數據傳輸交換格式，在安卓客戶端中常用

當然IPFS的加密層還有很多其他的設計，可能我還沒研究到，如果大家有新發現，可以隨時聯繫我，一起探討。

接下來，給大家講一下今天的第二個主角：重加密技術（Re-Encryption）起源於雲計算時代對HTTP網路數據的安全性需求激增（大量用戶參與，不可避免出現了隱私問題），因此而誕生。即：在原有的常用加密手段上對用戶的隱私實現明文保密、公鑰保密、防非法公鑰替換、防合法公鑰替換、別名無關性等。譬如：用戶的實時位置數據通過手機定位存儲在手機客戶端中，我們將在客戶端中根據用戶ID或者Cuid生成私鑰，自動加密定位數據再存儲在IPFS上，由於數據採用的是我的密鑰進行的再加密，除非我授權（即：將密鑰共享），哪怕IPFS的哈希指紋暴露，任何第三方都無法訪問我的數據內容。特別適合如內容授權分發這樣的場景。

那麼，為何需要對IPFS網路進行重加密技術的使用？

這裡有三個值得思考的地方：

滿足特異性：協議實驗室雖然已經考慮到了很多細節，並為此進行了最初的Crypto層設計，但這是局部的抽象方案，沒法滿足特例。

滿足敏感性：用戶數據隱私一直是存儲界的熱議話題和痛點，也是政策最關心的邊界。

滿足適用性：IPFS技術是為多種生態技術服務的，存在繁多的業務（eg：數據分享）和技術場景，類型不一樣，需要搭配不同的Re-Encryption技術方案。

就像大家熟知的：沒有最好的技術，只有最適合的技術。

最後分享幾種對於IPFS網路的Re-encryption思路：

1）需要隱藏 哈希指紋 的業務場景：

舉個例子：一些需要付費或者設置許可權才能暴露文件Hash指紋的場景：優惠券刮獎信息，VIP數據，遊戲點卡激活碼等。猶記得我在百度地圖做商場新零售業務的時候，有一次運營活動就是通過實體卡刮開，來標記用戶使用了我們導流過去的優惠券，從而和商場進行核銷和結算。我很理解產品當時比較很體諒我們這些程序員的，通過實體卡刮開這個操作，省了我們不少事，但是個人覺得還是這個處理方式不太優雅。如果放到這裡，我會有新的設計思路：將優惠券業務邏輯放在IPFS網路生成Hash指紋之前，即根據業務信息，許可權狀態變更後，才發生觸發在IPFS網路中添加文件，生成Hash指紋的響應，做到」事先隱藏」的效果。

2）需要隱藏 File內容 的業務場景：

這類場景往往是：在IPFS公網環境中，暴露Hash指紋，也無法暴露File內容，適合文件授權分享等場景。之前我有這個思考的時候，當時是看了一個網上的一篇宣傳軟文，然後有一個叫Carblock的區塊鏈項目，當時被他們的加密層設計吸引，之後順著這些問題去進行研究，總結成了今天這樣一個分享。這類場景的話就是是大家最關心的一個，我也基於這個場景寫了一個Demo程序，馬上給大家演示一下：

這邊是我新建的一個PHP工程：ipfs-re-encrytion,我將ipfs的基本方法（cat、add、id、pinAdd），都封裝進了ipfs.php工具類，同時又封裝了一個reEncrytion.php加密工具類，構建了基於RSA的非對稱加解密方案和基於base64的對稱加解密方法，方便一會使用的對比測試。

接下來，我來編寫一個測試腳本testBase64.php，並運行邏輯，來進行說明：

我們首先在測試腳本中導入之前封裝的src/ipfs.php,src/reEncrytion.php,創建類實例，定義一段需要加密的明文，即「hello，ipfser，daijiale」，作為原始數據，同時，我們立刻對這段原始數據進行base64對稱加密，輸出加密後的數據，之後，我們將加密後的原始數據通過add()方法添加進IPFS網路中（事前開啟本地的IPFS節點），拿到Hash指紋，在瀏覽器中迅速驗證指紋有效性，並輸出在命令行中，之後，通過cat()方法，從IPFS網路中模擬第三方的數據讀取請求，把拿到的數據輸出，顯示為加密後的:「 aGV...Ywxl」的亂碼數據，最後，通過base64解密演算法，拿到明文原始數據，演示效果如下所示，即完成了整個流程的驗證，非對稱的RSA加密過程也是類似。

IPFS-Re-Encrytion的Demo已開源至Github上：https://github.com/daijiale/ipfs-re-encryption，大家可以隨時下載，也歡迎一些建設性的Issue和PR，一起交流和豐富這塊內容。

感謝聆聽，我的分享就到這了。

參考文獻

• 中國IPFS開發者圓桌沙龍：戴嘉樂 IPFS和Re-Encryption技術的結合思考

• 張首晟教授：區塊鏈又讓一個網路去中心化的時代來臨

• 中國IPFS開發者圓桌沙龍：林東吳 基於IPFS的重前端應用

• Proxy Re-Encryption Wikipedia

• Learn to securely share files on the blockchain with IPFS (需要科學上網訪問)

• 區塊鏈不只有去中心化：基於 IPFS 加密的去中心化數據應用落地分析

• 學會通過IPFS在區塊鏈上安全地分享文件

• Textile Photos: your photos, decentralized and encrypted?

• ED25519

轉載聲明：特別鳴謝天一哥（飛向未來 IPFS指南公眾號作者）與ipfser.org早期在IPFS大量的佈道工作，才有了博主致力於IPFS應用實踐的想法，期望更多和我們一樣對這個領域感興趣的朋友能加入進來。

本文研究成果同時收錄在https://github.com/ChainBook/IPFS-For-Chinese中，該倉庫由 本體網路核心工程師劉一痕發起併兼任Maintainer，對現有的一些成熟公鏈技術進行源碼中文解讀工作，遵守Mozilla Public License 2.0開放協議，歡迎感興趣的朋友加入。

已授權轉載的公眾號和媒體網站有：

• 巴比特 IPFS專欄

• ipfser.org

• 公眾號：IPFS方得社區 (IPFS-Fund)

• 公眾號：IPFS指南(ipfs_guide)

• 星鑒網：http://www.ipfsfirst.com/

• 鏈得得-得得號：IPFS指南

• 鏈得得-得得號：楓言楓語（個人號）

推薦閱讀：