Wiki / Protocols

LoRaWAN

The network and security layer above LoRa. Two AES-128 keys stand in for TLS, so LoRaWAN security is a key-management problem: reused AppKeys, static ABP keys, and replayable joins.

lorawan lora otaa abp appkey nwkskey appskey chirpstack iot
LoRaWAN roles and keys
Network Server (NwkSKey)
Application Server (AppSKey)
Gateway (no keys)
End device (AppKey + session keys)
In LoRaWAN the gateway is a dumb packet forwarder that holds no per-device keys. The Network Server checks the frame MIC with the NwkSKey; the Application Server decrypts the payload with the AppSKey. Both session keys derive from a root key (the AppKey in 1.0.x), so leaking that one key breaks integrity and confidentiality for the device.

LoRaWAN is the network and security layer that most deployments run on top of the LoRa radio. Keep the split straight: LoRa is the physical layer (the chirp modulation), LoRaWAN is the MAC, the roles, and the AES-128 key hierarchy that stands in for TLS. Because RF secrecy is no defense (a cheap SDR hears every frame for kilometres), LoRaWAN security is entirely a key-management problem.

What it is

LoRaWAN defines four roles. Note that the gateway holds no per-device secrets: it is a dumb forwarder that bridges the air to the servers over IP.

Role Example Holds
End device a water meter, a sensor root key(s) + derived session keys
Gateway a rooftop antenna nothing per-device (packet forwarder)
Network server ChirpStack NS NwkSKey, checks the frame MIC, routes
Application server ChirpStack AS AppSKey, decrypts the payload

Devices are identified by a 64-bit DevEUI, join a network under an AppEUI/JoinEUI, and get a DevAddr once active. LoRaWAN 1.0.x has exactly two session keys, both AES-128: the NwkSKey protects frame integrity (the MIC over the whole frame), and the AppSKey protects payload confidentiality (FRMPayload). Every uplink and downlink carries a frame counter (FCntUp/FCntDown) that is the anti-replay guard for a session.

Why it matters

There are two ways a device gets its session keys, and each has a distinct weakness:

  • OTAA (Over The Air Activation) derives fresh NwkSKey/AppSKey from a join exchange (a JoinRequest answered by a JoinAccept) rooted in the AppKey. The join carries a DevNonce; if the network server does not track it, a captured JoinRequest can be replayed to force a re-key or deny service. And if the AppKey is reused across a fleet or shipped in plaintext firmware, one teardown compromises every device.
  • ABP (Activation By Personalization) burns static session keys straight into the device, with no join at all. If those keys leak or are reused, an attacker can decrypt and forge that device indefinitely.

LoRaWAN 1.1 hardens this (it splits the root into NwkKey/AppKey, adds a JoinNonce, and introduces separate network integrity keys), but 1.0.x is still the fleet in the field. Leak the session keys (or the root key they derive from) and both layers fall: you read payloads and forge frames with a valid MIC.

How to work it

Capture happens on the radio; the crypto work happens on the keys. Match the LoRa PHY first (see the lora entry), then:

  1. Receive frames with an SDR and a LoRa decoder:
# RTL-SDR receive around 868 MHz (EU), demodulate with gr-lora / SDRangel
  1. Inspect joins and uplinks. A JoinRequest exposes DevEUI/JoinEUI/DevNonce; an uplink exposes DevAddr and the frame counter. Wireshark has a LoRaWAN dissector.
  2. With a key, decrypt. Load a NwkSKey+AppSKey (or an ABP device's static keys, or keys derived from a recovered AppKey) into the dissector or lorawan-parser to read the plaintext payload.
  3. Replay or forge. Where the server does not track the DevNonce, replay a captured JoinRequest; a stand-in for the air (a ChirpStack lab over an MQTT transport) lets you push frames without a real radio.

Pitfalls

  • LoRaWAN is not LoRa. A Flipper or CC1101 can replay a dumb sub-GHz remote but cannot demodulate LoRa CSS, and neither touches the LoRaWAN key layer. Attacking the crypto needs captured frames plus the keys.
  • The frame counter is the anti-replay control. A compliant server rejects a repeated or lower FCntUp; replay works only where counters are unchecked or reset (a known ABP failure mode).
  • DevNonce replay only works against a server that does not track it. LoRaWAN 1.0.4 / 1.1 servers track it and reject the replay.
  • Regional duty-cycle limits (notably 1% in EU868) constrain legal transmit time; jamming and flooding cross legal lines fast. The lab replaces the air, so nothing you do there transmits.

Further reading