Skip to main content

Security

Introduction​

In an era where digital security is paramount, LoRaWAN emerges as a robust solution for IoT communications, offering layers of security designed to protect data integrity and confidentiality. The myDevices documentation on LoRaWAN security outlines the framework's comprehensive approach, emphasizing key management, encryption standards, and secure device authentication methods. These protocols ensure that data transmitted across networks is safeguarded against unauthorized access and manipulation, underlining myDevices' commitment to delivering secure, reliable IoT connectivity solutions.

Topology of a myDevices Network Server​

  • Devices: End Nodes or Devices are elements such as sensors or actuators, which are usually remotely located and sends or receives modulated messages to/from the gateway.
  • Gateway: Gateways are access points for end nodes. It receives messages from devices and forward them to the Network Server via MQTTS connection.
  • Network Server: The LoRa Network Server acts to eliminate duplicate packets, manages security and data rates. myDevices operates as a Network Server.
  • myDevices Platform: myDevices Platform responsible for processing messages, manage payload security, normalizes payload and performs analysis to utilize sensor data.

LoRa Alliance

Security Keys in LoRaWAN 1.0​

LoRaWAN 1.0 uses several security keys: NwkSKey, AppSKey, and AppKey. Each of these keys is 128 bits long. The protocol uses the AES-128 encryption algorithm, similar to the one used in the 802.15.4 standard.

Session Keys

When a device joins the network, it generates two session keys: AppSKey and NwkSKey. The NwkSKey is shared with the network, while the AppSKey is kept private. These keys are used throughout the session.

  • The NwkSKey is used for communication between the Node and the Network Server. It ensures message integrity through a Message Integrity Code (MIC).
  • The AppSKey is used for payload encryption and decryption. This ensures that only the sender and receiver can read the message content.

These session keys are unique for each device and session. They are regenerated for each activation in dynamically activated devices (OTAA), while they remain constant until changed in statically activated devices (ABP).

Application Key

The Application Key (AppKey) is known only to the device and the application. In dynamically activated devices, it's used to derive the two session keys during the activation process.

Frame Counters

To prevent replay attacks, frame counters (FCntUp and FCntDown) are used. They are set to 0 when a device is activated and incremented with each uplink and downlink message. Messages with a frame counter lower than the last one are ignored.

Spread Spectrum Radio Transmission

LoRa employs a technique called 'CHIRP' (Compressed High Intensity Radar Pulse) in its spread spectrum radio transmission. This technique enhances interference immunity, channel sharing, and resistance to radio reflections, providing security against operating conditions rather than surveillance resistance.

Device Activation​

End Device Activation in LoRaWAN

Every end device must be registered with a network before it can send and receive messages. This registration process is known as activation. myDevices utitlizes the OTAA method described below.

  1. Over-The-Air-Activation (OTAA): This is the most secure and recommended activation method. During this process, the device performs a join procedure with the network, where a dynamic device address is assigned and security keys are negotiated.

The join procedure varies slightly between LoRaWAN 1.0.x and 1.1.

Over The Air Activation in LoRaWAN 1.0.x

In LoRaWAN 1.0.x, the join procedure involves two MAC messages exchanged between the end device and the Network Server: a Join-request from the device and a Join-accept from the server. Before activation, the AppEUI, DevEUI, and AppKey should be stored in the end device. The same AppKey should be provisioned onto the network where the end device will register.

The join procedure is initiated by the end device, which sends a Join-request message to the network. This message includes the AppEUI, DevEUI, and a unique, random DevNonce. The Message Integrity Code (MIC) is calculated over all the fields in the Join-request message using the AppKey and added to the message.

The Network Server processes the Join-request message and, if the device is permitted to join, generates two session keys (NwkSKey and AppSKey) and the Join-accept message. The Join-accept message is then encrypted with the AppKey and sent back to the end device.

The Network Server retains the NwkSKey and distributes the AppSKey to the Application Server. The end device decrypts the Join-accept message, uses the AppKey and AppNonce to derive the two session keys, and is then activated on the Network.

Over-The-Air-Activation in LoRaWAN 1.1

In LoRaWAN 1.1, the join procedure is similar to 1.0.x but involves the Join Server. Before activation, the JoinEUI, DevEUI, AppKey, and NwkKey should be stored in the end device. The matching AppKey, NwkKey, and DevEUI should be provisioned onto the Join Server.

The join procedure is initiated by the end device, which sends a Join-request message to the network. This message includes the JoinEUI, DevEUI, and a DevNonce. The MIC is calculated over all the fields in the Join-request message using the NwkKey and added to the message.

The Network Server forwards the Join-request message to the corresponding Join Server. If the device is permitted to join, the Join Server generates all the session keys (AppSKey, FNwkSIntKey, SNwkSIntKey, and NwkSEncKey). The Network Server then generates the Join-accept message, which is encrypted with the NwkKey and sent back to the end device.

The Join Server sends the AppSKey to the Application Server and the three network session keys to the Network Server. The end device decrypts the Join-accept message, uses the AppKey, NwkKey, and JoinNonce to generate session keys, and is then activated on the Network.

Gateway Security​

myDevices LoRa Gateways are fortified through advanced security measures, including the deployment of x509 TLS certificates, which ensures encrypted communication channels. Utilizing MQTTS, a secure version of MQTT protocol, further enhances data transmission security, safeguarding against potential breaches. Additionally, robust device management protocols are in place, enabling precise control and monitoring of devices to prevent unauthorized access. These layered security features underscore myDevices' dedication to providing a secure and reliable IoT ecosystem.