什么阻止LoRaWAN节点在OTAA

Question

我肯定一定错过了阅读LoRaWAN规范的内容，因为这似乎太糟糕了。请告诉我，我的谵妄:)

当我有许多OTAA节点并且我无法弄清楚会阻止它的时候，我的测试平台似乎发生了以下情况：

1. 我的网络中的多个节点同时发出JOIN REQUEST（这可能偶然发生或同时启动）

2. 网关成功接收（至少）其中一个，并以JOIN ACCEPT响应，分配DevAddr，认为一个节点做了一个连接请求

3. 执行JOIN REQUEST的所有节点将收到ACCEPT并认为JOIN ACCEPT是针对他们的，并乐意设置相同的接收DevAddr

从现在开始，我们有几个节点都认为它们已经成功加入，并且都认为它们是唯一的但具有相同的DevAddr。不用说，系统严重搞砸了。

阅读LoRaWAN规范，JOIN REQUEST有一个节点唯一的DevEUI，一个网络唯一的AppEUI和一个随机DevNonce（以防止重放攻击）。 MIC由这些以及存储在节点中的秘密网络唯一AppKey计算。

就我所见，JOIN ACCEPT中没有来自JOIN REQUEST的数据，因此在许多节点当前正在侦听的情况下，它无法定向到特定节点接受。

它具有：AppNonce NetID DevAddr DLSettings RxDelay CFList，并使用AppKey加密，AppKey是网络唯一的，而不是节点唯一的。 MIC只涉及这些值，因此也没有帮助。

我原本预计JOIN ACCEPT至少包括请求加入作为MIC的一部分的DevEUI，还包括DevNonce。似乎它既不包括。

是什么给出的？ OTAA是否破损？ ：）

Answer 1

每种设备的MIC都会不同，因为它基于设备和网络之间共享的秘密（并且应该是唯一的）主密钥（AppKey）。

设备要做的第一件事是检查MIC，如果不是预期的那样，它将丢弃该消息。

所以您在下面所说的并不完全正确：

  

据我所知，JOIN ACCEPT中没有从JOIN> REQUEST派生的数据，因此在当前有许多>>节点的情况下，无法将其定向到特定节点听接受。

     

它具有：AppNonce NetID DevAddr DLSettings RxDelay CFList，并且   使用AppKey加密，这是网络唯一的，而不是节点唯一的。   MIC仅包含这些值，因此也无济于事

当然，如果您在每个设备上都设置了相同的AppKey， 得到你所描述的：）

Answer 2

除了Pierre答案中提到的不同AppKey（强烈建议）外，该节点的Join Request中还包含DevNonce。此DevNonce用于从“加入接受”响应中导出NwkSKey和AppSKey会话密钥。

在LoRaWAN 1.0.x中，此DevNonce应该是随机的。因此，即使在所有设备上使用相同的AppKey，也应该降低它们也将生成相同的DevNonce的机会。因此，即使MIC以某种方式进行了验证，派生的密钥也将与服务器已知的密钥不匹配，从而基本上使设备在不知道的情况下变得无用。

在LoRaWAN 1.1中，我 认为DevNonce越来越多，但是在1.1中，OTAA发生了变化，所以我不知道这会如何影响结果。

请参见https://runkit.com/avbentem/deciphering-a-lorawan-otaa-join-accept

  

这可能是偶然发生的，或者如果它们同时开机

关于同时打开，the 1.0.x specifications state：

  

终端设备调度的传输时隙基于其自身的通信需求，并且基于随机时间会有很小的变化

那么，在这种情况下，如此小的变化可能不会避免节点听到对方的Join Accept消息，因为下行接收窗口也需要稍宽一些。

Answer 3

一个限定词是加入请求（JR）和加入接受（JA）的时间要求。规范规定，设备只能在发送JR后的5或6（第二窗口）秒内“准确”使用JA。

我希望有比这种情况更好的故障保护功能，但其目的可能是防止错误的标签采用JA。