Public-Key

簽署非對稱加密的交換對稱密鑰

  • June 16, 2017

考慮以下實現:

Bob 希望通過不安全的渠道與他的團隊進行長期溝通。Bob 和團隊的所有成員生成單獨的公鑰/私鑰對(例如 RSA)並在不受信任的密鑰伺服器上儲存/共享他們的公鑰。

Bob 作為團隊的第一個成員,還為團隊生成了一個長期隨機對稱密鑰,他和所有團隊成員將使用該密鑰來加密他們的通信。Bob 用他的公鑰和團隊所有目前成員的公鑰加密團隊的對稱密鑰,並將它們儲存在同一個不受信任的密鑰伺服器上。

當新成員加入團隊時,Bob(或團隊中任何可以添加新成員的現有成員)從密鑰伺服器獲取他自己的團隊對稱密鑰的加密版本,用他的私鑰解密,然後複製並重新- 使用新成員的公鑰對其進行加密,將其儲存回密鑰伺服器上,以供新成員用於未來與團隊的通信。

這種實現的問題在於對稱密鑰可以由 Eve 偽造,Eve 是一個有權修改密鑰伺服器的不良行為者。由於公鑰都是可用的,Eve 可以使用 Bob(或團隊的任何和所有成員)的公鑰並在密鑰伺服器上加密一個新的對稱密鑰。過去的通信將無法解密,然而,如果團隊沒有註意到任何未來的通信,Eve 可能會讀取任何未來的通信。如果在首次儲存對稱密鑰時發生了偽造,那麼團隊中的任何成員都不會知道 Eve 一直在閱讀他們的通信。

我認為我們需要在對稱密鑰交換上進行某種簽名,但是,該簽名的密鑰材料從何而來?我們如何生成簽名,使團隊的每個成員都可以私下驗證他們的團隊對稱密鑰版本是真實的?也許有其他方式?


更新#1

一種解決方案是讓 Bob 在第一次生成對稱密鑰時計算它的雜湊值,然後用他的私鑰對雜湊值進行簽名並將其儲存在密鑰伺服器上。每當成員從密鑰伺服器檢索他們的對稱密鑰副本時,他們還可以獲得 Bob 的公鑰,驗證雜湊的簽名並重新計算雜湊以驗證對稱密鑰。

然而,我看到這個解決方案的問題是,Eve 似乎仍然可以偽造一個新的對稱密鑰,用她的私鑰對其進行簽名,然後在密鑰伺服器上用她的公鑰替換 Bob 的公鑰。這將允許她在其他團隊成員驗證和使用偽造的對稱密鑰時冒充 Bob 的簽名。

您的場景似乎過於簡化,但無論如何:

只需讓 Bob 簽署他上傳的密鑰即可。

您假設人們無論如何都知道彼此的公鑰。所以每個人都可以驗證密鑰是否已被 Bob 簽名。

如果你想保持一對一的信任結構,添加新團隊成員的人也可以再次簽署密鑰,或者只是簽署他們信任 Bob。

我認為在這里分析社會問題也很有幫助:因為團隊中的任何成員都可以合併新成員,這使得團隊作為一個整體很難驗證上傳的新對稱密鑰是否真實。因為 Eve 可以訪問每個人的公鑰,她可以偽裝成團隊成員,為了讓團隊發現入侵,他們需要詢問每個成員是否加入了新成員。這讓我有兩個收穫:

**1)**使只有 Bob 可以添加新成員。這使得檢測冒名頂替者變得很容易,但理所當然地認為 Bob 總是保持警惕和容易接近,所以它並不理想。

**2)**如果 Alice(或任何團隊成員)想要加入一個新成員,她會生成一個獨立的對稱密鑰,她用她的私鑰對其進行加密,以便可以用她的公鑰對其進行解密。她將其廣播給團隊,以確保此密鑰真正由她生成。然後,她將該對稱密鑰提供給 Tom,Tom 用他的私鑰對其進行加密。團隊成員可以使用他的公鑰解密並驗證 Alice 給了 Tom 對稱密鑰(即加入組的權限)。在此之後,可以忽略獨立對稱密鑰,並且可以使用每個人(包括湯姆)的公鑰重新加密原始團隊對稱密鑰。

引用自:https://crypto.stackexchange.com/questions/48342