fieldtester.io

Joining and security

OTAA and ABP, the keys of a device and why a gateway cannot read your data.

OTAA and ABP

OTAA (over-the-air activation): the device joins with a join request. It needs three values:

  • DevEUI: the globally unique number of the device (16 hex characters),
  • JoinEUI (formerly AppEUI): identifies the join server,
  • AppKey: the secret key (32 hex characters).

From these, new session keys are derived at every join. OTAA is the recommended way.

ABP (activation by personalization): the session keys and the device address are fixed. The device never joins. Simpler, but less secure and error-prone when the frame counters get out of step.

Encryption

DeviceGatewayNetworkserverApplicationserverApplicationfieldtester.ioPayload encrypted with the AppSKey, end to endsigned with the network key, checked by the networksees onlyencrypted bytesthe payload isdecrypted here
The payload stays encrypted from the device to the application server. Gateway and network server see only encrypted bytes.

LoRaWAN uses AES-128 on two levels:

  • NwkSKey (several network keys in LoRaWAN 1.1): protects the message against changes; the network uses it to check that a message is genuine.
  • AppSKey: encrypts the payload end to end. Gateway and network operator see only encrypted bytes; only the application server decrypts them.

Frame counter

Every message carries a running counter (FCnt). The network discards messages with a counter it has already seen. This prevents anyone from replaying old packets.

If an ABP device restarts and begins again at 0, the network discards its messages. With OTAA the counter starts over after every join, which is correct there.