Decentralized Identity for IoT Device Authentication

ROLE: You are an IoT security architect who specializes in applying decentralized identity to the Internet of Things. You understand the unique constraints of IoT devices — limited compute, intermittent connectivity, long deployment lifetimes, supply chain integrity — and how DID-based identity solves critical IoT security challenges that traditional PKI and certificate authorities struggle with: scalability, device ownership transfer, and decentralized trust.

OBJECTIVE: Design a decentralized identity system for IoT devices that provides secure device authentication, verifiable provenance, ownership management, and machine-to-machine trust establishment without relying on centralized certificate authorities.

TASK:
Design an IoT identity system for the following deployment:

**Device Type:** {{DEVICE_TYPE}} (e.g., smart home sensors, industrial PLCs, medical devices, autonomous vehicles, supply chain trackers)
**Fleet Size:** {{FLEET_SIZE}} (e.g., hundreds, thousands, millions of devices)
**Compute Constraints:** {{COMPUTE}} (e.g., microcontroller 256KB RAM, embedded Linux, full SoC, constrained RTOS)
**Connectivity:** {{CONNECTIVITY}} (e.g., always connected, intermittent cellular, mesh network, air-gapped with periodic sync)
**Lifecycle:** {{LIFECYCLE}} (e.g., 2 years disposable, 10 years maintained, 30 years critical infrastructure)

Provide the following system design:

1. **Device DID Architecture:**
   - DID method selection for IoT: evaluating did:key (simple, no ledger dependency), did:web (enterprise-managed), did:ion (Bitcoin-anchored, high assurance), did:peer (peer-to-peer, no external dependency)
   - DID document for devices: authentication key (device signs challenges), assertion key (device attests to sensor readings), service endpoints (device API, telemetry stream, firmware update channel)
   - Key generation and storage: hardware secure element (ATECC608, TPM 2.0, ARM TrustZone), software-based for constrained devices, key derivation from device-unique properties (PUF — Physical Unclonable Function)
   - DID creation timing: factory provisioning, first-boot generation, or owner-initiated activation
   - Lightweight DID resolution: caching strategies, local DID document storage, resolution over constrained protocols (CoAP, MQTT)

2. **Device Provenance & Supply Chain:**
   - Manufacturing identity: how devices receive their initial identity during manufacturing, binding DID to hardware serial number
   - Supply chain credentials: each handler in the supply chain adds a verifiable credential (manufactured by X, shipped through Y, received by Z, deployed at location W)
   - Anti-counterfeiting: how to verify a device is genuine using its DID and attestation chain, detecting cloned devices
   - Ownership transfer: when a device is sold or redeployed, how ownership DID changes without compromising the device identity
   - End-of-life: secure decommissioning, DID revocation, data wipe verification credential

3. **Machine-to-Machine Authentication:**
   - Device-to-device auth protocol: mutual DID authentication between devices (e.g., sensor authenticating to gateway, vehicle authenticating to charging station)
   - Challenge-response for constrained devices: lightweight cryptographic protocols (COSE, CBOR-encoded challenges) that work within RAM and processing constraints
   - Session establishment: DTLS or OSCORE session setup using DID-authenticated key exchange
   - Trust policies: which device DIDs to trust, issuer-based trust (trust all devices from manufacturer X), attribute-based trust (trust all devices with valid calibration credential)
   - Group authentication: device swarm authentication, fleet-level identity, cluster membership verification

4. **Verifiable Device Credentials:**
   - Credential types for devices:
     - Manufacturing certificate: hardware specs, firmware version at birth, security certification level
     - Calibration credential: last calibration date, calibration authority, accuracy specification
     - Firmware attestation: current firmware hash, update history, vulnerability patch status
     - Compliance credential: regulatory approval (CE, FCC, UL), inspection records, safety certifications
     - Operational credential: deployment location, operational parameters, maintenance history
   - Credential issuance: automated issuance from management platforms, manual issuance from technicians via mobile app
   - Credential verification: how a verifier checks device credentials (query device directly, check cached credentials, consult trust registry)

5. **Lifecycle Key Management:**
   - Key rotation for long-lived devices: how to update keys on devices deployed for 10-30 years, backward compatibility during rotation
   - Compromise recovery: what happens when a device key is extracted — revocation propagation, fleet-wide security assessment, replacement procedures
   - Firmware update authentication: verifying firmware updates came from the legitimate manufacturer using DID-based code signing
   - Remote attestation: device proving its current software state is legitimate (measured boot, runtime integrity)
   - Disaster recovery: restoring device identity after hardware failure, key escrow considerations for critical infrastructure

6. **Scalability & Performance:**
   - DID resolution at scale: handling millions of device DID lookups, caching architecture, CDN for DID documents
   - Credential verification throughput: batch verification for fleet management, asynchronous verification for non-critical operations
   - Network bandwidth: minimizing identity-related traffic for metered connections (cellular IoT, satellite)
   - Edge computing: running identity verification at edge gateways rather than cloud, reducing latency for real-time device interactions
   - Protocol efficiency: comparison of authentication overhead for DID-based vs. traditional certificate-based approaches, demonstrating comparable or better performance