使用派生密鑰與客戶端進行對稱相互身份驗證
我正在嘗試找到一種客戶端/伺服器身份驗證協議，當客戶端不知道伺服器機密但確實具有從機密派生的敏感密鑰時，該協議允許客戶端和伺服器相互進行身份驗證。
我想使用非對稱證書，但是這種情況下的伺服器在 CPU 和記憶體資源方面非常有限，大約為 16MHz 和 32K Ram；但它確實有硬體 AES 支持。該過程的速度對使用者體驗至關重要，但安全性至關重要。
我正在考慮它，我想要這樣的東西（每個函式最安全的形式是隱式的）：
ClientID (CID)：將令牌與客戶端聯繫起來的唯一客戶端標識符。
客戶端令牌（CT）：HMAC（秘密，CID）
Secret (S)：伺服器知道的秘密。伺服器（或也知道密鑰的第三方）通過離線調試過程創建令牌。
Client -> Server CID, CNonce Server -> Client (Server derives expected CT with secret and CID) SNonce, HMAC(CT, CNonce) Client -> Server HMAC(CT, SNonce)這似乎給了我一些我需要的屬性：
- 客戶端可以驗證伺服器是否知道秘密，因為它能夠使用派生的 CT 進行 HMAC CNonce。
- 伺服器可以驗證客戶端是否擁有令牌，因為它可以使用 CT 對 SNonce 進行 HMAC。
- 隨機數減輕了重放攻擊。
- 由於從未傳輸令牌，MITM 攻擊得到緩解。
一般的答案是“不，除非他們知道一些秘密資訊，否則您無法通過電線對某人進行身份驗證。” 對某人進行身份驗證的唯一方法是讓他們做其他人無法做到的事情。如果你只是想通過在各方之間發送消息來做到這一點，那麼我能做別人做不到的事情的唯一方法就是如果我知道他們不知道的事情（無論我發送什麼都只基於我知道的事情; 如果他們知道我所知道的，他們就能弄清楚我會發送給他們自己什麼）。
不過，您的計劃並非如此。雙方都有一個秘密*；事實上，每一方（即CT）都是相同的秘密。有了共享的秘密，認證絕對成為可能；當共享秘密是高熵的（即不是從密碼派生的）時，它會更好。MAC應該*是實現這一目標的一種不錯的方法，儘管我會警惕可能的陷阱（一個值得注意的是，攻擊者可以通過伺服器獲得他想要的任何東西，但是使用強大的 MAC 只能允許直接重播，並且計劃停止）。
您的方案的另一部分是從伺服器主密鑰派生共享密鑰。如果使用帶有密鑰的 HMAC 來派生客戶端令牌的想法是您不需要擁有客戶端令牌的主列表，那麼這似乎是一種明智的方法；HMAC 應該阻止攻擊者創建他們從其他來源不知道的任何秘密令牌。TLS 使用 HMAC 作為 PRF 從秘密中生成加密密鑰，因此這是一個完全合理的選擇（TLS 使用它的方式是擁有種子併計算 HMAC（秘密，標籤+種子），但在您的情況下，您不需要一個標籤）。
很大程度上取決於您計劃在身份驗證後做什麼——如果他們繼續通信，那麼您所做的任何事情都無法阻止攻擊者篡改其餘的通信。例如，攻擊者可以保留消息 3，然後在幾天后發送。這是您的協議的問題嗎？如果是這樣，你必須以某種方式處理它。