I am making a set of devices that aren’t simply sensors, but also take certain actions based on the response by the application. For these, I’d like to use The Things Network, since it fits my bandwidth requirements just fine. However, I’d like to make sure these devices are secure.
I’m reading a lot of things about LoRaWAN’s security mannerisms, but there’s one thing I couldn’t really find a satisfying answer to. Consider I have these devices share the same AppKey, and I’m using OTAA. If someone takes one device and extracts the AppKey, would they be able to spoof a gateway and application to control the rest of the devices? If not, how does LoRaWAN mitigate against this? If yes, is there anything I could do to prevent this?
Thanks in advance, and feel free to move this topic if I posted it in the wrong section. I’m not sure if I did this right.
OTAA session keys are derived not only from the AppKey, but also from the a nonce chosen by each of the joining device and the network server. If someone in possession of the AppKey overheard both packets of the join session then yes, they can trivially recover the session keys.
Even if they did not see both sides, there are re-use rules which likely make the values actually used something which can be narrowed down to the degree where the remaining possibilities can be brute forced. And looking at the system overall, there are other areas where enough entropy is “leaked” that brute forcing things may be possible for someone determined enough.
Generally, consider LoRaWAN to be “lightly” encrypted and authenticated against “nosy neighbors” but not against determined attackers.
Even without decryption or spoofing, traffic analysis may be quite possible.
OTAA is not magic, if you are willing to build the systems to manage them, using your own device unique keys can be better.
Nothing says you cannot take additional steps with the data before and after it is handled with LoRaWAN, just remember that anything you do needs to tolerate a high possibility of packet loss and to operate in an unconfirmed “uplink mostly” setting.
Remember that TTN policy limits how many downlinks you can send, as downlinks are very “expensive” of network capacity compared to uplinks. And you can only send downlinks in response to uplinks, which means that the latency of an infrastructure desired downlink could be minutes to hours to days, as it has to wait until there is a downlink to attach it to, and even then it might not actually be transmitted or successfully received.
Thanks for the very useful answers. Customizing AppKey on a per-device basis sounds like a sound way to secure against this kind of attacks, even if a bit inconvenient to setup.
TTN does store all nonces used by the node to prevent replay attacks. That is one of the reasons a device should not join too often as (with LoRaWAN 1.0.2 and below) the random nonce will be reused at some point and as such be (silently) rejected.