当前位置:首页 > 区块链新闻 > 正文

INTfs协议--加密、私有和匿名分布式文件共享

来源: 互联网时间:2019-09-19 14:26:40

本文由IPFS原力区收集译制,版权所属原作者

摘要

 

数据传输是物联网的核心功能之一。网络中的决策将依赖于数据来完成。在分布式网络中存储和检索数据的现有协议在其方法上是通用的,在协议隐私控制中没有提供。IPFS是这一领域的领导者,但它专注于分散式互联网。使用文件哈希作为请求键,构建一个who-requests-what可能导致匿名性崩溃的图片。INTfs是一种专门用于分散存储的方法,它在INT和IPFS之间建立了一座桥梁,其中包含了一种协议,用于非交互式非对称加密、盲数据请求以及使用INT链作为事务基础的节点补偿的存储证明。

 介绍

概述和目标

IPFS为分布式数据托管和传输提供了坚实的基础。它可以用作个人云、文件传输协议或分散internet的HTTP后端。它结合了文件的BitTorrent分发和Merkle DAG数据结构,为版本化的文件系统或区块链提供了一个可靠和健壮的基础。它允许您上传任何文件,无论格式如何,并通过其哈希共享或访问它。因为IPFS不需要读取文件的能力,所以用户可以免费上传加密的文件,但没有提供框架或密钥索引系统来实现这一点。

其他项目也尝试使用IPFS作为其底层协议来生成分布式云服务,但是这些网络同样依赖于用户自己的技术能力来获得加密密钥并在上传之前对文件进行加密。为了鼓励这些网络中的存储节点参与,它们引入了自己的专用令牌来收取费用和奖励,要求用户获得该令牌才能使用服务。

INTfs试图通过提供一个框架来解决这些问题,该框架用于索引加密密钥、加密文件和消息,以及在基于活动资产事务的网络INT Chain上存储数据。利用现有的节点网络进行分布式存储,并采用统一的机制保护文件系统、确保同步和分发费用,我们可以提供其他分布式云网络的所有好处,而且成本低廉,不需要辅助令牌。这将创建一个私有的、匿名的分布式文件系统,在现有网络中具有最小的信任。

INT链作为交易基础

INT Chain是一个专注于物联网的DPoS区块链,具有异构多链框架,支持高吞吐量和易于扩展的子链添加。交易结构是基于帐户的,类似于Ethereum,具有有限的脚本编写功能。因为它不是基于UTXO的交易构建的,所以它允许几种交易类型用于标记、投票和注册节点。这就创建了一个开放结构,用于添加交易类型和将信息发布到区块链上的其他机制。DPOS共识机制允许10秒的阻塞时间,在13个“有序”节点的池中旋转,作为验证程序,在当前状态下以2000 tps的速度运行单个链。INT的计划是增加验证节点的数量,以支持添加子链,并定义每个子链的逻辑结构以支持用例(例如,附加事务吞吐量、物联网设备特定事务、智能合约、机密事务等)。

我们假设INT链的当前状态是事务基础,并且它可以接受本文中提出的事务格式以及用于存储与该协议相关联的证明的附加子链。系统节点将承担存储和服务文件的责任。

数据加密

加密数据既可以使用对称密钥,也可以使用非对称密钥。非对称加密方案允许使用公钥加密数据,无需像使用对称加密方案那样事先与接收方通信。非对称加密的问题在于加密/解密所需的计算时间和密钥的大小。对称密钥要小得多,但需要共享密钥。更实用的是使用对称密钥加密和非对称加密的混合系统来共享用于加密的密钥。

 

图1:类似安全的EC和RSA密钥大小的相对大小[Mart10]

 键大小是下一个关注点。密钥越小,数据管理就越容易,硬件需求就越低,传输所需的带宽就越小,移动设备的能耗也就越低。与RSA等其他密码系统相比,椭圆曲线密码技术为相同安全级别的密钥提供了更短的密钥。对于一个128位的安全级别,RSA密钥长度为3072位,而ECC密钥长度为256位,这对于这个应用程序来说已经足够强大了。

椭圆曲线综合加密方案(ECIES)

ECIES是Victor Shoup在2001年提出的一种混合加密系统[Shoup01]。它结合了密钥封装机制(KEM)和数据封装机制(DEM),以椭圆曲线密钥生成的效率提供对称加密的速度和非对称加密的安全性。

它使用以下功能:

  • 密钥协议(KA):双方用来创建共享密钥的函数。
  • 键派生函数(KDF):用于创建非对称键对的函数。
  • 哈希(Hash):消化功能。
  • 对称加密(ENC):使用一个密钥进行加密和解密的加密
  • 消息验证码(MAC):用于验证消息的信息。
由于公钥-私钥对将提前生成并发布,因此这个过程完全可以由发送方完成,而不需要它们之间进行任何通信。

使用这个协议,加密和通信一条消息m:

图2:ECIES加密过程[Mart10]

  • 我们首先生成一个名为ephemeralkey的新公私密钥对,表示为私有部分uand公钥U = u•G。
  • 使用密钥协议,我们通过获取临时私钥并将其乘以接收方的公钥V来创建共享密钥。
  • 将共享密钥u•V作为KDF的输入数据,输出是MAC密钥k_mac和加密密钥k_ENC的连接。
  • 加密消息m,使用对称加密算法ENC与密钥k_ENC。结果是密文c。
  • 使用带有密文c和MAC密钥k_mac的MAC函数生成atag。
  • 连接临时公钥、标记和密文(U||标记||c),并将此密码发送给接收方。
接收方解密消息m:

图3:ECIES解密过程[Mart10]

  • 将密码分为其组成部分U、标记和c。
  • 使用检索到的临时公钥U和接收方私钥v检索共享密钥U: v•U=(v•U)•G= U•v
  • 在与上面步骤3相同的过程中,使用KDF生成加密密钥和MAC密钥k_ENC '和k_mac '。
  • 使用MAC函数和密码(c)中的密文以及MAC密钥(k_mac ')来生成标记。如果tag '不等于tag,则产生MAC验证失败。如果相同的情况下,继续。
  • 使用密钥k_ENC的对称加密算法ENC解密密文c。结果是预期的消息m。

标准

研究发现,以下标准产生了计算速度最快的强加密[Mart15]。

对于密钥协议中用于短暂密钥生成的椭圆曲线操作,将使用二进制扩展有限域GF(2 m) 上的椭圆曲线X[CPPCBench]。这对硬件实现是有益的,因为它的加法和乘法等操作可以通过AND和XOR逻辑门完成。

  • 关键协议(KA): Diffie-Hellman (DH)比其他方法更有优势,因为它只需要一个标量乘法。
  • 关键派生函数(KDF): KDF2作为标准函数被广泛使用和接受。
  • 算法:为了最大限度地提高安全性和最小化内存和带宽使用,我们将输入SHA-256。
  • 对称加密函数(ENC):为了最大化安全性和效率,我们使用AES-128 CTR,它不需要填充,因此更有效。填充的缺乏也会降低解密负载。
  • 消息验证码(MAC):为了最大限度地提高安全性,减少内存和带宽的使用,我们将使用HMAC-SHA-256。
 

INTfs-事务协议

INTfs将作为一个抽象层运行,将INT链和IPFS捆绑在一起。该协议的目的不是改变IPFS的工作方式,而是提供一个与IPFS交互的框架,该框架为数据的存储和检索提供支付机制,使数据加密更加容易,并且完全保密,匿名,以便在各方之间接收数据。它允许您加密您的数据,而不需要知道预期的接收者,支付检索数据的费用,而不必透露您正在请求的内容,下载文件而不透露您正在下载的内容,以一种不会向文件上的旁观者泄露任何信息的方式。wnLoaded或谁请求了该文件。

基本结构如下:

注册加密密钥

 

图4:寄存器加密密钥处理流程

  • 两个用户创建INT链公钥,下载密钥库并将INT传递给他们。
  • 然后,用户创建INTfs加密密钥,下载密钥存储库并创建一个寄存器事务,将密钥的公共部分发布到区块链,实际上,将其绑定到他们的INT地址。

上传和发送文件

图5:加密、上传、发送文件处理流程

  • 用户A希望向用户B发送一个文件。用户A输入用户B的INT地址,并要求用户A选择该文件。然后询问他们希望INT网络存储文件多长时间,以及他们希望包含在密文中的任何注释。
  • 钱包向网络查询用户B的加密公钥,使用上面指定的ECIES协议和用户B的加密公钥加密所选文件。然后,它在本地存储加密文件,由IPFS校验和散列命名。
  • 然后,钱包使用用户B的加密公钥(包含文件散列、文件大小和注释)对消息进行加密。然后它获取文件的大小以及用户A希望存储文件的时间,并确定费用。然后,它使用用户B的地址、密码(包含文件哈希)、丢弃高度、费用和签名准备上载事务。
  • 一旦网络验证了该事务,钱包就开始将加密文件上载到IPFS中。

请求一个文件

图6:请求文件处理流程

  • 用户B接收一个包含密码c的事务,然后ECIES使用用户B的私钥解密该密码,以显示文件散列、大小和注意事项。
  • 用户B希望下载该文件。他们使用文件哈希创建一个请求事务,并记录希望下载它的次数。
  • 然后,用户B的钱包生成一个随机的nonce nand哈希(n || 文件散列)。哈希(n || 文件哈希)是请求键。然后,它在文件库中本地存储n、文件哈希和请求键之间的关系。
  • 然后,用户b的钱包获取其公开加密密钥v=v•g,然后使用该公开加密密钥(即[erta07]中规定的1/N阈值密钥)创建共享密钥,t=d•g,例如s=v•t=v•g=d•q
  • 然后,用户B的钱包使用共享密钥S对消息M进行加密,其中包含nonce n、下载次数x和使用ECIES协议请求的文件哈希(ECIES协议由验证节点解密)。
  • 然后用户B的钱包使用文件大小和x来确定下载费用。
  • 用户B的钱包使用密码(包含n、x和请求的文件散列)、费用和签名准备请求事务。
  • 一旦被验证节点接收到,它们使用验证节点私钥解密c,以检索文件哈希、nonce和nonce的有效次数。此信息存储在连接nonce到文件散列的共享数据库中。
  • 一旦验证了该事务,请求键现在就可以用于下载了。

下载一个文件

图7:下载文件处理流程

  • 要执行下载,用户从文件库中选择file。然后,钱包将请求密钥发送到节点。
  • 节点查询区块链以查看reqkey是否已被“使用”。如果没有,节点将发布一个只包含ReqKey的“spend”事务。
  • 然后节点查询散列键数据库以返回文件散列并将其发送给IPFS以启动下载。

费用计算

我还没能想出一个能满足所有要求的东西。它需要考虑文件大小和文件上传的存储时间,以及用于检索的文件大小和下载次数。它应该足够便宜,以鼓励使用,因为这是网络的附加组件,但不要太便宜,因为它只是一个额外的成本,对节点没有真正的回报。由于验证池中的存储节点数量有限,因此应该确定最佳的网络总存储大小,这也将推动神权节点的最小需求。这些费用应该在最小程度上抵消这些成本。

VPS的存储成本约为每月每GB 0.10美元。因此,每个月的费用至少应该达到每GB 1.30美元(每天0.043美元),当前的神权池是13个节点。

需要做进一步的工作来定义最小的存储时间,但是可以被10秒(按主链块)整除。最大值可以是不确定的存储,但需要定义费用逻辑。

共识和奖励

 

存储证据来(PoSt)

由于从理论上讲,主链上的块生成比存储数据库的任何更改都要快得多,因此检查整个网络对存储状态的一致意见,或者为每个主链块支付文件存储费用,都没有多大意义。更有意义的是,按照分钟的顺序定义一个状态检查历元,并将该一致检查作为一个块存储在二级链上,该二级链可用于支付费用授权和独立验证。

该存储证据来是一个两步的过程的第一步是修剪的IPFS数据库和第二步的随机抽样Merkle Tree根哈希创建一个独特的哈希Proof-of-Work风格相结合计算,将作为证据的存储。

状态机的第一部分将专门用于存储周转。在每个块创建过程的开始,节点将检查文件存储持续时间数据库,如果任何文件显示当前块(或小于)为丢弃高度,节点将删除该文件的链接。

状态机的第二部分将专门用来证明每个节点在一段时间内都在存储文件。由于这是一个更大事务网络的附加协议,为了安全起见,一致性证明算法不需要完全完成。节点需要随机测试,这样就很难伪造有效的结果。没有更完整的存储检查所带来的风险不会影响主链上的资产转移,只会影响存储奖励的分配。因此,困难在于,造假的成本要高于回报的价值。

过程如下,在本例中,我们假设主链上的最优PoSt block时间为10分钟或60个block:

图8:INTfs存储验证逻辑流程

  • 一旦在主链上创建了触发器块,所有节点都会检查需要在(discardHeight≤currentHeight)丢弃的文件。
  • 一旦该过程完成,就从主链块哈希中确定地派生出一组挑战顶点。查询本地IPFS DAG,找到所有挑战点的对应根,返回根。
  • 以四个根和一个nonce开始PoW谜题。难度应使节点的平均响应时间与求解时间保持在1分钟左右。
  • 如果节点是当前块生成器,则将完整的解决方案作为建议发送给所有节点以验证工作。
  • 如果节点不是当前块生成器,则向生成块的节点发送完整的解决方案以验证工作。
  • 一旦所有节点验证了块生成器的工作,对消息进行签名并发送给块生成器。
  • 块生成器验证所有提案,通过将给定的nonce与计算出的挑战点哈希,独立检查所有节点的工作。注意有效或无效状态。
  • 收到所有签名后,创建一个包含提议者证明、质询根和所有节点证明的块。结果是一个带有给定挑战点的证明块,链接到创建它们的块哈希,任何人都可以独立检查它,并给出一个应该获得存储奖励的所有节点的列表。
此过程将遵循通过验证器进行的现有DPoS圆桌迭代。

通过不将独立派生的根包含到建议中的其他节点,可以确保(在此测试的范围内)识别出那些具有不完整DAG的根。当您使用您的点验证它们的给定散列时,散列将不匹配。

通过要求一个难度不可忽略的PoW样式的哈希图,并要求节点的解响应在指定的范围内,使得节点之间串通产生错误证明变得更加困难。

奖励机制

也许有更好的解决办法,但这是我能想到的最好的办法。在主链上的交易中发送的费用将成为一个智能合同,该合同将添加费用和期限,以按块定义奖励日历。它需要时间,除以费用,以确定该费用如何分割成块奖励在给定的时间内。这些信息存储在单独的数据库中。

在创建PoSt块时,主链将对提供有效存储状态证明的所有地址执行coinbase事务,所给出的数量由(按块存储奖励)除以(要奖励的节点总数)决定。

在验证coinbase事务时,包含存储费用池的smart契约将消耗等量的INT,从而保持净零通胀。

影响

创建如上所述的事务结构允许我们断开那些进行上传、请求和下载的人之间的信息链接。通过加密文件,只有指定的收件人才能解密它。通过将加密的文件哈希发送给收件人,没有人可以看到正在发送的是什么文件。通过使用nonce加密请求,没有人可以看到您正在请求的文件。通过使用请求键单独启动下载,下载不能绑定到请求事务,并且与支付源分离。

为了进一步断开连接并加强隐私,客户端钱包可以从不同的地址发出请求,而不是发送文件的地址,并通过任何网关或VPN从任何软件发起下载。

指定nonce的有效次数后,您可以付费下载并分发带有ReqKey的链接。存储费用是根据大小计算的,用户决定的存储时间将阻止大文件和停滞不前的数据库。

要求您必须能够从要下载到的设备发送事务是没有意义的。通过支付下载费用并创建独立于实际下载的请求密钥,它使我们能够从单独的设备使用这些密钥。

将INTfs合并到INT网络之上,我们可以将状态机绑定到网络的一致机制中,而不必使用专用的令牌创建独立的容错机制。这降低了集成的总体成本,使服务在成本上具有竞争力,并简化了it实现。

由于此存储和协商一致协议与主链协商一致协议是分开的,并且吞吐量需求要小得多,因此参与节点可以包含第二组节点,可能是该工作的第二组注册。这将扩大节点的地理范围,增加整个网络的存储和带宽。

INTfs将不要求用户加密存储在网络中的文件,甚至可能托管整个数据目录。

ECIES系统可以更广泛地用于为包括manet在内的轻量级物联网数据应用程序创建非对称加密。

开放的问题

费用计算

必须进一步确定逻辑和适当的定价,以实现节点和用户的期望参与。这是为比我聪明的人工作。

验证节点阈值解密

在本文的检索事务部分忽略了阈值解密。为了以验证池组中的任何一个都可以解密的方式加密消息,需要一个1 / n的阈值密钥。

此密钥要求所有密钥持有者共享秘密,以便创建聚合公钥。但是,验证池不是静态的,因此需要一个系统,在新验证器进入时重新计算和分发组阈值键。

攻击

从理论上讲,完全绕过上传事务,或者通过向软件传递一个有效的交易作为支付凭证,而不是上传文件的付款凭证,就有可能迫使数据进入IPFS,而无需支付存储费用。需要设置安全措施来清除存储数据库中没有丢弃日期的文件。用户将无法检索这些文件没有支付,虽然哈希表将不知道。

为了伪造PoSt的证明,所有人需要做的就是与另一个节点串通,以便及时接收挑战根,以便在允许的时间范围内找到PoW的解决方案。我敢肯定,只要多想想,巧妙地绕过PoW难度,这个问题就能解决,或者至少大大降低可能性。

IP匿名

 

为了使这个协议更加匿名,可以为文件下载实现网关和无关路由,从而进一步将下载程序与网络内存分离。

当事务通过网络传递时,关于事务来自谁或从哪里来的信息可能会被最先在网络节点中看到这些事务的位置泄露出去。这可以通过简单地监视来自该地址的事务以及最先接收它们的节点来确定谁拥有什么地址。蒲公英++是一个协议,提供了正式保证匿名在同行之间的闲话。实现Dandelion++将完成此协议,使其成为完全无信息泄漏的文件检索协议。

信任

目标是尽可能多地分解事务图。因此,为了让网络为您提供所需的文件,您需要某种方式来通信该文件是什么以及您希望将其发送到何处。这似乎是最小的公分母。在这个框架中,我们通过加密每个步骤和分解事务链接来限制攻击向量,但是神权节点仍然保留一些信息。他们知道什么地址发布了什么文件,什么地址付费接收它,以及一些关于谁声称拥有它的有限信息。

我们可以通过在定义的周期内重新生成阈值键来进一步最小化这个值。当新的验证器进入池时将需要这样做,但是如果定期这样做,将使以前的加密请求事务不再解密,因此无法链接到特定的请求密钥。所有要存储的都是一个nonce(随机数)到文件哈希关系。

笔记和引用

ECIES一般流程基于V. Gayoso Martinez、L. Hernandez Encinas和C. Sanchez Avila的工作,他们的工作发表在《椭圆曲线集成加密方案概览》[Mart10]中。

[Shoup01] https://www.shoup.net/papers/iso-2_1.pdf

[Mart10] http://digital.csic.es/bitstream/10261/32671/1/v2 - i2 - p7 - 13. - pdf

[Mart15]https://www.researchgate.net/publication/277941706_Security_and_Practical_Considerations_When_Implementing_the_Elliptic_Curve_Integrated_Encryption_Scheme # pf28

[Chen17]https://pdfs.semanticscholar.org/a00d/79d4d9fac939469be3a04d34d6ec5b92bcdf.pdf

[CPPbench] https://www.cryptopp.com/benchmarks.html

[Erta07]https://pdfs.semanticscholar.org/fca5/8019046317d03328eb38b61ad5dcbf83c6f6.pdf

-全文完-

本文由IPFS原力区编译,原文链接:

https://medium.com/@grayblock/intfs-protocol-for-encrypted-private-and-anonymous-distributed-file-sharing-in-the-int-network-7dc8e34ac287

免责声明:

1.本文内容综合整理自互联网,观点仅代表作者本人,不代表本站立场。

2.资讯内容不构成投资建议,投资者应独立决策并自行承担风险。