在DPKI中，标识符通常是查找密钥，其映射到只能由具有相应私钥的实体（或多个实体）修改的值。在这样的系统中，可能发生的最坏情况是：
通过使用轻客户端（稍后讨论）和审查规避工具，可以解决这些问题。
虽然可能性极低，但也可能为标识符发送错误值。例如，如果通过工作证明保护的区块链具有能够压倒诚实节点并且在注册点之外反转历史的对手，则可能发生这种情况。但是系统的所有参与者都能够检测到这种攻击，因为它会导致一条长链的孤立。
这种问题最有可能来自区块链的集中化，这是一个更大的安全问题。
5.1 防止集中化
权力下放的程度对系统的安全起着重要作用。集中式系统易受到操纵、审查和危害的影响。它们代表了用户必须信任的单点故障。当集中式系统出现故障时，所有用户都失效。
虽然区块链可能从分散开始，但并不一定会以这种方式结束。这意味着需要一个简单的衡量标准，告诉我们“分散式数据存储”是否仍然是分散的：
你必须敲多少门才能与危害系统用户？
我们可以通过计算以下实体来粗略地定义用于测量大多数区块链分散的度量标准（每个实体在集中时对整个系统起单一故障点）：
“开发者”——控制区块链行为（源代码）的参与方数量。
“节点”——区块链副本的数量，由完整节点的数衡量。
“验证者”——区块链矿工/验证者的数量，负责创建新区块和授权交易。
由于任何一个组织的损害导致系统的损害，我们将区块链的分散定义为：
Decentralization(Blockchain) = MIN("Devs",“Nodes”, “Validators”)
更通俗的说，用户可以通过它提供的服务质量（QoS）来推断数据存储的分散。例如，如果用户注意到他们突然无法更新其标识符，这可能表明由于集中化而导致的审查。
5.1.1 防止集中化的数据存储不可知协议
如果DPKI将特定区块链指定为其“事实上分散式数据存储”，那么它就会对区块链产生集中压力。更糟糕的是，如果由于对链条缺乏兴趣而导致区块链被废弃，那么使用事实上的数据存储可能会破坏DPKI。对特定区块链进行编码支持的软件开发人员将不得不花费大量精力重写该软件以迁移到不同的区块链。同时，可能存在严重的安全问题或QoS问题。
因此，使用不可知协议访问分散数据库是确保DPKI整体功能和分散的基本要求。如果不同的数据存储更好地满足其需求，则不可知协议使用户和开发人员能够更轻松地进行迁移。仅仅存在这种可能性就会产生分散的数据存储市场，以满足用户的需求。
5.2 安全访问区块链数据
大多数终端设备由于所需的资源而无法运行完整节点，那么客户端如何安全地访问该区块链？
一种解决方案是是进行区块链版本的融合，其中一组“区块链公证人”告诉用户区块链维护的特定对象的状态，并且客户端软件检查一组可信的公证人之间的一致性协议。然而，这条路线可能会破坏区块链技术的主要目的：消除对可信中介的需求。
幸运的是，还有另一个技术解决方案：轻客户端协议。轻客户端下载区块链的较小部分，足以提供比可信中介提供更强的安全保证，且足够小以供任何现代设备使用。附录“轻客户端详细信息”中讨论了轻客户端协议如何工作的详细示例。
对于缺少轻客户端的区块链，默认值应该是基于可信节点的随机抽样的类似收敛的一致共识。这些节点都应该看到相同的链，所以即使其中一个节点不一致，则表明有什么不对劲并且应该报告事件。
一般来说，这表明采用模块化设计，设备可以与任意区块链通信并使用该链可用的最安全技术。没有单一技术提供最大的安全性，在这种情况下，最少数量的技术可以组合起来以提供设备维持的最高安全级别。
5.3 防止审查制度
最后，DPKI的安全性必须解决审查问题：最终用户是否可以访问数据存储。如果ISP正在审查区块链，则区块链无用。
诸如网状网络、代理和洋葱路由之类的审查规避技术可用于绕过区块链网络的审查。
一个单独但相关的问题是对区块链引用的数据进行审查，例如当哈希值存储在标识符的值中，该哈希值表示的数据存储在别处。在这种情况下，除了在各种不同的存储机制上查找哈希之外，还可以使用相同的技术（例如，洋葱路由，代理）[参见IPFS，Blockstore]。
标识符的强大可靠的所有权可以使这些标识符非常有价值。标识符可用于验证用户的房门、车等。这些标识符开始代表“王国的钥匙”。如果这些标识符丢失或受损，那将是灾难性的。因此，解决这个问题对DPKI的成功至关重要。
6.1 两种形式的丢失
由于其重要性，必须通过建立在DPKI之上的任何身份系统来最小化主密钥的使用。事实上这是如Blockchain ID等身份系统已经采用的方法。不使用主密钥对消息进行签名，而是为与标识符一起使用的每个新服务创建子密钥。
这意味着有两种类型的密钥可能会丢失或泄露：
主密钥和子密钥的安全性和恢复属性略有不同。以下是两种可能性的概述; 对这个主题的完整处理超出了本文的范围，留待未来进行。
6.2 恢复主密钥
控制标识符的主密钥的人是标识符的主人。
有多种机制可用于在分散系统中恢复主密钥。
6.2.1 重组主密钥分片
通过将主密钥碎片分发给可信实体，主体可以防止主密钥丢失。Shamir 秘密共享和阈值签名是两种可用于生成和重组这些分片的技术。
如果发生丢失，主体将向M个实体索要N个主密钥的分片。N是恢复所需的不同分片数。收到N个分片后，主密钥将被成功恢复。
然而，这种技术在主密钥泄露的情况下对保护主体没有多大作用。
6.2.2防止损害
损害的危险来自于任何时间点拥有主密钥的单个实体。我们可以通过确保任何单一实体在任何时间点都不拥有主密钥来解决此问题。
例如，我们可以设想一个系统，在注册时，用户可以选择他们信任的五个实体来保护他们的身份。这些实体可以由可信任的人、组织或甚至设备来代表。虽然他们像权威一样行事，但他们从不强迫任何人，而且总是由主体自己挑选。
然后主密钥短暂生成，分解成碎片，发送到这些实体，并立即销毁。可以使用阈值签名方案来代替Shamir秘密共享，以便永远不需要在任何给定设备上完全重新组合主密钥。
6.2.3使用智能合约
一些区块链（如以太坊）支持任意计算。在这种情况下，主体可以建立与其偏程度成比例的恢复机制。
作为一个简单的例子，像Google这样的公司可以通过使用智能合约来更新其价值的命名空间来保护他们对区块链域的控制。智能合约只有在接收到由10个实体中的6个签名的消息时才能够编码，或者遵循任何其他任意逻辑。
6.3 恢复和/或撤销子密钥
与主密钥的丢失或损害相比，子密钥泄露或损失不太重要，因为验证通常使用标识符的当前子密钥集来完成。如果子密钥丢失或受损，主密钥可以简单地用于安全地生成和替换区块链中的旧子密钥。但根据它们的使用方式，旧的子密钥可能仍然需要恢复或撤销。
如前所述，主密钥的重要性意味着通过标识符的子密钥签署的消息进行身份验证，而不是通过主密钥签名的消息进行身份验证。但由于这些消息通常与标识符本身相关联，因此它们实际上是由主密钥签名的（因为主密钥直接与标识符绑定）。因此，主密钥仍可用于签署和传播撤销一个或多个历史子密钥的消息。
可以使用先前描述的分片机制来恢复丢失的子密钥。或者与上述基于分组的恢复方案一样，主体可以选择将其标识的权限指定给一个组。该组可以将新子密钥签名为属于标识符，并且能够签署指示旧密钥被泄露并因此被撤销的消息。
在本文中，我们讨论了如何通过全局可读的标识符（如网站域名）在线管理身份。我们在互联网的两个主要身份管理系统中发现了各种安全和可用性问题：DNS和X.509 PKIX。我们确定这些问题的根源是这些系统的集中性质，他们阻止了标识符代表的实体真正控制它们，从而使第三方有危害其安全的可能性。
然后，我们展示了如何通过使用分散key-value数据存储（如区块链）来解决DNS和PKIX的安全性和可用性问题，从而为分散式公钥基础结构（DPKI）创建规范。在描述DPKI的属性时，我们发现DPKI甚至可以在资源受限的移动设备上运行，并且能够通过保护组织免受私钥丢失或损害来保护标识符的完整性。
作为这些模型如何应用的示例：请考虑“查找与帐户关联的当前公钥”的简单情况，假设存在一个有权撤销和替换密钥的主密钥（或一组主密钥）。假设我们有一个区块链，其中只有交易被放置在Merkle树中。然后，轻客户端发送请求，要求网络提供替换公钥的最近事务的Merkle证明。如果客户收到答案，它知道：
对于具有更复杂需求的协议（例如，实施复杂的名称注册规则），我们被迫处理更普遍的“证明状态”问题。如果我们使用只跟踪事务的简单区块链，客户端只能通过N / 2-of-N信任安全保证知道答案。但是，如果我们有一个区块链，状态位于Merkle树中，那么客户端可以绝对地学习任何具有最大安全保障的事实。
由于不同区块链对Merkle证据的使用程度不同，我们提出的解决方案是开发一种抽象协议，通过该协议可以使用不同的区块链（因为没有单个区块链被100％保证不会有致命缺陷，我们需要一个类似于用于加密算法选择的抽象模型），并根据区块链的功能自动尝试提供最佳安全级别。公证人可以作为支持者使用，但是会存在区块链插件，客户端可以安装这些插件来支持特定的区块链。根据区块链是否支持针对特定类型问题（存在证明，证明状态等）的强大安全保证，智能地进行区块链查询，从而提供尽可能多的安全性。
首先，轻客户端仅下载链的一部分，通常是块头。对于包含元数据的每个块，块头通常包含非常少量的信息（通常为80-600字节），例如（i）工作随机数证明; （ii）加密哈希树的根，例如Merkle树，包含诸如交易之类的数据; 和（iii）区块链可能跟踪的应用程序的状态。
其次，客户端使用区块链的基础共识算法（例如检查工作证明或证明签名）来验证块头。之后，客户端将块头视为“可信”。它应用加密技术，将块头中的数据用作“根哈希”，从中可以验证关于存储在区块链中的其余数据的声明。
瘦客户机端的首要任务是下载并验证块头。假设有一个有效的网络连接，这很容易。例如，在工作量证明的情况下，客户端向网络请求尽可能多的块头，网络回复，并且客户端检查以确保每个块头具有有效的工作证明，然后确定“最长”的有效块头（其中“最长”表示“代表最累积的工作”）。存在更高级的使用跳过列表的协议，以至于客户端甚至不需要下载每个块头，尽管对此的深入讨论超出了本文的范围。
这种机制面临的主要挑战很简单：如果网络连接受到威胁会怎样？潜在地，互联网服务提供商可以通过审查告诉客户端关于官方链的回复来攻击用户，并告知用户他们自己的分支。通过工作量证明协议，可以通过注意到块生产率的降低来统计检测到这一点; 然而，需要更多的研究来确定最佳和最可靠的方法。
在轻客户端成功接收到一小段“可信”数据后，它必须能够验证关于区块链中其余数据的声明。这依靠Merkle树。 Merkle树是一种散列算法，其中大量“数据块”一次散列几块，然后将所产生的散列放入小组中，并且递归地散列直至该过程生成一个哈希值，称为根。这个简单的描述显示如下：
只有这组节点，轻客户端就可以验证树中特定块是否具有特定的证据。该方案能够确保抵碰撞; 为了让攻击者欺骗该方案，攻击者需要打破底层的哈希函数。有许多不同种类的Merkle树，包括简单的二叉树和更高级的设计，如Merkle Patricia树，允许有效的插入和删除操作，但基本原理是相同的。
