1436  E1: Link Layer Encryption

Prerequisites: Encryption Architecture Overview

This enables: E2: Device-to-Gateway Encryption | IoT Devices and Network Security

1436.1 Learning Objectives

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

• Understand E1 Link Layer Encryption: Explain how device-to-device encryption protects local wireless communications
• Implement AES-CCM for IoT: Configure AES-128-CCM authenticated encryption for constrained devices
• Recognize Shared Key Vulnerabilities: Identify the blast radius of shared network key compromise
• Select Appropriate Security Levels: Choose IEEE 802.15.4 security levels based on application requirements

1436.2 Introduction to E1 Link Layer Encryption

Time: ~10 min | Level: Intermediate | Unit: P11.C08.U02

E1 (Link Layer) encryption protects device-to-device communications at the MAC layer, preventing external devices from joining the network and reading packet contents.

Figure 1436.1: Device to device encryption (E1)

Purpose: Prevent external devices from joining the network and watching packet contents.

Characteristics:

• All nodes share a common pre-shared key
• Implemented at the link layer (MAC)
• AES-128 encryption
• Hardware-accelerated in radio chipset
• Ensures privacy and confidentiality

WarningShared Key Vulnerability

E1 uses a single shared key for all devices—if any one device is compromised, the attacker can decrypt all network traffic. Never rely on E1 alone for security. Always combine with E2 (device-specific keys) to provide defense-in-depth. If a node is compromised, it can only read its own data, not the entire network’s communications.

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22'}}}%%
flowchart LR
    subgraph Node1["Sensor Node A"]
        Data1[Sensor Reading]
        Key1[Shared Network Key<br/>AES-128]
        Enc1[Encrypt at<br/>Link Layer]
    end

    subgraph Network["Wireless Network"]
        Packet[Encrypted Packet]
    end

    subgraph Node2["Router/Gateway"]
        Dec2[Decrypt at<br/>Link Layer]
        Key2[Shared Network Key<br/>AES-128]
        Data2[Sensor Reading]
    end

    Attacker[External Device<br/>No Key]

    Data1 --> Enc1
    Key1 -.-> Enc1
    Enc1 --> Packet
    Packet --> Dec2
    Key2 -.-> Dec2
    Dec2 --> Data2
    Packet -.->|Blocked| Attacker

    style Node1 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style Node2 fill:#2C3E50,stroke:#16A085,stroke-width:2px,color:#fff
    style Network fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
    style Attacker fill:#E74C3C,stroke:#2C3E50,stroke-width:2px,color:#fff

Figure 1436.2: E1 link layer encryption flow showing sensor node encrypting packet with AES-128 shared network key, transmitting over wireless link to router which decrypts with same shared key

1436.3 Common Misconception: “E1 Link Layer Encryption is Enough”

WarningWhy E1 Alone Fails

Misconception: “If my Zigbee network uses AES-128 encryption (E1), my IoT devices are secure and I don’t need additional encryption layers.”

Why This Fails: E1 often relies on a shared network key across many devices. If an attacker recovers that key from one compromised device (e.g., physical access, debug interface, or insecure commissioning), the consequences can scale to the whole network:

• Passive decryption: previously captured traffic becomes readable
• Impersonation risk: any device holding the shared key can mimic another device
• Large blast radius: one device compromise can expose many devices’ traffic

Vulnerability	Impact	Mitigation
Shared Key Extraction	Any single device compromise exposes all traffic	Add E2 (unique per-device keys)
No Device Authentication	Cannot verify which device sent data	Add E2 (device signatures)
Passive Eavesdropping	Attacker with key can silently monitor forever	Add E3 (end-to-end encryption)
Insider Threat	Gateway operator can read all device data	Add E3 (encrypt beyond gateway)

Correct Approach: Defense in Depth

Modern IoT security requires layered encryption:

• E1 (Link): Prevents casual eavesdropping and unauthorized network access
• E2 (Device-Gateway): Unique keys per device—compromise of one doesn’t expose others
• E3 (Device-Cloud): End-to-end protection even through untrusted gateways
• E5 (Key Renewal): Periodic key rotation limits damage from past compromises

Minimum Security Standard: Always combine E1 + E2, or use E1 + E3 if gateways are untrusted. Single-layer encryption is a single point of failure.

questionModule = await import("https://ngcharithperera.github.io/iotclass/assets/js/inline-knowledge-checks.js")

InlineKnowledgeCheck1 = {
  const question = {
    id: "encrypt_e1_shared_key_vulnerability",
    question: "You manage a Zigbee smart home network with 50 devices (sensors, lights, locks) all sharing a single AES-128 network key for E1 link-layer encryption. An attacker physically steals one smart bulb and extracts its firmware, recovering the shared network key. What is the MOST severe immediate consequence of this compromise?",
    options: [
      "The attacker can only control the stolen bulb remotely - other devices remain secure because each has unique identifiers",
      "The attacker can decrypt all past and future network traffic from all 50 devices, impersonate any device, and inject malicious commands",
      "The attacker can monitor the network traffic but cannot decrypt it because Zigbee uses per-packet randomized initialization vectors (IVs)",
      "The network automatically detects the compromise when the stolen device stops reporting and rotates the network key, limiting exposure to 24 hours"
    ],
    correctIndex: 1,
    difficulty: "intermediate",
    feedback: {
      correct: "Correct! This demonstrates the catastrophic **blast radius** of E1 shared key compromise. Because all 50 devices use the same AES-128 network key, extracting it from one device exposes the ENTIRE network. The attacker can: 1) Decrypt all previously captured traffic (passive decryption), 2) Monitor all ongoing communications in real-time, 3) Impersonate any device by sending encrypted packets with the shared key, and 4) Inject malicious commands (unlock doors, disable alarms, manipulate sensors). This is why **E1 alone is never sufficient** - you must add E2 (unique per-device keys) so that compromising one bulb doesn't expose the smart locks.",
      incorrect: "Not quite. Option A is wrong because shared network keys mean compromising one device compromises ALL devices. Option C is incorrect because while IVs prevent predictable ciphertext, they don't protect against key extraction. Option D is wishful thinking - most IoT networks don't have automatic key rotation triggered by device absence. The correct answer is **Option B**. With the shared E1 key extracted, the attacker can decrypt ALL network traffic (past and future), impersonate any device, and inject commands."
    }
  };
  return questionModule.createMultipleChoiceWidget(question);
}

1436.4 E1 Implementation Details

Algorithm: AES-128 in CCM (Counter with CBC-MAC) mode

Key Characteristics:

Aspect	Details
Key Size	128 bits (16 bytes) - shared across all network nodes
Cipher Mode	CCM (Cipher Block Chaining with MAC) with random IV per packet
Hardware Support	Implemented in radio chipset (802.15.4, Zigbee, BLE)
Performance	~20 us encryption time per packet on dedicated hardware
Energy Cost	Minimal - hardware acceleration reduces CPU overhead

Security Properties:

• Confidentiality: External devices cannot read packet contents
• Energy Efficient: Hardware implementation preserves battery life
• Single Point of Failure: Compromise of shared key exposes all traffic
• No Authentication: Any device with key can impersonate others

Real-World Protocol Examples:

• Zigbee: AES-128-CCM at MAC layer (IEEE 802.15.4)
• Bluetooth LE: AES-128-CCM for link encryption
• Thread: AES-128-CCM with network-wide key
• LoRaWAN: AES-128 for network session key (NwkSKey)

1436.5 Deep Dive: AES-CCM Implementation for IoT

NoteAES-CCM Technical Details

AES-CCM (Counter with CBC-MAC) is the dominant authenticated encryption mode for constrained IoT devices. Understanding its internals helps optimize implementation.

AES-CCM Structure:

+-------------------------------------------------------------+
|                     AES-CCM Packet                          |
+----------+---------------------------+----------------------+
|  Nonce   |      Encrypted Payload    |    Auth Tag (MAC)    |
| 13 bytes |       Variable length     |       4-16 bytes     |
+----------+---------------------------+----------------------+

Nonce = [Flags(1)] + [Source Address(8)] + [Frame Counter(4)]

Implementation in C (for microcontrollers):

#include <aes.h>

// AES-CCM encryption for IoT packet
typedef struct {
    uint8_t nonce[13];
    uint8_t *payload;
    uint16_t payload_len;
    uint8_t *aad;        // Additional Authenticated Data (headers)
    uint16_t aad_len;
    uint8_t tag[8];      // 64-bit authentication tag for IoT
} ccm_packet_t;

int aes_ccm_encrypt(ccm_packet_t *pkt, const uint8_t key[16]) {
    // Step 1: Generate CBC-MAC for authentication
    uint8_t cbc_state[16] = {0};

    // Format B0 block (first block for CBC-MAC)
    cbc_state[0] = 0x49;  // Flags: Adata=1, M=3 (8-byte tag), L=2
    memcpy(&cbc_state[1], pkt->nonce, 13);
    cbc_state[14] = (pkt->payload_len >> 8) & 0xFF;
    cbc_state[15] = pkt->payload_len & 0xFF;

    // Encrypt B0 to start CBC chain
    aes_encrypt(cbc_state, key);

    // Process AAD (headers authenticated but not encrypted)
    process_aad(cbc_state, pkt->aad, pkt->aad_len, key);

    // Process payload through CBC-MAC
    for (int i = 0; i < pkt->payload_len; i += 16) {
        xor_block(cbc_state, &pkt->payload[i], MIN(16, pkt->payload_len - i));
        aes_encrypt(cbc_state, key);
    }

    // Step 2: CTR mode encryption
    uint8_t counter[16] = {0};
    counter[0] = 0x01;  // L=2 flag
    memcpy(&counter[1], pkt->nonce, 13);

    // Encrypt authentication tag with A0
    aes_encrypt(counter, key);
    xor_block(pkt->tag, cbc_state, 8);  // Extract 8-byte tag

    // Encrypt payload with A1, A2, ...
    for (int i = 0; i < pkt->payload_len; i += 16) {
        increment_counter(counter);
        uint8_t keystream[16];
        memcpy(keystream, counter, 16);
        aes_encrypt(keystream, key);
        xor_block(&pkt->payload[i], keystream, MIN(16, pkt->payload_len - i));
    }

    return 0;
}

Performance on common IoT platforms:

Platform	Clock	AES-CCM (64B)	Energy/Packet
ESP32 (HW)	240 MHz	15 us	0.9 uJ
nRF52840 (HW)	64 MHz	21 us	0.5 uJ
STM32L4 (SW)	80 MHz	180 us	3.6 uJ
ATmega328P (SW)	16 MHz	2.5 ms	75 uJ

Nonce management (critical for security):

// WRONG: Reusing nonces breaks CCM security completely
static uint8_t nonce[13];  // Don't do this!

// RIGHT: Unique nonce per packet
typedef struct {
    uint64_t source_addr;  // 8 bytes: unique per device
    uint32_t frame_counter; // 4 bytes: increment each packet
    uint8_t security_level; // 1 byte: constant
} nonce_t;

void generate_nonce(nonce_t *n, uint64_t device_id, uint32_t *counter) {
    n->source_addr = device_id;
    n->frame_counter = (*counter)++;  // NEVER reuse!
    n->security_level = 0x05;  // ENC-MIC-32
}

Security level options (IEEE 802.15.4):

Level	Auth Tag	Encryption	Overhead	Use Case
0x00	None	None	0 B	No security
0x01	4 B	None	5 B	Integrity only
0x05	4 B	Yes	9 B	Standard IoT
0x06	8 B	Yes	13 B	Enhanced security
0x07	16 B	Yes	21 B	Maximum security

Recommendation: Use security level 0x05 (4-byte tag) for constrained devices, 0x06 (8-byte tag) for gateways and critical applications.

1436.6 AES-128 vs AES-256 for IoT

InlineKnowledgeCheck2 = {
  const question = {
    id: "encrypt_e1_aes_128_vs_256",
    question: "Your team is designing a battery-powered soil moisture sensor that transmits readings every 30 minutes for 2 years (26,280 transmissions) using a 1,200 mAh battery @ 3.6V (15.6 kJ total). Hardware AES acceleration is available. AES-128 uses 0.8 mJ per encrypted packet, while AES-256 uses 1.2 mJ per packet. Security researchers estimate that breaking AES-128 via brute force would require 2^128 operations (3.4 x 10^38) taking approximately 10^18 years with all current computing power. Which AES mode should you choose?",
    options: [
      "Use AES-256 - the extra security is essential for agriculture IoT, and the 50% longer key provides future-proofing against quantum computing",
      "Use AES-128 - it provides unbreakable security (10^18 years to crack) while consuming 33% less energy, extending battery life by months",
      "Use AES-192 as a compromise - it balances security and efficiency by using 50% longer keys than AES-128 with only 25% overhead",
      "Alternate between AES-128 and AES-256 based on payload importance - use AES-256 for critical threshold alerts, AES-128 for routine readings"
    ],
    correctIndex: 1,
    difficulty: "advanced",
    feedback: {
      correct: "Excellent analysis! AES-128 is the optimal choice here. The math is clear: AES-128 security (2^128 = 3.4 x 10^38 keys) is unbreakable with current and foreseeable technology - brute-forcing would take 10^18 years. Meanwhile, AES-256's 40% overhead translates to real battery impact: 26,280 packets x 0.8 mJ = 21 kJ for AES-128 vs 26,280 x 1.2 mJ = 31.5 kJ for AES-256. For constrained IoT, the encryption algorithm is NOT the weak point - key extraction from physical devices, insecure provisioning, and lack of key rotation are far more realistic threats than brute-forcing AES-128.",
      incorrect: "Not quite. Option A (AES-256) wastes 50% more energy for negligible security benefit - breaking AES-128 would take 10^18 years. Option C (AES-192) isn't widely supported in IoT hardware accelerators. Option D (alternating algorithms) introduces unnecessary complexity. The correct answer is **Option B: AES-128**. It provides 128-bit security (2^128 combinations) which is computationally infeasible to break. For IoT, **the weak point is never the AES algorithm strength - it's key management, physical security, and rotation policies**."
    }
  };
  return questionModule.createMultipleChoiceWidget(question);
}

WarningCommon Misconception: “AES-256 is Always Better Than AES-128”

The Misconception: Longer keys are always more secure, so use AES-256 everywhere.

Why It’s Wrong:

• AES-128 provides 128-bit security (unbreakable with current technology)
• AES-256 key expansion is 40% slower
• More rounds = more power consumption
• Brute-forcing 2^128 keys would take billions of years
• For IoT, the key exchange is usually the weak point, not AES

Real-World Example:

• Sensor node with AES hardware accelerator
• AES-128 encryption: 0.5ms, 0.1mJ per block
• AES-256 encryption: 0.7ms, 0.14mJ per block
• 1000 messages/day: 100mJ vs 140mJ = 40% more energy
• Security improvement: Negligible (both practically unbreakable)

The Correct Understanding:

Key Size	Security Level	Speed	Use Case
AES-128	128-bit (sufficient)	Faster	IoT, consumer
AES-192	192-bit	Medium	Rare use
AES-256	256-bit	Slower	Government, quantum-proofing

AES-128 is secure. Use AES-256 only if regulations require it or for future quantum protection.

1436.7 Key Exchange Tradeoffs

WarningTradeoff: RSA vs ECC for IoT Key Exchange

Option A (RSA-2048/3072): Widely supported by legacy systems and cloud providers, RSA-2048 signature verification: 0.5ms on Cortex-M4 (hardware) / 50-100ms (software), key generation: 2-30 seconds on constrained MCU, key size: 256-384 bytes (public key), proven 40+ year cryptanalysis history, quantum-vulnerable (requires 4096+ bits for 2030+ security).

Option B (ECC P-256/P-384): 32-byte public key (8x smaller than RSA-2048), ECDSA signature verification: 50-100ms on Cortex-M4 without hardware acceleration, ECDH key agreement: 100-200ms software / 5-10ms with hardware, equivalent security to RSA-3072 with 256-bit ECC, newer algorithm with less cryptanalysis history, quantum-vulnerable but smaller impact on key sizes.

Decision Factors: Choose RSA when: interoperating with legacy enterprise systems (older TLS servers, PKCS#11 HSMs), hardware has dedicated RSA accelerator, certificates must be validated by existing PKI infrastructure, regulatory compliance mandates specific RSA key sizes. Choose ECC when: bandwidth-constrained networks (LoRaWAN payload limit: 51-222 bytes), battery-powered devices (ECC uses 10-20x less energy per operation), storage-constrained MCUs (<64KB flash), modern cloud IoT platforms (AWS IoT, Azure IoT Hub natively support ECC), TLS 1.3 deployments (prefers ECDHE).

WarningTradeoff: Pre-Shared Keys (PSK) vs Certificate-Based Authentication

Option A (Pre-Shared Keys): Symmetric 128-256 bit keys provisioned during manufacturing, DTLS-PSK handshake: 2 round trips (vs 4 for certificates), minimal flash footprint (~2KB for PSK stack), key per device: requires secure provisioning infrastructure, compromised device key doesn’t expose fleet (if unique per device), no certificate expiration management, vulnerable to key extraction via physical access.

Option B (Certificate-Based/PKI): X.509 certificates with RSA-2048 or ECC P-256 keys, device certificate: 500-1500 bytes storage, full TLS/DTLS handshake: 4-6 round trips (1-3 seconds on constrained devices), supports certificate revocation (CRL/OCSP), device identity verifiable by any party with CA trust, certificate expiration requires renewal infrastructure (5-10 year validity typical for IoT), enables mutual TLS (mTLS) for zero-trust architectures.

Decision Factors: Choose PSK when: ultra-constrained devices (<32KB RAM), minimizing handshake latency critical (industrial control <100ms), devices never communicate with third parties, closed ecosystem with controlled provisioning, battery life prioritized over security flexibility. Choose certificates when: devices must authenticate to multiple cloud backends, regulatory compliance requires audit trail of device identity, fleet spans multiple organizations or trust domains, zero-trust architecture mandates mutual authentication, devices have >64KB RAM and hardware crypto acceleration, certificate lifecycle management infrastructure exists.

1436.8 Summary

This chapter covered E1 link layer encryption:

• E1 Purpose: Prevents external devices from joining the network and reading packet contents using AES-128 with shared network keys
• AES-CCM: The dominant authenticated encryption mode for constrained IoT, providing both confidentiality and integrity
• Shared Key Vulnerability: A single compromised device exposes all network traffic—never rely on E1 alone
• Performance: Hardware-accelerated AES-128-CCM is extremely efficient (~15-21 us per packet on modern IoT SoCs)
• Security Levels: IEEE 802.15.4 offers configurable security from integrity-only (4B tag) to maximum security (16B tag)

1436.9 Knowledge Check

Knowledge Check: E1 Link Layer Encryption Quick Check

Concept: Understanding E1 shared key vulnerabilities and defense-in-depth requirements.

Why is E1 link layer encryption alone insufficient for IoT security?

B is correct. E1 typically uses a shared key across all network devices. If an attacker extracts this key from any single device (via physical access, debug interfaces, or insecure provisioning), they can decrypt ALL network traffic from every device. This “blast radius” problem is why defense-in-depth with E2 (per-device keys) is essential.

1436.10 What’s Next

Continue to E2: Device-to-Gateway Encryption to learn how unique per-device keys provide authentication and prevent intermediate nodes from reading data, addressing the shared key vulnerability of E1.

NoteRelated Chapters

• Encryption Architecture Overview - Five-layer encryption framework
• E2: Device-to-Gateway - Per-device keys and replay protection
• Encryption Principles - Cryptographic fundamentals
• IoT Devices and Network Security - Network-level security