譯文 | 分散式公鑰基礎設施

網際網路促進了全球個人之間的通訊和交易，通過諸如電子郵件地址、域名和使用者名稱等識別符號進行的。但誰來控制這些識別符號？如何管理？他們之間的安全通訊是如何促進的？

當今，第三方機構（如DNS註冊服務機構，ICANN，X.509證書頒發機構（CA）和社交媒體公司）負責建立和管理線上識別符號以及它們之間的安全通訊。不幸的是，這種設計顯示出嚴重的可用性和安全缺陷。

1.1 線上識別符號的控制和管理

在設計DNS和X.509PKIX時，網際網路無法以可靠、分散的方式就註冊管理機構（或資料庫）的狀態達成一致。因此這些系統指定可信第三方來管理識別符號和公鑰。幾乎所有的網際網路軟體都依賴這些權威機構。因此，網站域名並不屬於註冊它們的組織（注意：它們屬於第三方，如ICANN、域名註冊機構、證書頒發機構以及任何能夠影響、強制或入侵它們的任何人）。同樣，網站上的使用者名稱並不屬於這些使用者。

這些可信第三方（有時縮寫為TTP）作為可破壞的中心故障點，每個都可能危及整個網際網路的完整性和安全性。由於這些識別符號的控制權被賦予TTP，因此其可用性也受到影響。這些與可靠性和可用性有關的問題會導致其他問題：

• 一些公司花費大量資源來解決由行為不當的CA導致安全漏洞；

• 許多網站仍然不支援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的複雜性，社交網路不會以任何方式加密使用者的通訊，除了依靠PKIX通過HTTPS傳送它們。由於訊息未經過簽名，因此無法確定使用者是否真正說出他們所說的內容，或顯示的文字是否是資料庫洩露的結果。類似地，使用者通訊以能夠訪問這些資料庫的任何人都可以讀取的方式儲存——損害使用者隱私並增加具有巨大責任風險的社交網路。

與傳統的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形成對比，在傳統的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的目標所產生的若干要求，以確保身份屬於他們所代表的實體：

• 私鑰必須以分散的方式生成，以確保它們在主體的控制之下（例如，通過主體裝置上的開源客戶端軟體）。這意味著明確禁止代表主體在伺服器上生成金鑰對的註冊服務。否則將重新出現第一節“簡介 - 為什麼是DPKI”中提到的問題。

• 軟體必須確保主體始終控制其識別符號和相應的金鑰。主體可將其識別符號的控制權擴充套件到第三方（例如，為了恢復目的），但這必須始終是需要明確的、知情的決定，而不是軟體的預設、隱含或誤導行為。永遠不要以不安全的方式儲存或傳輸私鑰。

• 軟體必須儘可能確保不存在允許單個實體在未經其同意的情況下剝奪其識別符號的主體的機制。這意味著：

在區塊鏈內建立了名稱空間後（例如，通過以太坊的智慧合約），就無法銷燬它。同樣，名稱空間不能包含允許任何人使不屬於它們的識別符號無效的黑名單機制。
 
註冊和更新識別符號的規則必須是透明的，並且必須以一種簡單的、難以忽略或誤解的方式（例如先到先得、拍賣）表達給使用者。特別是，如果註冊受到過期政策的約束，則必須明確告知主體，這可能導致主體失去對識別符號的控制。
一旦完成設定，就不能更改名稱空間規則以引入更新或更新識別符號的任何新限制，否則可以在未經其同意的情況下從主體中控制識別符號。同樣，不能修改用於更新或升級識別符號的客戶端軟體以引入用於更新或更新識別符號的新限制。
預設情況下，用於管理識別符號的軟體必須確保用於建立、更新、恢復或刪除識別符號的所有網路通訊都是通過分散的對等機制傳送。這同樣是為了確保單個實體（如註冊服務商）無法阻止升級或更新識別符號。

註冊識別符號可能具有與其相關聯的兩種型別的金鑰：用於註冊和更新與識別符號相關聯的資料的金鑰對，以及與識別符號（子金鑰）相關聯的公鑰。

建議主體使用子金鑰對訊息進行簽名。它們可以直接或間接儲存在資料儲存區中：

• 直接儲存意味著公鑰本身直接儲存在DPKI資料儲存中。對於大多數區塊鏈來說不太可能，因為一些金鑰非常大，大多數區塊鏈不可能儲存它們或非常昂貴。

• 間接儲存意味著指標（例如，URI）與公鑰指紋一起儲存（或其本身包含公鑰指紋）。