986  Zigbee Security Architecture

Trust Center, encryption keys, and protecting Zigbee networks

986.1 Learning Objectives

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

  • Explain the Trust Center’s role in Zigbee security
  • Distinguish between Network Keys, Link Keys, and Install Codes
  • Describe how AES-128 encryption protects Zigbee traffic
  • Identify security vulnerabilities and mitigation strategies
  • Implement secure deployment practices for Zigbee networks

986.2 Introduction

Zigbee security protects against eavesdropping, replay attacks, and unauthorized device joining. The security architecture centers on the Trust Center, which manages keys and authenticates devices. Understanding these mechanisms is essential for deploying secure IoT systems.

Think of Zigbee security like a secure office building:

  • Trust Center = Security office that issues badges
  • Network Key = Building access card (everyone has same card to enter building)
  • Link Key = Office-specific key (only certain people have access)
  • Install Code = Verification document (proves you’re supposed to be here)

When you join the company (network), you get your badge (Network Key) from security (Trust Center) after showing your ID (Install Code).

986.3 Trust Center

The Trust Center is the security manager for the entire Zigbee network:

986.3.1 Responsibilities

Trust Center Functions:
1. Authenticate joining devices
2. Generate and distribute Network Key
3. Manage Link Keys for device pairs
4. Enforce security policies
5. Update/rotate keys when needed
6. Revoke access for removed devices

986.3.2 Location

The Trust Center runs on the Coordinator by default:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#7F8C8D', 'tertiaryColor': '#ECF0F1', 'fontSize': '12px'}}}%%
flowchart TB
    subgraph TC["Trust Center (Coordinator)"]
        KeyMgr["Key Manager"]
        DevTable["Device Table"]
        Policy["Security Policy"]
    end

    R1["Router 1"]
    R2["Router 2"]
    ED1["End Device 1"]
    ED2["End Device 2"]

    TC ---|"Network Key<br/>(same for all)"| R1
    TC ---|"Network Key"| R2
    TC ---|"Network Key"| ED1
    TC ---|"Network Key"| ED2

    TC -.-|"Link Key<br/>(unique pair)"| ED1

    style TC fill:#E67E22,stroke:#2C3E50,stroke-width:3px,color:#fff
    style R1 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style R2 fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style ED1 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style ED2 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff

Figure 986.1: Trust Center on Coordinator managing security for all network devices

986.3.3 Trust Center Policies

Configurable Security Policies:

1. Join Policy:
   - Allow all (open network)
   - Allow with default TC Link Key
   - Require Install Code (high security)
   - Whitelist only (pre-authorized)

2. Key Distribution:
   - Send in clear (legacy, insecure)
   - Send encrypted (standard)
   - Require out-of-band (highest security)

3. Key Rotation:
   - Automatic periodic rotation
   - On-demand rotation
   - Never rotate (not recommended)

986.4 Encryption Keys

Zigbee uses multiple key types for layered security:

986.4.1 Network Key

The Network Key encrypts all network-layer traffic:

Network Key Properties:
- Size: 128 bits (16 bytes)
- Scope: Entire network (all devices share same key)
- Protection: Encrypts NWK layer frames
- Algorithm: AES-128-CCM

Example Network Key:
AB:CD:EF:12:34:56:78:90:AB:CD:EF:12:34:56:78:90

Usage:
- ALL traffic between ANY devices encrypted
- Broadcast messages protected
- Route discovery protected

986.4.3 Key Hierarchy

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '12px'}}}%%
flowchart TD
    subgraph Keys["Zigbee Key Hierarchy"]
        IC["Install Code<br/>(Per-device secret)"]
        TCLK["Trust Center Link Key<br/>(Derived from Install Code)"]
        NWK["Network Key<br/>(Shared network-wide)"]
        ALK["Application Link Key<br/>(Optional, device pairs)"]
    end

    IC -->|"Hash function"| TCLK
    TCLK -->|"Encrypts transport of"| NWK
    NWK -->|"Encrypts all traffic"| TRAFFIC["Network Traffic"]
    ALK -->|"Additional encryption"| APP["Sensitive App Data"]

    style IC fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style TCLK fill:#16A085,stroke:#2C3E50,stroke-width:2px,color:#fff
    style NWK fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style ALK fill:#7F8C8D,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 986.2: Zigbee key hierarchy showing derivation and protection relationships

986.4.4 Install Codes

Install Codes provide per-device security during joining:

Install Code Process:

1. Manufacturing:
   - Factory generates unique 128-bit Install Code
   - Printed on device label/QR code
   - Example: 83FE:D340:7A93:9F2B:CAFE:BABE:DEAD:BEEF

2. Deployment:
   - Admin enters Install Code into Trust Center
   - Trust Center derives unique Link Key:
     TCLK = Hash(Install Code)
   - This key ONLY known by this device and TC

3. Joining:
   - Device uses derived TCLK
   - Network Key encrypted with device-specific key
   - Attacker cannot decrypt without Install Code

Security Benefit:
- No shared/default keys
- Per-device authentication
- Cannot be intercepted over-the-air

986.5 AES-128 Encryption

Zigbee uses AES-128-CCM for authenticated encryption:

986.5.1 CCM Mode

CCM (Counter with CBC-MAC) provides:

AES-128-CCM Properties:
- Confidentiality: Message content encrypted
- Integrity: Tampering detected via MIC
- Authentication: Sender identity verified

Components:
1. Nonce: 13 bytes (frame counter + addresses)
2. Payload: Variable (actual message data)
3. AAD: Additional authenticated data (headers)
4. MIC: Message Integrity Code (4-16 bytes)

986.5.2 Frame Counter

Each device maintains frame counters to prevent replay attacks:

Frame Counter Mechanism:
- Each device has 32-bit outgoing counter
- Counter increments with every transmission
- Receiver tracks last seen counter per sender
- Frames with old counter values REJECTED

Example:
Device A sends Frame Counter = 12345
Device B accepts (12345 > last seen 12344)
Attacker replays captured frame (FC = 12340)
Device B rejects (12340 < 12345, replay detected)

986.5.3 Security Levels

Zigbee supports configurable security levels:

Level Encryption MIC Size Use Case
0x00 None None Testing only
0x01 None 4 bytes Integrity only
0x04 AES-128 None Confidential, no auth
0x05 AES-128 4 bytes Standard (Zigbee 3.0)
0x06 AES-128 8 bytes High security
0x07 AES-128 16 bytes Maximum security

Standard Zigbee 3.0: Level 0x05 (encryption + 4-byte MIC)

986.6 Security Vulnerabilities

Understanding potential attacks helps design secure systems:

986.6.1 Key Extraction Attack

Attack Vector:
1. Attacker captures traffic during device joining
2. Default TCLK ("ZigBeeAlliance09") used
3. Attacker decrypts Network Key transport
4. Now has Network Key - can decrypt all traffic

Mitigation:
- Use Install Codes (unique per-device TCLK)
- Keep Permit Join closed except when adding devices
- Monitor for unauthorized join attempts

986.6.2 Replay Attack

Attack Vector:
1. Attacker captures valid "unlock door" command
2. Later replays the same frame
3. Door unlocks again

Mitigation (built-in):
- Frame counter prevents replay
- Each frame must have higher counter
- Replayed frames rejected

Limitation:
- Frame counter is per-device, not global
- Counter reset on device rejoin could re-enable old frames

986.6.3 Coordinator Compromise

Attack Vector:
1. Attacker gains access to Coordinator
2. Extracts Network Key from memory
3. Can decrypt all network traffic
4. Can inject malicious commands

Mitigation:
- Physical security for Coordinator
- Secure boot / tamper detection
- Regular key rotation
- Intrusion detection on network

986.7 Secure Deployment Practices

986.7.1 Checklist for Secure Zigbee Deployment

Pre-Deployment:
[ ] Use Install Codes for all devices
[ ] Generate random Network Key (not default)
[ ] Configure Trust Center with strict join policy
[ ] Disable Touchlink if not needed

During Deployment:
[ ] Add devices one at a time
[ ] Open Permit Join briefly (60 seconds)
[ ] Verify correct device joined (check MAC address)
[ ] Close Permit Join immediately after

Post-Deployment:
[ ] Verify Permit Join is CLOSED
[ ] Document all device MAC addresses
[ ] Backup Coordinator configuration securely
[ ] Set up monitoring for unauthorized joins

Ongoing:
[ ] Review join logs weekly
[ ] Rotate Network Key annually (if supported)
[ ] Replace devices with security patches when available
[ ] Physical audit of device locations

986.7.2 Network Key Backup

CRITICAL: Backup these items securely

1. Network Key
   - Store in password manager or HSM
   - Do NOT store in plain text
   - Required to restore network after Coordinator failure

2. PAN ID and Extended PAN ID
   - Document for network identification

3. Device Table
   - Export from Coordinator
   - Contains all member MAC addresses

4. Install Codes
   - Keep original documentation
   - Needed if device re-joins

Storage:
- Encrypted backup file
- Separate from production network
- Access limited to administrators

986.7.3 Key Rotation

Key Rotation Process:

1. Trust Center generates new Network Key
2. Broadcasts Key Update frame (encrypted with old key)
3. All devices receive and store new key
4. Trust Center broadcasts Key Switch frame
5. All devices switch to new key atomically

Timing:
- Rotation should complete within seconds
- Devices failing to update become orphaned
- Plan for potential device re-join

When to Rotate:
- Scheduled (annual/quarterly)
- After suspected compromise
- After removing trusted device
- After employee departure (if they had access)

986.8 Green Power Security

Green Power devices have simplified security due to energy constraints:

Green Power Security Model:

Limitations:
- No bidirectional key exchange
- Limited computation capability
- Must use pre-shared keys

Security Options:
1. No security (not recommended)
   - Frame sent in clear
   - Anyone can spoof commands

2. Shared Key (default)
   - GPD and GPS share pre-configured key
   - 128-bit AES encryption
   - Key entered during commissioning

3. Device-Specific Key (recommended)
   - Unique key per GPD
   - Configured via Install Code equivalent
   - Highest GP security level

Commissioning Security:
- Proximity required (physical security factor)
- Short commissioning window
- Key exchange via secure side-channel

986.9 Summary

This chapter covered Zigbee security architecture:

  • Trust Center: Central security manager on Coordinator
  • Network Key: Shared key encrypting all network traffic
  • Link Keys: Per-device or pair-wise encryption keys
  • Install Codes: Per-device secrets for secure joining
  • AES-128-CCM: Authenticated encryption with replay protection
  • Vulnerabilities: Key extraction, replay, Touchlink attacks

Key Security Recommendations:

  1. Always use Install Codes for commercial deployments
  2. Keep Permit Join closed except during device addition
  3. Backup Network Key and configuration securely
  4. Monitor for unauthorized join attempts
  5. Rotate keys periodically
  6. Physical security for Coordinator

986.10 What’s Next

In the next chapter, Zigbee Exercises and Knowledge Checks, you can test your understanding with practice problems and interactive quizzes covering all Zigbee topics.