1102  LoRaWAN Review: Security Architecture and Adaptive Data Rate

1102.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain LoRaWAN Security Layers: Understand application, network, and physical layer protection
  • Compare OTAA and ABP Activation: Select appropriate activation method for production deployments
  • Implement Security Best Practices: Apply key management and frame counter protection
  • Configure ADR Settings: Optimize spreading factor and power based on link quality
  • Troubleshoot Security Issues: Diagnose common authentication and encryption problems

1102.2 Prerequisites

Required Chapters:

Related Review Chapters:

Chapter Focus
Physical Layer Review Spreading factors, modulation
Deployment Review Regional parameters, TTN, troubleshooting

Estimated Time: 15 minutes

The Challenge: LoRaWAN devices often operate unattended for years in public spaces. They transmit over radio waves that anyone can receive. How do we keep data safe?

The Solution: LoRaWAN uses multiple layers of encryption, like having: 1. A locked box (application encryption) - only you and the app can open it 2. A sealed envelope (network encryption) - proves message wasn’t tampered with 3. A secret language (CSS modulation) - hard to intercept in the first place

Simple Analogy: Think of mailing a valuable item. You lock it in a box (encryption), put it in a tamper-evident envelope (integrity check), and use a courier service that speaks a language only you understand (physical layer security).

1102.3 Security Architecture

1102.3.1 Three-Layer Security Model

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph "LoRaWAN Security Layers"
        APP["Application Layer"]
        NET["Network Layer"]
        PHY["Physical Layer"]
    end

    APP --> APPKEY["AppSKey<br/>(Application Session Key)"]
    APPKEY --> ENC1["AES-128 Encryption"]
    ENC1 --> PAYLOAD["Encrypts payload<br/>End-to-end security"]

    NET --> NWKKEY["NwkSKey<br/>(Network Session Key)"]
    NWKKEY --> ENC2["AES-128 + MIC"]
    ENC2 --> INTEGRITY["Message integrity<br/>Frame counter<br/>Prevents replay"]

    PHY --> CSS["Chirp Spread Spectrum"]
    CSS --> JAM["Interference resistant<br/>Difficult to jam"]

    APPKEY -.->|Derived from| ROOTKEY["AppKey / NwkKey<br/>(Root Keys)"]
    NWKKEY -.->|Derived from| ROOTKEY

    style APP fill:#2C3E50,color:#fff
    style NET fill:#16A085,color:#fff
    style PHY fill:#E67E22,color:#fff
    style APPKEY fill:#3498DB,color:#fff
    style NWKKEY fill:#3498DB,color:#fff
    style ROOTKEY fill:#9B59B6,color:#fff

Figure 1102.1: LoRaWAN Three-Layer Security: Application, Network, and Physical

{fig-alt=“LoRaWAN three-layer security architecture showing Application Layer with AppSKey for AES-128 payload encryption providing end-to-end security, Network Layer with NwkSKey for message integrity checking and frame counter anti-replay protection, and Physical Layer using Chirp Spread Spectrum for interference resistance. Both session keys are derived from root AppKey/NwkKey provisioned during OTAA activation.”}

1102.3.2 Key Hierarchy

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph "Root Keys (Pre-provisioned)"
        APPKEY["AppKey<br/>(128-bit)"]
        NWKKEY["NwkKey<br/>(128-bit, LoRaWAN 1.1)"]
    end

    subgraph "Join Process (OTAA)"
        JOIN["Join Request/Accept"]
        DERIVE["Key Derivation<br/>using nonces"]
    end

    subgraph "Session Keys (Per-session)"
        APPSKEY["AppSKey<br/>Encrypt payload"]
        NWKSKEY["NwkSKey<br/>MAC commands + MIC"]
        SNWKSKEY["SNwkSIntKey<br/>Uplink MIC (1.1)"]
        FNWKSKEY["FNwkSIntKey<br/>Downlink MIC (1.1)"]
    end

    APPKEY --> JOIN
    NWKKEY --> JOIN
    JOIN --> DERIVE
    DERIVE --> APPSKEY
    DERIVE --> NWKSKEY
    DERIVE --> SNWKSKEY
    DERIVE --> FNWKSKEY

    style APPKEY fill:#9B59B6,color:#fff
    style NWKKEY fill:#9B59B6,color:#fff
    style JOIN fill:#16A085,color:#fff
    style APPSKEY fill:#3498DB,color:#fff
    style NWKSKEY fill:#3498DB,color:#fff
    style SNWKSKEY fill:#3498DB,color:#fff
    style FNWKSKEY fill:#3498DB,color:#fff

Figure 1102.2: LoRaWAN Key Hierarchy: From Root Keys to Session Keys

{fig-alt=“LoRaWAN key hierarchy diagram showing root keys (AppKey, NwkKey) pre-provisioned on device, which are used during OTAA join process with nonces to derive session keys. Session keys include AppSKey for payload encryption, NwkSKey for MAC integrity, and in LoRaWAN 1.1 additional SNwkSIntKey and FNwkSIntKey for separate uplink/downlink MIC calculation.”}

1102.3.3 Security Functions by Key

Key Purpose Scope Who Has It
AppKey Root key for OTAA Permanent Device + Join Server
NwkKey Root network key (1.1) Permanent Device + Join Server
AppSKey Payload encryption Per-session Device + App Server
NwkSKey MAC integrity (MIC) Per-session Device + Network Server
DevAddr Device address Per-session Assigned during join

1102.4 Activation Methods

1102.4.1 OTAA vs ABP Comparison

Feature OTAA (Recommended) ABP (Legacy)
Security Dynamic session keys Static pre-provisioned keys
Scalability Excellent Poor (manual provisioning)
Frame Counter Reset on rejoin Must never reset
Complexity Higher (join procedure) Lower (no join)
Use Case Production deployments Testing, debugging
Key Rotation Automatic on rejoin Manual reconfiguration
Best Practice Always use OTAA Avoid in production

1102.4.2 OTAA Join Procedure

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant Device as End Device
    participant GW as Gateway
    participant NS as Network Server
    participant JS as Join Server

    Note over Device: Power on, has DevEUI + AppKey

    Device->>GW: Join Request<br/>(DevEUI, AppEUI, DevNonce)
    GW->>NS: Forward Join Request

    NS->>JS: Validate Device<br/>(Check DevEUI, AppEUI)
    JS->>JS: Generate Session Keys<br/>(AppSKey, NwkSKey)
    JS->>NS: Join Accept<br/>(Encrypted with AppKey)

    NS->>GW: Join Accept
    GW->>Device: Join Accept<br/>(DevAddr, DLSettings, NetID)

    Device->>Device: Derive Session Keys<br/>(Same as Join Server)

    Note over Device,JS: Both now have matching<br/>AppSKey and NwkSKey

    Device->>GW: First Uplink<br/>(Encrypted with session keys)
    GW->>NS: Forward (decrypts MAC)
    NS->>JS: Forward (decrypts payload)

Figure 1102.3: LoRaWAN OTAA Join Procedure with Key Exchange

{fig-alt=“OTAA join procedure sequence diagram showing device sending Join Request with DevEUI and DevNonce to gateway, which forwards to network server. Network server consults join server to validate device and generate session keys. Join Accept returns encrypted with AppKey containing DevAddr and settings. Device independently derives same session keys from AppKey and nonces. Both ends now share matching AppSKey and NwkSKey for encrypted communication.”}

1102.4.3 Security Best Practices

WarningCritical Security Requirements
  1. NEVER reuse frame counters - Leads to replay attacks and data decryption
  2. Always use OTAA in production - ABP is only for testing
  3. Protect AppKey/NwkKey - Never hardcode in source code or transmit unencrypted
  4. Monitor for anomalies - Unexpected join requests, frame counter resets
  5. Secure key storage - Use hardware secure elements when available
  6. Regular key rotation - Force rejoin periodically for long-lived devices

1102.4.4 Frame Counter Protection

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    subgraph "Frame Counter Operation"
        SEND["Device sends packet<br/>FCntUp = 100"]
        RECEIVE["Network receives<br/>FCntUp = 100"]
        CHECK{"FCntUp > last seen?"}
        ACCEPT["Accept packet<br/>Update: last = 100"]
        REJECT["Reject packet<br/>Possible replay attack"]
    end

    SEND --> RECEIVE
    RECEIVE --> CHECK
    CHECK -->|Yes| ACCEPT
    CHECK -->|No| REJECT

    subgraph "Problems"
        RESET["Device resets FCnt to 0"]
        BLOCK["All packets rejected<br/>until rejoin"]
    end

    RESET --> BLOCK

    style SEND fill:#16A085,color:#fff
    style ACCEPT fill:#27AE60,color:#fff
    style REJECT fill:#E74C3C,color:#fff
    style RESET fill:#E74C3C,color:#fff
    style BLOCK fill:#E74C3C,color:#fff

Figure 1102.4: Frame Counter Anti-Replay Protection Mechanism

{fig-alt=“Frame counter operation showing device sends packet with FCntUp=100, network checks if FCntUp is greater than last seen value. If yes, packet is accepted and counter updated. If no (indicating potential replay), packet is rejected. Problem scenario shows device reset causing FCntUp to return to 0, blocking all future packets until device rejoins network.”}

1102.5 Adaptive Data Rate (ADR)

1102.5.1 ADR Operation

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
    participant Device as End Device
    participant GW as Gateway
    participant NS as Network Server

    Device->>GW: Uplink (SF12, BW125, PWR14dBm)
    GW->>NS: Forward with RSSI, SNR
    NS->>NS: Analyze link quality<br/>RSSI: -95dBm, SNR: +10dB
    NS->>NS: Good margin!<br/>Can optimize
    NS->>GW: Downlink: ADR Command
    GW->>Device: Set SF10, PWR11dBm
    Note over Device: Faster transmission<br/>Lower power<br/>Better battery life
    Device->>GW: Next uplink (SF10, PWR11dBm)
    GW->>NS: Monitor performance
    NS->>NS: Still good margin<br/>Continue optimizing
    NS->>GW: Downlink: Set SF9, PWR11dBm
    GW->>Device: Further optimization

    Note over Device,NS: ADR continuously adapts<br/>based on link budget

Figure 1102.5: LoRaWAN Adaptive Data Rate Optimization Sequence

{fig-alt=“LoRaWAN Adaptive Data Rate sequence diagram showing iterative optimization. Device initially transmits at conservative SF12 with 14dBm power. Network Server analyzes received RSSI (-95dBm) and SNR (+10dB), determines good margin exists, and commands device to use faster SF10 with lower 11dBm power. Device benefits from faster transmission and lower power consumption. Network Server continues monitoring and further optimizes to SF9, demonstrating continuous adaptation to link conditions.”}

1102.5.2 ADR Algorithm Logic

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    START["Receive 20 uplinks<br/>with ADR flag set"]
    CALC["Calculate average<br/>SNR margin"]
    MARGIN{SNR Margin<br/>above threshold?}

    MARGIN -->|Sufficient| OPTIMIZE
    MARGIN -->|Insufficient| INCREASE

    subgraph OPTIMIZE["Optimize (Lower SF/Power)"]
        OPT1["Reduce TX power first"]
        OPT2["Then reduce SF"]
        OPT3["Until margin = threshold"]
    end

    subgraph INCREASE["Conservative (Raise SF/Power)"]
        INC1["Increase SF first"]
        INC2["Then increase TX power"]
        INC3["Until reliable"]
    end

    OPT3 --> SEND["Send ADR command<br/>in downlink"]
    INC3 --> SEND

    style START fill:#2C3E50,color:#fff
    style CALC fill:#16A085,color:#fff
    style MARGIN fill:#2C3E50,color:#fff
    style SEND fill:#E67E22,color:#fff

Figure 1102.6: ADR Algorithm Decision Flow

{fig-alt=“ADR algorithm flow showing network server collects 20 uplinks with ADR flag, calculates average SNR margin. If margin is sufficient, optimization reduces TX power first, then SF, until margin equals threshold. If margin is insufficient, SF is increased first, then TX power, until reliable. Final settings are sent as ADR command in downlink.”}

1102.5.3 ADR Benefits and Considerations

Aspect Benefit Consideration
Battery Life Optimize for minimum airtime Requires stable RF conditions
Network Capacity More devices per gateway Not suitable for mobile devices
Data Rate Maximize when possible May degrade with interference
Coverage Adapt to changing conditions Requires downlink reception
Deployment Automatic optimization Manual override for special cases

1102.5.4 When to Disable ADR

ImportantADR Is Not Always Appropriate

Disable ADR for: - Mobile devices - Link conditions change faster than ADR can adapt - Unstable RF environments - Interference causes rapid fluctuations - Critical applications - Need guaranteed delivery, not optimization - Devices without downlink - Cannot receive ADR commands

For these cases, manually configure a conservative SF/power setting.

1102.6 Knowledge Check: Security and ADR

Question 1: What is a major security advantage of OTAA over ABP activation?

Explanation: B. OTAA performs a join to derive fresh session keys, whereas ABP relies on static pre-provisioned keys.

Question 2: What happens if a device’s frame counter resets to zero?

Explanation: B. Frame counter reset is a critical security violation. Network servers reject any frame counter less than or equal to previously seen values to prevent replay attacks. Device must rejoin to reset counter legitimately.

Question 3: Which key is used to encrypt application payload?

Explanation: C. AppSKey (Application Session Key) encrypts payload end-to-end from device to application server. Network server cannot decrypt payload, only MAC commands. AppKey is root key, not session key.

Question 4: In a production deployment of 10,000 devices, why is OTAA strongly preferred over ABP?

Explanation: C. Provisioning 10,000 devices with ABP requires manually entering DevAddr, NwkSKey, AppSKey for each device. Static keys cannot be rotated. Frame counter management is complex. OTAA scales via automated join with only DevEUI/AppKey per device.

Question 5: In which situation is ADR (Adaptive Data Rate) often a poor choice and commonly disabled?

Explanation: B. ADR assumes relatively stable link conditions; mobility can cause the chosen data rate/SF to lag behind real conditions.

Question 6: A device has RSSI of -100 dBm and gateway sensitivity is -137 dBm. The link margin is:

Explanation: A. Link margin = Received Power - Sensitivity = -100 - (-137) = 37 dB. This excellent margin allows ADR to reduce SF and/or TX power, improving battery life and network capacity.

1102.7 Summary

This chapter reviewed LoRaWAN security architecture and Adaptive Data Rate:

  • Three Security Layers: Application (AppSKey encrypts payload), Network (NwkSKey for integrity), Physical (CSS for interference resistance)
  • Key Hierarchy: Root keys (AppKey/NwkKey) derive session keys (AppSKey/NwkSKey) during OTAA join
  • OTAA vs ABP: OTAA provides dynamic keys and scalable provisioning; ABP uses static keys and is only for testing
  • Frame Counters: Monotonically increasing counters prevent replay attacks; resets cause packet rejection
  • ADR Operation: Network server analyzes link quality and commands devices to optimize SF and TX power
  • ADR Limitations: Not suitable for mobile devices or unstable RF conditions

1102.8 What’s Next

Continue your LoRaWAN review:

Prerequisites: - LoRaWAN Overview - Core concepts - Architecture & Classes Review - Network topology

Deep Dives: - LoRaWAN Comprehensive Review - Full technical review - LoRaWAN Quiz Bank - Practice questions