LoRaWAN 1.0.2 會話密鑰安全
我正在閱讀有關 LoRaWAN 1.0.2規範的資訊。為了通信的機密性和完整性，協議生成兩個會話密鑰，NwkSKey 和 AppSKey（規範的第 6.2.5 部分，第 35 頁）。
應用程序和網路會話密鑰都派生如下，唯一的區別是第一個組件（0x01 和 0x02）：
AppSKey = aes128_ecb_encrypt(AppKey, 0x02 | AppNonce | NetID |DevNonce | pad_16 )
- 0x02 是 8 位的常數。
- AppNonce 是由 24 位網路伺服器生成的隨機數。
- NetID 是 24 位的網路標識符，如果加入過程在同一網路上相關，則不會改變。
- DevNonce 是由 16 位終端設備生成的隨機數。
- pad_16 函式附加零個八位字節，以便數據的長度是 16 的倍數。
我不確定這個密鑰推導的穩健性。塊內的可變部分是否被加密而不僅僅是 40 位？此外，如果您長時間使用相同的 AppSKey，甚至 3/4 年，該解決方案仍然健壯嗎？
此外，DevNonce 是在加入請求消息中從終端設備發送的，並且該消息未加密。
aes128_ecb_encrypt（正向的 AES 分組密碼）是一個偽隨機排列族：如果對手不知道密鑰，那麼知道與某些輸入相對應的輸出無助於找到與某些其他輸入相對應的輸出。換句話說，找到AppSKey給定的唯一方法AppKey是說服知道AppKey計算並發布該AppSKey精確輸入的值的人（相同AppNonce，相同NetID和DevNonce）。因此，該協議的潛在問題是：
AppKey可以說服共享一個的使用者重複兩者AppNonce並DevNonce在同一個內重複NetID嗎？- 這種使用會
AppKey導致使用與其他使用相同的輸入呼叫 AES 置換AppKey嗎？1. Nonce 重複
雙方都需要進行隨機數重複。
AppNonce是一個 24 位的值，所以如果它是隨機選擇的，它可能會在稍微多一點的時間內至少重複一次 $ 2^{12} \approx 4000 $ 嘗試（生日悖論）。DevNonce是一個 16 位的值，應該是隨機的，所以它可能會在稍微多一點的時間內至少重複一次 $ 2^8 = 256 $ 嘗試（第 6.2.4 節）。但是由於這兩個 nonce 是由不同的設備選擇的，所以一個 nonce 重複的機率與另一個 nonce 重複的機率無關。如果AppNonce真的是隨機的，那麼要獲得一個很好的重複機會，你需要大約 $ 2^{20} \approx 1,000,000 $ 嘗試。在 11kbit/s（標稱最大頻寬）下，如果設備的電池可用，您可以在一天內完成。如果 nonce 重複，它們最終將使用相同的
AppSKey.AppSKey用於使用 CCM* 進行未經身份驗證的加密。未經身份驗證的 CCM* 是具有初始計數器值選擇的 CTR，可確保在 CCM* IV 不重複時計數器值不會重複。因此，為了讓一個塊重複，您不僅需要安排要重複的鍵，還需要安排 IV。由於 IV 是根據恆定的設備特性和幀計數（第 4.3.3 節）以簡單的方式計算的，因此每個會話都使用相同的 IV 序列。因此，如果兩個會話使用相同的AppSKey，那麼這些會話中的相應消息將使用相同的遮罩進行加密。這揭示了每對對應消息的異或。的用途
AppKey除了 的推導之外
AppSKey，AppKey還用於計算加入消息（第 6.2.4 節）和加入接受消息（第 6.2.5 節）的完整性值 (MIC)、推導NwkSKey（第 6.2.5 節）和加密加入接受消息（§6.2.5）。
NwkSKey``AppSKey以與前綴相同的方式派生0x01而不是0x02.- MIC 是 CMAC 計算。CMAC 在加密方向使用 AES，輸入是連續輸入塊的異或結果，中間結果是 AES 輸出。中間結果不公佈。
- 通過解密數據塊來計算加入接受消息。
我沒有看到讓輸入發生衝突的明顯方法，但這需要進行廣泛的分析。