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.
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.
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.