Security

Security is a fundamental need for any wireless network. Protecting messages from various threats such as unauthorized access, spoofing, modification, and eavesdropping are the biggest challenges. In LoRaWAN various tools and techniques are available to mitigate these threats, for example using advanced cryptographic algorithms with strong keys for protecting payloads by encrypting and computing message integrity code, using fields such as JoinNonce and NbTrans to prevent replay attacks, using frame counters for both uplink and downlink messages etc.

LoRaWAN Network Servers are fully compliant with the latest LoRaWAN specifications. In this article we will take a look at some major security implementations in LoRaWAN for protecting messages.

Security implementation

LoRaWAN uses the Advanced Encryption Standard (AES) combined with several modes of operations. The Cipher-based Message Authentication Code (CMAC) mode is used for integrity protection of messages and Counter (CTR) mode is used for encryption of payloads.

Each LoRaWAN device is personalized with two unique 128 bit AES keys (AppKey and NwkKey) known as root keys and a EUI-64-based globally unique identifier (DevEUI). In addition to that the JoinEUI is required to be stored in the end-device. The JoinEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the Join Server that is able to assist in the processing of the Join-request message and the session keys derivation.

The join procedure of an end-device is securely handled by the Join Server. The same set of root keys (AppKey and NwkKey) are provisioned into the Join Server for generating AES-128 symmetric session keys to enable secure transmission of messages. The join procedure proves that both the end device and the Join Server have the knowledge of root keys.

Protecting the join procedure

The join procedure involves two MAC messages to be exchanged between the end device and the Join Server. The Join-request message is protected by Message Integrity Code (MIC) computed using the NwkKey and then sent to the Join Server. The Join Server is used the same NwkKey to compute the MIC of the received Join-request message to validate the message authenticity. The Join-accept message is encrypted by NwkKey and then the MIC is computed by JSIntKey.

If the end-device is permitted to join with the network, the Join Server will generate three network session keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey) using the NwkKey and the application session key (AppSKey) using the AppKey. In addition to that two specific lifetime keys (JSIntKey and JSEncKey) are derived from the NwkKey root key.

The join-accept message is encrypted by the NwkKey and its MIC is calculated by JSIntKey. Then the join-accept message is sent to the end-device.

The Join Server distributes the FNwkSIntKey, SNwkSIntKey, and NwkSEncKey to the Network Server in order to prove and verify the message authenticity and integrity. Also, the AppSKey is distributed to the Application Server in order to encrypt and decrypt the application payloads. The AppKey and AppSKey are not made visible to the network operator so that it is not able to decrypt the application payloads.

Using the join-accept and two root keys, the end-device generates session keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey, and AppSKey) that are identical to the session keys generated by the Join Server.

Encrypting MAC commands and Application payloads

The derived session keys are used to encrypt and decrypt application payloads and MAC commands of all the uplink and downlink data messages for ensuring message confidentiality.

An application payload (also known as application-specific data) can be sent in the frame payload (FRMPayload) field of a data message. Application payloads are always end-to-end encrypted between the end-device and the Application Server. The AppSKey is used by both the end-device and the Application Server to encrypt and decrypt the application payload.

A sequence of MAC commands can be sent either in the frame options (FOpts) field or frame payload (FRMPayload) field of a data message, but not both simultaneously. MAC commands are always sent encrypted between the end-device and the Network Server. The NwkSEncKey is used by both the end-device and the Network Server to encrypt and decrypt the MAC commands.

The FRMPayload field CAN NOT contain MAC commands and application payload simultaneously.

Furthermore, the message integrity code (MIC) is calculated over all the fields in a data message and then added to the message itself. The MIC ensures the integrity of the data message and provides protection against packet tampering.

The FNwkSIntKey and SNwkSIntKey are used to compute MIC for all uplink data messages while the SNwkSIntKey is used to compute MIC for all downlink data messages.

Each data message carries a frame counter to avoid packet replay.