Keeping LoRaWAN keys safe with the Alliot Key Management System

Any LoRaWAN device needs keys in order to work. They are an integral part of the protocol and used to keep data secure and to authorise devices to be able to connect to your IoT system. LoRaWAN key management is an important consideration.

Nearly all LoRaWAN devices connect to a Network Server using an Over-The-Air-Activation process referred to as OTAA. Amongst other things, this uses an AppKey to authenticate your device and as a basis for data encryption for all communication between the device and your server.

Currently, whenever you buy a LoRaWAN device you need to be given the AppEUI (or JoinEUI as it is known in LoRaWAN 1.1) and the AppKey. It is important that this is done in a secure way. If someone is able to intercept your keys then they can compromise the security of your IoT system.

At Alliot we care so much about your security that we have built a secure service to deliver keys to our customers.

Our LoRaWAN Key Management System (KMS) is free to use for our customers, whenever you buy sensors from us (whether we have provisioned new keys or the devices are using the manufacturer’s default keys), we will load the keys into KMS for you to log in and retrieve whenever you want.

Alliot LoRaWAN Key Management System Screenshot
(Note; the data in this screenshot is fake test data!)

How is This Secure?

Our KMS system offers the following security features:

  • Hardened web server with HTTPS only communication. All access to the KMS web software is over HTTPS, we use modern certificates with only modern, secure ciphers enabled. We regularly run our servers through the Qualys SSL-Labs web server testing tool. Our server is given the highest A+ rating. (See screenshot below).
  • Password hashing and enforced long, secure passwords. We only ever store login passwords hashed with unique salt and many thousand iterations of hashing. This means that there is essentially no way of someone cracking passwords. I have to use the word “essentially” as nothing is impossible but it would take even the most powerful super-computers billions of years to do! We enforce the use of long, random passwords, this seems like an inconvenience but it is the only way of making sure people don’t compromise their own security by using easy to guess passwords. If you aren’t already then please use a password manager tool such as https://bitwarden.com/, https://www.lastpass.com/ or similar.
  • Brute force protection and “back door” access protection. We rate limit login attempts to mean brute force guessing of passwords is basically impossible (this only works when long, random passwords are used as above). We audit our servers and ensure that there are no unnecessary services running, any necessary services (such as ssh) are locked down, monitored and rate limited and administrative logins to servers for our staff are carefully managed.
  • A no login sharing policy. We insist that our customers use individual logins rather than generic per company logins. Each individual login will see the stored keys for the whole customer. The reason for this is two fold. On one hand it discourages people from keeping login passwords in publicly accessible places or emails for their staff to share. On the other hand it gives us an audit trial of who is doing what on the server if we ever need it.
  • The LoRaWAN keys themselves are stored in a database for retrieval. They are stored using modern, secure encryption methods and master keys are kept securely and not obtainable by unauthorised staff. We rotate the encryption keys periodically.
Qualys SSL Labs result for Alliot LoRaWAN Key Management Server
(Screenshot of Qualys SSL Labs results as of 24th May 2021)

This only covers part of the story. It is important that customers are handling keys securely once they have obtained them. Our LoRaWAN Key Management system means you do not even need to attempt to store keys yourself, if you need them again just login to our system at any time. However, it’s still important to make sure that when you are loading keys into whatever LoRaWAN platform you use, that it is secure itself. Feel free to speak to us for recommendations.

Lastly, it’s worth talking about the standardisation of a secure method of device provisioning and key distribution that the https://lora-alliance.org/ have worked on. This involves manufacturers (or potentially distributors such as ourselves) to operate Join Servers which handle the authentication of devices into any LoRaWAN Network Server. It decouples the authentication and encryption setup process from the Network Server and Application Servers meaning the LNS itself does not need to even know the keys anymore. This will add a whole new level of security to LoRaWAN and is a worthwhile addition to the protocol. But it relies on hardware changes to devices, widespread implementation of LoRaWAN 1.1 on devices and servers and adoption by network providers and manufacturers. So we feel that it will come but it will be some time in the future when all LoRaWAN devices and services are using it. Certainly once it is viable outside of the laboratory, we will be offering it to our customers and we lobby manufacturers to accelerate adoption of new specifications such as this.

The Alliot KMS service is available to any customers buying LoRaWAN devices from us. Please Contact Us to get started.

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.