26  LoRaWAN Security & Activation

In 60 Seconds

LoRaWAN security relies on AES-128 dual-layer encryption (NwkSKey for network integrity, AppSKey for application privacy) and frame counters to prevent replay attacks. The critical production rule: always use OTAA activation because it regenerates session keys on each rejoin, while ABP’s static keys mean a power outage resets the frame counter and causes all subsequent packets to be rejected.

Most Valuable Undergraduate (MVU) Takeaway

The single most important concept: LoRaWAN security depends on OTAA activation and frame counters. ABP activation creates a critical vulnerability where power outages cause devices to reset their frame counter, leading to packet rejection. Always use OTAA for production deployments - it generates fresh session keys after each rejoin, eliminating frame counter reset issues and preventing replay attacks.

Interview-ready statement: “LoRaWAN uses AES-128 encryption with separate network and application session keys. OTAA is essential for production because it regenerates keys after device reboots, while ABP’s static keys make frame counter resets a security and reliability disaster.”

Hey kids! Let’s learn about LoRaWAN security with the Sensor Squad!

Sammy the Sensor says: “Imagine you’re sending secret messages to your friend across a big field. You need THREE things to stay safe!”

The Three Security Secrets:

  1. A Special Codebook (AppKey) - Only you and your friend know the secret code
  2. A Counting Number (Frame Counter) - Like numbering your messages: “This is message #5, #6, #7…”
  3. A Magic Stamp (MIC) - Proves the message really came from you

Lila the LED explains OTAA vs ABP:

  • OTAA (Over-The-Air Activation) = Like getting a NEW codebook every time you start playing
    • “Hey friend, let’s make up NEW secret codes today!”
    • Super safe because old codes don’t work anymore
  • ABP (Activation By Personalization) = Like using the SAME codebook forever
    • If you forget what number you were on, your friend ignores your messages!
    • Not as safe for important stuff

Max the Motor asks: “What happens if the power goes out?” - With OTAA: You get new codes, start fresh at message #1 - all good! - With ABP: You forget your message number, friend says “You already sent #1!” - messages rejected!

Remember: Always use OTAA for real projects - it’s like getting a fresh codebook every day!

This section covers LoRaWAN security mechanisms and activation methods:

Two Activation Methods:

Method Keys Security Best For
OTAA Generated per session Dynamic, more secure Production deployments
ABP Pre-configured Static, simpler Testing only

Key Security Concepts:

  • Frame Counter: Prevents replay attacks
  • MIC (Message Integrity Code): Validates packet authenticity
  • AES-128 Encryption: Protects payload data

26.1 Learning Objectives

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

  • Contrast Activation Methods: Evaluate OTAA vs ABP trade-offs in terms of security, reliability, and operational cost
  • Diagnose Frame Counter Issues: Identify and resolve ABP frame counter reset vulnerabilities after power outages
  • Design Secure Deployments: Select and justify appropriate key management and activation configurations for production
  • Analyze MIC Errors: Explain why FCnt mismatches produce “invalid MIC” errors and trace the root cause

26.2 Prerequisites

Before this section, complete:

26.3 OTAA vs ABP: Activation Method Comparison

26.3.1 Over-The-Air Activation (OTAA)

OTAA is the recommended activation method for production deployments:

OTAA Parameters:

  • DevEUI: 64-bit unique device identifier
  • AppEUI (JoinEUI): 64-bit application identifier
  • AppKey: 128-bit AES root key (never transmitted)

Derived Session Keys:

  • AppSKey: Application session key (encrypts payload)
  • NwkSKey: Network session key (validates MIC)

OTAA Join Procedure:

OTAA join procedure sequence diagram with four steps: Device sends Join Request containing DevEUI and AppEUI, Network Server validates credentials and derives session keys, Network Server sends Join Accept with DevAddr and network configuration, Device derives NwkSKey and AppSKey from AppKey and nonces

OTAA join procedure sequence showing Device sending Join Request with DevEUI, AppEUI to Network Server, Network Server deriving session keys and sending Join Accept with DevAddr and network settings, Device deriving NwkSKey and AppSKey from AppKey

26.3.2 Activation By Personalization (ABP)

ABP uses pre-configured keys - simpler but less secure:

ABP Configuration:

  • DevAddr: 32-bit device address (hardcoded)
  • NwkSKey: Network session key (hardcoded)
  • AppSKey: Application session key (hardcoded)

ABP Limitation: Keys never change unless manually reprogrammed.

26.3.3 OTAA vs ABP Comparison

Side-by-side comparison showing OTAA activation path with DevEUI, AppEUI, AppKey leading to dynamic NwkSKey and AppSKey generation versus ABP activation with pre-programmed static DevAddr, NwkSKey, and AppSKey hardcoded at manufacturing

Comparison diagram showing OTAA activation with dynamic session key generation from AppKey versus ABP activation with pre-configured static DevAddr, NwkSKey, and AppSKey that never change
Aspect OTAA ABP
Keys Generated per session Pre-configured, static
Security Dynamic, more secure Static, vulnerable
Power Outage Auto-rejoin, fresh keys FCnt reset, packets rejected
Setup Requires join procedure Immediate, no join
Use Case Production deployments Lab testing only

26.3.4 Quick Check: OTAA vs ABP

26.4 Quiz: ABP Frame Counter Vulnerability

Why OTAA Solves the Problem:

After power outage with OTAA:

1. Device reboots (power restored)
2. Device doesn't have session keys (lost in RAM)
3. Device sends Join Request
4. Network server generates NEW session keys:
   - New AppSKey (different from previous)
   - New NwkSKey (different from previous)
5. Network server resets expected FCnt to 0 (legitimate new session)
6. Device starts with FCnt=0 using NEW keys
7. All packets accepted (new session, new keys, FCnt=0 is expected)

Security with OTAA:

Old captured packets (before power outage):
- Encrypted with old AppSKey
- MIC calculated with old NwkSKey
- Device now uses NEW AppSKey and NEW NwkSKey

Attacker tries to replay old packet:
- Packet MIC calculated with old NwkSKey
- Network server validates with NEW NwkSKey
- received_mic (old key) != expected_mic (new key)
- Packet rejected (invalid MIC)

Result: Replay attack prevented
Old packets useless after device rejoins

Why Other Options Are Wrong:

B: Add Battery Backup

  • Partial solution, doesn’t address root cause
  • Cost: $5-12 per device x 10,000 = $50,000-$120,000
  • Doesn’t help with long outages or firmware resets
  • Still vulnerable to replay attacks

C: Reconfigure with Correct NwkSKey

  • Problem is NOT wrong key - problem is frame counter
  • Same key, different FCnt -> different MIC -> validation fails

D: Synchronize Network Server Time with NTP

  • MIC calculation doesn’t use timestamps
  • Only uses: keys, frame counter, payload
  • Time synchronization completely irrelevant to MIC validation

OTAA Migration Plan:

Step 1: Update device firmware

// Old ABP configuration (remove):
// static const u4_t DEVADDR = 0x260B1234;
// static const u1_t NWKSKEY[16] = { ... };
// static const u1_t APPSKEY[16] = { ... };

// New OTAA configuration (add):
static const u1_t PROGMEM APPEUI[8] = { 0x00, 0x00, ... };
static const u1_t PROGMEM DEVEUI[8] = { 0x01, 0x23, ... };
static const u1_t PROGMEM APPKEY[16] = { 0x00, 0x11, ... };

Step 2: Register devices on network server

Step 3: Deploy updated firmware

Expected Results:

Before (ABP):

Total devices: 10,000
Devices affected by power outages: 15-20% (1,500-2,000)
Packet loss: 15-20%
Manual intervention: 167 hours after each outage
Security: Vulnerable to replay attacks

After (OTAA):

Total devices: 10,000
Devices affected by power outages: 15-20% (1,500-2,000)
Packet loss: <1% (automatic rejoin after power restoration)
Manual intervention: None (automatic)
Security: Protected against replay attacks (new keys after each join)

Real-world case study: Smart water metering deployment in Madrid: - Initial: 50,000 meters using ABP - Problem: 10-15% packet loss after storms (power outages) - Solution: Firmware update to OTAA over 6 months - Result: Packet loss reduced from 15% to 0.8% - Operational cost: Reduced by $500,000/year (eliminated manual frame counter resets)

26.5 LoRaWAN Security Architecture

The LoRaWAN security model uses a two-layer key hierarchy:

Hierarchical diagram showing AppKey at root level deriving two session keys: NwkSKey held by network server for MAC layer MIC validation and MAC commands, and AppSKey held by application server for end-to-end payload encryption, with network operator unable to decrypt application data

LoRaWAN two-layer key hierarchy showing root AppKey deriving session keys NwkSKey for network server MAC layer validation and AppSKey for application server payload decryption, ensuring network operator cannot read application data

Key Separation Principle:

  • NwkSKey: Used by network server for MAC layer validation (MIC, MAC commands)
  • AppSKey: Used by application server for payload decryption (end-to-end encryption)
  • Network operator cannot read application data (only holds NwkSKey)

26.6 Knowledge Check: Key Hierarchy

## Knowledge Check: Replay Attack Prevention {#net-lora-security-replay-quiz}

## Security Best Practices

Two-column checklist showing DO best practices: use OTAA for production, protect AppKey, monitor frame counters, implement join retry with exponential backoff, log join events, use separate applications; and DONT practices: avoid ABP for production, never disable frame counter checks, never hardcode session keys, never assume devices never reset, never share AppKey across devices

Security best practices checklist showing DO list including use OTAA, protect AppKey, monitor frame counters, implement join retry logic, and DONT list including avoid ABP in production, never disable frame counter checks, never hardcode session keys

DO:

  1. Always use OTAA for production (not ABP)
  2. Protect AppKey - never hardcode in public repositories
  3. Monitor frame counters - investigate large jumps or resets
  4. Implement join retry logic with exponential backoff
  5. Log join events - track device lifecycle
  6. Use separate applications for different security contexts

DON’T:

  1. Use ABP for production deployments
  2. Disable frame counter checks (security vulnerability)
  3. Hardcode session keys in firmware
  4. Assume devices never reset
  5. Share AppKey across multiple devices

26.7 Frame Counter Security

The frame counter (FCnt) is critical for LoRaWAN security:

Sequence diagram showing normal frame counter operation: Device sends Message 1 with FCnt=0, Network Server accepts and tracks last FCnt=0, Device sends Message 2 with FCnt=1, Network Server validates FCnt greater than last and accepts, Device sends Message 3 with FCnt=2, Network Server validates and accepts, demonstrating incrementing counter preventing replay attacks

Frame counter sequence showing normal operation with device incrementing FCnt from 0, 1, 2, 3 with each uplink transmission, and network server validating and accepting each packet in order, preventing replay attacks

Purpose:

  • Prevents replay attacks
  • Ensures packet freshness
  • Detects out-of-order delivery

Behavior:

  • Increments with each uplink/downlink
  • Network server rejects packets with FCnt <= last received
  • 16-bit counter (0-65535) with optional 32-bit extension

Key Concepts

  • End-to-End Encryption: LoRaWAN AppSKey ensures only the application server can read payload content; intermediate components (gateways, network server) cannot decrypt application data.
  • Network Authentication: NwkSKey authenticates device-to-network communication; prevents rogue device injection and ensures frame integrity.
  • Key Security: Root keys (AppKey) must be stored in secure hardware (TPM, secure element); compromise enables device impersonation and traffic decryption.
  • OTAA Advantages: Over-the-air activation provides session key freshness on each join, DevNonce prevents replay of join requests, and join server can be separate from network server.
  • ABP Risks: Activation by personalization hardcodes session keys; non-persistent frame counters allow replay attacks after device reset; avoid for security-sensitive deployments.
  • LoRaWAN 1.1 Improvements: Enhanced security in spec 1.1 including separate Forwarding Network Session Integrity Key (FNwkSIntKey), improved key hierarchy, and join server abstraction.
  • Security Monitoring: Detecting anomalies including unusual join requests, unexpected frame counter resets, abnormal traffic patterns, and unauthorized gateway connections.

Common Issues:

Symptom Cause Solution
All packets rejected after reboot ABP frame counter reset Use OTAA
Intermittent rejections Frame counter rollover Enable 32-bit FCnt
“Invalid MIC” errors FCnt mismatch Check device/server sync

26.8 Knowledge Check: Security Best Practices

## MIC Calculation Process

The Message Integrity Code (MIC) is calculated using AES-128 CMAC and includes the frame counter:

Block diagram showing MIC calculation inputs: NwkSKey, DevAddr, FCnt frame counter, Direction flag, and Message payload all feeding into AES-128 CMAC block which outputs 4-byte MIC tag appended to LoRaWAN packet for integrity verification

MIC calculation process showing inputs of NwkSKey, DevAddr, FCnt, Direction, and Message feeding into AES-128 CMAC algorithm to produce 4-byte Message Integrity Code appended to packet

Why FCnt mismatch causes “Invalid MIC”:

When the device sends a packet with FCnt=0 but the server expects FCnt=100:

  1. Device calculates MIC with FCnt=0 in the input
  2. Server calculates expected MIC with FCnt=100 in the input
  3. MICs don’t match → Server rejects packet as “Invalid MIC”

This is why the error log shows “invalid MIC” even though the real problem is the frame counter reset.

26.10 Summary

This section covered LoRaWAN security fundamentals essential for production deployments:

Key Concepts:

Topic Key Takeaway
OTAA vs ABP Always use OTAA for production – dynamic keys, automatic rejoin after power outages
Frame Counter Critical for replay attack prevention; ABP vulnerability causes 15-20% packet loss after outages
Key Hierarchy NwkSKey (network validation) vs AppSKey (payload encryption) provides end-to-end security
MIC Calculation Includes FCnt – why FCnt mismatch shows as “Invalid MIC” error
Security Best Practices OTAA + 32-bit FCnt + protected AppKey + monitoring

Production Checklist:

Common Pitfalls

LoRaWAN provides data confidentiality and integrity but doesn’t prevent DoS attacks (jamming), traffic analysis (metadata visibility), or application server compromises. Security architecture must address threats beyond the radio layer.

If a device is physically stolen or lost and later recovered, the AppKey may have been compromised. Failing to provision new unique keys on recovered devices allows potential attackers who extracted keys to continue accessing the network.

Network server logs provide visibility into protocol events but are not tamper-evident security audit trails. For security-sensitive deployments, implement application-layer logging with cryptographic timestamps independent of the network server.

LoRaWAN gateways installed in publicly accessible locations (rooftops, utility poles) can be physically accessed and modified. Secure gateway enclosures, tamper detection, and remote attestation protect against hardware-level attacks on the LoRaWAN infrastructure.

26.11 What’s Next

You have completed the LoRaWAN Comprehensive Review. Continue your learning:

Direction Chapter Focus
Overview LoRaWAN Comprehensive Review Main index page
Compare LPWAN Comparison LoRaWAN vs Sigfox vs NB-IoT
Next Protocol Sigfox Ultra-narrow-band LPWAN
Cellular NB-IoT Cellular LPWAN option