今天的互聯(lián)網把在線身份的控制權交給第三方。電子郵件地址、用戶名和網站域名是通過DNS、X.509和社交網絡借用或“租借”的。這導致了整個互聯(lián)網范圍內嚴峻的可用性和安全性問題。本文描述了一種可能的替代方法,稱為分散式公鑰基礎設施(DPKI),它將在線身份的控制權返還給他們所屬的實體。通過這樣做,DPKI解決了許多困擾傳統(tǒng)公共密鑰基礎設施(PKI)的可用性和安全性問題。DPKI在PKI生命周期的每個階段都有優(yōu)勢。它使得在線身份無許可bootstrapping(自舉:程序語言編譯器用自身的語言及其特性來編譯自己)成為可能,并提供了更簡單的更強大的放法創(chuàng)建SSL證書。在使用中,它可以幫助“Johnny”最終加密,這要歸功于公鑰管理的降級,以確保分散的數(shù)據(jù)存儲。最后,它還包括恢復丟失或損壞的標識符的機制。
簡介——為什么是DPKI
互聯(lián)網促進了全球個人之間的通信和交易,是通過諸如電子郵件地址、域名和用戶名等標識符進行的。但誰來控制這些標識符?如何管理?他們之間的安全通信是如何促進的?
現(xiàn)代社會,第三方機構(如DNS注冊服務機構,ICANN,X.509證書頒發(fā)機構(CA)和社交媒體公司)負責創(chuàng)建和管理在線標識符以及它們之間的安全通信。不幸的是,這種設計顯示出嚴重的可用性和安全缺陷。
1.1在線標識符的控制和管理
在設計DNS和X.509 PKIX時,互聯(lián)網無法以可靠、分散的方式就注冊管理機構(或數(shù)據(jù)庫)的狀態(tài)達成一致。因此這些系統(tǒng)指定可信第三方來管理標識符和公鑰?,F(xiàn)在幾乎所有的互聯(lián)網軟件都依賴這些可信第三方。因此,網站域名并不屬于注冊它們的組織(注意:它們屬于第三方,如ICANN,域名注冊機構,證書頒發(fā)機構以及任何能夠影響、強制或入侵它們的任何人)。同樣,網站上的用戶名并不屬于這些用戶。
這些可信第三方(有時縮寫為TTP)作為可破壞的CPoF,每個都可能有損害整個互聯(lián)網的完整性和安全性。 因為這些標識符的控制權是給予TTP的,所以其可用性也受到損害。這些與可靠性和可用性有關的問題會導致其他問題:
· 一些公司花費大量資源來對付由不當行為造成的安全漏洞;
· 許多網站仍然不支持HTTPS;
· 對于大多數(shù)網民來說,真正安全和用戶友好的交流仍然遙不可及。
出于所有這些原因,DPKI的基本原則是身份屬于他們所代表的實體。這就要求設計一個分散的基礎設施,其中每個身份不是由可信第三方控制,而是由其所有者控制。
1.2在線交互的安全性
在線交互通過安全傳遞公鑰得到保護。這些密鑰對應于身份。這些身份所代表的實體(稱為委托人)使用相應的私鑰來解密發(fā)送給它們的消息,并且證明他們發(fā)送了消息(通過用私鑰對其進行簽名)。
PKI系統(tǒng)負責公鑰的安全傳送。但是,常用的X.509 PKI、PKIX破壞了這些密鑰的創(chuàng)建和安全傳遞。
1.2.1第三方面臨的挑戰(zhàn):尋找“正確的密鑰”
在X.509 PKIX中,通過創(chuàng)建由CA簽署的密鑰來保護Web服務。然而,在PKIX中生成和管理密鑰和證書的復雜性使得網絡托管公司自己管理這些密鑰的創(chuàng)建和簽署,而不是將其留給客戶。這從一開始就產生了主要的安全問題,因為它導致私鑰在CpoF(網絡托管公司)的積累,使得有權訪問該密鑰存儲庫的任何人都可能以幾乎無法察覺的方式危害與這些網站的連接的安全性。
X.509 PKIX的設計還允許世界各地約1200個CA模擬任何網站。CA的強制或妥協(xié)的風險使情況進一步復雜化。由于這些危險,用戶不能確定他們的通信沒有被允許進行MITM(中間人攻擊)的欺詐證書所破壞。 這些攻擊非常難以發(fā)現(xiàn); 像谷歌這樣的產生網頁瀏覽器的公司有時可以識別他們自己網站上的攻擊,但是它們不能阻止對任意網站的攻擊。
解決方法已經被提出。HPKP是一種IETF標準它允許網站告訴訪問者在一段時間內“扣住”他們收到的公鑰(忽略任何其他密鑰)。但是這種機制對于網站管理員來說很難使用,因此在實踐中可能不會使用太多。HPKP容易受到“敵意鎖定”的影響,并且在合法的情況下,如果密鑰需要被合法替換,則存在破壞網站的風險。更糟糕的是,HPKP的某些實現(xiàn)使第三方在沒有用戶同意的情況下覆蓋任意指針的做法變得輕而易舉。
1.3 PKI的可用性
即使可以信任權威第三方,目前的PKI系統(tǒng)也存在重大的可用性問題。 Brigham Young大學的一個小組調查了Mailvelope的可用性,Mailvelope是一種瀏覽器擴展,支持通過Gmail等第三方網站進行GPG加密通信。他們的研究表明參與者之間的安全通信嘗試的失敗率高達90%。研究發(fā)現(xiàn),公鑰管理是用戶無法正確使用軟件的主要原因。
TextSecure / Signal – 由愛德華斯諾登認可的安全和信息易用性的安全郵件系統(tǒng) —由于無法順利處理公鑰更改而導致可用性問題。如果用戶刪除并重新安裝應用程序他們的朋友將被警告其公鑰“指紋”已更改。這種情況與MITM攻擊無法區(qū)分,很少有用戶能夠理解或費力去驗證他們收到了正確的公鑰。
1.3.1消息妥協(xié)的危險
由于傳統(tǒng)PKI的可用性挑戰(zhàn),今天大多數(shù)網絡交流都是未簽名和未加密的。這在主要的社交網絡上尤其明顯。由于PKI的復雜性,社交網絡不會以任何方式加密用戶的通信,除非通過HTTPS發(fā)送它們來依賴PKIX。由于郵件未經過簽名,因此無法確定用戶是否真正說出他們所說的內容,或顯示的文本是否是數(shù)據(jù)庫泄密的結果。同樣,用戶通信的存儲方式使任何有權訪問這些數(shù)據(jù)庫的人都可以閱讀 – 危害用戶隱私并給社交網絡帶來巨大責任風險。
2. DPKI解決網絡信任問題
答案不是放棄PKI,而是尋找替代方案:DPKI,未來的分散式公鑰基礎設施標準。
DPKI的目標是確保與PKIX不同,任何單一的第三方都不可能危及整個系統(tǒng)的完整性和安全性。通過技術使信任分散化,使地理和政治上不同的實體可以就共享數(shù)據(jù)庫的狀態(tài)達成共識。DPKI主要關注分散的key-value數(shù)據(jù)存儲,稱為區(qū)塊鏈,但它完全能夠支持其他提供類似或具有更安全屬性的技術。
被稱為礦工(或驗證節(jié)點)的第三方依然存在,但它們的作用僅限于確保區(qū)塊鏈(或分歩式賬本)的安全性和完整性。這些礦工通過遵循議一致性協(xié)議得到財政激勵。偏離協(xié)議會導致經濟懲罰,而與協(xié)議的一致性通常會產生經濟回報。由中本聰創(chuàng)造的比特幣是第一個這樣成功的協(xié)議。它基于工作證明,其中“礦工”的能量消耗用于保護數(shù)據(jù)庫。
通過在區(qū)塊鏈中注冊標識符,可以像任何其他類型的交易一樣,授予委托人直接控制和擁有像網站域這樣的全球可讀標識符。在key-value數(shù)據(jù)存儲中(注意:在這種情況下,“key”是指數(shù)據(jù)庫查找字符串,而不是公鑰或私鑰),委托人使用標識符作為查找密鑰。
同時,區(qū)塊鏈允許將任意數(shù)據(jù)(例如公鑰)分配給這些標識符,并允許這些值以安全的方式在全局可讀,而不易受PKIX中可能出現(xiàn)的MITM攻擊的影響。 這是通過將標識符的查找值鏈接到該標識符的最新和最正確的公鑰來完成的。
在該設計中,標識符的控制權返回給委托人。對于任何一個實體來說,破壞整個系統(tǒng)的安全性或者損害不屬于它們的標識符都不再是輕而易舉的。這就是DPKI如何能夠解決困擾DNS和X.509 PKIX的安全性和可用性問題。
區(qū)塊鏈及其共識協(xié)議的完整描述超出了本文的范圍。第5節(jié)“標識符和公鑰的安全性”討論了它們的一些安全屬性,附錄“輕客戶端詳細信息”描述了這些區(qū)塊鏈中的數(shù)據(jù)如何從移動設備安全地訪問,而這些移動設備本身并沒有完整的區(qū)塊鏈副本。
3. DPKI威脅模型
與傳統(tǒng)的PKI系統(tǒng)一樣,DPKI假定一個持續(xù)的活躍對手Mal經常試圖欺騙一個委托人Alice信任另一個委托人Bob的錯誤密鑰。這可以采取發(fā)現(xiàn)Bob的錯誤標識符(例如,在twitter.com上找到錯誤的帳戶)或一旦知道標識符就緩存錯誤的密鑰的形式。
假設Mal是一個計算有限的對手,他能夠妥協(xié)或迫使集中的可信PKI方欺騙Alice信任錯誤的密鑰。這已經被證明是可行的,就像DigiNotar的情況一樣,并且在國家行為者迫使其轄區(qū)的CA簽署無效密鑰的情況下也是如此。另外,假設Mal能夠改變或阻止Alice和Bob之間交換的消息的約束分數(shù)(小于100%)。 這在今天也是可行的,并且通過ISP級審查,通過請求重新定向以及為了破壞像BitTorrent這樣的現(xiàn)有文件共享技術而執(zhí)行的分組修復攻擊,從已知的Tor出口節(jié)點發(fā)送黑洞數(shù)據(jù)包, 并阻止對政治敏感資料的HTTP訪問。
鑒于Mal的權力,DPKI的兩個設計原則變得明顯:
· 如前所述,每個委托人必須完全控制其當前的標識符/公鑰綁定。如果只有委托人可以修改他們的標識符,那么Mal就不得不攻擊每個委托人。這與傳統(tǒng)的PKI相反,Mal只需要危害一個CA來欺騙許多委托人。
· 該系統(tǒng)必須完成全有或全無的任何進展:每個主體必須見證其他主體對其標識符/公鑰綁定的更新,否則無人會觀察到任何更新。這是必要的,以防止Mal可能發(fā)生的網絡級攻擊,如果她檢查某些主體的更新,則通知整個網絡她的存在。這使得針對特定用戶或密鑰對的針對性攻擊極其昂貴,因為它使Mal攻擊任何人的唯一方式是立即攻擊所有人。
如前所述,DPKI通過使用安全的分散式key-value數(shù)據(jù)存儲庫來實現(xiàn)這些設計原則,以承載標識符和公鑰之間的綁定。有關詳細信息,請參閱第5節(jié)“標識符和公鑰的安全性”。
4. 注冊和標識符
如前幾節(jié)所述,DPKI的核心是分散式key-value數(shù)據(jù)存儲區(qū),可用作標識符注冊表,允許委托人的公鑰與其標識符安全關聯(lián)。只要這種注冊在有效狀態(tài),并且委托人能夠保持對其私鑰的控制權,則任何第三方都不能對該標識符擁有所有權,而不訴諸直接脅迫委托人。
DPKI沒有指定應該使用哪種類型的標識符,并且認識到可能有不同的方法(例如,用戶名或UUID),這些方法在易用性、持久性、唯一性、安全性和其他屬性方面可能不同。
對于DPKI使用key-value存儲,必須具有以下屬性:
· 無權寫入。任何委托人都可以廣播符合語法規(guī)則的消息。系統(tǒng)中的其他同等權限的人不需要準入控制。這意味著分散的共識機制。
· 叉選規(guī)則。給定兩個更新歷史,任何委托人都可以通過檢查確定哪一個是最“安全”的。
這些需求可以通過區(qū)塊鏈來滿足,例如Namecoin,Ethereum,甚至可能是比特幣(通過Blockstore等技術)。
4.1 DPKI注冊要求
在DPKI中標識符注冊與DNS不同。雖然注冊商可能存在于DPKI中,但他們必須遵守DPKI的目標中出現(xiàn)的幾項要求,以確保身份屬于他們所代表的實體:
· 私鑰必須以分散的方式生成,以確保其在委托人的控制之下(例如,通過委托人的設備上的開源客戶端軟件)。這意味著明確禁止代表委托人在服務器上生成密鑰對的注冊服務。否則將重新創(chuàng)建§1“簡介 – 為什么DPKI”中提到的問題。
· 軟件必須確保委托人始終控制其標識符和相應的密鑰。委托人可以將其標識符的控制權擴展到第三方例如,為了恢復目的),但這必須始終是需要明確的、知情的決定,而不是軟件的默認,隱含或誤導行為。永遠不要以不安全的方式存儲或傳輸私鑰。
· 軟件必須盡最大可能確保沒有任何機制能夠允許單一實體在未經其同意的情況下剝奪委托人的標識符。這意味著:
· 一旦在區(qū)塊鏈內創(chuàng)建了一個名稱空間(例如,通過以太坊的智能合約),它就不會被銷毀。同樣,命名空間不能包含黑名單機制,這將允許任何人使不屬于它們的標識符失效。
· 注冊和更新標識符的規(guī)則必須是透明的,并且必須以一種簡單的、難以忽略或誤解的方式(例如先到先得、拍賣)表達給用戶。特別是,如果注冊受制于到期政策,則必須明確告知委托人,這可能導致委托人失去對標識符的控制權。
· 一旦完成設置,命名空間規(guī)則就不能改變以引入任何新的更新或恢復標識符的限制,否則將有可能在未經其同意的情況下標識符脫離委托人控制。同樣,用于更新或更新標識符的客戶端軟件也不能被修改以引入用于更新或恢復標識符的新限制。
· 默認情況下,用于管理標識符的軟件必須確保用于創(chuàng)建、更新、恢復或刪除標識符的所有網絡通信都是通過分散的對等機制發(fā)送的。 這也是為了確保單個實體(如注冊服務商)不能阻止標識符被更新或恢復。
我們推薦DPKI基礎設施也努力確保:
· 至少有一類標識符在正確注冊后不會過期。
· 至少有一類中立注冊政策可供所有公眾以及希望提供注冊服務的任何服務提供商使用。
4.2 DPKI注冊機制
注冊標識符可能有兩種類型的密鑰與它們相關聯(lián):密鑰對用于注冊和更新與標識符相關聯(lián)的數(shù)據(jù)以及與標識符(子密鑰)關聯(lián)的公鑰。
建議委托人使用子密鑰對消息進行簽名。它們可以直接或間接存儲在數(shù)據(jù)存儲中:
· 直接存儲意味著公鑰本身直接存儲在DPKI數(shù)據(jù)存儲中。對于大多數(shù)區(qū)塊鏈來說不太可能的,因為一些密鑰非常大,大多數(shù)區(qū)塊鏈不可能存儲或非常昂貴。
· 間接存儲意味著指針(例如,URI)與公鑰指紋一起存儲(或其本身包含)。
· 標識符和公鑰的安全
在DPKI中,標識符通常是查找密鑰,映射到只能由具有相應私鑰的實體(或多個實體)修改的值。在這樣的系統(tǒng)中,可能發(fā)生的最壞情況是:
· 發(fā)送查找鍵的過期值響應查找。
· 標識符的所有者由于審查而無法更新其值,并且一旦標識符到期,他們就會失去所有權。
這些問題可以通過使用輕客戶端(稍后討論)和審查規(guī)避工具來解決。
雖然可能性極低,但也有可能為標識符發(fā)送錯誤的值。例如,如果由工作證明保護的區(qū)塊鏈擁有能夠壓倒誠實節(jié)點并在注冊點之外扭轉歷史的對手,則可能發(fā)生這種情況。但是系統(tǒng)的所有參與者都能夠檢測到這種攻擊,因為這會導致一個非常長的鏈的孤立。
這類問題很可能是由于區(qū)塊鏈的集中化引起的,是更大的安全問題。
5.1 防止集中化
權力下放的程度對系統(tǒng)的安全起著重要作用。中心化系統(tǒng)容易受到操縱、審查和妥協(xié)。它們代表了用戶必須信任的SPoF。當中心化系統(tǒng)停機時,所有用戶都失效。
雖然區(qū)塊鏈可能從分散開始,但不一定會以這種方式結束。這意味著需要一個簡單的衡量標準,告訴我們“分散式數(shù)據(jù)存儲”是否仍然是分散的:
你必須敲多少門才能與系統(tǒng)的用戶達成妥協(xié)?
我們可以粗略定義衡量大多數(shù)區(qū)塊鏈分散度量的指標,方法是對以下實體進行計數(shù)(當整個系統(tǒng)時中心化的,每個實體作為SPoF):
“開發(fā)者” – 控制區(qū)塊鏈行為(源代碼)的參與方數(shù)量。
“節(jié)點” – 區(qū)塊鏈副本的數(shù)量,以完整節(jié)點的數(shù)衡量。
“驗證者” – 區(qū)塊鏈采礦者/驗證者的人數(shù),他們負責創(chuàng)建新塊和授權交易。
由于任何一個組織的妥協(xié)導致系統(tǒng)的妥協(xié),我們將區(qū)塊鏈的分散化定義為:
Decentralization(Blockchain) = MIN(“Devs”, “Nodes”, “Validators”)
更通俗的說,用戶可以通過它提供的服務質量(QoS)來推斷數(shù)據(jù)存儲的分散。例如,如果用戶注意到他們突然無法更新他們的標識符,這可能表明由于集中化而導致的審查。
5.1.1防止中心化的數(shù)據(jù)存儲不可知協(xié)議
如果DPKI將特定區(qū)塊鏈指定為其“事實上分散的數(shù)據(jù)存儲區(qū)”,那么它將會在該區(qū)塊鏈上施加集中化壓力。更糟糕的是,如果區(qū)塊鏈由于對鏈條缺乏興趣而被放棄,那么使用事實上的數(shù)據(jù)存儲可能會破壞DPKI。對特定區(qū)塊鏈進行編碼支持的軟件開發(fā)人員將不得不花費大量精力重寫該軟件以遷移到不同的區(qū)塊鏈。 同時,可能存在嚴重的安全問題或QoS問題。
因此,使用不可知協(xié)議訪問分散數(shù)據(jù)庫是確保整個DPKI運作和下放的基本要求。如果不同的數(shù)據(jù)存儲更好地滿足他們的需求,則不可知協(xié)議使用戶和開發(fā)人員能夠更輕松地進行遷移。這種可能性的存在創(chuàng)造了一個分散的數(shù)據(jù)存儲市場,相互競爭以滿足用戶的需求。
5.2 安全訪問區(qū)塊鏈數(shù)據(jù)
大多數(shù)終端設備由于所需的資源而無法運行完整節(jié)點,那么客戶如何安全地訪問該區(qū)塊鏈?
一種解決方案是做一個區(qū)塊鏈版本的集合,其中一組“區(qū)塊鏈公證人”告訴用戶區(qū)塊鏈維護的特定對象的狀態(tài),并且客戶端軟件檢查一組可信的公證人之間的一致性協(xié)議。這條路線可以說是區(qū)塊鏈技術的主要目的:消除對可信中介的需求。
幸運的是,還有另一個技術解決方案:輕客戶端協(xié)議。輕客戶端下載較小的區(qū)塊鏈部分,足以提供比受信任中介提供的更強的安全保證,而且足夠小,可供任何現(xiàn)代設備使用。 附錄“輕客戶端詳細信息”中討論了輕客戶端協(xié)議如何工作的詳細示例。
對于沒有輕客戶端的區(qū)塊鏈,缺省值應該是基于可信節(jié)點的隨機抽樣的類似于Convergence的一致共識。這些節(jié)點都應該看到相同的鏈,所以如果其中一個節(jié)點不同意,則表明有什么不對勁并且應該報告事件。
一般來說,建議采用模塊化設計,其中設備可以任意與區(qū)塊鏈對話并使用該鏈可用的最安全的技術??赡軟]有單一技術提供最大的安全性,在這種情況下,最少數(shù)量的技術被結合起來以提供設備維持的最高級別的安全性。
5.3防止審查
最后,DPKI的安全必須解決審查問題:數(shù)據(jù)存儲是否可供最終用戶訪問。 如果ISP正在審查它,區(qū)塊鏈就沒用了。
審查制度規(guī)避技術,如網狀網絡,代理和洋蔥路由,可以用來繞過區(qū)塊鏈網絡的審查。
一個獨立但相關的問題是對區(qū)塊鏈引用的數(shù)據(jù)進行審查,比如當一個哈希值存儲在標識符的值中,而由該哈希值表示的數(shù)據(jù)存儲在別處。在這種情況下,除了在各種不同的存儲機制上查找散列之外,還可以使用相同的技術(例如,洋蔥路由,代理)[參見IPFS,Blockstore]。
6. 恢復丟失的標識符 – 私鑰管理
標識符的強大可靠可以使這些標識符非常有價值。標識符可以用來認證用戶到他們房子的門,他們的車等。這些標識符開始代表“王國的鑰匙”。 如果這些標識符丟失或受損,那將是災難性的。 因此,解決這個問題對DPKI的成功至關重要。
6.1兩種形式的丟失
由于其重要性,必須通過建立在DPKI之上的任何身份系統(tǒng)來最小化對主密鑰的使用。事實上這是身份系統(tǒng)已經采用的方法,如Blockchain ID。不使用主密鑰對消息進行簽名,而是為每個使用該標識符的新服務創(chuàng)建子密鑰。
這意味著有兩種類型的密鑰可能會丟失或泄露:
· 主私鑰,用于控制與標識符關聯(lián)的數(shù)據(jù)。丟失此密鑰可能意味著失去對您的在線身份的控制權。
· 子密鑰,它們被鏈接到標識符并被存儲為標識符數(shù)據(jù)的一部分。
主密鑰和子密鑰的安全性和恢復屬性稍有不同。以下是兩種可能性的概述; 對這個話題的全面處理超出了本文的范圍,留待未來進行。
6.2 恢復主密鑰
將主密鑰控制為標識符的人是標識符的主人。
有多種機制可用于在分散系統(tǒng)中恢復主密鑰。
6.2.1重組主密鑰碎片
通過將主密鑰碎片分發(fā)給可信實體,委托人可以防止主密鑰丟失。 Shamir Secret Sharing和Threshold Signatures是兩種可用于生成和重組這些碎片的技術。
如果發(fā)生丟失,委托人將向M個實體索要N個主密鑰的碎片。N是恢復所需的不同碎片的數(shù)量。在收到N個碎片后,主密鑰將被成功恢復。
然而,這種技術在主密鑰泄露的情況下對保護委托人沒有多大作用。
6.2.2防止妥協(xié)
妥協(xié)的危險來自單一實體擁有任何時間點的主密鑰。我們可以通過確保任何單一實體在任何時間點都不擁有主密鑰來解決此問題。
例如,我們可以設想一個系統(tǒng),在注冊后,用戶選擇他們信任的五個實體來保護他們的身份。這些實體可以由可信任的人、組織或甚至設備來代表。雖然他們像權威一樣行事,但他們從不強迫任何人,而且總是由委托人自己挑選。
然后主密鑰短暫生成,分解成碎片,發(fā)送到這些實體,并立即銷毀??梢允褂瞄撝岛灻桨竵泶鍿hamir Secret Sharing,以便主密鑰不需要在任何給定設備上完全重新組合。
6.2.3使用智能合約
一些區(qū)塊鏈(如以太坊)支持任意計算。在這種情況下,委托人可以建立與其偏執(zhí)狂水平成正比的恢復機制。
作為一個簡單的例子,像Google這樣的公司可以通過使用智能合約來更新其價值的名稱空間來保護他們對區(qū)塊鏈域的控制。智能合約只能在接收到由10個實體中的6個簽名的消息時才能夠編碼,或者遵循任何其他任意邏輯。
6.3恢復和/或撤銷子密鑰
子密鑰泄露或丟失不如主密鑰泄露或丟失更嚴重,因為驗證通常使用當前標識符的子密鑰集來完成。如果子密鑰丟失或被破壞,主密鑰可以簡單地用于在區(qū)塊鏈中安全地生成和替換舊的子密鑰。但根據(jù)它們的使用方式,舊的子密鑰可能仍然需要恢復或撤銷。
如前所述,主密鑰的重要性意味著通過標識符的子密鑰簽署的消息來驗證標識符,而不是由主密鑰簽署的消息。但由于這些消息通常與標識符本身相關聯(lián),所以它們實際上由主密鑰簽名(因為主密鑰直接與標識符相關聯(lián))。 因此,主密鑰仍可用于簽署和傳播撤銷一個或多個歷史子密鑰的消息。
恢復丟失的子密鑰可以使用前面描述的分片機制來完成?;蛘吲c上述基于分組的恢復方案一樣,委托人可以選擇將其標識的權限指定給一個組。這個組有能力簽署屬于標識符的新子密鑰,并簽名表示舊密鑰已被泄密并被撤銷的消息。
結論
在本文中,我們討論了如何通過全球可讀的標識符(如網站域)在線管理身份。我們在互聯(lián)網的兩個主要身份管理系統(tǒng)中發(fā)現(xiàn)了各種安全和可用性問題:DNS和X.509 PKIX。 我們將這些問題的根源確定為這些系統(tǒng)的中心化,他們阻止這些標識符代表的實體真正控制它們,從而使第三方有危害其安全的可能性。
然后,我們展示了如何通過使用分散式鍵值數(shù)據(jù)存儲(如區(qū)塊鏈)來解決DNS和PKIX的安全性和可用性問題,以便為分散式公鑰基礎結構(DPKI)創(chuàng)建規(guī)范。在描述DPKI的屬性時,我們發(fā)現(xiàn)DPKI即使在資源受限的移動設備上也能正常工作,并且能夠通過保護組織免受私鑰丟失或損害來保護標識符的完整性。
我們未來的工作是通過像IETF這樣的互聯(lián)網標準機構為DPKI制定完整的規(guī)范。
評論