27  Zero Trust Device Identity

27.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
In 60 Seconds

Device identity in zero trust IoT requires each device to cryptographically prove its identity before any network access is granted. This means provisioning unique X.509 certificates or hardware attestation keys at manufacturing, implementing certificate rotation before expiry, and continuously monitoring device behavior to detect identity compromise through behavioral anomalies.

Key Concepts

  • Device Identity: Unique, cryptographically verifiable identifier for an IoT device; typically implemented using X.509 certificates with private keys protected in secure hardware.
  • Device Certificate: X.509 digital certificate binding a device’s public key to its identity (device ID, type, manufacturer); issued by a trusted Certificate Authority during manufacturing.
  • Hardware Security Module (HSM): Dedicated cryptographic hardware that stores and protects private keys; prevents key extraction even with physical access to the device.
  • Device Attestation: Process of cryptographically proving that a device is running authentic, unmodified firmware and has not been tampered with; enables remote trust establishment.
  • Certificate Authority (CA): Trusted entity issuing and signing device certificates; in IoT, organizations often operate private CAs for internal device fleets.
  • Certificate Lifecycle Management: Processes and automation for issuing, renewing, revoking, and auditing device certificates throughout device operational lifetime.
  • Behavioral Biometrics: Device identification technique using unique RF characteristics, timing patterns, or operational signatures as secondary identity factors beyond certificates.

In a zero trust world, every IoT device must prove who it is before it can do anything on the network – like showing your ID at every door, even inside your own building. Instead of trusting devices just because they are on the local network, zero trust requires each device to have a unique, unforgeable identity backed by special hardware chips. This chapter explains how devices prove their identity using cryptographic keys stored in tamper-proof hardware, and why simple identifiers like MAC addresses are not enough.

“In zero trust, every device needs to prove its identity – every single time,” Max the Microcontroller said seriously. “And I do not mean just a password. I mean hardware-backed proof that I am the genuine Max, running authentic firmware, in a healthy state.”

Sammy the Sensor explained how it works. “I have a tiny secure chip called a TPM – Trusted Platform Module – embedded in my hardware. It stores my private key in a tamper-proof vault that nobody can extract, not even me! When I need to prove my identity, the TPM creates a cryptographic signature that proves I am genuinely Sammy, not an impostor.”

“Device attestation goes even further,” Lila the LED added. “It is not enough to prove WHO you are – you also have to prove you are HEALTHY. The device reports what firmware it is running, what software is loaded, and what its security configuration looks like. If the firmware has been tampered with or the device is not up to date on patches, access gets denied even though the identity is valid.”

“For tiny constrained devices that cannot run a full TPM, there are Physical Unclonable Functions – PUFs,” Bella the Battery explained. “A PUF uses the unique physical characteristics of a chip – tiny manufacturing variations that are impossible to clone – as a fingerprint. It is like the unique swirl pattern in a piece of wood. No two chips are identical, so no attacker can create a copy!”

27.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.

27.3 Device Identity

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

27.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

27.3.2 Certificate-Based Authentication

Sequence diagram illustrating token-based authentication in a zero trust architecture. Shows the flow: User logs into AuthServer, receives token, presents token to ResourceServer, which validates the token with AuthServer before granting access. Key security principle highlighted: user never passes credentials directly to the resource server. Source: University of Edinburgh IoT Security Course.

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)

27.3.3 Device Attestation

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

Attestation Flow:

Diagram showing four stages of TPM-based firmware attestation: boot measurement stored in PCR registers (red), PCR values extended at each boot stage (orange), remote verifier checks the PCR quote (teal), and untampered boot chain verified (blue). Illustrates the zero trust principle of never trust, always verify.
Figure 27.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

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.

27.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)

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

27.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

27.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 hundreds of permission hashes
// False positive rate ~1% with ~200 entries (higher with more entries)
#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)
}

27.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

27.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.

27.3.9 IoT Authentication Power Budget Explorer

Use this calculator to estimate the battery impact of adding HMAC-based authentication to constrained IoT devices.

27.4 Worked Example: Token-Based Authentication for LoRaWAN

Worked 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.

Identity Mechanism Best For Security Level Device Requirements Cost per Device Key Management Complexity
Hardware TPM 2.0 Enterprise IoT, industrial controllers, medical devices HIGHEST (hardware root of trust, tamper-resistant) 32-bit+ MCU, 512KB+ flash, $5+ BOM budget $3-5 HIGH (provisioning at mfg)
Secure Element Payment terminals, access control, high-value devices VERY HIGH (dedicated crypto chip, isolated) Any MCU with I2C/SPI, $2+ BOM budget $1-3 HIGH (certificate provisioning)
PUF (Physical Unclonable Function) Low-cost sensors, commodity IoT, anti-counterfeiting HIGH (unclonable silicon characteristics) SRAM-based PUF requires 8KB+ RAM $0.10-0.50 MEDIUM (enrollment at mfg)
X.509 Certificates (software) General IoT, cloud-connected devices, standard compliance MEDIUM (extractable keys via firmware dump) Crypto library support (mbedTLS, OpenSSL) $0 (PKI infra only) MEDIUM (cert renewal automation)
API Keys / Tokens Prototyping, internal systems, non-critical LOW (shared secrets, easily leaked) HTTP client capability $0 LOW (manual key distribution)
Pre-Shared Keys (PSK) Zigbee, LoRaWAN, 6LoWPAN, ultra-constrained devices MEDIUM (symmetric key, no PKI needed) AES-128 hardware (or 64KB+ flash for software) $0 VERY HIGH (secure key provisioning + rotation)

Decision Tree:

START: What's your device computational capability?

→ High-performance (ARM Cortex-A, 1GB+ RAM):
  ├─ Choose: TPM 2.0 (best security) or X.509 with software storage (cost-effective)
  └─ Use case: Industrial PLCs, smart home hubs, edge gateways

→ Medium (ARM Cortex-M, 256KB+ RAM, 48MHz+):
  ├─ Choose: Secure Element (if budget allows) or X.509 with software storage
  └─ Use case: Smart thermostats, connected appliances, medical sensors

→ Low (8-bit MCU, 32-64KB RAM, <16MHz):
  ├─ Choose: PUF (if SRAM available) or Pre-Shared Keys (if constrained network)
  └─ Use case: Battery-powered sensors, Zigbee devices, basic actuators

→ Ultra-constrained (LoRaWAN, <8KB RAM):
  ├─ Choose: Pre-Shared Keys with HMAC authentication
  └─ Use case: Agricultural sensors, environmental monitoring, long-range IoT

Risk vs Cost Trade-Off Analysis:

Threat TPM/Secure Element Defense Software Certificate Defense PSK Defense API Key Defense
Key extraction via firmware dump IMMUNE (hardware-isolated) VULNERABLE (keys in flash) VULNERABLE VERY VULNERABLE
Device cloning IMMUNE (hardware-unique) MITIGATED (cert per device) VULNERABLE (copy PSK) VERY VULNERABLE
Man-in-the-middle attack IMMUNE (mutual auth + attestation) MITIGATED (TLS mutual auth) MITIGATED (if properly implemented) VULNERABLE
Compromised device impersonation STRONG MITIGATION (attestation detects firmware tampering) WEAK MITIGATION (no integrity check) NONE NONE
Supply chain attack (counterfeit devices) IMMUNE (TPM provisioned at chip fab) VULNERABLE (fake device gets cert) VULNERABLE VERY VULNERABLE

Worked Example: Smart Building with 2,000 Devices

Device Inventory:

  • 50 edge gateways (high-performance, ARM Cortex-A)
  • 800 HVAC/lighting controllers (medium, ARM Cortex-M)
  • 1,000 occupancy sensors (low, 8-bit MCU)
  • 150 legacy thermostats (no crypto capability)

Identity Architecture:

  1. Edge Gateways (50 devices): TPM 2.0
    • Rationale: High-value targets, sufficient budget, enterprise requirement
    • Cost: 50 × $5 = $250
    • Implementation: TPM-backed X.509 certificates, firmware attestation every 4 hours
    • Key rotation: 90-day certificate renewal via SCEP
  2. HVAC/Lighting Controllers (800 devices): Secure Element (NXP A71CH)
    • Rationale: Medium budget, security-critical (building access control)
    • Cost: 800 × $2 = $1,600
    • Implementation: ECC-256 certificates, mutual TLS, attestation daily
    • Key rotation: 180-day certificate renewal
  3. Occupancy Sensors (1,000 devices): Software-Based X.509 Certificates with PUF Seed
    • Rationale: Cost-sensitive, SRAM PUF provides device uniqueness
    • Cost: 1,000 × $0.20 (PUF enrollment) = $200
    • Implementation: PUF-derived device secret seeds certificate key generation
    • Key rotation: 365-day certificate renewal (annual)
  4. Legacy Thermostats (150 devices): Gateway Proxy Authentication
    • Rationale: No crypto hardware, cannot be updated
    • Cost: 8 gateway appliances × $2,500 = $20,000 (each gateway handles ~20 devices)
    • Implementation: Gateway authenticates on behalf of legacy devices, MAC address binding
    • Key rotation: Gateway rotates its own certificates (90 days), legacy devices unchanged

Total Cost: $22,050 for comprehensive device identity across 2,000 devices

Implementation Timeline:

  • Week 1-2: Deploy TPM-backed gateways (foundation)
  • Week 3-6: Certificate enrollment for 800 controllers
  • Week 7-10: PUF enrollment and certificate provisioning for 1,000 sensors
  • Week 11-12: Gateway proxy deployment for 150 legacy devices
  • Week 13+: Monitoring, policy refinement, certificate renewal automation

Key Decision Factors:

  1. Lifetime: Devices with 10+ year lifetimes need hardware-backed identity (key extraction risk over long deployment).

  2. Connectivity: Cloud-connected devices justify X.509 (TLS mutual auth standard). Local-only devices can use PSK (lower overhead).

  3. Regulatory: Medical (FDA), automotive (UNECE WP.29), critical infrastructure (NIST 800-53) require hardware-backed identity.

  4. Attack Surface: Internet-facing devices need strongest identity (TPM/Secure Element). Isolated devices can use software certificates.

  5. Supply Chain: High-value or safety-critical devices need anti-counterfeiting (TPM with chip-level provisioning).

Common Pitfall: “We’ll Add Hardware Security Later”

Many projects start with software certificates planning to add TPM “in v2.” Problem: Retrofitting hardware requires PCB redesign, firmware rewrite, re-certification. Cost 10x more than designing in from start. If you need hardware security, include it in v1 or accept software certificate risk forever.

Common Mistake: Using MAC Address as Device Identity

The Problem: A smart city project deployed 5,000 environmental sensors across 100 locations. To “simplify” device identity, the development team used MAC addresses as unique device identifiers. Each sensor’s MAC address was registered in the cloud database, and the authentication system checked: “Is this MAC address in our allowlist?”

What They Thought:

  • “MAC addresses are globally unique (IEEE 48-bit allocation)”
  • “Every device has a MAC address - no extra hardware needed”
  • “Simple to implement - just read MAC from network interface”
  • “Cost: $0 per device”

What Actually Happened:

Month 3: First Compromise

A researcher at a nearby university discovered the sensor network (802.11 probe requests visible to anyone with Wireshark). Within 2 hours:

  1. MAC Address Enumeration: Captured 347 sensor MAC addresses from broadcast traffic
  2. MAC Spoofing: Changed laptop MAC address to match sensor AA:BB:CC:DD:EE:01
  3. Authentication Bypass: Laptop now authenticates as legitimate sensor
  4. Data Injection: Uploaded fake environmental readings (CO2: 5000 ppm, temp: 45°C)
  5. Impact: City’s air quality dashboard showed false pollution spike, triggered emergency response (cost: $12K wasted)

Month 5: Coordinated Attack

Attacker discovered the sensor cloud API accepts any device with allowlisted MAC address:

Attack Script (10 lines of Python):
import requests
mac_addresses = open('captured_macs.txt').readlines()  # 5,000 MAC addresses
for mac in mac_addresses:
    spoofed_headers = {'X-Device-MAC': mac.strip()}
    fake_data = {'temp': 100, 'humidity': 0, 'co2': 9999}
    requests.post('https://api.smartcity.gov/sensors/upload',
                  json=fake_data, headers=spoofed_headers)

Result: All 5,000 sensors simultaneously reported impossible values. Dashboard crashed. Emergency services called. City evacuated 2 neighborhoods (false alarm). Cost: $1.2M.

Why MAC Address “Authentication” Fails:

  1. MAC Addresses Are Not Secrets
    • Broadcast in every packet (visible to anyone with packet sniffer)
    • Printed on device labels (physical access = compromised)
    • No cryptographic proof device possesses secret knowledge
  2. Trivial to Spoof
    • Linux: ip link set dev eth0 address AA:BB:CC:DD:EE:FF
    • Windows: Network adapter settings → Advanced → Locally Administered Address
    • 5 seconds to spoof, no special tools required
  3. No Integrity Protection
    • MAC address in packet header is set by sender (not validated by network)
    • Attacker can claim to be any MAC address
    • Even “secure” networks (WPA2/3) only encrypt traffic, not validate MAC authenticity
  4. No Mutual Authentication
    • Device proves identity to server: NO (MAC is not proof)
    • Server proves identity to device: NO (anyone can run fake server)
    • Vulnerable to man-in-the-middle attacks

Correct Implementation: Certificate-Based Authentication

After $1.2M incident, city redeploys with proper device identity:

New Architecture:

Device Identity (per sensor):
1. X.509 certificate (ECC-256) provisioned during manufacturing
2. Private key stored in secure element (Microchip ATECC608B, $1.80/device)
3. Certificate signed by city's device CA (hierarchical trust)
4. Certificate CN = device serial number (globally unique)

Authentication Protocol:
1. Device connects to cloud API via TLS 1.3
2. Mutual authentication: device presents certificate, server verifies signature
3. Server presents certificate, device verifies against trusted root CA
4. TLS handshake fails if either certificate invalid
5. Server extracts device ID from certificate (can't be spoofed)

Cost:
- Secure element: 5,000 × $1.80 = $9,000
- Certificate provisioning setup: $5,000
- Firmware update (OTA): $8,000
- Total: $22,000 to fix the vulnerability

Attack Resistance (After Fix):

Attack Before (MAC Address) After (Certificate) Result
Capture device ID Easy (MAC visible in packets) Impossible (certificate is not secret, but private key is) Attacker can see certificate, but cannot use it
Spoof device identity Trivial (change MAC in 5 seconds) Impossible (requires private key from secure element) Attacker blocked at TLS handshake
Man-in-the-middle Easy (no server authentication) Prevented (mutual TLS, both sides verified) Attacker cannot intercept traffic
Clone device Easy (copy MAC address) Impossible (private key cannot be extracted) Each sensor has unique, unforgeable identity
Physical compromise Device → all devices (MAC is only secret) Device → that device only (cert revoked, key destroyed) Blast radius limited to single device

Real-World Impact (12 Months After Fix):

  • Attempted MAC spoofing attacks: 847 detected
  • Successful authentication bypasses: 0 (all blocked by certificate verification)
  • False data injection attempts: 234 blocked
  • Incident response cost: $0 (no successful attacks)
  • ROI: $22K investment prevented $1.2M+ in false emergencies

Key Lessons:

  1. MAC Addresses Are Not Authentication: They are network identifiers, not secrets. Using MAC as authentication is security theater.

  2. Cost of Doing It Right: $1.80 per device for secure element. Cheaper than a single false emergency response.

  3. Retrofit Is Expensive: Post-deployment secure element addition cost 3x more than designing it in from start (field visits, firmware updates, testing).

  4. Cryptographic Identity Is Non-Negotiable: For any internet-connected IoT device, use certificate-based authentication with hardware-backed keys.

  5. Defense in Depth: Even if MAC address filtering were secure (it’s not), it’s only one layer. Certificate + TLS provides identity + confidentiality + integrity.

Warning Signs You’re Making This Mistake:

  • “We use MAC address allowlist for security” (MAC is not secret)
  • “Our network is private, no one can spoof MAC” (802.11 is broadcast radio, Ethernet is shared bus)
  • “We have firewall rules by MAC address” (attacker bypasses by spoofing allowed MAC)
  • “Hardware security costs too much” ($1.80 per device vs $1.2M incident - do the math)
  • “We’ll add proper auth in v2” (v2 never comes, or costs 10x more to retrofit)

Proper Device Identity Checklist:

  • ✅ Device possesses cryptographic secret (private key)
  • ✅ Secret is unique per device (not shared across fleet)
  • ✅ Secret cannot be extracted (hardware security module or secure element)
  • ✅ Authentication uses challenge-response (proves device possesses key without transmitting it)
  • ✅ Mutual authentication (both device and server verify each other)
  • ✅ Attestation capability (device proves firmware integrity, not just identity)

If your authentication system doesn’t meet all 6 criteria, you don’t have device identity - you have device suggestion.

Concept Relationships

How device identity concepts interconnect with security architecture:

Identity Concept Relates To Connection
TPM/Secure Elements Hardware Root of Trust Tamper-resistant key storage prevents extraction
X.509 Certificates PKI Infrastructure Hierarchical trust model with CA signatures
Device Attestation Firmware Integrity TPM PCR values prove unmodified boot chain
Mutual TLS (mTLS) Encrypted Channels Both client and server verify identities
PUFs Physical Characteristics Unclonable silicon variations create unique IDs
Pre-Shared Keys Symmetric Cryptography Lightweight for constrained devices
Certificate Rotation Key Management 90-day renewal limits compromise window

Certificate Revocation List (CRL) size grows linearly with device count and revocation rate. OCSP reduces bandwidth but adds query latency.

CRL Size Estimation: \[\text{CRL Size} = N_{\text{devices}} \times P_{\text{revoke}} \times S_{\text{entry}}\]

where \(P_{\text{revoke}}\) is cumulative revocation probability over certificate lifetime.

OCSP Query Overhead: \[\text{Bandwidth}_{\text{OCSP}} = N_{\text{requests}} \times (S_{\text{query}} + S_{\text{response}})\]

Working through an example:

Given: Smart city with 50,000 IoT devices - Certificate validity: 365 days - Daily revocation rate: 0.2% (100 devices/day due to compromise/decommission) - CRL entry size: 32 bytes (serial number + timestamp) - OCSP query: 128 bytes, OCSP response: 256 bytes - Device authentication frequency: 4 times/day

Step 1: Calculate cumulative revocations over certificate lifetime \[N_{\text{revoked}} = 50,000 \times 0.002 \times 365 = 36,500 \text{ revoked certificates}\]

Step 2: Calculate CRL size \[\text{CRL Size} = 36,500 \times 32 = 1,168,000 \text{ bytes} = 1.11 \text{ MB}\]

Step 3: Daily CRL download bandwidth (all devices) \[\text{Bandwidth}_{\text{CRL}} = 50,000 \times 1.11 \text{ MB} = 55,500 \text{ MB/day} = 54.2 \text{ GB/day}\]

Step 4: Daily OCSP bandwidth (query per auth) \[\text{Bandwidth}_{\text{OCSP}} = 50,000 \times 4 \times (128 + 256) = 76,800,000 \text{ bytes} = 73.2 \text{ MB/day}\]

Result: CRL approach requires 54.2 GB/day bandwidth (each device downloads full 1.11 MB list). OCSP reduces to 73.2 MB/day (742x reduction), but adds OCSP responder infrastructure and per-request latency (+30ms).

In practice: LoRaWAN devices with 1KB/day data budgets cannot download 1.11 MB CRLs. OCSP or OCSP stapling essential for constrained networks. Alternative: short-lived certificates (24-hour validity) eliminate revocation need.

Try it yourself – adjust the parameters to see how CRL and OCSP bandwidth scale with your deployment:

27.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.

27.6 See Also

Expand your understanding of device identity and authentication:

Zero Trust Series:

Cryptographic Foundations:

Device Security:

27.7 Knowledge Check

Common Pitfalls

Assigning the same certificate or pre-shared key to all devices of the same type means compromising one device compromises all. Every device must have a unique cryptographic identity. Device certificate uniqueness is not optional in zero trust architectures.

X.509 certificates have expiry dates. IoT devices deployed for 5-10 years require certificate renewal processes. Devices with expired certificates lose network access if zero trust enforcement is properly implemented. Build certificate lifecycle management into deployment operations from day one.

Device private keys stored in flash memory or RAM without hardware protection can be extracted by attackers with physical device access. Use TPM, secure element, or ARM TrustZone for private key storage to prevent key extraction attacks.

A device with a valid certificate that is behaving anomalously (transmitting to unexpected destinations, operating at unusual times, accessing unauthorized resources) may have been compromised despite valid credentials. Combine certificate authentication with continuous behavioral monitoring.

27.8 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.

← Zero Trust Implementation Network Segmentation →