LoRaWAN Security

This week, a security company called IOActive published a white paper on security vulnerabilities in LoRaWAN. You can read it here. I was also in the audience at a talk they gave during the Things Conference 2020 in Amsterdam last week on the same subject of security in LoRaWAN.

This report has caused a slight stir in the LoRaWAN community, to that end the LoRa-Alliance published a blog post on security. You can read this here.

I’ve read both and having been involved in security conscious areas of computing for many years (Voice-over-IP before IoT/LPWAN), there’s nothing in either report that I can’t agree with in some way. I do feel the IOActive report is a little bit sensationalist but hey, they’re a business trying to get their name out there so I can let them off. Plus, everything they talk about I have seen before in the VoIP world so it’s not new to me. Here’s my own thoughts on this subject.

There’s really two aspects to the report, the first is that LoRaWAN version 1.0 AppKeys are brute forceable. This is true, any encrypted or hashed password is brute forceable given enough time and resource. This information is neither new or surprising. The problem here is that it’s not that hard to do in a lot of cases, often due to poor management of these keys. LoRaWAN 1.1 adds extra security to mitigate this risk, I wont go into details here, the spec is published by the LoRa-Alliance if you want to read it plus these reports cover it too.

The other aspect the reports deal with are implementation issues and human factors. These are frequently the cause of cyber security problems in all areas, certainly it is the case in the Voice-over-IP world as well as IoT.

With respect to LoRaWAN, the issue is one of management of the AppKeys. Here’s a run down of the problems. I have seen each and every one of these problems in the real world several times!

  • Keys sent and stored in a non-secure fashion. I’ve seen both manufacturers and end user emailing spreadsheets or text files containing AppKeys in plain text. Then keeping hold of these files on their computer in case they need to refer to them later on. This is bad. If someone ever got hold of these files then they have a copy of the keys. Keys should be treated in the same way as passwords (although many people are terrible at that too). There’s an old saying, if you wouldn’t write something on the back of a postcard and drop it into a post box, then don’t send it in an email, there’s no way of knowing who might see that email.
  • Poor quality, non-random or non-unique keys. The most common one is where devices all share the same AppKeys, either from the manufacturer with little consideration given to changing them or installers being lazy and provisioning the same AppKey to all devices because it’s quicker. Also, non-random keys such as the DevEUI repeated twice, 32 zeros, “1234” repeated etc… These are all similar to using “password123” for a login password, they are easily guessable and not secure.
  • Hard-coded keys which can’t be changed. This one is down to manufacturers of devices. Would you sign up to a social media website and post your photos on it if they forced you to use a set password with no way of changing it (especially if they’d emailed it to you in plain text)? Hopefully the answer is no.
  • Insecure out-of-band management. Some devices are configurable over Bluetooth or NFC using a mobile app. It seems in some cases, there’s no security on this. You can download the manufacturer’s free app and connect to a device if you are close enough to it, then read the AppKey from it. Personally I think this is a limited attack vector, it requires the attacker to be physically close to the device. Having said that, if you’ve also used the same AppKey on all your devices, now your entire system is compromised because someone got hold of a single sensor.

So what should you do? Should you rip out all your LoRaWAN systems and hide in a cupboard for the rest of the year? Absolutely not, in fact mitigating these risks is not very hard. I can confidently say that I’ve been implementing these measures and instilling secure ways of handling LoRaWAN keys in all our staff for a long time. What this means for us and what I would encourage anyone reading this to do is as follows.

  • Use unique AppKeys on each and every device you install. Don’t even use common ones for testing, it’s just a bad habit to get in to. This website can be used to generate random 128bit keys for use as AppKeys. When we provision devices for customers, we always use this or similar tools to generate unique keys and securely load them onto the devices.
  • Keep your keys safe. Don’t email them, an Excel spreadsheet with a password applied is still pretty poor security. We provide a securely encrypted portal to allow our customers to submit keys to us (or for us to send keys to our customers). This software generates a single-use obscure link, without the link it’s not easily possible to decrypt the keys even if someone had access to the server the portal is hosted on. We can also provide a password as an extra layer of security which is sent separately to the link itself. We use open source software called PrivateBin to do this. We also never store keys and I regularly train staff on the virtues of key security.
  • Keep your infrastructure secure. Your LoRaWAN Network Server has copies of all your keys stored on it. Make sure this is secure, use secure random passwords to log in to it. Make sure any other access to the server (e.g. ssh access) is secure. I wont go into details here, if you’d like to talk about this then feel free to get in touch.
  • Communicate. If you see someone doing something you feel is bad practise, say so. If you deal with us and we advice you that you are doing something we feel can be improved, don’t take it personally, we are trying to help. Similarly, we are very open to discussion and suggestions you might have for us. We keep in touch with our suppliers and manufacturers to advise and take advice on security. We also actively lobby manufacturers of devices to improve security and keep developing firmware to implement new standards.

I encourage the LoRaWAN community to openly discuss these issues so they can be debated in an organised manner. I have seen the IOActive report being dismissed as FUD, this is counterproductive, there are real issues to address, defensiveness and an unwillingness to debate are not helpful in my opinion (although it’s a reaction I have encountered many times in the technical/computing industry). I am always happy for anyone to talk to me about an issue they feel they have found and I am always willing to assist in talking to device manufacturers about fixing problems and improving security in an open and honest fashion.