Blog

LoRaWAN: New Security for a New Network

Low Power Wide Area Networks (LPWANs) are emerging to address Internet of Things applications where devices are distributed over a wide area. Think agriculture and smart cities.

The LoRa (Long Range) Alliance is a leading industry alliance to develop specifications and have a certification program to guarantee interoperability for LPWAN. The LoRa Alliance specifies end-to-end symmetric encryption between end devices and servers. However, the LoRa security model does not define best practices for key management: key generation, storage, and migration of device keys.

In this post we look at the LoRaWAN™ security model, examine potential threats and how to mitigate those threats.

LoRaWAN Network

A LoRaWAN operates in a star topology in the 868 MHz and 900 MHz ISM bands with data rates of 0.3 kbps to 50 kbps over several kilometers. LoRa devices include the set of low power sensors that collect data in the field. LoRa devices communicate with LoRa gateways, which send data to network server and onto an application server accessible by owners of LoRa devices. See the diagram below.

LoRaWAN Security Model

LoRa specifies two types of symmetric session keys for security that are unique to each LoRa device. The NwkSkey is used for network layer message integrity from the LoRa device to LoRa network server. The AppSkey is used for application layer end-to-end AES-128 encryption from the LoRa device to the application server. See the diagrams below.

There are two ways for LoRa devices to join the network. The first is Over-the-Air Activation (OTAA). The LoRa device and network server are first provisioned with a 128-bit AppKey. When the LoRa device is first powered a join-request is sent to the LoRa network server. The AppKey is used to create a message integrity code (MIC) on a number of parameters including device ID and a device nonce. The server checks the MIC with the AppKey. If valid the LoRa network server generates two new 128-bit device keys: the app session key (AppSKey) and the network session key (NwkSKey). The keys are sent back to the LoRa device using the AppKey as an encryption key. The LoRa device decrypts and installs the session keys.

The second method is Activation by Personalization (ABP). In this case the LoRa device is provisioned with session keys NwkSkey and AppSkey. This could be done in a manufacturing environment, for example. These LoRa devices can begin communicating with the LoRa network server.

LoRa Network Threats & Mitigation

Once LoRa devices are provisioned with unique session keys, there should be no way for a man-in-the-middle attack that would affect data integrity or confidentiality. There are other threats at a system level that should be considered.

ABP Key Provisioning: Activation by Personalization (ABP) calls for creating session keys for the LoRa device, possibly at manufacturing. In that case, session keys have to be injected into the device and securely transported to the LoRa network server. Hardware Security Module (HSM) at the manufacturing site would be the best way to do this so that keys are not exposed during LoRa device programming.

OTAA Key Provisioning: Over-The-Air-Activation (OTAA) uses a secure process for generating session keys; however, the AppKey must be provisioned in a secure manner and securely transported to the LoRa Network Server. This could be done over HTTPS in a secure web client/server model.

Key Management: The LoRa Security model calls for symmetric encryption and authentication. Thus the same session keys must be stored in the LoRa device and on the Network/Application Server, offering two areas of vulnerability.

LoRa Device Key Storage: An attacker with access to device keys (AppKey, NwkSKey and AppSKey) can easily spoof a node, and therefore they must be stored securely. Well known side channel attacks can be used to recover these keys from memory that is not accessible via software means. Smart card chips are secure elements that have been designed for side channel protection.

Client Side Key Storage: Depending on the application server architecture, the client could be responsible for secure key storage (AppKey, NwkSKey and AppSKey). To mitigate the threat of exposure, all device keys are encrypted under a master key so they are not exposed when not in use. Clients can also employ a USB smart key to protect keying material in a physical device.

LoRa Network Server Key Storage: The Network Server is used to generate device keys for all LoRa devices. All device keys should be encrypted under master keys to mitigate threats of exposure.

Weaknesses in Key Generation: The LoRaWAN Specification V1.0 Explicitly Warns Developers About Generating Secure Network and Application Keys:

“Each device should have a unique set of NwkSKey and AppSKey. Compromising the keys of one device shouldn’t compromise the security of the communications of other devices.”

“The process to build those keys should be such that the keys cannot be derived in any way from publicly available information (like the Node address for example)”

Conclusion

A LoRaWAN offers a simple process for end-to-end sensor data confidentiality and integrity that should be interoperable among implementers and network providers. The main security risk is in key life cycle management. There are many point vulnerabilities related to session key generation, storage and transport that need careful design and implementation.

Contact TrustPoint Innovation to learn more about solutions that can help you implement and enhance the security of applications utilizing LoRa technology.