Rescuing LoRaWAN 1.0

Abstract

LoRaWAN is a worldwide deployed IoT security protocol. We provide an extensive analysis of the version 1.0, which is the currently deployed version, and we show that it suffers from several weaknesses. We introduce several attacks, including practical ones, that breach the network availability, data integrity, and data confidentiality, and target either an end-device or the backend system.

Based on the inner weaknesses of the protocol, these attacks do not lean on potential implementation or hardware bugs. Likewise they do not entail a physical access to the targeted equipment and are independent from the means used to physically protect secret parameters.

Finally we propose practical recommendations aiming at thwarting the attacks, while at the same time being compliant with the specification, and keeping the interoperability between patched and unmodified equipment.

Appendices

A Duty Cycle

The ducty cyle is a mechanism used to regulate the occupation rate of the radio channel by the end-device. Enforcing the duty cycle implies that an end-device cannot repeatedly send a lot of messages. Hence one could claim that the duration of the attack is greater than the figure we provide. However, the duty cycle is a regulation mechanism, not a security one (even if it could cleverly be used as such). And not all countries compel to use such a mechanism. Also, an end-device may well be certified (by the LoRa Alliance [13]) and yet not apply the duty cycle. Indeed a LoRa Alliance certification document explicitly states that “the LoRa Certification testing will not do any duty cycle testing” [8].

B Exhaustion Attack

Generating a parameter ($\mathtt{DevNonce}$, $\mathtt{AppNonce}$) with no repetition, and detecting replays are some countermeasures one may think of. Yet, in LoRaWAN, size does matter. Applying one of these methods while keeping at the same time the original parameter size (for compliance reasons) may lead to an attack aiming at exhausting all possible $\mathtt{DevNonce}$ or $\mathtt{AppNonce}$ values, hence forbidding the NS or the end-device to start a new activation. Therefore this exhaustion attack, targeting the end-device or the NS it connects to, may lead to an irrevocable disconnection of the end-device.

1.1 B.1 Against the $\mathtt{DevNonce}$ Parameter

Core. If the end-device generates $\mathtt{DevNonce}$ values with no repetition or if the NS keeps track of all $\mathtt{DevNonce}$ values it receives, it is possible to disconnect the end-device once and for all.

Attack. Every time the end-device sends a Join Request message, the attacker replies with a “false” Join Accept message. Hence the end-device generates a new message once again. If unique $\mathtt{DevNonce}$ values are generated, all values will be eventually used. If the NS keeps track of all $\mathtt{DevNonce}$ values, the NS will refuse further Join Request messages once all possible $\mathtt{DevNonce}$ values have been received, be these values pseudo-random or not.

Numerical Example. Let us assume that a key exchange is done in 5 s. If the $\mathtt{DevNonce}$ values never repeat, the attack targeting the end-device is achieved in $2^{16} \times 5\,\text {s} = 91$ h.

Let us consider the case when the NS keeps track of all $\mathtt{DevNonce}$ values. If the values are pseudo-random, the proportion effectively generated by the end-device, hence received by the NS after $\ell$ key exchanges, is $p = 1 - \exp (-\frac{\ell }{2^{16}})$. In order this proportion to be $p = 99\%$, the number of key exchanges must be at least $\ell = -2^{16}\times \ln (1-p)$. This corresponds to $\ell \simeq 301{,}804$ activations and more than 17 days to exhaust almost all $\mathtt{DevNonce}$ values. Remind that such an end-device is supposed to have an autonomous lifespan of up to ten years.

1.2 B.2 Against the $\mathtt{AppNonce}$ Parameter

Core. If the NS generates the $\mathtt{AppNonce}$ parameter so that it never repeats, or if the end-device keeps track of all $\mathtt{AppNonce}$ values it receives, then it is possible to disconnect the end-device once and for all.

Attack. Let us consider the first case. The purpose is to compel the NS to use all possible $\mathtt{AppNonce}$ values. The NS generates a Join Accept message (hence a new $\mathtt{AppNonce}$ value) only if it receives a valid Join Request message. Therefore the NS must accept as many Join Request messages as possible $\mathtt{AppNonce}$ values. Since $|\mathtt{DevNonce}| < |\mathtt{AppNonce}|$, this is possible only if the NS does not keep track of all $\mathtt{DevNonce}$ values it receives (which is likely its behaviour). Then the attacker can use a circular list of Join Request messages. Such messages can be collected using the technique described in Sect. 3.1, and then used in a similar way as the one described in Sect. 3.1.

Note that if the NS uses the same pool of $\mathtt{AppNonce}$ values for all the end-devices, this leads to the definitive disconnection of all these end-devices. In such a case the attack may be distributed among several “false” end-devices (controlled by the attacker; no duty cycle enforced).

Let us consider the second case. The purpose of this attack is to make the end-device keep track, hence receive, all possible $\mathtt{AppNonce}$ values. This means that the NS has to accept as many Join Request messages as possible $\mathtt{AppNonce}$ values. Therefore the NS must not keep track of all the $\mathtt{DevNonce}$ values it receives (since $|\mathtt{DevNonce}| < |\mathtt{AppNonce}|$). Yet this is not sufficient. Indeed the end-device accepts as many Join Accept messages (hence $\mathtt{AppNonce}$ values) as Join Request messages it sends. Therefore if the end-device generates $\mathtt{DevNonce}$ values with no repetition, it limits the number of received $\mathtt{AppNonce}$ values. Therefore this attack is possible if the NS does not keep track of all $\mathtt{DevNonce}$ values, and if the end-device does not generate unique $\mathtt{DevNonce}$ values (which is likely their basic behaviour).

Moreover the implementation of this second case implies to be able to compel the end-device to send multiples Join Request messages while receiving the corresponding Join Accept responses. We have not identified such means but to be able to influence on the end-device power supply. Yet, if the end-device is switched off, it may lose memory of the stored $\mathtt{AppNonce}$ values, which is orthogonal to the goal of this attack.

Numerical Example. If the $\mathtt{AppNonce}$ values do not repeat, they are all produced after $2^{24}\times 5\,\text {s} = 2.66$ years (using one end-device).

If the same pool of $\mathtt{AppNonce}$ values is used by the NS for all end-devices, the attack may be distributed among several end-devices controlled by the attacker. If 300 such end-devices are used in parallel, the attack is achieved in 3 days approximately.

If the end-device keeps track of all $\mathtt{AppNonce}$ values, and if the values are pseudo-random, $p = 99\%$ values are received by the end-device after $\ell = -2^{24}\times \ln (1-p) \simeq 77.26 \times 10^6$ activations. This means more than 12 years to exhaust almost all $\mathtt{AppNonce}$ values.