Security Mechanisms

In this section we will briefly discuss the following security mechanisms.

  • Replay protection
  • Eavesdropping
  • Spoofing
  • Securing communication between network elements

Replay Protection

Replay protection ensures that the receiver does not accept an already received frame.

The replay protection of the Join-request messages is protected using DevNonce. The DevNonce field is used when computing the MIC.

  • In LoRaWAN 1.0.x, DevNonce is a random value. It is used to keep track of the Join-request messages. The network server keeps track of a certain number of DevNonce values for each end device. It ignores any Join-requests that include a previously recorded DevNonce value.
  • In LoRaWAN v1.1, DevNonce is a counter starting at 0. It is used to keep track of the Join-request messages. The DevNonce value is incremented with every Join-request. The Network Server keeps track of the last DevNonce value used by the end device and ignores Join-requests if DevNonce is not incremented.

Similarly, the replay protection for the ReJoin-request messages is implemented with the RJcount0 (for ReJoin-request Type 0 or 2 messages) or RJcount1 (for ReJoin-request Type 1 messages).

Replay protection of data messages is implemented with the frame counters.

  • In LoRaWAN 1.0.x two frame counters are used to keep track of uplink and downlink messages - FCntUP and FCntDown. These two counters are stored in both the end device and the Network Server. Frame counters are initially set to 0 and incremented by the value 1 with each transmission.

  • FCntUp - keeps track of the number of data messages sent from the end device to the Network Server.

  • FCntDown - keeps track of the number of data messages sent from the Network Server to the end device.

If either the device or the network receives a message with a frame counter that is lower than the last one, the message is discarded.

  • In LoRaWAN 1.1 each end device maintains three frame counters to keep track of uplink and downlink data messages.
    • Uplink - The frame counter, FCntUp is used to keep track of the data messages sent from the end device to the Network Server.
    • Downlink - two frame counter schemes are available.
      • Single counter scheme - all ports share the same downlink frame counter FCntDown when the device operates as a v1.0 device.
      • Two-counter scheme - NFCntDown is managed by the Network Server, whereas the AFCntDown is managed by the Application Server.
        • NFCntDown is used to keep track of data messages that transports MAC commands on port 0 and when the FPort field is missing (which means no FRMPayload field).
        • AFCntDown is used to keep track of data messages on all other ports (1 - 223) when the device operates as a LoRaWAN1.1 device.

Eavesdropping

Since LoRaWAN provides two layers of security, the MAC payload is encrypted between the end device and the Network Server whereas the application payload is encrypted between the end device and the Application Server. This ensures only the authorised parties (end device, network server, application server) that hold the security keys (network session key/s and the application session key) can decrypt the payload and read the plain text content.

Spoofing

The MACPayload in the data message is origin-authenticated and integrity protected with the MIC. This ensures only the authorised parties (end device, network server, application server) that hold the security keys (network session key/s and the application session key) can generate valid data frames. Securing communication between network elements LoRaWAN uses HTTPS and VPN for securing communication among network elements such as Network Server, Application Servers, and Join Server.

Securing communication between network elements

LoRaWAN uses HTTPS and VPN for securing communication among network elements such as Network Server, Application Servers, and Join Server.