這種 DIY 遠端鎖定協議安全嗎？

我需要您對以下遠端鎖和鑰匙之間的交換協議方案的建議。我打算使用以下算法：

1. Key 生成永遠不會重複的唯一值（實際上它只是每次按下按鈕時遞增的計數器），我們稱之為“NONCE1”。
2. Key 向鎖發送請求，請求由 NONCE1 和 H1 = MD5(NONCE1 + KEY1) 組成。第二部分僅用於“簽名”請求，如果攻擊者不知道 KEY1，他將無法生成有效請求。
3. Lock 檢查是否 H1 = MD5(NONCE1 + KEY1)，這用於檢查傳入請求是否來自密鑰（或至少來自知道 KEY1 值的人）。之前未描述的其他步驟是：

• Lock檢查前一個密鑰請求的NONCE1是否小於剛剛收到的NONCE1。這部分防止對先前處理的請求進行操作，具有此類請求的攻擊者將無法繼續進行。我試圖讓他處於鎖定不接受舊請求的情況，並且無法生成新請求，因為他無法在沒有 KEY1 的情況下重現它。
• 鎖集 NONCE1(previous request) = NONCE1(current request)

4. 鎖產生完全唯一的永不重複的值，我們稱之為“NONCE2”。
5. Lock 向包含 H2 = MD5(NONCE2 + KEY2) 的密鑰發送響應。NONCE2 - 基於計數器（為了完全排除可能的衝突），因此為了向攻擊者隱藏它的“基於計數器的性質”，這裡使用了 MD5(NONCE2 + KEY2)。
6. 密鑰執行 H3 = MD5(H2 + KEY3) 並將其發送回鎖
7. Lock 檢查是否 H3 = MD5(H2 + KEY3) 並對其進行操作

可能存在哪些漏洞？在這種特殊情況下使用 MD5 是否足夠安全？

我添加了一些額外的“子步驟”來稍微澄清一下

接受的建議/解決方案如下：

• 擺脫步驟 1 - 3
• 用 HMAC-XXX 替換 MD5

即使在您更新之後，第一部分似乎也沒有必要。然而，步驟 4-5 確實阻止了攻擊者學習他們可以詢問關鍵 MAC 值的未來隨機數。因此，協議步驟 4-7 使用安全 MAC 將是安全的。

我同意 CodesInChaos 的觀點，即使用 HMAC 會更好，因為 H(m||k)有一些弱點，而 HMAC 是標準的。除非您有充分的理由使用 MD5，否則我也更喜歡使用更強的散列，儘管HMAC-MD5 仍然是安全的（即關於加密數據，但通常適用）。

然而，我認為這些弱點實際上並不適用於此，因為攻擊者沒有自由選擇他們需要計算密鑰雜湊的值。所以即使它應該是安全的。儘管如此，我還是建議切換到 HMAC。更好的辦法是使用現有的用於此目的的相互身份驗證協議，如HAC第 10 章中描述的協議（參見 10.2.3）。

---

以下適用於問題原始版本中描述的協議。

1. Key 生成完全唯一且永不重複的值（某種計數器），我們稱之為“NONCE1”。
2. Key 向鎖發送請求，請求由 NONCE1 和 H1 = MD5(NONCE1 + KEY1) 組成
3. 鎖檢查是否 H1 = MD5(NONCE1 + KEY1)

這部分不能向任何人證明什麼，所以它是無用的。冒充密鑰的攻擊者可以重用任何以前的 nonce+MD5 對，因為鎖不知道 nonce 是否唯一。冒充鎖的攻擊者可以簡單地忽略接收到的數據。

4. 鎖產生完全唯一的永不重複的值，我們稱之為“NONCE2”。
5. Lock 向包含 H2 = MD5(NONCE2 + KEY2) 的密鑰發送響應

為什麼不簡單地發送 NONCE2 用作 H2？雜湊似乎沒有任何幫助，因為隨機數不用於其他任何事情。

6. 密鑰執行 H3 = MD5(H2 + KEY3) 並將其發送回鎖
7. Lock 檢查是否 H3 = MD5(H2 + KEY3) 並對其進行操作

這是協議中唯一具有明確目的的部分：鎖正在驗證 ad-hoc MAC以驗證密鑰。

引用自：https://crypto.stackexchange.com/questions/32299