【IPFS】运用Re-Encryption技术对你的IPFS网络数据进行多重保护

大家好，我叫戴嘉乐，很荣幸，然后今天能站在这里跟大家一起分享。首先感慨两句，这个《中国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，一起交流和丰富这块内容。

感谢聆听，我的分享就到这了。

一些题外话：感谢近期一些朋友的关心和青睐，这里做一个郑重的统一声明：本人2月份从百度离职后，一直处在自由职业的状态，每天的时间除了少部分在打理自己的OneMix基金，更多的是想静下心来做一些技术沉淀和知识积累工作，目前没有加入任何主体公司&机构，没有直接参与任何商业形式的项目&硬件研发（只为一些IPFS相关产品&公司提供技术咨询和顾问支持），很喜欢目前的一种生活状态，也很喜欢目前所在做的一些开源社区属性事情（开发者技术氛围营造，举办开发者沙龙，公益技术文章输出，开源项目分享等），如果后续要切换工作状态，会第一时间发布在朋友圈和最新的文章中，可能会和一些前辈成立或加入类似 区块链实验室，区块链技术研究院这样的科研组织。

• 中国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指南
• 链得得-得得号：枫言枫语（个人号）