86  802.15.4 Devices & Security

In 60 Seconds

IEEE 802.15.4 has two device types: FFDs (Full Function Devices) that route and coordinate with full MAC implementation, and RFDs (Reduced Function Devices) that operate as simplified leaf nodes with minimal RAM. Security uses AES-128 CCM adding approximately 14 bytes overhead per frame for encryption, authentication, and replay protection.

Key Concepts

• Device Types: PAN coordinator (root), coordinator (routing FFD), and end device (RFD or non-routing FFD)
• Association Process: Device discovery → beacon scanning → association request → coordinator approval → short address assignment
• Disassociation: Device or coordinator initiated termination of network membership; releases short address
• Security Suite: AES-128 CCM with configurable MIC length (0, 4, 8, 16 bytes) and optional encryption
• ACL (Access Control List): Optional list of authorized device addresses maintained by coordinator for access restriction
• Key Types: Master key (device-specific for key establishment), link key (pairwise), network key (shared group key)
• Replay Protection: Frame counter in auxiliary security header prevents re-sending captured frames
• Security Material: Cryptographic keys and counters; must be provisioned before network operation and protected from exposure

86.1 Minimum Viable Understanding

This quiz tests three interconnected concepts: (1) FFD vs RFD device architecture – how the 8x RAM difference between full and reduced function devices drives network topology (80-90% RFDs as leaf sensors, 10-20% FFDs as routing infrastructure); (2) frame packing efficiency – fitting multiple sensor readings into the 102-byte payload limit; and (3) AES-128 CCM security overhead – the 14-byte cost of encryption and authentication that is justified by preventing packet injection and replay attacks in safety-critical applications.

86.2 Learning Objectives

After completing this quiz section, you should be able to:

1. Contrast FFD (Full Function Device) and RFD (Reduced Function Device) capabilities, constraints, and network roles
2. Compute frame capacity and the number of transmissions required to clear an RFD buffer
3. Evaluate IEEE 802.15.4 security overhead trade-offs with AES-128 CCM encryption
4. Justify adaptive channel hopping mechanisms and blacklisting decisions in Thread networks

For Beginners: 802.15.4 Devices and Security

This quiz covers 802.15.4 device types (coordinators, routers, end devices) and security features (encryption, authentication, access control). Understanding both topics is essential because the role a device plays in the network affects what security measures it needs.

Navigation

Return to: Quiz Bank Part 1 Overview

Other Quiz Sections:

• Addressing and Network Structure
• Power and Performance Calculations
• Device Types and Security (Current)

Study Materials:

• 802.15.4 Fundamentals - Core concepts
• 802.15.4 Topic Review - Quick reference

86.3 Quiz: RFD vs FFD Device Types

Buffer Transmission Calculation:

Step 1: Analyze memory usage

Total RAM: 8 KB = 8,192 bytes
Firmware operation: 2 KB = 2,048 bytes
Available for buffer: 8,192 - 2,048 = 6,144 bytes

Sensor readings to buffer: 24 readings
Size per reading: 32 bytes
Total buffered data: 24 x 32 = 768 bytes

Verification:
768 bytes << 6,144 bytes available
Buffer utilization: 768 / 6,144 = 12.5%

Step 2: Calculate frame capacity

Maximum frame payload: 102 bytes (from IEEE 802.15.4 spec).

• Sensor reading: 32 bytes each
• Readings per frame: floor(102 / 32) = 3 readings
• Bytes per frame: 3 x 32 = 96 bytes
• Remaining in frame: 102 - 96 = 6 bytes (insufficient for a 4th reading)

Step 3: Calculate transmissions needed

Total readings: 24
Readings per frame: 3
Transmissions needed: ceiling(24 / 3) = ceiling(8) = 8 transmissions

Verification:
- First 7 frames: 7 x 3 = 21 readings (672 bytes)
- Last frame: 24 - 21 = 3 readings (96 bytes)
- Total frames: 8

86.3.1 Quick Check: Frame Packing

Frame Structure Details:

IEEE 802.15.4 frame structure:

Field	Size	Notes
PHY header	6 bytes	Preamble + SFD + length
MAC header	3-23 bytes	Depends on addressing mode
Payload	0-102 bytes	Application data
FCS	2 bytes	Frame Check Sequence (CRC)

Individual sensor reading (32 bytes):

Field	Size	Example
Patient ID	4 bytes	uint32 identifier
Timestamp	4 bytes	Unix time
Heart Rate	4 bytes	bpm
SpO2	4 bytes	Oxygen saturation %
Blood Pressure	8 bytes	Systolic/diastolic
Temperature	4 bytes	Celsius
Checksum	4 bytes	CRC/padding

Why RFDs Can’t Route:

IEEE 802.15.4 Functional Differences:

Capability	FFD	RFD
MAC layer	Complete implementation	Minimal (data TX only)
Beacon generation	Yes (if coordinator)	No
Frame routing	Yes	No
Neighbor table	Yes (10-50 entries)	No (only parent)
Network layer routing	Yes (RPL, AODV)	No
Operating modes	Coordinator, router, end device	End device only

Architectural Constraints:

1. Firmware Limitation: RFD firmware doesn’t include routing code; ROM size typically 32-64 KB (vs 128-256 KB for FFD)
2. RAM Limitation: Routing table ~50-100 bytes per neighbor; 10 neighbors = 500-1000 bytes; RFDs can’t afford this
3. Processing Limitation: Routing requires route discovery, maintenance, forwarding decisions; RFD has simple MCU (8-bit, 8 MHz)
4. Protocol Definition: IEEE 802.15.4 explicitly defines: “RFD: Intended for simple applications, talks only to FFD”

Key Insight:

RFDs are intentionally simplified devices optimized for end-node applications:

• 8 transmissions efficiently clear 24 readings (3 per frame, 94% utilization)
• RFDs can’t route because they implement only device functionality
• Network relies on FFDs (coordinators/routers) for routing infrastructure

86.4 Quiz: Security Overhead

86.5 Quiz: Channel Hopping and Interference Adaptation

86.6 Interactive: RFD Frame Packing Calculator

viewof total_ram_kb = Inputs.range([4, 64], {value: 8, step: 4, label: "Total RAM (KB)"})
viewof firmware_kb = Inputs.range([1, 8], {value: 2, step: 1, label: "Firmware overhead (KB)"})
viewof reading_bytes = Inputs.range([8, 64], {value: 32, step: 4, label: "Reading size (bytes)"})
viewof max_payload = Inputs.range([80, 102], {value: 102, step: 1, label: "Max frame payload (bytes)"})

{
  const avail_ram = (total_ram_kb - firmware_kb) * 1024;
  const max_readings = Math.floor(avail_ram / reading_bytes);
  const per_frame = Math.floor(max_payload / reading_bytes);
  const tx_needed = Math.ceil(max_readings / per_frame);
  const efficiency = (per_frame * reading_bytes / max_payload * 100).toFixed(1);
  const wasted = max_payload - per_frame * reading_bytes;

  return html`<div style="background:#f8f9fa; border-left:4px solid #3498DB; padding:16px; border-radius:4px; font-family:Arial,sans-serif;">
    <div style="display:grid; grid-template-columns:1fr 1fr; gap:10px;">
      <div><strong style="color:#2C3E50;">Available buffer:</strong> ${avail_ram} bytes (${total_ram_kb - firmware_kb} KB)</div>
      <div><strong style="color:#2C3E50;">Max buffered readings:</strong> ${max_readings}</div>
      <div><strong style="color:#2C3E50;">Readings per frame:</strong> ${per_frame} (${wasted} bytes wasted)</div>
      <div><strong style="color:#2C3E50;">Packing efficiency:</strong> ${efficiency}%</div>
      <div><strong style="color:#3498DB; font-weight:bold;">Transmissions to clear buffer:</strong> ${tx_needed}</div>
      <div><strong style="color:#2C3E50;">Total data to transmit:</strong> ${max_readings * reading_bytes} bytes</div>
    </div>
  </div>`;
}

86.7 Match: 802.15.4 Device and Security Concepts

86.8 Order: Securing an IEEE 802.15.4 Frame for Transmission

86.9 Knowledge Checks

86.9.1 Knowledge Check: RFD Memory Constraints

86.9.2 Knowledge Check: Replay Attack Prevention

86.9.3 Knowledge Check: Channel Hopping Recovery

Decision Framework: Choosing Security Level for 802.15.4 Home Automation

Context: You are designing an 802.15.4 smart home system with door locks, window sensors, and motion detectors. You must select a security level that balances payload efficiency, power consumption, and threat protection.

Step 1: Understand Security Level Options

IEEE 802.15.4 defines 8 security levels (0-7):

Level	Mode	MIC Size	Aux Header	Total Overhead	Protection
0	None	0	0	0 bytes	None
1	MIC-32	4	5-6	9-10 bytes	Auth only (32-bit)
2	MIC-64	8	5-6	13-14 bytes	Auth only (64-bit)
3	MIC-128	16	5-6	21-22 bytes	Auth only (128-bit)
4	ENC	0	5-6	5-6 bytes	Encrypt only (no auth)
5	ENC-MIC-32	4	5-6	9-10 bytes	Encrypt + auth (32-bit)
6	ENC-MIC-64	8	5-6	13-14 bytes	Encrypt + auth (64-bit)
7	ENC-MIC-128	16	5-6	21-22 bytes	Encrypt + auth (128-bit)

Auxiliary Security Header (5-6 bytes):

• Security Control: 1 byte
• Frame Counter: 4 bytes (replay protection)
• Key Identifier: 0-9 bytes (typically 0-1 for home networks)

Step 2: Threat Model for Home Automation

Threat 1: Eavesdropping (Eve listens to sensor data)

• Impact: Privacy violation (knows when you are home/away)
• Mitigation: Encryption (Levels 4-7)
• Required: Yes (Level 4 minimum)

Threat 2: Packet Injection (Mallory sends fake “unlock door” command)

• Impact: Physical security breach
• Mitigation: Message authentication (MIC)
• Required: Yes (Level 1-3, or 5-7 with encryption)

Threat 3: Replay Attack (Mallory captures and retransmits “unlock door” packet)

• Impact: Physical security breach (attack works even if encrypted)
• Mitigation: Frame counter monotonicity check
• Required: Yes (automatic with security enabled)

Threat 4: Brute-Force MIC Forgery (Mallory tries to craft valid fake packet)

• Impact: Fake commands accepted
• Mitigation: Larger MIC (longer to brute-force)
• Analysis:
  • 32-bit MIC: 2^32 = 4.3 billion attempts (feasible in hours on GPU)
  • 64-bit MIC: 2^64 = 18 quintillion attempts (infeasible)
  • 128-bit MIC: 2^128 = 3.4x10^38 attempts (astronomically infeasible)

Conclusion: Level 6 (ENC-MIC-64) is the minimum for actuator control.

Step 3: Calculate Payload Impact

Smart home sensor frame composition (door sensor example):

Field	Size	Notes
PHY Header	6	Preamble + SFD + length
MAC Header	9	Frame control + seq + PAN ID + short addresses
Security (Level 6)	14	6-byte aux header + 8-byte MIC
Payload	?	Sensor data
FCS	2	CRC

Available payload:

Max frame: 127 bytes
Overhead: 6 (PHY) + 9 (MAC) + 14 (Security) + 2 (FCS) = 31 bytes
Available payload: 127 - 31 = 96 bytes

Sensor data requirements (door sensor):

Device ID: 2 bytes (short address already in MAC header -- skip this!)
Sensor state: 1 byte (open/closed/tampered)
Battery voltage: 1 byte (0-255 = 0-3.3V scaled)
Reed switch count: 2 bytes (number of open/close cycles)
Timestamp: 4 bytes (Unix time, coordinator provides via beacon)
Total: 8 bytes (fits easily in 96-byte payload)

Payload utilization: 8 / 96 = 8.3% (plenty of headroom)

Step 4: Compare Security Levels

Level	Overhead	Available Payload	Sensor Data Fits?	Encryption	Auth Strength	Recommended?
0 (None)	0	116 bytes	Yes (8 bytes)	No	None	NEVER for home automation
1 (MIC-32)	9-10	106-107 bytes	Yes	No	Weak (GPU brute-force)	Insufficient
4 (ENC only)	5-6	110-111 bytes	Yes	Yes	No auth (packet injection)	Dangerous
5 (ENC-MIC-32)	9-10	106-107 bytes	Yes	Yes	Weak (GPU brute-force)	Marginal
6 (ENC-MIC-64)	13-14	102-103 bytes	Yes	Yes	Strong (2^64)	RECOMMENDED
7 (ENC-MIC-128)	21-22	94-95 bytes	Yes	Yes	Very strong	Also acceptable

Decision: Use Level 6 (ENC-MIC-64)

Rationale:

• 14 bytes overhead is acceptable (sensor data only needs 8 bytes)
• Provides encryption (privacy) + 64-bit MIC (infeasible brute-force)
• Frame counter prevents replay attacks automatically
• 102 bytes available payload leaves room for future features

Why not Level 7 (ENC-MIC-128)?

• 128-bit MIC provides no practical security benefit over 64-bit (2^64 is already computationally infeasible)
• Extra 8 bytes (16-byte MIC vs 8-byte) wastes bandwidth and power (longer transmission time)
• For small sensor data, the overhead difference is negligible, but Level 6 is more efficient

Step 5: Verify Power Consumption Impact

Transmission time comparison:

No security (Level 0):

Frame size: 6 (PHY) + 9 (MAC) + 8 (payload) + 2 (FCS) = 25 bytes
Transmission time @ 250 kbps: 25 x 8 bits / 250,000 bps = 0.8 ms

Level 6 (ENC-MIC-64):

Frame size: 6 + 9 + 14 (security) + 8 + 2 = 39 bytes
Transmission time: 39 x 8 / 250,000 = 1.25 ms

Power impact:

Transmit current: 12 mA
Additional TX time: 1.25 - 0.8 = 0.45 ms

Extra energy per transmission: 12 mA x 0.45 ms = 5.4 uA-ms

For 5-minute reporting interval (300,000 ms):
Average current impact: 5.4 / 300,000 = 0.000018 mA = 0.018 uA

Compared to sleep current (3 uA), this is 0.6% increase -- negligible!

Conclusion: Security overhead has almost no impact on battery life for low-duty-cycle sensors.

Step 6: Implementation Checklist

Required for Level 6 Security:

1. Key Management:
   • Pre-install network key during manufacturing OR
   • Use secure commissioning (e.g., Thread DTLS handshake, Zigbee Trust Center)
   • NEVER transmit keys in plaintext
2. Frame Counter Management:
   • Persist frame counter to non-volatile memory every 1,000 increments
   • On reboot, load counter from NVM and add 1,001 (ensures monotonicity)
   • Reset counter only when changing network key
3. Neighbor Table:
   • Store highest frame counter seen from each neighbor
   • Drop frames with counter less than or equal to stored value (replay protection)
   • Table size: 10-50 entries (80-400 bytes RAM)
4. Security Processing Pipeline:
   • On TX: Increment counter -> Build aux header -> Encrypt payload -> Compute MIC -> Append
   • On RX: Extract counter -> Check replay -> Decrypt -> Verify MIC -> Pass to app if valid

Real-World Example: Zigbee vs Thread Security Choices

Zigbee 3.0:

• Uses Level 5 (ENC-MIC-32) for most traffic
• Rationale: Legacy (backward compatibility with older devices)
• Trade-off: Accepted slightly weaker MIC for ecosystem compatibility

Thread 1.3:

• Uses Level 5 or Level 6 (ENC-MIC-32/64) depending on message type
• Link-local traffic: Level 5 (lower overhead for frequent neighbor discovery)
• Network-wide traffic: Level 6 (stronger auth for routed messages)

Your Smart Home System:

• Recommendation: Level 6 uniformly across all device types
• Simpler codebase (one security configuration)
• Future-proof (64-bit MIC will remain secure for decades)
• Performance impact is negligible for home-scale networks (< 100 devices)

---

Concept Relationships:

Core Concept	Design Constraint	Trade-off	Real-World Impact
RFD vs FFD	RAM availability (8 KB vs 128 KB)	Cost/power vs routing capability	Network topology planning: 80-90% RFDs (sensors), 10-20% FFDs (infrastructure)
Frame packing	102-byte max payload	Efficiency vs frame count	Healthcare: 3 readings/frame = 94% efficiency, 8 transmissions for 24 readings
Security overhead	14 bytes (AES-128 CCM)	Payload space vs attack prevention	88 bytes usable, but prevents injection/replay/eavesdropping
Channel hopping	PER-based blacklisting	Detection delay vs false positives	Self-healing in 30-60 seconds, < 100 ms transition impact

86.10 See Also

• 802.15.4 Review: Power Management - Sleep modes and duty cycling for RFDs
• 802.15.4 Review: Security - AES-128 CCM encryption and channel management
• 802.15.4 Fundamentals - Core standard and device types
• Zigbee Security - Security in Zigbee networks built on 802.15.4
• Addressing and Network Structure Quiz - Addressing modes and Cskip algorithm

Common Pitfalls

1. Allowing Open Association Without ACL

Default 802.15.4 association accepts any device. Without an Access Control List or upper-layer authentication, any device with the correct PAN ID can join the network. Always implement association filtering for production security-sensitive deployments.

2. Hardcoding Security Keys in Firmware

Embedding network or link keys in firmware creates a single point of compromise — anyone who extracts firmware from one device gets keys for all devices. Use secure key provisioning during manufacturing and implement key storage in secure elements or protected memory regions.

3. Confusing MIC Length With Security Level

Security level 5 = AES encryption + 4-byte MIC; level 7 = AES encryption + 16-byte MIC. A longer MIC means stronger authentication but more overhead. Specifying “maximum security” without specifying the MIC length leads to implementation inconsistencies.

4. Not Handling Coordinator-Initiated Disassociation

When a coordinator disassociates a device (e.g., due to address table full), the device must receive the disassociation notification and rescan. Devices that ignore coordinator-initiated disassociation continue transmitting frames the coordinator silently drops.

🏷️ Label the Diagram

💻 Code Challenge

86.11 Summary

This quiz section covered IEEE 802.15.4 device types and security mechanisms:

Topic	Key Concept	Practical Impact
RFD vs FFD	Device capability hierarchy	80-90% RFDs (sensors), 10-20% FFDs (routers)
Frame Capacity	102-byte max payload	3 readings per frame (94% efficiency)
Security Overhead	14 bytes (header + MIC)	88 bytes usable payload with AES-128
Channel Hopping	Adaptive PER monitoring	Self-healing in <100 ms

86.11.1 Key Formulas

Frame Packing Efficiency:

Readings per frame = floor(Max_Payload / Reading_Size)
Transmissions needed = ceiling(Total_Readings / Readings_per_Frame)
Efficiency = (Readings_per_Frame x Reading_Size) / Max_Payload

Security Overhead:

Auxiliary Header: 5-14 bytes (typically 6 bytes)
MIC: 4-16 bytes (8 bytes for MIC-64)
Total: 13-14 bytes typical
Available Payload: 102 - 14 = 88 bytes

Channel Blacklisting:

PER threshold: 50-70%
Detection window: 5 consecutive hop cycles
Recovery time: 1-2 hop intervals (30-60 seconds)
Transition impact: <100 ms (1-2 packets)

86.12 Device Type Comparison

Attribute	FFD	RFD
ROM	128-256 KB	32-64 KB
RAM	64-256 KB	8-32 KB
MCU	32-bit, 48 MHz	8-bit, 8 MHz
Roles	Coordinator, router, device	Device only
Communication	Any device	Parent FFD only
Routing	Yes	No
Cost	Higher	Lower
Power	Higher	Lower
Use case	Infrastructure	Sensors

86.13 What’s Next

Chapter	Focus
Addressing and Network Structure	Addressing modes and Cskip algorithm
Power and Performance Calculations	Battery life, GTS, variant selection
Quiz Bank Part 1 Overview	Return to main navigation
Quiz Bank Part 2	More comprehensive review questions