LoRaWAN puts security first
An LPWAN can provide an enticing target to hackers. It offers low-cost, reliable connectivity over distances of 10 km and sometimes more. This makes the networks much easier to find than private short-range WiFi and Bluetooth networks and attacks can potentially be staged from many locations.
The devices that LPWANs connect are also of high interest to malicious users. For example, smart-city systems use LPWANs to automate the collection of meter data and perform control and monitoring functions of the urban infrastructure. Systems use this data to show parking availability and control when refuse is collected. Utilities are using LPWANs to collect data from remote substations. And farmers are making use of the technology to monitor livestock and crops all day, every day.
LoRaWAN itself has emerged as the dominant open specification for LPWANs. As of 2018, there are more than 500 vendors in the LoRaWAN ecosystem with some 60 service providers operating public networks around the world.
The types of systems for which LoRaWAN is designed place a number of constraints on designers that are not found in many traditional networking technologies. Low power and low cost are essential. Some devices that need to communicate over LoRaWAN may only keep running thanks to energy harvesting. This calls for a security infrastructure that can operate efficiently and rules out more heavyweight systems that were developed for desktops and servers that access the internet. But the protocol cannot skimp on protections and weak encryption schemes. Networks and devices need to be sure when they operate on a network they are talking to legitimate systems. And they need to use proven technologies.
In contrast to some cellular communications systems, LoRaWAN implements end-to-end encryption for the application data transferred between sensor nodes and application servers. Cellular networks may encrypt data packets for transfers over the wireless part of the network. But the packets are then decrypted to plaintext when they are transferred over the operator’s core network. To provide end-to-end encryption, users need to select and manage additional security protocols such as TLS. These add an extra processing burden to the sensor node that will reduce battery life.
In creating the security mechanisms for LoRaWAN, the protocol designers decided to employ the AES cryptographic algorithms. These algorithms have been analysed by the cryptographic community for many years, are approved by NIST and have become widely adopted as reliable and effective for constrained nodes and networks.
To join a LoRaWAN network, each device must provide credentials that satisfy a network server that it is a legitimate user. Conversely, the device needs to be able to tell whether it is connected to systems for which it is designed. This ensures that only genuine and authorised devices will be connected to genuine and authentic networks.
To support these requirements, at manufacture, each LoRaWAN device is personalised with a unique 128bit AES key, known in the protocol as the AppKey. The device is also provided with a globally unique identifier, DevEUI, that is based on the IEEE EUI64 address space. Each network has its own identifier: based on a 24bit address range and managed by the LoRa Alliance.
The AppKey is central to the over-the-air activation or join procedure in LoRaWAN. It ensures that both end device and the network infrastructure can agree that they are talking to legitimate systems and so continue to bring the device onboard. To initiate the join procedure, the device issues a request that is forwarded to a Join Server that performs the initial authentication routines, such as checking the device’s AppKey. The method used to determine the validity of the AppKey is the AES cipher-based message-authentication code (CMAC) protocol.
Once the AES-CMAC has been computed and verified, the join server and device create a pair of session keys. One is the NwkSKey, which is used to protect LoRaWAN network commands; the other is the AppSKey, which encrypts the application data. The keys are distributed to the LoRaWAN network server and relevant application servers, respectively. This maintains a separation between application data and network management messages. This avoids the need to share keys with the network operator. Users can be sure packets containing application data simply pass through the LoRaWAN gateways and network routers without the risk of snooping or man-in-the-middle attacks.
All traffic sent and received by a sensor node is protected using the two session keys. The payload of each packet is encrypted using the AES counter mode (AES-CTR). This embeds a frame counter and message integrity code (MIC) computed using the NwkSKey code in the payload. The combination of protections prevents packet-replay attacks, in which a hacker inserts data in a message and retransmits it into the data stream.
Although LoRaWAN enforces security as part of its core design, a number of aspects are outside the control of the protocol designers and need to be taken care of by the applications developer or integrator. The key elements that need attention are key management and provisioning.
An important aspect of LoRaWAN security is that it uses symmetric-key cryptography. Each root key that is dedicated to a sensor node needs to be made available to a corresponding server application for the required session keys to be generated. To manage the keys that will be used by server applications and programmed into devices, the user needs to employ a key management system (KMS) that is responsible for distributing keys to systems that need them. For example, a KMS can make root keys available to the Join Server so that it can perform the required AppKey check and handle the initial session-key generation routines.
Similarly, the KMS can be responsible for providing the AppKey to each device when it is ready to be programmed during manufacture, production test or installation. To ensure high security when requests are made to the KMS, two-factor authentication or similar techniques can be employed. In a typical scenario, an end-of-line tester requests a key for each device that it probes using previously created session keys to encrypt the transaction. A second factor, such as the correct response to a challenge issued by the KMS, ensures that only the authorised tester is provided with the requested AppKey. The LoRa-Alliance defines for network service providers a back-end specification for methods to allow a Join Server to make secure requests to a user’s KMS.
Once delivered to the end device, the AppKey needs to be stored securely so that it cannot be read out and misused by a hacker who gains access to the hardware either physically or through network-based attacks. A microcontroller (MCU) with secure on-chip storage can satisfy this requirement. Alternatively, the MCU can be paired with a secure companion integrated circuit (IC) that is programmed with the AppKey and which takes care of the AES processing on behalf of the MCU. Cryptographic acceleration is also an effective hardware-based security feature to reduce transaction times significantly as well as power consumption.
With a sufficiently secure MCU, once it is programmed into on-chip flash there is no mechanism to read out the raw key. Physical protections can zero out on-chip keys if they detect an attack that shows a high risk of compromise. This ensures that the AppKey and other secure credentials cannot be stolen and misused.
Thanks to the decision to take security into account when designing the protocol, LoRaWAN’s designers have succeeded in building an LPWAN that can cope with the challenges of today’s IoT. Supported by an effective key-management infrastructure and choice of secure hardware for devices, integrators can achieve a high level of confidence that their systems are not vulnerable to hackers.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
