AES-GCM 認證標籤可以用作密鑰派生函式嗎？
我想建構一個確定性的密鑰派生樹，其中根安全地儲存在集中式服務中，而葉子則嵌入在眾多設備中。當設備想要與後端通信時，設備會提供其 ID 和 salt，而集中式服務從根密鑰以及設備 ID 和 salt 派生設備特定密鑰。
通常我會支持 HKDF 或其他眾所周知的密鑰派生函式。但由於我們打算在雲提供商上執行整個服務，我們對安全密鑰儲存的選擇更加有限。
Azure Key Vault 在其託管的 HSM 上提供對 AES-GCM 的實驗性支持。我的想法是使用設備 salt 作為 AES-GCM 的輸入 nonce (IV)，使用設備 ID 作為關聯數據輸入，不使用純文字作為輸入。作為 AES-GCM 的輸出，我將使用生成的標籤作為確定性偽隨機密鑰：
$ \text{KDF}(key, salt, id) := \text{AES-GCM-encryption}(key, \epsilon, salt, id) $
在哪裡 $ key $ 是儲存在密鑰庫中的全域根密鑰， $ \epsilon $ 是用作明文 GCM 輸入的空字元串， $ salt $ 是一個 96 位值，用作 $ nonce $ 在 GCM 中，以及 $ id $ 是一個可變長度的設備標識字元串，沒有設備與其他設備共享，並用作 GCM 中的關聯數據輸入。
那個建築安全嗎……
- 假設salt / nonce在密鑰的整個生命週期和所有設備 ID 中是全域唯一的？
- 假設**鹽/“nonce”僅對特定 ID 是唯一的，**並且可能有多個設備意外共享相同的鹽（由於隨機值的衝突）？
直覺上，我很確定使用全球唯一的鹽，這種結構應該是一個安全的密鑰派生函式。但是對於我們想到的案例來說，這很難實現。
第一，定義結構。以建議的方式使用 AES-GCM 相當於$$ \operatorname{KDF}(K,S,I)=\operatorname{AES}K(S|0^{32})\oplus \operatorname{GHASH}{\operatorname{AES}_K(0^{128})}(I) $$
在哪裡 $ \operatorname{GHASH}_H(M)\approx \sum_i H^iM_i $ 對於消息塊 $ M_i $ 大小為 128 位，乘法和加法在具有多項式表示的 128 位有限域中完成。這是 GHASH 的近似值，適用於我們下面的討論。
那個建築安全嗎……
如果它在兩個輸入中的行為都像 PRF 一樣，我將把它稱為安全的 KDF 構造，受命名的約束，即唯一的輸入產生獨立的偽隨機輸出。
$$ Assuming $$salt/nonce 在密鑰的整個生命週期和所有設備 ID 中是全域唯一的嗎？
正如您從上面的表達式中看到的，假設您的鹽是唯一的，AES 操作將屏蔽任何 GHASH 結果，並且輸出看起來是隨機且不可預測的。但是，鑑於下一部分的答案，除了可能稍微掩蓋鹽碰撞事件之外，相關數據是否提供任何有用的好處是值得懷疑的。
$$ Assuming $$salt /“nonce”僅對於特定 ID 是唯一的，並且可能有多個設備意外共享相同的 salt（由於隨機值的衝突）？
抱歉不行。如果兩個派生使用相同的 $ (K,S) $ 與兩個不同的配對 $ I,I’ $ 查詢和對手學習相應的輸出鍵 $ k,k’ $ ，那麼對手可以學習 $ k\oplus k’ = \operatorname{GHASH}_{\operatorname{AES}K(0^{128})}(I) \oplus \operatorname{GHASH}{\operatorname{AES}_K(0^{128})}(I’)\approx \sum_i H^i(I’_i\oplus I_i) $ 這是一個對手可以從中恢復的表達式 $ H=\operatorname{AES}K(0^{128}) $ 讓他們恢復 $ k\oplus \operatorname{GHASH}{\operatorname{AES}_K(0^{128})}(I) = \operatorname{AES}_K(S|0^{32}) $ 並從那裡預測任何派生密鑰 $ I $ 對於這個固定 $ (K,S) $ 一對。