【戴嘉樂】（上篇）運用Re-Encryption技術對你的IPFS網絡數據進行多重保護

作者簡介：戴嘉樂( Mr.Maple ) | 前百度高級研發工程師 | IPFS應用實踐者&佈道師|《中國IPFS開發者圓桌沙龍》舉辦人
個人網站：https://www.daijiale.cn
聯繫方式：微信號：daijiale6239

一、研究背景

1.1 從HTTP到HTTPS的變遷來看：

從HTTP逐漸過渡到HTTPS的過程可以看出，網絡中的明文傳輸始終具有不安全感，據我所知，從2015年開始，大部分互聯網巨頭公司都強制要求各產品線切換使用HTTPS（加密超文本傳輸協議），通過SSL/TLS完成雙向加密，加固萬維網上的安全通信，尤其是在交易支付場景下。

1.2 從IPFS網絡的侷限性來看：

IPFS有潛力成爲區塊鏈領域很棒的超級內容分發網絡，本身IPFS也自帶一些加密特性，但如果我們能通過一些有效的技術使得我們項目和業務在入網前（上傳到IPFS網絡前）前就加固一層安全屬性，將大大提高IPFS網絡的可用性和可信任性，讓更多企業和用戶願意投入使用這項技術。

1.3 從行業內安全性角度來看：

行業安全性問題應當是每個開發者都該重視的方面（我們不能只顧着開發區塊鏈業務，而忽視用戶、投資者的安全隱患），隨着區塊鏈市場的不斷擴大，整個生態的區塊鏈項目也日益增多，同時，由於各個公司水平參差不齊，項目方做事的態度褒貶不一，不靠譜的區塊鏈項目和合約漏洞數量也在與日俱增，類似美圖這樣的大公司之前也因爲安全問題吃過大虧。

二、IPFS網絡的Encryption層設計

2.1 具有PKI 特性

玩密碼學的童鞋應該都不會陌生這個，PKI技術：Public Key Infrastructure ，也叫公鑰基礎設施，PKI是一種遵循標準的利用公鑰加密技術爲電子商務的開展提供一套安全基礎平臺的技術和規範。

• HTTP協議中PKI的使用：可參考 HTTPS協議詳解(三)：PKI 體系

• IPFS協議中PKI的使用：Node ID生成，IPNS掛載，私有集羣網絡搭建

2.1.1 PKI特性：Node ID生成

Eg：

difficulty = <integer parameter> n = Node{} do { n.PubKey, n.PrivKey = PKI.genKeyPair() n.NodeId = hash(n.PubKey) p = count_preceding_zero_bits(hash(n.NodeId)) } while (p < difficulty)

這是IPFS白皮書中在初始化生成NodeID（n）時，所執行的一段僞代碼：

我們可以看到，在創建過程中將通過PKI.genKeyPair()(默認用的RSA非對稱加密算法)生成一套公鑰（n.PubKey）和私鑰（n.PrivKey），NodeId 將通過hash(n.PubKey)公鑰進行簽名。

這樣做的好處是當Node 節點在第一次連接對等Peer方時，可以通過互相交換公鑰，來驗證hash(other.PublicKey) = other.NodeId是否成立 ，如果成立，則確定可信身份，保持通信，否則連接終止，防範網絡中的一些嗅探***。（這和我們在做後端微服務之前的接口通信時，常設置變量參數參與的對稱加密簽名來防止網絡***一樣）

在本地，我們可以通過ipfs id隨時來查看我們的公鑰（PublicKey）和其對應的NodeID：

也可以通過vim ~/.ipfs/config 來進行私鑰（PrivKey）的查看：

2.1.2 PKI特性：IPNS掛載

這裏要提一下之前搬山工童鞋小密圈發起的一個提問： 如何在不同節點中更新同一個IPNS Hash的內容？的問題

我們直接使用

ipfs name publish QmSomeHash

是默認掛載一個文件空間到的ipns/nodeID上，因爲這邊默認讀取的公鑰文件是生成NodeID的Self公鑰，但是我們可以通過新生成一份代理公鑰來實現不同節點中同一份IPNS地址的內容更新：

//A節點生成mykey： ipfs key gen --type=rsa --size=2048 mykey //公鑰一般存儲在./ipfs/keystore 中 //拷貝mykey 至B節點同目錄下，更新掛載點，更新內容 ipfs name publish --key=mykey QmSomeHash 

Type可選，默認是RSA，但也支持ed25519：

//From：https://github.com/ipfs/go-ipfs/blob/master/core/commands/keystore.go var sk ci.PrivKey var pk ci.PubKey switch typ { case "rsa": if !sizefound { res.SetError(fmt.Errorf("please specify a key size with --size"), cmdkit.ErrNormal) return } priv, pub, err := ci.GenerateKeyPairWithReader(ci.RSA, size, rand.Reader) if err != nil { res.SetError(err, cmdkit.ErrNormal) return } sk = priv pk = pub case "ed25519": priv, pub, err := ci.GenerateEd25519Key(rand.Reader) if err != nil { res.SetError(err, cmdkit.ErrNormal) return } sk = priv pk = pub default: res.SetError(fmt.Errorf("unrecognized key type: %s", typ), cmdkit.ErrNormal) return } 

2.1.3 PKI特性：私有集羣網絡搭建

通過官方提供的共享密鑰生成工具：https://github.com/Kubuxu/go-ipfs-swarm-key-gen

//From:https://github.com/Kubuxu/go-ipfs-swarm-key-gen/blob/master/ipfs-swarm-key-gen/main.go func main() { key := make([]byte, 32) _, err := rand.Read(key) if err != nil { log.Fatalln("While trying to read random source:", err) } fmt.Println("/key/swarm/psk/1.0.0/") fmt.Println("/base16/") fmt.Print(hex.EncodeToString(key)) } 

生成一份公共的swarm.key，存儲在不同節點的上~/.ipfs/根目錄下，

在我們添加完各個節點的bootstrap地址後，執行ipfs swarm connect操作後，會對公共密鑰swarm.key進行再校驗：

//From：https://github.com/ipfs/go-ipfs/blob/master/core/commands/swarm.go for _, c := range conns { swcon, ok := c.(*swarm.Conn) if ok { ci.Muxer = fmt.Sprintf("%T", swcon.StreamConn().Conn()) } } 

• 具體細節可以參考IPFS指南文章：私有網絡的搭建與使用

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

2.2 文件尋址加密

我們添加的地址+文件名都將通過Multihash模塊加密映射成大家看到的Hash指紋，默認均採用sha2-256

//From：https://github.com/ipfs/go-ipfs/blob/master/core/commands/add.go  Options: []cmdkit.Option{ ... cmdkit.StringOption(hashOptionName, "Hash function to use. Implies CIDv1 if not sha2-256. (experimental)").WithDefault("sha2-256"), }, 

Multihash支持多達10餘種哈希算法，目前只在IPFS本地測試環境下才可配置：

// From: https://github.com/multiformats/go-multihash/blob/master/multihash.go // Names maps the name of a hash to the code var Names = map[string]uint64{ "id":           ID, "sha1":         SHA1, "sha2-256":     SHA2_256, "sha2-512":     SHA2_512, "sha3":         SHA3_512, "sha3-224":     SHA3_224, "sha3-256":     SHA3_256, "sha3-384":     SHA3_384, "sha3-512":     SHA3_512, "dbl-sha2-256": DBL_SHA2_256, "murmur3":      MURMUR3, "keccak-224":   KECCAK_224, "keccak-256":   KECCAK_256, "keccak-384":   KECCAK_384, "keccak-512":   KECCAK_512, "shake-128":    SHAKE_128, "shake-256":    SHAKE_256, }

2.3 DAG分片

這塊應該是IPFS內容尋址的設計精髓，當然，IPFS採用Merkle DAG技術對整個系統帶來的優點有很多，今天這裏我們只討論DAG分片對文件的安全保護屬性：

這是我之前上傳的 自己的頭像數據：Qmdv...：

DAG分片之後：QmVo...,QmYG...，QmdF...，QmXA...，QmSN...

我們拿到的一些分片文件是RAW格式（原始圖像編碼數據編碼）的碎片文件，只獲取其中的幾個碎片數據是無法通過DAG解析器拼合成原圖像的，一定意義上提升了網絡中文件的安全性：

觀察IPFS的Core層源碼可以瞭解到：DAG解析器這部分，專門適配了四種格式：

• json

• raw

• cbor

• protobuf

//From :https://github.com/ipfs/go-ipfs/blob/master/core/coredag/dagtransl.go // DagParser is function used for parsing stream into Node type DagParser func(r io.Reader, mhType uint64, mhLen int) ([]ipld.Node, error) // FormatParsers is used for mapping format descriptors to DagParsers type FormatParsers map[string]DagParser // InputEncParsers is used for mapping input encodings to FormatParsers type InputEncParsers map[string]FormatParsers // DefaultInputEncParsers is InputEncParser that is used everywhere var DefaultInputEncParsers = InputEncParsers{ "json":     defaultJSONParsers, "raw":      defaultRawParsers, "cbor":     defaultCborParsers, "protobuf": defaultProtobufParsers, }

2.4 More

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

三、Re-Encryption技術

Re-Encryption：重加密技術起源於雲計算時代對HTTP網絡數據的安全性需求激增（大量用戶參與，不可避免出現了隱私問題），因此而誕生的再加密技術，即：在原有的常用加密手段上對用戶的隱私實現明文保密、公鑰保密、防非法公鑰替換、防合法公鑰替換、別名無關性（除了你，任何實體都不能夠判斷不同別名是否對應同一個ID）等。

Eg：如果業務方A向業務方C發送一個在代理方B的密鑰下加密的消息，代理B將通過提供密鑰來授權業務方C解密消息內容，以得到明文。譬如：用戶的實時位置數據通過手機定位存儲在手機客戶端中，我們將在客戶端中根據用戶ID或者Cuid生成私鑰，自動加密定位數據再存儲在IPFS上，由於數據採用的是我的密鑰進行的再加密，除非我授權（即：將密鑰共享），哪怕IPFS的哈希指紋暴露，任何第三方都無法訪問我的數據內容。特別適合如內容授權分發這樣的場景。

3.1 常見的加密技術：

3.1.1、對稱加密

有流式、分組兩種，加密和解密都是使用的同一個密鑰。

例如：DES、AES-GCM、ChaCha20-Poly1305等

3.1.2、非對稱加密

加密使用的密鑰和解密使用的密鑰是不相同的，分別稱爲：公鑰、私鑰，公鑰和算法都是公開的，私鑰是保密的。非對稱加密算法性能較低，但是安全性超強，由於其加密特性，非對稱加密算法能加密的數據長度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3.1.3、哈希算法

將任意長度的信息轉換爲較短的固定長度的值，通常其長度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

3.1.4、數字簽名

簽名就是在信息的後面再加上一段內容（信息經過hash後的值），可以證明信息沒有被修改過。hash值一般都會加密後（也就是簽名）再和信息一起發送，以保證這個hash值不被修改。

四、爲何需要對IPFS網絡進行Re-Encryption

4.1 滿足特異性

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

4.2 滿足敏感性

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

4.3 滿足適用性

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

系列篇預告

《【應用】（中篇）運用Re-Encryption技術對你的IPFS網絡數據進行多重保護》

• 幾種對於IPFS網絡的Re-encryption思路

• 需要隱藏 Node ID 的場景：

• 需要隱藏 Hash 指紋的場景：

• 需要隱藏 File 內容的場景

• 需要隱藏 Object 結構的場景

《【應用】（下篇）運用Re-Encryption技術對你的IPFS網絡數據進行多重保護》

• 工程實踐爲主：

• 加密算法綜合比較

• 幾種再加密技術對於IPFS網絡實測性能綜合比較

• 如何配合IPFS官方API使用

• 適合集成進哪些公司業務場景

一些題外話：感謝近期一些朋友的關心和青睞，這裏做一個鄭重的統一聲明：本人2月份從百度離職後，一直處在自由職業的狀態，每天的時間除了少部分在打理自己的OneMix基金，更多的是想靜下心來做一些技術沉澱和知識積累工作，目前沒有加入任何主體公司&機構，沒有直接參與任何商業形式的項目&硬件研發（只爲一些IPFS相關產品&公司提供技術諮詢和顧問支持），很喜歡目前的一種生活狀態，也很喜歡目前所在做的一些開源社區屬性事情（開發者技術氛圍營造，舉辦開發者沙龍，公益技術文章輸出，開源項目分享等），如果後續要切換工作狀態，會第一時間發佈在朋友圈和最新的文章中，可能會和一些前輩成立或加入類似 區塊鏈實驗室，區塊鏈技術研究院這樣的科研組織。

參考文獻

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

  
  

• 中國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

---

---

圓方圓學院博客中文章全部都是圓方圓的講師或者朋友們的文章，全部得到過授權。都是經過圓方圓審覈過的，優秀的文章。

圓方圓學院彙集大批區塊鏈名師，打造精品的區塊鏈技術課程。 
許曉笛老師的51CTO學院視頻專欄 http://edu.51cto.com/lecturer/13766370.html

郭金宏老師的51CTO學院視頻專欄:  http://edu.51cto.com/lecturer/4968230.html