在藍牙配對中使用共享密鑰作為帶外身份驗證數據

根據藍牙規範，配對過程從 Slave 發送一個可連接的廣告包開始，然後由 Master 發起連接。在 LE Legacy OOB 身份驗證中，一個秘密的 128 位臨時密鑰 (TK) 應該通過其他一些安全通道（例如 NFC）共享，以用於質詢-響應身份驗證，如下所示：

1. Master選擇隨機Mrand併計算Mconfirm = AES(TK, AES(TK, Mrand XOR p1) XOR p2)
2. 從機選擇隨機 Srand 併計算 Sconfirm = AES(TK, AES(TK, Srand XOR p1) XOR p2)
3. Master 發送 Mconfirm
4. 從站發送確認
5. Master發送Mrand和Slave確認
6. Slave 發送 Srand 和 Master 確認
7. 短期密鑰計算為 STK = AES(TK, Srand$$ 65:128 $$|| 蘭德$$ 65:128 $$)
8. 進一步的通信使用 STK 加密。

其中 p1 和 p2 包含 Master 和 Slave 的地址以及有關配對命令等的一些資訊。

現在假設 Master 和 Slave 共享一個密鑰（SK），該密鑰在工廠被燒錄到它們中。我打算在廣告包中發送一個 128 位隨機數據 (RD)，以便雙方都可以使用它來計算 TK，因為 TK = AES(SK, RD)。我在其他任何地方都沒有見過這種方法，據我所知，關於 LE Legacy OOB 身份驗證分析的文獻很少。

那麼，這是一種有效的方法嗎？它有什麼問題？

其他相關資訊和假設：

1. 可連接的廣告數據包的有效負載已經通過 CCM 使用另一個密鑰以及通過計數器和/或時間戳的重放保護進行了加密和驗證。
2. 有許多主機和從機，主機在固定位置，從機是移動的。每個從站都有一個唯一的 SK，主站可以從安全數據庫中查找它。
3. 不能使用綁定，因為不應該有使用者互動進行身份驗證，並且綁定密鑰不能在主伺服器之間共享。
4. LE 安全連接應該更安全，但需要使用者互動進行身份驗證，我們無法提供。
5. 每個從站將每 1-10 分鍾建立一次連接。

這並沒有讓我覺得這是一個非常好的身份驗證協議。您可以查看 $ (Mrand, \textsf{AES}{TK}(\textsf{AES}{TK}(Mrand \oplus p_1) \oplus p_2)) $ 作為隨機 CBC-MAC 的嘗試 $ p_1|p_2 $ ， 和 $ Mrand $ 是初始化向量。

不幸的是，隨機 CBC-MAC 作為 MAC 完全被破壞了。假設對手看到一個有效的 MAC $ (R,T) = \bigl(R, \textsf{AES}_K(\textsf{AES}_K(R \oplus p_1) \oplus p_2)\bigr) $ 一條消息 $ p_1 | p_2 $ . 然後就可以產生 $ (R \oplus \delta, T) $ 這是消息的有效 MAC $ (p_1 \oplus \delta) | p_2 $ .

除了對 MAC 的糟糕嘗試之外，該協議還遭受了微不足道的重放攻擊。每一方選擇一個僅影響他們自己的消息的隨機值。為了防止重放，每一方都應該將他們的協議消息綁定到另一方選擇的隨機值。

甚至還有反射攻擊。在這個協議中，如果主機發送 $ Mrand, Mconfirm $ 然後客戶端可以回顯 $ Srand=Mrand $ 和 $ Sconfirm=Mconfirm $ ，除非協議比您提到的更多，否則應該正確驗證。

這些攻擊的結果是一個端點認為它已成功配對，儘管另一個端點不知道帶外密鑰 $ TK $ . 但是，攻擊者無法導出會話密鑰。

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