分散式公钥基础设施

翻译自《Decentralized Public Key Infrastructure – A White Paper from Rebooting the Web of Trust》

摘要

今天的互联网把在线身份的控制权交给第三方。电子邮件地址、用户名和网站域名是通过DNS、X.509和社交网络借用或“租借”的。这导致了整个互联网范围内严峻的可用性和安全性问题。本文描述了一种可能的替代方法,称为分散式公钥基础设施(DPKI),它将在线身份的控制权返还给他们所属的实体。通过这样做,DPKI解决了许多困扰传统公共密钥基础设施(PKI)的可用性和安全性问题。DPKI在PKI生命周期的每个阶段都有优势。它使得在线身份无许可bootstrapping(自举:程序语言编译器用自身的语言及其特性来编译自己)成为可能,并提供了更简单的更强大的放法创建SSL证书。在使用中,它可以帮助“Johnny”最终加密,这要归功于公钥管理的降级,以确保分散的数据存储。最后,它还包括恢复丢失或损坏的标识符的机制。

  • 简介——为什么是DPKI

互联网促进了全球个人之间的通信和交易,是通过诸如电子邮件地址、域名和用户名等标识符进行的。但谁来控制这些标识符?如何管理?他们之间的安全通信是如何促进的?

现代社会,第三方机构(如DNS注册服务机构,ICANN,X.509证书颁发机构(CA)和社交媒体公司)负责创建和管理在线标识符以及它们之间的安全通信。不幸的是,这种设计显示出严重的可用性和安全缺陷。

1.1在线标识符的控制和管理

在设计DNS和X.509 PKIX时,互联网无法以可靠、分散的方式就注册管理机构(或数据库)的状态达成一致。因此这些系统指定可信第三方来管理标识符和公钥。现在几乎所有的互联网软件都依赖这些可信第三方。因此,网站域名并不属于注册它们的组织(注意:它们属于第三方,如ICANN,域名注册机构,证书颁发机构以及任何能够影响、强制或入侵它们的任何人)。同样,网站上的用户名并不属于这些用户。

这些可信第三方(有时缩写为TTP)作为可破坏的CPoF,每个都可能有损害整个互联网的完整性和安全性。 因为这些标识符的控制权是给予TTP的,所以其可用性也受到损害。这些与可靠性和可用性有关的问题会导致其他问题:

  • 一些公司花费大量资源来对付由不当行为造成的安全漏洞;
  • 许多网站仍然不支持HTTPS;
  • 对于大多数网民来说,真正安全和用户友好的交流仍然遥不可及。 [参考:“为什么约翰尼不能加密”

出于所有这些原因,DPKI的基本原则是身份属于他们所代表的实体。这就要求设计一个分散的基础设施,其中每个身份不是由可信第三方控制,而是由其所有者控制。

1.2在线交互的安全性

在线交互通过安全传递公钥得到保护。这些密钥对应于身份。这些身份所代表的实体(称为委托人)使用相应的私钥来解密发送给它们的消息,并且证明他们发送了消息(通过用私钥对其进行签名)。

PKI系统负责公钥的安全传送。但是,常用的X.509 PKI、PKIX破坏了这些密钥的创建和安全传递。

1.2.1第三方面临的挑战:寻找“正确的密钥”

在X.509 PKIX中,通过创建由CA签署的密钥来保护Web服务。然而,在PKIX中生成和管理密钥和证书的复杂性使得网络托管公司自己管理这些密钥的创建和签署,而不是将其留给客户。这从一开始就产生了主要的安全问题,因为它导致私钥在CpoF(网络托管公司)的积累,使得有权访问该密钥存储库的任何人都可能以几乎无法察觉的方式危害与这些网站的连接的安全性。

X.509 PKIX的设计还允许世界各地约1200个CA模拟任何网站。CA的强制或妥协的风险使情况进一步复杂化。由于这些危险,用户不能确定他们的通信没有被允许进行MITM(中间人攻击)的欺诈证书所破坏。 这些攻击非常难以发现; 像谷歌这样的产生网页浏览器的公司有时可以识别他们自己网站上的攻击,但是它们不能阻止对任意网站的攻击。

解决方法已经被提出。HPKP是一种IETF标准它允许网站告诉访问者在一段时间内“扣住”他们收到的公钥(忽略任何其他密钥)。但是这种机制对于网站管理员来说很难使用,因此在实践中可能不会使用太多。HPKP容易受到“敌意锁定”的影响,并且在合法的情况下,如果密钥需要被合法替换,则存在破坏网站的风险。更糟糕的是,HPKP的某些实现使第三方在没有用户同意的情况下覆盖任意指针的做法变得轻而易举。

1.3 PKI的可用性

即使可以信任权威第三方,目前的PKI系统也存在重大的可用性问题。 Brigham Young大学的一个小组调查了Mailvelope的可用性,Mailvelope是一种浏览器扩展,支持通过Gmail等第三方网站进行GPG加密通信。他们的研究表明参与者之间的安全通信尝试的失败率高达90%。研究发现,公钥管理是用户无法正确使用软件的主要原因。

TextSecure / Signal – 由爱德华斯诺登认可的安全和信息易用性的安全邮件系统 —由于无法顺利处理公钥更改而导致可用性问题。如果用户删除并重新安装应用程序他们的朋友将被警告其公钥“指纹”已更改。这种情况与MITM攻击无法区分,很少有用户能够理解或费力去验证他们收到了正确的公钥。

1.3.1消息妥协的危险

 

由于传统PKI的可用性挑战,今天大多数网络交流都是未签名和未加密的。这在主要的社交网络上尤其明显。由于PKI的复杂性,社交网络不会以任何方式加密用户的通信,除非通过HTTPS发送它们来依赖PKIX。由于邮件未经过签名,因此无法确定用户是否真正说出他们所说的内容,或显示的文本是否是数据库泄密的结果。同样,用户通信的存储方式使任何有权访问这些数据库的人都可以阅读 – 危害用户隐私并给社交网络带来巨大责任风险。

  • DPKI解决网络信任问题

答案不是放弃PKI,而是寻找替代方案:DPKI,未来的分散式公钥基础设施标准。

DPKI的目标是确保与PKIX不同,任何单一的第三方都不可能危及整个系统的完整性和安全性。通过技术使信任分散化,使地理和政治上不同的实体可以就共享数据库的状态达成共识。DPKI主要关注分散的key-value数据存储,称为区块链,但它完全能够支持其他提供类似或具有更安全属性的技术。

被称为矿工(或验证节点)的第三方依然存在,但它们的作用仅限于确保区块链(或分歩式账本)的安全性和完整性。这些矿工通过遵循议一致性协议得到财政激励。偏离协议会导致经济惩罚,而与协议的一致性通常会产生经济回报。由中本聪创造的比特币是第一个这样成功的协议。它基于工作证明,其中“矿工”的能量消耗用于保护数据库。

通过在区块链中注册标识符,可以像任何其他类型的交易一样,授予委托人直接控制和拥有像网站域这样的全球可读标识符。在key-value数据存储中(注意:在这种情况下,“key”是指数据库查找字符串,而不是公钥或私钥),委托人使用标识符作为查找密钥。

同时,区块链允许将任意数据(例如公钥)分配给这些标识符,并允许这些值以安全的方式在全局可读,而不易受PKIX中可能出现的MITM攻击的影响。 这是通过将标识符的查找值链接到该标识符的最新和最正确的公钥来完成的。

在该设计中,标识符的控制权返回给委托人。对于任何一个实体来说,破坏整个系统的安全性或者损害不属于它们的标识符都不再是轻而易举的。这就是DPKI如何能够解决困扰DNS和X.509 PKIX的安全性和可用性问题。

区块链及其共识协议的完整描述超出了本文的范围。第5节“标识符和公钥的安全性”讨论了它们的一些安全属性,附录“轻客户端详细信息”描述了这些区块链中的数据如何从移动设备安全地访问,而这些移动设备本身并没有完整的区块链副本。

  • DPKI威胁模型

与传统的PKI系统一样,DPKI假定一个持续的活跃对手Mal经常试图欺骗一个委托人Alice信任另一个委托人Bob的错误密钥。这可以采取发现Bob的错误标识符(例如,在twitter.com上找到错误的帐户)或一旦知道标识符就缓存错误的密钥的形式。

假设Mal是一个计算有限的对手,他能够妥协或迫使集中的可信PKI方欺骗Alice信任错误的密钥。这已经被证明是可行的,就像DigiNotar的情况一样,并且在国家行为者迫使其辖区的CA签署无效密钥的情况下也是如此。另外,假设Mal能够改变或阻止Alice和Bob之间交换的消息的约束分数(小于100%)。 这在今天也是可行的,并且通过ISP级审查,通过请求重新定向以及为了破坏像BitTorrent这样的现有文件共享技术而执行的分组修复攻击,从已知的Tor出口节点发送黑洞数据包, 并阻止对政治敏感资料的HTTP访问。

鉴于Mal的权力,DPKI的两个设计原则变得明显:

  • 如前所述,每个委托人必须完全控制其当前的标识符/公钥绑定。如果只有委托人可以修改他们的标识符,那么Mal就不得不攻击每个委托人。这与传统的PKI相反,Mal只需要危害一个CA来欺骗许多委托人。
  • 该系统必须完成全有或全无的任何进展:每个主体必须见证其他主体对其标识符/公钥绑定的更新,否则无人会观察到任何更新。这是必要的,以防止Mal可能发生的网络级攻击,如果她检查某些主体的更新,则通知整个网络她的存在。这使得针对特定用户或密钥对的针对性攻击极其昂贵,因为它使Mal攻击任何人的唯一方式是立即攻击所有人。

如前所述,DPKI通过使用安全的分散式key-value数据存储库来实现这些设计原则,以承载标识符和公钥之间的绑定。有关详细信息,请参阅第5节“标识符和公钥的安全性”。

  • 注册和标识符

如前几节所述,DPKI的核心是分散式key-value数据存储区,可用作标识符注册表,允许委托人的公钥与其标识符安全关联。只要这种注册在有效状态,并且委托人能够保持对其私钥的控制权,则任何第三方都不能对该标识符拥有所有权,而不诉诸直接胁迫委托人。

DPKI没有指定应该使用哪种类型的标识符,并且认识到可能有不同的方法(例如,用户名或UUID),这些方法在易用性、持久性、唯一性、安全性和其他属性方面可能不同。

对于DPKI使用key-value存储,必须具有以下属性:

  • 无权写入。任何委托人都可以广播符合语法规则的消息。系统中的其他同等权限的人不需要准入控制。这意味着分散的共识机制。
  • 叉选规则。给定两个更新历史,任何委托人都可以通过检查确定哪一个是最“安全”的。

这些需求可以通过区块链来满足,例如Namecoin,Ethereum,甚至可能是比特币(通过Blockstore等技术)。

4.1 DPKI注册要求

在DPKI中标识符注册与DNS不同。虽然注册商可能存在于DPKI中,但他们必须遵守DPKI的目标中出现的几项要求,以确保身份属于他们所代表的实体:

  • 私钥必须以分散的方式生成,以确保其在委托人的控制之下(例如,通过委托人的设备上的开源客户端软件)。这意味着明确禁止代表委托人在服务器上生成密钥对的注册服务。否则将重新创建§1“简介 – 为什么DPKI”中提到的问题。
  • 软件必须确保委托人始终控制其标识符和相应的密钥。委托人可以将其标识符的控制权扩展到第三方例如,为了恢复目的),但这必须始终是需要明确的、知情的决定,而不是软件的默认,隐含或误导行为。永远不要以不安全的方式存储或传输私钥。
  • 软件必须尽最大可能确保没有任何机制能够允许单一实体在未经其同意的情况下剥夺委托人的标识符。这意味着:
    • 一旦在区块链内创建了一个名称空间(例如,通过以太坊的智能合约),它就不会被销毁。同样,命名空间不能包含黑名单机制,这将允许任何人使不属于它们的标识符失效。
    • 注册和更新标识符的规则必须是透明的,并且必须以一种简单的、难以忽略或误解的方式(例如先到先得、拍卖)表达给用户。特别是,如果注册受制于到期政策,则必须明确告知委托人,这可能导致委托人失去对标识符的控制权。
    • 一旦完成设置,命名空间规则就不能改变以引入任何新的更新或恢复标识符的限制,否则将有可能在未经其同意的情况下标识符脱离委托人控制。同样,用于更新或更新标识符的客户端软件也不能被修改以引入用于更新或恢复标识符的新限制。
    • 默认情况下,用于管理标识符的软件必须确保用于创建、更新、恢复或删除标识符的所有网络通信都是通过分散的对等机制发送的。 这也是为了确保单个实体(如注册服务商)不能阻止标识符被更新或恢复。

我们推荐DPKI基础设施也努力确保:

  • 至少有一类标识符在正确注册后不会过期。
  • 至少有一类中立注册政策可供所有公众以及希望提供注册服务的任何服务提供商使用。

4.2 DPKI注册机制

注册标识符可能有两种类型的密钥与它们相关联:密钥对用于注册和更新与标识符相关联的数据以及与标识符(子密钥)关联的公钥。

建议委托人使用子密钥对消息进行签名。它们可以直接或间接存储在数据存储中:

  • 直接存储意味着公钥本身直接存储在DPKI数据存储中。对于大多数区块链来说不太可能的,因为一些密钥非常大,大多数区块链不可能存储或非常昂贵。
  • 间接存储意味着指针(例如,URI)与公钥指纹一起存储(或其本身包含)。
  • 标识符和公钥的安全

在DPKI中,标识符通常是查找密钥,映射到只能由具有相应私钥的实体(或多个实体)修改的值。在这样的系统中,可能发生的最坏情况是:

  • 发送查找键的过期值响应查找。
  • 标识符的所有者由于审查而无法更新其值,并且一旦标识符到期,他们就会失去所有权。

这些问题可以通过使用轻客户端(稍后讨论)和审查规避工具来解决。

虽然可能性极低,但也有可能为标识符发送错误的值。例如,如果由工作证明保护的区块链拥有能够压倒诚实节点并在注册点之外扭转历史的对手,则可能发生这种情况。但是系统的所有参与者都能够检测到这种攻击,因为这会导致一个非常长的链的孤立。

这类问题很可能是由于区块链的集中化引起的,是更大的安全问题。

5.1 防止集中化

权力下放的程度对系统的安全起着重要作用。中心化系统容易受到操纵、审查和妥协。它们代表了用户必须信任的SPoF。当中心化系统停机时,所有用户都失效。

虽然区块链可能从分散开始,但不一定会以这种方式结束。这意味着需要一个简单的衡量标准,告诉我们“分散式数据存储”是否仍然是分散的:

你必须敲多少门才能与系统的用户达成妥协?

我们可以粗略定义衡量大多数区块链分散度量的指标,方法是对以下实体进行计数(当整个系统时中心化的,每个实体作为SPoF):

  • “开发者” – 控制区块链行为(源代码)的参与方数量。
  • “节点” – 区块链副本的数量,以完整节点的数衡量。
  • “验证者” – 区块链采矿者/验证者的人数,他们负责创建新块和授权交易。

由于任何一个组织的妥协导致系统的妥协,我们将区块链的分散化定义为:

Decentralization(Blockchain) = MIN(“Devs”, “Nodes”, “Validators”)

更通俗的说,用户可以通过它提供的服务质量(QoS)来推断数据存储的分散。例如,如果用户注意到他们突然无法更新他们的标识符,这可能表明由于集中化而导致的审查。

5.1.1防止中心化的数据存储不可知协议

如果DPKI将特定区块链指定为其“事实上分散的数据存储区”,那么它将会在该区块链上施加集中化压力。更糟糕的是,如果区块链由于对链条缺乏兴趣而被放弃,那么使用事实上的数据存储可能会破坏DPKI。对特定区块链进行编码支持的软件开发人员将不得不花费大量精力重写该软件以迁移到不同的区块链。 同时,可能存在严重的安全问题或QoS问题。

因此,使用不可知协议访问分散数据库是确保整个DPKI运作和下放的基本要求。如果不同的数据存储更好地满足他们的需求,则不可知协议使用户和开发人员能够更轻松地进行迁移。这种可能性的存在创造了一个分散的数据存储市场,相互竞争以满足用户的需求。

5.2 安全访问区块链数据

大多数终端设备由于所需的资源而无法运行完整节点,那么客户如何安全地访问该区块链?

一种解决方案是做一个区块链版本的集合,其中一组“区块链公证人”告诉用户区块链维护的特定对象的状态,并且客户端软件检查一组可信的公证人之间的一致性协议。这条路线可以说是区块链技术的主要目的:消除对可信中介的需求。

幸运的是,还有另一个技术解决方案:轻客户端协议。轻客户端下载较小的区块链部分,足以提供比受信任中介提供的更强的安全保证,而且足够小,可供任何现代设备使用。 附录“轻客户端详细信息”中讨论了轻客户端协议如何工作的详细示例。

对于没有轻客户端的区块链,缺省值应该是基于可信节点的随机抽样的类似于Convergence的一致共识。这些节点都应该看到相同的链,所以如果其中一个节点不同意,则表明有什么不对劲并且应该报告事件。

一般来说,建议采用模块化设计,其中设备可以任意与区块链对话并使用该链可用的最安全的技术。可能没有单一技术提供最大的安全性,在这种情况下,最少数量的技术被结合起来以提供设备维持的最高级别的安全性。

5.3防止审查

最后,DPKI的安全必须解决审查问题:数据存储是否可供最终用户访问。 如果ISP正在审查它,区块链就没用了。

审查制度规避技术,如网状网络,代理和洋葱路由,可以用来绕过区块链网络的审查。

一个独立但相关的问题是对区块链引用的数据进行审查,比如当一个哈希值存储在标识符的值中,而由该哈希值表示的数据存储在别处。在这种情况下,除了在各种不同的存储机制上查找散列之外,还可以使用相同的技术(例如,洋葱路由,代理)[参见IPFS,Blockstore]。

  • 恢复丢失的标识符私钥管理

标识符的强大可靠可以使这些标识符非常有价值。标识符可以用来认证用户到他们房子的门,他们的车等。这些标识符开始代表“王国的钥匙”。 如果这些标识符丢失或受损,那将是灾难性的。 因此,解决这个问题对DPKI的成功至关重要。
6.1两种形式的丢失

由于其重要性,必须通过建立在DPKI之上的任何身份系统来最小化对主密钥的使用。事实上这是身份系统已经采用的方法,如Blockchain ID。不使用主密钥对消息进行签名,而是为每个使用该标识符的新服务创建子密钥。

这意味着有两种类型的密钥可能会丢失或泄露:

  • 主私钥,用于控制与标识符关联的数据。丢失此密钥可能意味着失去对您的在线身份的控制权。
  • 子密钥,它们被链接到标识符并被存储为标识符数据的一部分。

主密钥和子密钥的安全性和恢复属性稍有不同。以下是两种可能性的概述; 对这个话题的全面处理超出了本文的范围,留待未来进行。

6.2 恢复主密钥

将主密钥控制为标识符的人是标识符的主人。

有多种机制可用于在分散系统中恢复主密钥。

6.2.1重组主密钥碎片

通过将主密钥碎片分发给可信实体,委托人可以防止主密钥丢失。 Shamir Secret Sharing和Threshold Signatures是两种可用于生成和重组这些碎片的技术。

如果发生丢失,委托人将向M个实体索要N个主密钥的碎片。N是恢复所需的不同碎片的数量。在收到N个碎片后,主密钥将被成功恢复。

然而,这种技术在主密钥泄露的情况下对保护委托人没有多大作用。

6.2.2防止妥协

妥协的危险来自单一实体拥有任何时间点的主密钥。我们可以通过确保任何单一实体在任何时间点都不拥有主密钥来解决此问题。

例如,我们可以设想一个系统,在注册后,用户选择他们信任的五个实体来保护他们的身份。这些实体可以由可信任的人、组织或甚至设备来代表。虽然他们像权威一样行事,但他们从不强迫任何人,而且总是由委托人自己挑选。

然后主密钥短暂生成,分解成碎片,发送到这些实体,并立即销毁。可以使用阈值签名方案来代替Shamir Secret Sharing,以便主密钥不需要在任何给定设备上完全重新组合。

6.2.3使用智能合约

一些区块链(如以太坊)支持任意计算。在这种情况下,委托人可以建立与其偏执狂水平成正比的恢复机制。

作为一个简单的例子,像Google这样的公司可以通过使用智能合约来更新其价值的名称空间来保护他们对区块链域的控制。智能合约只能在接收到由10个实体中的6个签名的消息时才能够编码,或者遵循任何其他任意逻辑。

6.3恢复和/或撤销子密钥

子密钥泄露或丢失不如主密钥泄露或丢失更严重,因为验证通常使用当前标识符的子密钥集来完成。如果子密钥丢失或被破坏,主密钥可以简单地用于在区块链中安全地生成和替换旧的子密钥。但根据它们的使用方式,旧的子密钥可能仍然需要恢复或撤销。

如前所述,主密钥的重要性意味着通过标识符的子密钥签署的消息来验证标识符,而不是由主密钥签署的消息。但由于这些消息通常与标识符本身相关联,所以它们实际上由主密钥签名(因为主密钥直接与标识符相关联)。 因此,主密钥仍可用于签署和传播撤销一个或多个历史子密钥的消息。

恢复丢失的子密钥可以使用前面描述的分片机制来完成。或者与上述基于分组的恢复方案一样,委托人可以选择将其标识的权限指定给一个组。这个组有能力签署属于标识符的新子密钥,并签名表示旧密钥已被泄密并被撤销的消息。

  • 结论

在本文中,我们讨论了如何通过全球可读的标识符(如网站域)在线管理身份。我们在互联网的两个主要身份管理系统中发现了各种安全和可用性问题:DNS和X.509 PKIX。 我们将这些问题的根源确定为这些系统的中心化,他们阻止这些标识符代表的实体真正控制它们,从而使第三方有危害其安全的可能性。

然后,我们展示了如何通过使用分散式键值数据存储(如区块链)来解决DNS和PKIX的安全性和可用性问题,以便为分散式公钥基础结构(DPKI)创建规范。在描述DPKI的属性时,我们发现DPKI即使在资源受限的移动设备上也能正常工作,并且能够通过保护组织免受私钥丢失或损害来保护标识符的完整性。

我们未来的工作是通过像IETF这样的互联网标准机构为DPKI制定完整的规范。

 

附录:轻客户端

信息类型

轻客户端想要知道什么样的信息?

以下是一些例子

  • 确定特定记录创建或首次出现的时间
  • 查找当前与帐户ID关联的公钥
  • 查找IP地址和当前与域名关联的其他数据
  • 了解密钥的撤销(没有找到替换密钥的特定流程)
  • 确定开发人员为特定软件包发布的最新版本

更通俗的说,我们可以将其分解为三类问题:

  • 证明存在性:证明在T时刻发生了某种事件。
  • 证明不存在:证明在时间T_1和T_2之间没有发生特定事件。
  • 证明状态:证明应用程序的“状态”可能是应用许多事务的复杂“状态转换”规则的结果,在时间T时等于X。

这些大致按照难易程度的顺序排列。 证明存在是最容易的,证明状态是最难的。

安全等级

一般来说,区块链顶部的轻客户端协议可以提供三种安全级别:

  • 最大的安全性:如果轻客户端进行查询,并且任何节点回应该查询的有效答复,则(如果我们可以检测到阻止预留攻击),轻客户端可以立即得到(i)查询的正确答案, 或(ii)答复无效,应予以忽略。
  • 1-of-N信任安全性:如果轻客户端进行查询,并且它被接受为安全假设,即至少有一个诚实的节点在T秒内能够正确响应,那么轻客户端可以在T秒后得到正确答案,不管有多少个离线/故障/拜占庭节点。
  • N/2-of-N 信任安全性:如果轻客户端进行查询,它必须选择一些信任的节点(比如说100),然后从该列表中随机抽样3个左右的节点,并要求响应一致。 只要所有3个节点不共谋,它就会得到正确的答案 如果任何节点处于脱机状态,则可以继续随机搜索联机节点,直到检查到某个节点的上限阈值,并且一旦达到该阈值时发生严重故障并出现错误。

作为这些模型如何应用的例子:假设存在一个有权撤销和替换密钥的单一主密钥(或一组主密钥),考虑“找到与帐户相关联的当前公钥”的简单情况。 假设我们有一个区块链,其中只有交易被放置在Merkle树中。然后,一个轻客户端发送一个请求,要求网络提供一个Merkle证明最近一次交易取代了公钥。 如果客户收到答案,它知道:

  • 有了最大的安全保证,这是过去某个时刻的有效密钥。这是“存在证明”问题。
  • 凭借1-of-N信任安全保证,这仍然是有效的密钥。(理论上可能存在一个更新的替换交易,但100%的合谋或审查可能导致客户不知道它)。这是“不存在证明”问题。

对于需求更复杂的协议(例如,实施复杂的名称注册规则),我们被迫处理更普遍的“证明状态”问题。 如果我们使用仅记录事务的简单区块链,客户端只会以N / 2-N信任安全保证的方式知道答案。但是,如果我们的区块链,状态位于Merkle树中,那么客户可以通过最大的安全保证来学习绝对的事实。

由于不同区块链对Merkle证据的使用程度不同,我们提出的解决方案是开发一种抽象协议,通过该协议可以使用不同的区块链(因为没有单个区块链被100%保证不会有致命缺陷,我们需要一个类似于用于加密算法选择的抽象模型),并根据区块链的功能自动尝试提供最佳安全级别。公证人可以作为支持者,但存在客户端可以安装以支持特定区块链的区块链插件。根据区块链是否支持针对特定类型问题(存在证明,证明状态等)的强大安全保证,这些插件可以智能地进行区块链查询,从而提供尽可能高的安全性。

轻客户端协议

轻客户端协议通常分两个阶段工作。

首先,轻客户端仅下载链的一部分,通常是块头。对于包含元数据的每个块,块头通常包含非常少量的信息(通常为80-600字节),例如(i)工作随机证明; (ii)包含诸如事务的数据的密码散列树的根,例如Merkle树; 和(iii)区块链可能跟踪的应用程序的状态。

其次,客户端使用区块链的基础共识算法(例如检查工作证明或证明签名)来验证块头。之后,客户端将块头视为“可信”。 它应用加密技术,将块头中的数据用作“根散列”,从中可以验证关于存储在区块链中的其余数据的声明。

获取链头

瘦客户机端的首要任务是下载并验证块头。假设一个工作网络连接,这很容易。 例如,在工作证明的情况下,客户端向网络请求尽可能多的块头,网络返回,客户端检查以确保每个块头具有有效的工作证明,然后确定 “最长”的有效块头(其中“最长”表示“代表最累积的工作”)。 存在更高级的使用跳过列表的协议,以至于客户端甚至不需要下载每个块头,尽管对此的深入讨论超出了本文的范围。

这种机制的主要挑战很简单:如果网络连接受到威胁会怎样? 潜在地,互联网服务提供商可以通过审查答复来告诉用户关于官方链的反馈,并告知用户他们自己的分支。 通过工作证明协议,人们可以通过注意到块生产率的降低来统计检测到这一点; 然而,需要更多的研究来确定最佳和最可靠的方法来做到这一点。

Merkle树进行验证

在轻客户端成功接收到一小段“可信”数据后,它必须能够验证关于区块链中其余数据的声明。这依靠Merkle树。 Merkle树是一种散列算法,其中大量“数据块”一次散列几块,然后将所产生的散列放入小组中,并且递归地散列直至该过程生成一个哈希值,称为根。 这个简单的描述显示如下:

这种方法的好处是可以通过Merkle分支来证明树中任何单数据块的成员资格,Merkle分支是树中节点的子集,其值在计算根散列的过程中使用。

仅使用这组节点,轻客户端就可以验证树中特定块是否具有特定的证据。 该方案能够确保抵碰撞; 为了让攻击者欺骗该方案,攻击者需要打破潜在的散列函数。有许多不同种类的Merkle树,包括简单的二叉树和更高级的设计,例如允许有效插入和删除操作的Merkle Patricia树,但基本原理是相同的。

发表评论

电子邮件地址不会被公开。 必填项已用*标注