Encryption
固定密鑰增量IV小數據加密
我有一個藍牙設備，它定期發送一個小包（不接收）。我想使用 AES-128 加密和驗證數據。它有一個嵌入的隨機且唯一的密鑰，該密鑰在生產時被刻錄到記憶體中，並且為接收者所知。我有以下消息結構：
計數器未加密，將按每條消息順序遞增（永不重複），並將用作 AES-CTR 模式的 IV。它還將用於防止重放攻擊，即忽略舊包。
魔術是固定且已知的數字，用於檢查解密的消息是否是亂碼和有效數據。
填充在接收端被忽略，用於將加密數據補全到 16 字節。
Payload + Magic + Padding 在發送前會一起加密，即
問題是：
- 被動偵聽器能否破解此加密和/或製作合法消息？
- 這是否也提供身份驗證，因為除了密鑰持有者之外沒有人可以製作這樣的消息？
- 可以使用 IV/nonce 並在 Counter 前添加 0 嗎？我應該將計數器附加到一個隨機數（這也是在工廠燒毀的）嗎？
- 填充什麼，0 或隨機數？甚至有必要嗎？
- 以這種方式使用幻數是否合乎邏輯？我是否需要生成隨機魔法並將其發送未加密和加密以供接收者驗證？
- 在這樣的設置中，正確/完善的加密和身份驗證方法是什麼？
- 被動偵聽器能否破解此加密和/或製作合法消息？
被動偵聽器不應該能夠反轉 AES，因此應該不可能獲取明文，除非每個會話都重新啟動。但是，這種方案容易受到明文預言機攻擊。繼續閱讀。
至於製作合法消息：這不是被動攻擊。
- 這是否也提供身份驗證，因為除了密鑰持有者之外沒有人可以製作這樣的消息？
不。如果你在中間扮演一個人，你可以改變資訊的每一點並保持魔法完好無損。在 CTR 模式下，明文/密文的所有位都是相互獨立的。它還允許攻擊者執行明文預言攻擊（通過更改一些明文，然後檢測系統如何響應它）。
- 可以使用 IV/nonce 並在 Counter 前添加 0 嗎？我應該將計數器附加到一個隨機數（這也是在工廠燒毀的）嗎？
只要計數器從不重複 CTR 模式是相對安全的——只要它使用正確，這裡不是這種情況。
- 填充什麼，0 或隨機數？甚至有必要嗎？
不，對於 CTR 模式填充不是必需的。
- 以這種方式使用幻數是否合乎邏輯？我是否需要生成隨機魔法並將其發送未加密和加密以供接收者驗證？
您通常會使用身份驗證模式來創建身份驗證標籤。32 位通常太小，但根據案例，對於實時系統等可能就足夠了。
- 在這樣的設置中，正確/完善的加密和身份驗證方法是什麼？
如果您只有 AES，那麼 CCM 模式將是正常模式。
注意
- 您目前描述的方案似乎更適合直接 AES 加密或 AES-CBC。例如，如果您要填充和加密計數器，您可以將其用作 AES-CBC 的 IV。如果您將該值
02放在消息的填充字節中，那麼您將擁有 PKCS#7 兼容的填充。這樣做的好處是消息的 AES 塊加密中的位現在都相互依賴，因此魔術會更好地工作。- 您目前的方案似乎僅限於一個會話。通常，您將為每個會話派生新的會話密鑰。
- 即使將模式更改為CBC，也有 $ 1 \over 2^{32} $ 攻擊者通過隨機嘗試創建具有有效魔法的消息的機會。消息的其餘部分可能會出現亂碼，但處理亂碼文本也可能不是一個好主意。也許可以針對這種情況實施額外的對策（但是，其中大多數都可能導致 DoS 攻擊）。