1085 LoRaWAN Quiz: Activation and Security

1085.1 Learning Objectives

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

Compare OTAA vs ABP: Understand security trade-offs between activation methods
Diagnose Frame Counter Issues: Identify and resolve MIC validation failures
Prevent Replay Attacks: Implement proper session key management
Design Secure Deployments: Apply best practices for production LoRaWAN networks

Prerequisites

Before attempting this quiz, you should be familiar with:

LoRaWAN Overview - Activation procedures
LoRaWAN Architecture - Security architecture
Device Security - IoT security concepts

For Beginners: Quiz Navigation

This is Part 4 of 5 in the LoRaWAN Quiz Bank series.

Quiz	Focus Area
1. Fundamentals	Misconceptions, class selection
2. Battery Optimization	Battery life calculations
3. Network Scalability	Collision analysis, ADR
4. Activation & Security	OTAA vs ABP (You are here)
5. Regional Deployment	EU868, US915 configuration

Return to the Quiz Bank Index for the complete overview.

1085.2 Quiz Questions

Question 1: A smart water metering company deploys 10,000 LoRaWAN meters using ABP activation. After 6 months, they experience intermittent packet rejection (15-20% loss), but signal quality is good. Investigation reveals that packet loss correlates with power outages. The network server logs show “invalid message integrity code (MIC)” errors. What is the root cause and proper solution?

Explanation: This demonstrates the ABP frame counter reset vulnerability and why OTAA is required for production:

From the text - ABP Frame Counter Reset Warning:

“ABP Frame Counter Reset: A Replay Attack Vulnerability

Activation By Personalization (ABP) has a critical security flaw if not implemented correctly:

The problem: - LoRaWAN uses frame counters (FCnt) to prevent replay attacks - Network server rejects packets with FCnt lower than expected - If device resets (power cycle, crash), FCnt resets to 0 - Network server still expects higher FCnt -> all packets rejected”

Problem Analysis:

ABP Activation:

Pre-configured (hardcoded in device):
- DevAddr: 32-bit device address
- NwkSKey: Network session key (validates MIC)
- AppSKey: Application session key (encrypts payload)

These keys NEVER change (unless manually reprogrammed)

Frame Counter Behavior:

Normal operation:

Boot -> FCnt = 0
Message 1 -> FCnt = 1 (Network server expects FCnt >= 1)
Message 2 -> FCnt = 2 (Network server expects FCnt >= 2)
...
Message 1000 -> FCnt = 1000 (Network server expects FCnt >= 1000)

After power outage (ABP devices):

Device reboots -> FCnt resets to 0
Message 1001 -> FCnt = 0 (sent with FCnt=0)

Network server validation:
- Expected: FCnt >= 1000
- Received: FCnt = 0
- Decision: REJECT (security violation: frame counter went backwards)

Error logged: "invalid message integrity code (MIC)"

Why “invalid MIC” error?

Message Integrity Code calculation:

MIC = aes128_cmac(
    NwkSKey,  // Network session key
    MHDR | DevAddr | FCnt | FCtrl | FPort | FRMPayload
)

Network server MIC validation includes frame counter: - Device MIC calculated with FCnt=0 - Server validates expecting FCnt=1001 - MIC values differ -> “Invalid MIC” error

Why Packet Loss Correlates with Power Outages:

Total devices: 10,000
Packet loss: 15-20% (1,500-2,000 devices affected)
Correlation: Power outages

Hypothesis: 15-20% of devices lost power
These devices rebooted -> FCnt reset to 0
Network server rejects all packets from these devices

Proper Solution: Switch to OTAA Activation

OTAA Join Procedure:

Device->>Gateway: Join Request (DevEUI, AppEUI, DevNonce)
Gateway->>Network Server: Join Request
Network Server->>Join Server: Join Request
Join Server->>Join Server: Verify AppKey, Generate New Session Keys
Join Server->>Network Server: Join Accept + AppSKey + NwkSKey
Network Server->>Gateway: Join Accept (encrypted with AppKey)
Gateway->>Device: Join Accept
Device->>Device: Derive AppSKey and NwkSKey from AppKey
Note: Fresh session keys, FCnt resets to 0 (legitimate)

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 - Battery eventually depletes - Firmware bugs can still reset FCnt - Doesn’t prevent replay attacks (same session keys forever) - Cost: $5-12 per device x 10,000 = $50,000-$120,000

C: Reconfigure with Correct NwkSKey - Misunderstands the problem - NwkSKey IS correct (from initial ABP provisioning) - Problem is wrong frame counter, not wrong key - Same key + different FCnt = different MIC

D: Synchronize Network Server Time with NTP - Completely irrelevant - MIC calculation doesn’t use timestamps - LoRaWAN frame format has no timestamp field - Receive windows use relative timing, not wall-clock time

Production Deployment Best Practices:

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

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

Migration Results (Expected):

Before (ABP):

Packet loss: 15-20%
Manual intervention: 167 hours after each outage
Security: Vulnerable to replay attacks

After (OTAA):

Packet loss: <1% (automatic rejoin after power restoration)
Manual intervention: None (automatic)
Security: Protected against replay attacks (new keys after each join)

Question 2: Your LoRaWAN network server logs show a device with DevAddr 0x260B1234 sending packets with frame counters: 100, 101, 102, 50, 51, 52. The network server accepts all packets. What security vulnerability does this indicate, and what is the correct remediation?

Explanation: This demonstrates the security risk of disabled frame counter validation:

Frame Counter Purpose:

LoRaWAN uses frame counters (FCnt) to prevent replay attacks:

Legitimate sequence: 100, 101, 102, 103, 104...
Replay attack: Attacker captures packet 102, replays it later
With FCnt check: Server expects 105+, rejects replayed 102
Without FCnt check: Server accepts any FCnt value

Observed Behavior:

Packet 1: FCnt = 100 (accepted)
Packet 2: FCnt = 101 (accepted)
Packet 3: FCnt = 102 (accepted)
Packet 4: FCnt = 50 (accepted) <- PROBLEM: 50 < 102
Packet 5: FCnt = 51 (accepted)
Packet 6: FCnt = 52 (accepted)

Analysis: - FCnt dropped from 102 to 50 (backwards) - Server accepted all packets - This indicates frame counter check is DISABLED

Why This Is a Security Vulnerability:

Replay Attack Scenario:

T=0: Attacker captures packet (FCnt=100, "Water usage: 0 liters")
T=1 week: Device has sent FCnt up to 1000
T=1 week: Attacker replays captured packet (FCnt=100)

With FCnt check disabled:
- Server accepts FCnt=100 (no validation)
- Application sees "Water usage: 0 liters"
- Customer charged incorrectly

With FCnt check enabled:
- Server expects FCnt > 1000
- FCnt=100 rejected (too low)
- Replay attack prevented

Common Reasons FCnt Check Gets Disabled:

ABP device resets frequently
- Device reboots -> FCnt resets to 0
- Proper packets rejected (FCnt too low)
- “Solution”: Disable FCnt check
- Real solution: Use OTAA
Testing/development convenience
- Developers testing with same ABP credentials
- Each reflash resets FCnt to 0
- Disable FCnt to avoid re-provisioning
- Forgotten when deploying to production
Misunderstanding FCnt purpose
- Think FCnt is for ordering, not security
- Disable when packets arrive out of order
- Actually, out-of-order is rare in LoRaWAN

Why Other Options Are Wrong:

A: “Frame counter wrap around”

LoRaWAN 1.0: 16-bit FCnt (max 65535)
LoRaWAN 1.1: 32-bit FCnt (max 4 billion)

Wrap around behavior:
- FCnt reaches 65535
- Next packet: FCnt = 0
- Server expects this transition
- BUT: 102 -> 50 is NOT a wrap around (50 < 65535)

For wrap around:
- Would see: 65533, 65534, 65535, 0, 1, 2
- Not: 100, 101, 102, 50, 51, 52

C: “Confirmed uplinks with server-side FCnt reset”

Confirmed uplinks:
- Device sends with "ACK requested" flag
- Server responds with ACK in downlink
- Server tracks FCntUp (device) and FCntDown (server)

Server-side reset:
- Only resets server's FCntDown
- Never resets client's FCntUp expectation
- Doesn't explain accepting 50 after 102

No legitimate scenario causes accepting lower FCnt

D: “Multi-gateway deduplication”

Multi-gateway scenario:
- Device transmits once
- Multiple gateways receive same packet
- Network server receives duplicates
- Deduplication merges identical packets

Deduplication behavior:
- All duplicates have SAME FCnt (e.g., all show 102)
- Server accepts first, ignores duplicates
- Does NOT cause accepting different FCnt values

Deduplication doesn't explain: 100, 101, 102, 50, 51, 52
(These are clearly different transmissions, not duplicates)

Correct Remediation:

Step 1: Enable frame counter validation

// The Things Network device settings:
{
  "mac_settings": {
    "resets_f_cnt": false,
    "supports_32_bit_f_cnt": true
  }
}

// ChirpStack device profile:
{
  "supportsJoin": true,
  "skipFCntCheck": false  // <- Must be false
}

Step 2: Migrate to OTAA

// 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:
static const u1_t APPEUI[8] = { ... };
static const u1_t DEVEUI[8] = { ... };
static const u1_t APPKEY[16] = { ... };

Step 3: Monitor for replay attempts

def on_uplink(device, packet):
    if packet.fcnt < device.last_fcnt:
        alert(f"Replay attack detected: {device.id}")
        alert(f"Expected FCnt > {device.last_fcnt}, got {packet.fcnt}")
        # Log for security investigation
        security_log.write(device, packet, "REPLAY_ATTEMPT")

Security Impact of Disabled FCnt Check:

Attack Type	With FCnt Check	Without FCnt Check
Replay old data	Blocked	Vulnerable
Inject false readings	Blocked	Vulnerable
Denial of service (FCnt confusion)	Limited	Full
Session hijacking	Mitigated	Possible

1085.3 Visual Reference Gallery

Visual: LoRaWAN Topic Review Concepts

LoRaWAN topic review diagram summarizing key concepts including spreading factors, duty cycle, ADR, OTAA vs ABP, and regional parameters.

LoRaWAN Topic Review

Key LoRaWAN concepts for quiz preparation, including OTAA vs ABP comparison.

1085.4 Summary

This chapter covered activation and security concepts for LoRaWAN deployments:

OTAA vs ABP Trade-offs: Why OTAA is mandatory for production security
Frame Counter Vulnerabilities: Understanding MIC validation and replay prevention
Security Best Practices: Protecting against replay attacks with proper configuration
Troubleshooting: Diagnosing “invalid MIC” errors related to frame counter resets

1085.5 What’s Next

Continue to the Regional Deployment Quiz for EU868 vs US915 configuration and international roaming scenarios.

Other quiz chapters: - Fundamentals Quiz - Misconceptions and class selection - Battery Optimization Quiz - Battery life calculations - Network Scalability Quiz - Collision analysis and ADR