What prevents LoRaWAN nodes accepting the same JOIN ACCEPT message in OTAA

Question

I surely must have missed something from my reading of the LoRaWAN specifications, because this seems too bad to be true. Please tell me I'm delirious :)

The following seems to happen in my testbed when I have many OTAA nodes and I can't figure out what would prevent it:

1. multiple nodes in my network issues JOIN REQUEST at the same time (this can happen by chance or if they are powered on simultaneously)

2. gateway receives (at least) one of them successfully and responds with a JOIN ACCEPT assigning a DevAddr, thinking one node did a join req

3. all the nodes that did the JOIN REQUEST will receive the ACCEPT and think the JOIN ACCEPT was directed at them, and gladly sets the same received DevAddr

From here on, we have several nodes that all think they joined successfully and all think they are unique but have the same DevAddr. Needless to say, the system gets severely messed up.

Reading the LoRaWAN specification, the JOIN REQUEST has a node unique DevEUI, a network unique AppEUI, and a random DevNonce (to prevent replay attacks). The MIC is calculated from these and the secret network unique AppKey stored in the node.

The JOIN ACCEPT has, as far as I can see, no data in it which is derived from the JOIN REQUEST, and therefore it can't be directed to a specific node in the case that many nodes are currently listening to an ACCEPT.

It has: AppNonce NetID DevAddr DLSettings RxDelay CFList, and is encrypted with the AppKey which is network unique and not node unique. The MIC only involves these values and so doesn't help either.

I would have expected that the JOIN ACCEPT at the minimum includes the DevEUI requesting the join as a part of the MIC, and also that it would include the DevNonce. It seems it includes neither.

What gives? Is OTAA broken or not? :)

Mazda

Preliminary analysis: seems it really is a weakness. The node has to use an additional higher level handshake to assure it really is connected, or you need to use individual AppKeys for each device (kind of defeating part of the OTAA reason, I guess). – Mazda

Answer 1

The MIC will be different for each device because it's base on the secret (and supposedly unique) master key (AppKey) shared between the device and the network.

The first thing a device do is checking the MIC, if it's not what's expected it will drop the message.

So what you said below is not exactly right :

The JOIN ACCEPT has, as far as I can see, no data in it which is derived from the JOIN > REQUEST, and therefore it can't be directed to a specific node in the case that many > > nodes are currently listening to an ACCEPT.

It has: AppNonce NetID DevAddr DLSettings RxDelay CFList, and is encrypted with the AppKey which is network unique and not node unique. The MIC only involves these values and so doesn't help either

Of course if you set the same AppKey on every of your device, you will get what you described :)

Myth

Yeah well like I wrote in the comment above to my question, a unique AppKey per device is contrary to the OTAA policy (the point of it is that the server doesn't need predetermined keys to all the devices).. – Mazda

It's clearly written in the LoRaWAN Specification that the AppKey should be unique (and it's a good practice anyway). The AppKey is an AES-128 root key specific to the end-device. Whenever an end-device joins a network via over-the-air activation, the AppKey is used to derive the session keys NwkSKey and AppSKey specific for that end-device to encrypt and verify network communication and application data. Since all end-devices end up with unrelated application keys specific for each end-device, extracting the AppKey from an end-device only compromises this one end-device. – Myth

@PierreDUFOUR so the AppKey should be unique for each node (as the DevEUI), but each node should use the same AppEUI (for a specific application)? – Jhelum

The problem with deployment is not that each node would get a unique AppKey, but that you would somehow have to inform the server/gateway about this. In practice, I might tell my customer to add each node's EUI to the server list, but forcing the customer to read some 16 hex digit code from the node's sticker and enter somewhere else is not useable. So I guess you could just derive an AppKey from the DevEUI both at the server/gateway/setup side and at the node side.. but I'm not sure this really adds anything valuable to the security model. I would just want a mode where there is a single key. – Mazda

@BjornW, "forcing the customer to read some 16 hex digit code from the node's sticker and enter somewhere else is not useable", but when not using some provisioning system, that is how it works, and it would not be the only detail they need to copy. (Of course, some QR-code could help.) Also, please think twice before putting the node's secrets on a a sticker on the node. People tend not to remove stickers. – Blackberry

Answer 2

Apart from the different AppKey as mentioned in Pierre's answer (strongly recommended), the node also includes a DevNonce in its Join Request. This DevNonce is used to derive the NwkSKey and AppSKey session keys from the Join Accept response.

In LoRaWAN 1.0.x, this DevNonce should be random. So even when using the same AppKey for all devices, chances should be low that they would also have generated the same DevNonce. So even if the MIC somehow validated, then the derived keys will not match the keys known to the server, basically rendering the device useless without it knowing it.

In LoRaWAN 1.1 I think that the DevNonce is an increasing number, but in 1.1 OTAA has changed so I don't know how that affects the results.

See https://runkit.com/avbentem/deciphering-a-lorawan-otaa-join-accept.

The question also states:

this can happen by chance or if they are powered on simultaneously

As for switching on simultaneously, the 1.0.x specifications state:

The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis

Still then, such small variation probably won't avoid nodes hearing each others Join Accept messages in this scenario, as the downlink receive window will need to be slightly lenient too.

Blackberry

Interesting, yes the situation I had was that the nodes "broke". Maybe it isn't a security problem in that case, but the fact that they broke silently was a real problem. I think I just made sure the watchdog rebooted them if they didn't get any messages from the server at all for some time even after a "successfully" received JA.. – Mazda

Answer 3

One qualifier is the timing requirements for Join Request (JR) and Join Accept (JA). The specification is that a device can only use a JA received "precisely" 5 or 6 (2nd window) seconds after it sent the JR.

I'd hope there are better fail-safes then this timing but the intention might be to prevent the wrong tags from taking a JA.

Herzel

Yeah well there are highly probable scenarios when many nodes switch on simultaneously (for example, you could have 1000 nodes in a fleet that all reboot at midnight every day). With no knowledge of this, you would maybe insert some randomness in the JR to avoid radio congestion, but even so many would send during the same second anyway and hit this problem. – Mazda