AES 密鑰派生和管理的良好實踐
我正在開發基於 STM32L4x6 的設備。它通過 BLE 連接到智能手機，並與之交換加密數據。數據包括患者的健康數據。
加密是 AES-GCM 256 位，我使用的是 STMicro 提供的參考實現。
我在 Curve25519 上使用 Diffie-Helman 協議實現了經典的共享秘密交換機制。現在我直接使用這個共享密鑰作為 AES 密鑰。
我知道我需要從這個共享秘密中派生一個“密碼學上好的”AES 密鑰。
我計劃為此使用 HKDF-SHA512，因為它似乎是一種廣泛使用的算法，還因為 STMicro 還提供了參考實現。這是一個不錯的選擇嗎？
我對推導密鑰的鹽的大小和性質感到困惑。你對此有什麼建議嗎？
據我了解，可以使用 HKDF-SHA512 生成 256 位的密鑰，您確認嗎？
另外關於派生頻率：我應該以什麼頻率派生新密鑰？
謝謝
我知道我需要從這個共享秘密中導出一個“密碼學上好的”AES 密鑰……我打算為此使用 HKDF-SHA512，因為它似乎是一種廣泛使用的算法，而且還提供了一個參考實現意法半導體。這是一個不錯的選擇嗎？
是的。HKDF 是標準化的且備受推崇。
我對推導密鑰的鹽的大小和性質感到困惑。你對此有什麼建議嗎？
如果協議中已經提供了隨機數，您可能想要使用它。64 到 128 位的隨機數應該足夠了。任何超過 256 位的東西都是瘋狂的。注意鹽是互補的；任何大小的鹽總比沒有好。
當然，雙方都必須知道鹽，所以如果它還不可用，它會使協議變得有些複雜。
據我了解，可以使用 HKDF-SHA512 生成 256 位的密鑰，你確認嗎？
當然，你可以只取最左邊的256 位。您可以將剩餘位中的 96 位用於 IV。
另外關於派生頻率：我應該以什麼頻率派生新密鑰？
這取決於案例。對於智能卡，您可能只在協議開始時派生一次密鑰，如果正在處理太多數據，則只需停止，因為智能卡並不意味著持續可用。但是，如果您的傳輸協議的**安全通道只建立一次，那麼您可能需要在一定數量的消息後重新建立。
NIST的 GCM 規範的第 8 章中提供了有關如何確保密鑰是新鮮的提示，特別是第 8.3 章，它指定瞭如何使用 GCM。
請注意，創建傳輸協議有很多陷阱；您可能想看看 TLS 1.3 甚至直接實現它。TLS 1.3 也能夠使用 GCM 以及 HKDF。