LoRaWAN Security
LoRaWAN is a long-range yet low-power (Low Power, Wide Area - LPWA) network protocol designed to wirelessly connect battery-powered devices to the local or global Internet and provide key requirements for the Internet of Things (IoT - Internet of Things) such as bidirectional communication, connection security, mobility, etc.
Security is a top priority for any IoT development. The LoRaWAN specification defines two levels of cryptographic protection:
- a unique 128-bit Network Session Key common to the terminal device and network server;
- unique 128-bit application session key (AppSKey - Application Session Key) common end-to-end at the application level.
AES algorithms are used to provide authentication and packet integrity in a network server and for end-to-end encryption at the application server level. Providing these two levels allows you to implement multi-tenant shared networks, where the network operator does not have the ability to see user payload data.
Keys can be activated through personalization (ABP - Activated By Personalization) on the production line or during commissioning, or can be activated through the network (OTAA - Over-The-Air Activated) in the field. The OTAA activation method allows the device to change keys as needed.
Security FAQs
Where are the LoRaWAN protocol security mechanisms described?
All protection mechanisms are described in the specifications of the LoRa Alliance, which can be downloaded on their website. At the moment, you can download release 1.0.x and these answers are based on it. Under development is release 1.1.
How does the LoRa Alliance specification secure LoRaWAN networks?
LoRaWAN supports original authentication, integrity, and replay protection across the entire MAC (Media Access Control) frame. It also allows end-to-end encryption of the application payload between the terminal and its response on the network side (called the application server in release 1.1). LoRaWAN supports an operation mode that allows you to encrypt MAC commands.
All of these procedures rely on the AES Advanced Encryption Standard and use 128-bit cryptographic keys and algorithms.
Are there any differences between the ABP and OTAA modes in terms of information security?
LoRaWAN uses static root keys and dynamically generated session keys.
Root keys are provided only in OTAA devices. They are used to obtain session keys when the OTAA terminal performs the Join Procedure. A terminal device in OTAA mode, when installed in the field, can connect to any network that has an output to a key server (in Release 1.1, Join a server) with which the terminal device is connected. Session keys obtained in this way are already used by terminal devices to protect air traffic.
ABP devices do not use root keys. Instead, they are provided with a set of session keys for a pre-selected network. Session keys remain unchanged throughout the life of the ABP device.
The ability to change session keys makes OTAA devices more suitable for applications requiring a higher level of security.
What is the identity of LoRaWAN?
Each terminal device is identified by a 64-bit global unique number (EUI - Extended Unique Identifier), which is assigned either by the manufacturer or by the owner of the terminal device. Assignment of EUI numbers requires the assignor to have a unique OUI (Organizationally Unique Identifier) from the IEEE registration authority.
Each Join server that uses terminal authentication is also identified by a 64-bit global EUI, which is assigned either by the owner or operator of this server.
Open LoRaWAN networks and private networks that “communicate” with open LoRaWANs are identified by a 24-bit unique identifier assigned by the LoRa Alliance.
When the terminal device has successfully connected to the network, it receives the 32-bit temporary address assigned by the network.
Can I assign numbers to my devices or networks randomly?
Not. The previous question described the assignment rules for each type of identifier. If you do not follow these rules, then there may be a coincidence of numbers and unpredictable behavior during the deployment of your network (similar to what might happen if you use the same Ethernet MAC addresses on different devices connected to the same LAN).
Do all terminal devices that are out of production have the same “default” cryptographic key?
Not. LoRaWAN does not have the concept of a “default key” or a “default password”. All terminal devices have unique keys, even at the exit from production. Thus, a single compromised key from a terminal device will not affect other devices in any way.
What kind of cryptographic keys are used?
OTAA endpoints have root keys called AppKeys (Application Root Keys). On the network side, AppKey keys are located on the Join server, which may or may not be a network server at the same time.
ABP endpoints have two AppSKey and NwkSKey (Network Session Key) session keys. On the network side, NwkSKey is located on the network server, and AppSKey on the application server.
The procedures used to provide the listed keys with all the required network elements (terminal device, Join server, network server, application server) are outside the scope of the LoRaWAN specification.
What cryptography algorithms are used?
The AES-CMAC algorithm described in RFC4493 is used for original authentication and integrity protection. The AES-CCM algorithm described in IEEE 802.15.4-2011 is used for encryption.
How does LoRaWAN prevent you from listening?
MAC data is encrypted between the terminal device and the network at the time of transmission over the air. In addition, payload is encrypted between the terminal device and the application server (so-called end-to-end encryption). This ensures that only authorized objects that contain encryption keys can access the contents of the packet.
How does LoRaWAN prevent data spoofing?
The integrity and authentication of MAC data is protected by the packet field, which contains the Message Integrity Code (MIC) code known to the terminal device and network. This ensures that only authorized objects that contain integrity keys (i.e., terminal device and network server) can generate valid messages.
How does LoRaWAN discourage retransmissions?
MAC data integrity protection uses message counters to ensure that the recipient does not accept an already received (i.e., potentially retransmitted) message.
Does LoRaWAN support application payload protection?
LoRaWAN provides end-to-end encryption of application payloads between the terminal device and the application server. Integrity protection is provided in its hop-by-hop structure: one hop over the air through LoRaWAN integrity protection and another hop between the network server and application server using secure transmission technologies such as HTTPS and VPN. Applications requiring end-to-end integrity protection are encouraged to do the same with their payload.
How are backend interfaces protected?
Backend interfaces are involved in managing and exchanging data between network servers, Join servers and application servers. HTTPS and VPN technologies are recommended to protect the exchange of data between these critical infrastructure elements, to the same extent as it is implemented in other telecommunication systems. Backend interfaces are outside the scope of the LoRaWAN specification.
Does LoRaWAN support hardware protection?
Improving the security of terminal devices and server platforms in terms of hardware (security elements or security modules) relates to issues of equipment implementation and is not related to protocol interoperability aimed at the quality of communication, including LoRaWAN. However, the use of such technical solutions is compatible with the LoRaWAN specification and can be implemented by the developer in accordance with the requirements of the application.
What should I do if I find a security risk?
In general, a security risk can arise for one of three reasons, or combinations thereof:
- specification (for example, lack of protection against repetitions),
- implementation (for example, retrieving a key from a device),
- deployment (for example, the lack of protective screens).
The first step is to establish the cause. If the reason is in the specification, then write to the LoRa Alliance to help. For questions about the sale of equipment, contact the manufacturer.
And deployment issues are decided by LoRaWAN network operators.
A source