LoRaWAN 1.0.2会话密钥安全

Question

我正在阅读关于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位网络服务器生成的一种名为nonce的网络服务器。
• NetID是24位的网络标识符，如果连接过程在同一网络上相关，则不会更改。
• DevNonce是由16位终端设备产生的一种新的.
• pad_16函数附加零个八进制，因此数据的长度是16的倍数。

我不确定这个键派生的健壮性。块内的可变部分是否被加密，而不仅仅是40位？此外，如果您使用相同的AppSKey很长时间，甚至3/4年，解决方案是否仍然稳健？

此外，DevNonce是从连接请求消息中的终端设备发送的，并且消息没有加密。

Answer 1

aes128_ecb_encrypt (前进方向的AES分组密码)是一个伪随机排列族:如果对手不知道密钥，那么知道与某些输入对应的输出并不能帮助找到与其他输入对应的输出。换句话说，为给定的AppSKey找到AppKey的唯一方法是说服熟悉AppKey的人计算和发布准确输入的AppSKey值(相同的AppNonce、相同的NetID和DevNonce)。

因此，议定书的潜在问题是：

1. 能否说服共享AppKey的用户在同一个NetID中同时重复AppNonce和DevNonce？
2. 这种AppKey的使用会导致调用与AppKey的其他用途相同的输入的AES置换吗？

1.现在的重复

双方都需要立即重复。AppNonce是一个24位的值，所以如果它是随机选择的，它可能会在2^{12} \approx 4000尝试中至少重复一次(生日悖论)。DevNonce是一个16位的值，应该是随机的，所以它很可能在2^8 = 256尝试中至少重复一次(第6.2.4节)。但是，由于这两种非two是由不同的设备所选择的，因此，一个现在重复的概率与另一个现在重复的概率是独立的。如果AppNonce确实是随机的，那么很有可能重复您需要的2^{20} \approx 1,000,000尝试。在11 11kbit/s，这是名义上的最大带宽，你可以在一天内完成，如果设备的电池达到它。

如果重复使用非are，它们最终将使用相同的AppSKey。AppSKey用于使用CCM*进行未经身份验证的加密。未经验证的CCM*是CTR，具有初始计数器值的选择，以确保如果CCM* IV不重复，计数器值不会重复。因此，为了获得一个块来重复，您不仅需要安排密钥重复，而且还需要IV。由于IV是根据固定的设备特性和帧计数(§4.3.3)以简单的方式计算的，所以每个会话使用相同的IV序列。因此，如果两个会话使用相同的AppSKey，那么这些会话中的相应消息将使用相同的掩码加密。这揭示了每对对应消息的xor。

使用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，输入是连续输入块xor-ing的结果，中间结果是AES输出。中间结果未发布。
• 连接-接受消息是通过解密一个数据块来计算的。

我看不出有什么明显的方法可以让输入发生碰撞，但这需要进行广泛的分析。