5

在阅读 LoRaWAN 规范时，我肯定错过了一些东西，因为这似乎太糟糕了，难以置信。请告诉我我神志不清:)

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

  1. 我的网络中的多个节点同时发出 JOIN REQUEST（这可能是偶然发生的，或者如果它们同时通电）

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

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

从这里开始，我们有几个节点都认为他们成功加入并且都认为他们是唯一的但具有相同的 DevAddr。不用说，系统会严重混乱。

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

据我所知，JOIN ACCEPT 中没有从 JOIN REQUEST 派生的数据，因此在许多节点当前正在侦听 ACCEPT 的情况下，它不能被定向到特定节点。

它具有：AppNonce NetID DevAddr DLSettings RxDelay CFList，并使用网络唯一而非节点唯一的 AppKey 进行加密。MIC 只涉及这些值，因此也无济于事。

我本来希望 JOIN ACCEPT 至少包括作为 MIC 的一部分请求加入的 DevEUI，并且还包括 DevNonce。似乎两者都不包括。

是什么赋予了？OTAA 是否损坏？:)

4

3 回答 3

5

每个设备的 MIC 会有所不同，因为它基于设备和网络之间共享的秘密（并且据说是唯一的）主密钥 (AppKey)。

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

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

就我所见，JOIN ACCEPT 没有从 JOIN > REQUEST 派生的数据，因此在许多 > > 节点当前正在侦听的情况下，它不能被定向到特定节点接受。

它具有：AppNonce NetID DevAddr DLSettings RxDelay CFList，并使用网络唯一而非节点唯一的 AppKey 进行加密。MIC 只涉及这些值，因此也无济于事

当然，如果您在每台设备上设置相同的 AppKey，您将得到您所描述的内容：)

于 2018-07-24T12:54:23.463 回答
1

除了 Pierre 的回答（强烈推荐）中提到的不同 AppKey 之外，该节点还在其加入请求中包含一个 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。

该问题还指出：

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

至于同时打开，1.0.x 规范状态：

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

尽管如此，如此小的变化可能不会避免节点在这种情况下听到彼此的加入接受消息，因为下行链路接收窗口也需要稍微宽松一些。

于 2019-01-11T18:42:50.240 回答
0

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

我希望有比这个时间更好的故障保险，但目的可能是防止错误的标签获取 JA。

于 2018-07-02T05:59:24.443 回答