1371  Zero Trust Device Identity and Authentication

1371.1 Learning Objectives

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

• Design device identity systems using hardware-based security (TPM, secure elements, PUFs)
• Implement certificate-based authentication for IoT devices
• Explain device attestation and firmware verification processes
• Apply zero trust authentication patterns to constrained IoT devices

1371.2 Introduction

Strong device identity is the foundation of zero trust for IoT. Without reliable identification, you cannot authenticate devices, enforce policies, or monitor behavior. This chapter explores the technologies and techniques for establishing unforgeable device identities, from hardware security modules to lightweight authentication protocols for constrained devices.

1371.3 Device Identity

⏱️ ~12 min | ⭐⭐⭐ Advanced | 📋 P11.C02.U05

1371.3.1 Strong Identity Foundations

Hardware-Based Identity

The most secure device identities are rooted in hardware, making them extremely difficult to forge or clone:

1. TPM (Trusted Platform Module)
   • Dedicated cryptographic processor
   • Stores keys in tamper-resistant hardware
   • Performs cryptographic operations (signing, encryption)
   • Used in enterprise IoT devices, industrial controllers
   • Example: TPM 2.0 chips in modern industrial PLCs
2. Secure Elements
   • Isolated cryptographic chip (often on smartcards)
   • Common in payment terminals, access control systems
   • NXP, Infineon, STMicroelectronics manufacturers
   • Example: A71CH secure element in IoT gateways
3. PUFs (Physically Unclonable Functions)
   • Exploits unique manufacturing variations in silicon
   • Each chip has unique electrical characteristics
   • Cannot be cloned, even by manufacturer
   • Emerging technology in low-cost IoT devices
   • Example: SRAM PUF - power-up state of SRAM cells is unique per chip

Benefits of Hardware-Based Identity: - Keys never leave secure hardware - Resistant to software attacks and malware - Difficult to extract keys even with physical access - Can attest to firmware integrity

Challenges: - Cost: $1-5 per device (significant for low-cost sensors) - Legacy devices lack hardware security features - Complexity of provisioning and key management

1371.3.2 Certificate-Based Authentication

NoteAcademic Reference: Token-Based Authentication Flow (University of Edinburgh)

Authentication token flow showing user, resource server, and authorization server interactions

This diagram illustrates a fundamental zero trust principle: verify explicitly through token-based authentication. The user authenticates with a trusted Authorization Server and receives a token. When accessing resources, the user presents this token (never their actual credentials) to the Resource Server, which validates it with the Authorization Server. This pattern ensures:

• Credential isolation: Passwords never touch the resource server
• Centralized verification: All authentication decisions route through a trusted authority
• Token validation: Every access request can be independently verified
• Minimal trust: Resource servers don’t need to store or manage credentials

Source: University of Edinburgh - IoT Systems Security Course

X.509 Digital Certificates

The most common approach for IoT device identity uses X.509 certificates, the same standard that secures HTTPS websites.

Certificate Structure:

Certificate:
  Version: 3
  Serial Number: 4d:3f:a2:1e:9b:7c:8a:2f
  Issuer: CN=IoT Device CA, O=ACME Corp
  Validity:
    Not Before: 2025-01-01 00:00:00 UTC
    Not After: 2028-01-01 00:00:00 UTC
  Subject: CN=temp-sensor-042, O=ACME Corp
  Subject Public Key Info:
    Algorithm: EC (P-256)
    Public Key: 04:a3:7f:...
  X509v3 Extensions:
    Key Usage: Digital Signature
    Extended Key Usage: TLS Client Authentication
  Signature Algorithm: ecdsa-with-SHA256
  Signature: 30:45:...

Advantages: - Industry standard, widely supported - Hierarchical trust model (certificate chains) - Revocation mechanisms (CRL, OCSP) - Strong cryptographic properties

Implementation: - Device generates key pair (often in secure hardware) - Manufacturer signs certificate with CA (Certificate Authority) - Device presents certificate during TLS handshake - Server verifies certificate signature and validity

Alternative Approaches:

1. API Keys
   • Simpler than certificates
   • Static string (often 32-64 character hex)
   • Easier to deploy but harder to manage at scale
   • Example: api-key: 7a3f9c8e2d1b4a6f5e8d7c9b3a2f1e0d
2. JWT Tokens (JSON Web Tokens)
   • Self-contained identity claims
   • Can include permissions, expiration, device metadata
   • Signed by issuer, verified by resource server
   • Example use: OAuth2 device flow
3. Symmetric Keys
   • Pre-shared keys between device and server
   • Simpler cryptography, lower CPU requirements
   • Key distribution and rotation challenges
   • Common in constrained devices (LoRaWAN, Zigbee)

1371.3.3 Device Attestation

Device attestation proves that a device is running legitimate, unmodified firmware. This prevents attackers from compromising a device, loading malicious software, but still authenticating with valid credentials.

Attestation Flow:

%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%

sequenceDiagram
    participant Device
    participant TPM as TPM/Secure Element
    participant Server as Attestation Server
    participant Policy as Policy Engine

    Note over Device: Boot Process
    Device->>TPM: Measure bootloader
    TPM->>TPM: Extend PCR 0
    Device->>TPM: Measure OS kernel
    TPM->>TPM: Extend PCR 1
    Device->>TPM: Measure application
    TPM->>TPM: Extend PCR 2

    Note over Device,Server: Attestation Request
    Server->>Device: Request attestation
    Device->>TPM: Sign PCR values
    TPM->>Device: Signed attestation report
    Device->>Server: Attestation report + certificate

    Note over Server: Verification
    Server->>Server: Verify signature with device cert
    Server->>Server: Check PCR values against known-good

    alt Firmware Valid
        Server->>Policy: Device firmware verified
        Policy->>Server: Allow access
        Server->>Device: Access granted
    else Firmware Modified
        Server->>Policy: Device firmware compromised
        Policy->>Server: Deny access
        Server->>Device: Access denied - quarantine
    end

Figure 1371.1: TPM-Based Firmware Attestation: Boot Measurement, PCR Extension, and Verification

PCR (Platform Configuration Registers): - Special registers in TPM that track firmware measurements - Each boot stage measures the next stage and extends the PCR - Final PCR value represents the entire boot chain - If any component is modified, PCR value changes

Attestation Report Contents: - PCR values (proving firmware integrity) - Timestamp - Nonce (prevents replay attacks) - Signature (proves report came from genuine TPM)

Real-World Example: Microsoft Azure IoT Device Provisioning - Devices use TPM for hardware root of trust - Boot-time attestation generates quote signed by TPM - Azure verifies quote against expected firmware hash - Only devices with approved firmware can register - Continuous re-attestation detects runtime compromises

NoteDeep Dive: Implementing Zero Trust for Constrained Devices

Traditional zero trust implementations assume devices have sufficient computational resources for public-key cryptography, TLS 1.3 handshakes, and continuous authentication protocols. IoT devices with 64KB RAM, 8-bit microcontrollers, and battery constraints require fundamentally different approaches.

1371.3.4 Lightweight Authentication Protocols

EDHOC (Ephemeral Diffie-Hellman Over COSE) Designed specifically for constrained devices, EDHOC provides authenticated key exchange in just 3 messages totaling under 200 bytes:

Initiator → Responder: EDHOC Message 1 (32 bytes)
  - Method type, cipher suites
  - Ephemeral DH public key (X25519: 32 bytes compressed)

Responder → Initiator: EDHOC Message 2 (64 bytes)
  - Ephemeral DH public key
  - Encrypted credential + MAC

Initiator → Responder: EDHOC Message 3 (48 bytes)
  - Encrypted credential + MAC
  - Optional application data

Compare this to TLS 1.3 which requires 2-4KB for handshake messages.

Pre-Shared Key Rotation Strategies For devices that cannot perform asymmetric cryptography:

# Key Derivation Function for PSK rotation
# Uses lightweight HKDF with hardware-unique identifier
import hashlib
import hmac

def derive_session_key(master_psk, device_id, epoch_counter):
    """
    Rotate keys without full key exchange.
    Epoch counter increments on each successful authentication.
    """
    # IKM = master key || device ID || epoch
    ikm = master_psk + device_id + epoch_counter.to_bytes(4, 'big')

    # Extract phase (one HMAC operation)
    prk = hmac.new(b"zero-trust-iot", ikm, hashlib.sha256).digest()

    # Expand phase (one more HMAC)
    session_key = hmac.new(prk, b"session-key" + b"\x01",
                           hashlib.sha256).digest()[:16]

    return session_key  # 128-bit AES key

1371.3.5 Attestation Without TPM

Many constrained devices lack TPM or secure enclaves. Alternative attestation approaches:

Software-Based Attestation (SWATT) Exploits timing: legitimate firmware completes checksum in predictable time; modified firmware cannot.

// Time-bounded memory checksum for attestation
// Verifier sends random seed and expects response within strict deadline
uint32_t compute_attestation(uint8_t *seed, size_t seed_len) {
    uint32_t checksum = 0;
    uint8_t *memory_start = (uint8_t*)FIRMWARE_BASE;
    size_t memory_size = FIRMWARE_SIZE;

    // Pseudo-random traversal seeded by verifier's challenge
    srand(*(uint32_t*)seed);

    for (int i = 0; i < ATTESTATION_ITERATIONS; i++) {
        size_t offset = rand() % memory_size;
        checksum = (checksum << 1) ^ memory_start[offset];
        checksum ^= seed[i % seed_len];
    }

    return checksum;
}
// Verifier knows expected checksum and timing (e.g., 50ms ± 2ms)
// Any deviation indicates tampering or emulation

Control-Flow Attestation (C-FLAT) Monitors execution paths rather than static memory: - Hardware inserts trace instructions at basic block boundaries - Attestation report includes hash of executed path - Detects runtime attacks that modify behavior without changing code

1371.3.6 Micro-Segmentation for Resource-Constrained Networks

Standard SDN controllers and policy engines are too heavy for LoRaWAN or Zigbee networks. Lightweight alternatives:

Attribute-Based Encryption (ABE) for Access Control Encrypt resources with policies; only devices with matching attributes can decrypt:

Policy: "sensor AND (building-A OR building-B) AND firmware-v2.1+"
Ciphertext: Encrypt(data, policy)

Device attributes: {sensor, building-A, firmware-v2.3}
→ Can decrypt (attributes satisfy policy)

Device attributes: {actuator, building-A, firmware-v2.3}
→ Cannot decrypt (missing "sensor" attribute)

ABE eliminates need for central policy enforcement point—access control embedded in encryption.

Bloom Filter-Based Authorization Space-efficient permission checking for memory-constrained devices:

// 256-byte Bloom filter stores thousands of permission hashes
// False positive rate ~1% acceptable for security (fail open rarely)
#define BLOOM_SIZE 256
#define HASH_COUNT 3

uint8_t permission_filter[BLOOM_SIZE];

bool check_permission(uint8_t *device_id, uint8_t *resource_id) {
    // Combine device + resource into permission hash
    uint8_t combined[32];
    sha256_concat(device_id, resource_id, combined);

    for (int i = 0; i < HASH_COUNT; i++) {
        size_t bit_pos = hash_n(combined, i) % (BLOOM_SIZE * 8);
        if (!(permission_filter[bit_pos / 8] & (1 << (bit_pos % 8)))) {
            return false;  // Definitely not permitted
        }
    }
    return true;  // Probably permitted (check server if critical)
}

1371.3.7 Security Trade-offs for Constrained Environments

Constraint	Traditional Zero Trust	Constrained Adaptation	Security Impact
No TPM	Hardware attestation	Software-based (SWATT)	Timing attacks possible; requires tight tolerances
64KB RAM	Full TLS stack	DTLS 1.3 / EDHOC	Reduced cipher suites; smaller session cache
Battery	Continuous auth	Epoch-based tokens	Longer validity windows increase exposure
8-bit CPU	ECC-256	Curve25519 or PSK	PSK loses perfect forward secrecy
Low bandwidth	Real-time policy fetch	Cached Bloom filters	Stale permissions until sync

1371.3.8 Implementation Challenges

1. Clock synchronization: Token expiration requires synchronized clocks; NTP unavailable on many constrained networks. Solution: Use monotonic counters with loose time windows (hours, not minutes).

2. Key revocation: Cannot push revocation lists to 10,000 battery-powered sensors. Solution: Short-lived credentials (hours) that require periodic check-in.

3. Bootstrapping: How does a brand-new device establish initial trust? Solution: Manufacturer provisioning with unique device certificates, or PAKE (Password-Authenticated Key Exchange) during physical installation.

4. Fallback behavior: What happens when authentication server unreachable? Critical safety systems may need pre-authorized emergency modes with audit logging.

Zero trust for constrained IoT requires creative engineering that balances security guarantees against device limitations—accepting some degradation in exchange for practical deployability.

1371.4 Worked Example: Token-Based Authentication for LoRaWAN

NoteWorked Example: Implementing Token-Based Authentication for LoRaWAN Sensor Network

Scenario: An agricultural IoT company deploys 5,000 soil moisture sensors across 200 farms using LoRaWAN connectivity. The sensors must authenticate to a cloud platform to upload readings and receive configuration updates. Due to LoRaWAN’s limited payload size (51-222 bytes) and battery constraints (10-year lifespan on 2xAA batteries), traditional certificate-based authentication is infeasible. Design a lightweight token-based authentication system that provides strong security within LoRaWAN constraints.

Given: - 5,000 sensors with LoRaWAN Class A (uplink-focused, lowest power) - Maximum payload: 51 bytes (SF12/125kHz, worst case) - Uplink frequency: 1 message every 15 minutes (96/day) - Battery budget: 10 years on 2xAA (3000mAh total) - LoRaWAN network: Public network operator (not private) - Security requirement: Prevent sensor impersonation and data injection - Constraint: No real-time clock (RTC) on sensors (cost reduction)

Steps:

1. Design token structure for constrained payload:

   TOKEN FORMAT (32 bytes total, fits in minimum LoRaWAN payload):
   
   +--------+--------+--------+--------+--------+--------+--------+--------+
   | Device ID       | Sequence Number  | Payload Hash     | HMAC-SHA256    |
   | (4 bytes)       | (4 bytes)        | (8 bytes)        | (16 bytes)     |
   +--------+--------+--------+--------+--------+--------+--------+--------+
   
   Device ID (4 bytes):
   - Unique identifier per sensor
   - Assigned during manufacturing
   - Example: 0x7A3F2C9E
   
   Sequence Number (4 bytes):
   - Monotonically increasing counter
   - Prevents replay attacks (server rejects if seq <= last_seen)
   - Stored in non-volatile memory (survives power loss)
   - Range: 0 to 4.2 billion messages (~120 years at 96 msg/day)
   
   Payload Hash (8 bytes):
   - Truncated SHA-256 of sensor data payload
   - Binds token to specific data (prevents token reuse)
   - 8 bytes provides 64-bit collision resistance (sufficient for IoT)
   
   HMAC-SHA256 (16 bytes, truncated):
   - HMAC(device_secret, device_id || seq || payload_hash)
   - 128-bit truncated MAC (NIST approved for constrained devices)
   - Device secret: 256-bit key provisioned at manufacturing

2. Calculate authentication overhead vs battery life:

   POWER BUDGET ANALYSIS:
   
   Token computation (per message):
   - SHA-256 hash of payload: ~0.5ms @ 1mA on ARM Cortex-M0
   - HMAC-SHA256 computation: ~2ms @ 1mA
   - Total crypto overhead: 2.5ms @ 1mA = 0.0007 mAh per message
   
   Daily crypto overhead:
   - 96 messages × 0.0007 mAh = 0.067 mAh/day
   
   10-year crypto overhead:
   - 0.067 mAh × 3,650 days = 245 mAh (8.2% of 3000mAh battery)
   
   Token transmission overhead:
   - Additional 32 bytes per message
   - LoRaWAN SF12/125kHz: ~2.5 seconds per 32 bytes
   - Additional power: 2.5s × 25mA = 0.017 mAh per message
   - Daily: 96 × 0.017 = 1.6 mAh/day
   - 10-year: 5,840 mAh (EXCEEDS battery budget!)
   
   OPTIMIZATION: Use lower spreading factor when signal allows
   - SF7/125kHz: 32 bytes in 0.1 seconds
   - Reduces transmission overhead to 234 mAh over 10 years
   
   RESULT: Token-based auth is feasible with adaptive data rate (ADR)
   Total 10-year overhead: ~480 mAh (16% of battery) for security

3. Implement server-side token validation:

   # Cloud platform token validator
   
   class LoRaWANTokenValidator:
       def __init__(self, device_registry):
           self.device_registry = device_registry  # Redis/DB
           self.replay_window = 100  # Allow some out-of-order messages
   
       def validate_token(self, raw_message: bytes) -> ValidationResult:
           # Parse token fields
           device_id = raw_message[0:4]
           sequence = int.from_bytes(raw_message[4:8], 'big')
           payload_hash = raw_message[8:16]
           received_mac = raw_message[16:32]
   
           # Step 1: Look up device secret
           device = self.device_registry.get(device_id)
           if not device:
               return ValidationResult(valid=False, error="UNKNOWN_DEVICE")
   
           # Step 2: Verify HMAC
           expected_mac = hmac_sha256(
               key=device.secret_key,
               data=device_id + raw_message[4:8] + payload_hash
           )[:16]  # Truncate to 128 bits
   
           if not constant_time_compare(expected_mac, received_mac):
               log_security_event("INVALID_MAC", device_id)
               return ValidationResult(valid=False, error="AUTH_FAILED")
   
           # Step 3: Check replay protection (sequence number)
           if sequence <= device.last_sequence:
               # Allow small window for out-of-order delivery
               if device.last_sequence - sequence > self.replay_window:
                   log_security_event("REPLAY_ATTACK", device_id, sequence)
                   return ValidationResult(valid=False, error="REPLAY")
   
           # Step 4: Verify payload hash matches data
           # (Actual sensor data follows the token in LoRaWAN frame)
           sensor_payload = raw_message[32:]
           computed_hash = sha256(sensor_payload)[:8]
   
           if computed_hash != payload_hash:
               log_security_event("PAYLOAD_MISMATCH", device_id)
               return ValidationResult(valid=False, error="INTEGRITY")
   
           # Step 5: Update sequence number (atomic operation)
           self.device_registry.update_sequence(device_id, sequence)
   
           return ValidationResult(
               valid=True,
               device_id=device_id.hex(),
               farm_id=device.farm_id,
               payload=sensor_payload
           )

4. Design key provisioning and rotation:

   KEY LIFECYCLE:
   
   Manufacturing Provisioning:
   1. Generate unique 256-bit device secret per sensor
      device_secret = CSPRNG(256 bits)
   
   2. Store in sensor's OTP (one-time programmable) memory
      - Cannot be read via JTAG or firmware extraction
      - Set read-protect fuses after programming
   
   3. Register device in cloud platform
      device_registry[device_id] = {
          secret_key: encrypt(device_secret, master_key),
          farm_id: null,  # Assigned during installation
          last_sequence: 0,
          activated: false
      }
   
   4. Generate device QR code for field activation
      QR contains: device_id (not the secret!)
   
   Field Activation (farmer installs sensor):
   1. Farmer scans QR code with mobile app
   2. App associates device_id with farm_id in cloud
   3. Sensor sends first authenticated message
   4. Cloud marks device as activated
   
   Key Rotation (NOT SUPPORTED for deployed sensors):
   - LoRaWAN Class A cannot receive reliable downlinks
   - Design decision: 256-bit keys have >100-year security margin
   - Compromise response: Revoke device_id in cloud registry
   - Physical compromise: Replace sensor (cost: $25)

5. Define threat model and residual risks: | Threat | Mitigation | Residual Risk | |——–|————|—————| | Sensor impersonation | HMAC authentication with device secret | Key extraction via side-channel (requires physical access) | | Data injection | Payload hash binds token to data | None (integrity verified) | | Replay attack | Monotonic sequence number | Out-of-order messages within 100-message window | | Key extraction | OTP storage with read-protect fuses | Invasive chip decapping (expensive, destroys device) | | Cloud compromise | Device secrets encrypted with HSM master key | HSM compromise (extremely difficult) | | Network eavesdropping | LoRaWAN provides AES-128 encryption | None (encrypted at network layer) |

Result: - 5,000 sensors authenticated with 32-byte tokens - Battery impact: 16% of 10-year capacity (acceptable overhead) - No real-time clock required: Sequence numbers replace timestamps - Replay protection: Server-side sequence tracking rejects duplicates - Provisioning: One-time manufacturing setup, no field key exchange - Revocation: Cloud-side device blacklist (instant effect)

Key Insight: For severely constrained devices like LoRaWAN sensors, the traditional PKI approach (certificates, signatures) is impractical due to payload size and computational overhead. HMAC-based authentication with pre-shared keys provides equivalent security guarantees at a fraction of the cost. The sequence number replaces timestamps (which require RTCs that drain batteries), while the payload hash prevents token reuse across different data. The 256-bit device secret provides a 100+ year security margin, making key rotation unnecessary for the device’s operational lifetime. This pattern is applicable to any low-power, low-bandwidth IoT deployment where certificate-based auth would exceed resource constraints.

1371.5 Summary

Device identity is the foundation of zero trust security:

1. Hardware-based identity (TPM, secure elements, PUFs) provides the strongest security guarantees with unforgeable device credentials.

2. Certificate-based authentication using X.509 certificates is the industry standard, with alternatives like API keys and JWT tokens for different use cases.

3. Device attestation proves firmware integrity, preventing attackers from using valid credentials on compromised devices.

4. Constrained devices require adapted approaches including lightweight protocols (EDHOC), pre-shared keys, and software-based attestation.

1371.6 Related Chapters

NoteExplore Related Topics

Zero Trust Series: - Zero Trust Fundamentals - Core principles and comparison with perimeter security - Zero Trust Implementation - Practical deployment steps - Zero Trust Network Segmentation - Micro-segmentation and continuous verification - Zero Trust Architecture - Complete architecture and real-world implementations

Related Topics: - Encryption Architecture and Levels - Cryptographic foundations - Device and Network Security - Securing IoT endpoints

1371.7 What’s Next

Now that you understand device identity and authentication, continue to Zero Trust Network Segmentation to learn about micro-segmentation strategies and continuous verification techniques that limit the blast radius when devices are compromised.