在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樹，允許有效的插入和刪除操作，但基本原理是相同的。
