在 LoRaWAN 中使用 AES 是否正確？
我正在閱讀有關 LoRaWAN（規範）的資訊。該網路協議有一種特殊的數據加密方式，詳見 4.3.3.1 部分。據我了解，這是對加密工作原理的回顧。
首先，創建一個序列 A，其中每個塊的大小為 16 字節
A1..An。A 的長度取決於有效載荷的長度，因此len(payload) <= 16*n = len(A) < len(payload) + 16。以下是用於塊的值Ai：0x01 | 0x00 | 0x00 | 0x00 | 0x00 | Dir | DevAddr | Counter | 0x00 | i一個塊是 16 字節長。
Counter為每個有效載荷遞增；i為每個創建的塊遞增 (1 <= i <= n)。Dir是0或1取決於它是向上還是向下，並且DevAddr與終端設備的地址固定。現在創建了塊，它們被加密以獲得一系列
S塊Si：Si = aes128_encrypt(K, Ai) for i = 1..n S = S1 | S2 | .. | Sn最後對有效載荷進行加密：
(pld | pad16) xor S truncation of the first len(payload) bytes發送的消息是通過連接標頭（其中包含 和 的值
DevAddr）Counter、加密的有效負載和使用另一個 AES 密鑰生成的 MIC（消息完整性檢查）來創建的。接收設備知道密鑰，因此它可以：
- 檢查麥克風
A1..An使用標題中指示的值創建塊- 加密它們以獲得序列
S- 破譯有效載荷
這是我的問題
我發現這個實現是基本的。更具體地說，我的印像是有效載荷的特定位在加密後位於同一位置。但我不知道攻擊者是否可以利用它來獲取資訊？
此外，攻擊者可以通過攔截消息知道幾乎所有事情，因此他可能知道序列
A。有沒有辦法他可以解密有效載荷或獲取有關密鑰的資訊？
這與使用 MAC 的 CTR 模式加密相同。眾所周知，這是安全的。
它沒有在你的問題中說如果：
- Ai 塊是完全獨特的；
- 標頭包含在 MIC 計算中。
如果滿足這些先決條件，那麼我認為協議沒有任何問題。
第一個我無法驗證但似乎很可能，第二個肯定是真的（當我查看連結的文件時）。
請注意，MIC 有點短，只有 32 位。對於這個協議，它可能就足夠了。另一方面，基於 AES-128 的 CMAC 計算適用於 MIC。
免責聲明：這不應被視為對協議的全面審查，而只是對問題的直接回答。