AES ECB 用於短而重複的消息時的密鑰恢復

我的問題是基於協議 LoRaWAN 的規範，尤其是在6.2.5 Join-accept message部分。

據說join-accept消息是使用AES ECB加密的。這（通常）是這樣創建的單個消息：

aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC)

想像一下，攻擊者可以監聽通信。他不知道AppKey（顯然），AppNonce當然MIC. 如果攻擊者可以使終端設備發送大量的加入請求消息，並且如果伺服器總是以相應的加入接受消息進行響應，那麼攻擊者是否可以獲得AppKey使用 AES ECB 中的漏洞的知識？

免責聲明：對不起，如果我不清楚，密碼學不是我的專長。

ECB 模式有幾個弱點，正如我為什麼不應該使用 ECB 加密？但在這種特定情況下，它不允許獲取有關所AppKey涉及密鑰的資訊。

事實上，用相同的加密相同的塊AppKey將返回相同的密文。但是在 LoRaWAN join-accept 消息中，這並不重要，因為伺服器只加密了一個16 字節的塊，即AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC.

另外，每個這樣的塊應該是不同的，因為在 LoRaWAN 規範中指定：

1. >

AppNonce 是網路伺服器提供的隨機值或某種形式的唯一 ID

2. >

DevAddr 由 32 位組成，用於標識目前網路中的終端設備

如果攻擊者可以使終端設備發送大量的加入請求消息，並且如果伺服器總是以相應的加入接受消息進行響應，那麼攻擊者是否可以利用 AES ECB 中的缺陷獲得 AppKey 的知識？

請注意，加入請求具有以下結構：AppEUI | DevEUI | DevNoncewhereAppEUI標識應用程序並DevEUI標識終端設備。因此，如果攻擊者讓終端設備發送大量的加入請求消息，伺服器應該記住由標識的設備DevEUI在幾次之前發出了加入請求，並且應該以相同的DevAddr方式響應（或根本不響應）以避免拒絕服務攻擊。但我在規範中沒有看到任何關於它的內容。

引用自：https://crypto.stackexchange.com/questions/37535