LoRaWAN® Security FAQ

Issue link: https://read.uberflip.com/i/1423184

Contents of this Issue


Page 0 of 1

FREQUENTLY ASKED QUESTIONS LoRaWAN ® SECURITY 01. Where are the LoRaWAN ® security mechanisms specified? All security mechanisms are defined in the LoRa Alliance ® specifications, which can be downloaded by the public from https://lora-alliance. org/resource-hub. This FAQ is based on the LoRaWAN L2 1.0.3 specification. 02. How do the LoRa Alliance specifications ensure secure operation of LoRaWAN networks? LoRaWAN supports mutual end-point authentication, data origin authentication, integrity and replay protection. It also enables end-to- end encryption of the application payload between the end-device and its counter-part on the network side, the Application Server. LoRaWAN supports a mode of operation that allows encryption of the MAC commands. All of these procedures rely on the Advanced Encryption Standard (AES) and use 128-bit cryptographic keys and algorithms. 03. Are there any differences between the Activationby- Personalization (ABP) and Over-the-Air-Activation (OTAA) methods in terms of security? LoRaWAN uses static root keys and dynamically-generated session keys. Root keys are only provisioned in OTAA end-devices. They are used to derive session keys when the OTAA end-device executes a Join Procedure with the network. An OTAA end-device, when installed in the field, will be able to connect to any network that has an interface to the key server, the Join Server, to which the end-device is associated. Session keys are used by the end-devices to protect the over-the-air traffic. ABP end-devices are not provisioned with the root keys. Instead, they are provisioned with a set of session keys for a pre-selected network. The session keys remain the same throughout the lifetime of an ABP end-device. OTAA should be preferred over ABP for end-devices in need of higher levels of security. 04. What kind of identifiers are used in LoRaWAN? Each end-device is identified by a 64-bit globally unique identifier, DevEUI, that is assigned either by the manufacturer or the owner of the end-device. Allocation of DevEUI identifiers require the assignor to have an Organizationally Unique Identifier (OUI) from the IEEE Registration Authority. Each Join Server, which is used for authenticating the end-devices, is also identified by a 64-bit globally unique identifier, AppEUI/JoinEUI, that is assigned by either the owner or the operator of that server. Open LoRaWAN networks and private LoRaWAN networks that are collaborating (roaming) with the open networks are identified by a 24-bit globally unique identifier, NetID, assigned by the LoRa Alliance. When an end-device successfully joins a network, it gets a 32-bit ephemeral device address, DevAddr, assigned by the serving network. 05. Can I randomly assign any identifier to my device or my network? No. Please see question #4 about the assignment authority for each identifier. Not following these guidelines would cause identifier collision and unpredictable behavior in your network deployment (similar to what happens when using the same Ethernet MAC address on multiple devices attached to the same LAN). 06. Are all end-devices equipped with the same "default" cryptographic key when leaving the manufacturer? No. There is no concept of a "default key" or a "default password" in LoRaWAN. All end-devices are required to be equipped with unique keys when they leave the manufacturer. As a consequence, any compromise of a key from one end-device will not have an impact on other end- devices. 07. What kind of cryptographic keys are used? An OTAA end-device is provisioned with a root key called the Application Root Key (AppKey). On the network side, AppKey is provisioned on the Join Server, which may or may not be co-located with the Network Server.

Articles in this issue

Links on this page

view archives of FAQ - LoRaWAN® Security FAQ