Self-healing digital signatures for autonomous devices, SCADA systems, and edge infrastructure that cannot be manually re-keyed.
The Internet of Things represents the most challenging deployment context for digital signatures. IoT devices are characterized by a combination of properties that make traditional key management fundamentally unworkable: massive scale (millions of devices), constrained resources (limited compute, memory, and power), physical accessibility (devices deployed in uncontrolled environments), and long operational lifetimes (10–20 years for industrial equipment).
When an IoT device’s signing key is compromised — through firmware extraction, side-channel attack, supply chain tampering, or simple physical access — the traditional response is to revoke the device’s certificate and re-provision it with new keys. At scale, this is operationally impossible. A fleet of 100,000 smart meters, industrial sensors, or connected vehicles cannot be manually re-keyed when a vulnerability is discovered that affects the entire class of devices.
PhoenixSig solves this by making key recovery an autonomous, local operation that each device performs independently, without human intervention, without network connectivity, and without any centralized coordination.
Over-the-air firmware updates are the primary mechanism for patching and maintaining IoT fleets. Each update must be digitally signed to prevent malicious firmware injection. If the update signing key is compromised, an attacker can push malicious firmware to the entire device fleet — potentially bricking devices, exfiltrating data, or converting them into a botnet.
With PhoenixSig, the firmware signing server uses epoch-based keys that evolve continuously. A compromise of the signing infrastructure produces a bounded window of vulnerability: the attacker can sign malicious updates only until the next Phoenix refresh. After refresh, all future signing keys change unpredictably, and any malicious updates signed during the compromise window can be identified by their epoch range and quarantined during device-side verification.
Supervisory Control and Data Acquisition (SCADA) systems control critical infrastructure: power grids, water treatment plants, oil and gas pipelines, manufacturing lines. Commands sent to SCADA endpoints must be authenticated to prevent injection of malicious control signals that could cause physical damage or safety incidents.
SCADA environments present unique constraints. Devices have lifetimes measured in decades. Firmware updates are rare and operationally risky. Network connectivity may be intermittent or air-gapped. Manual key rotation requires physical site visits to remote installations.
PhoenixSig is designed for exactly this profile. The DyLWE state core has minimal computational requirements (a few kilobytes of state, microseconds of processing per evolution step). Phoenix refresh requires only local TEE entropy — no network connectivity. The epoch-based signing model means that devices can operate for years with continuously evolving key material, without any external key management infrastructure.
Modern vehicles contain dozens of networked Electronic Control Units (ECUs) that communicate over CAN bus, automotive Ethernet, and V2X (vehicle-to-everything) wireless links. Messages between ECUs — brake commands, steering inputs, sensor data — must be authenticated to prevent injection attacks that could cause safety-critical failures.
Vehicle security presents a particularly acute version of the compromise problem. Vehicles are physically accessible to adversaries (parked in public, serviced by third parties, sold second-hand). The computing hardware is well-documented and amenable to reverse engineering. And the consequences of forged control messages are potentially life-threatening.
PhoenixSig’s quarantine mechanism provides an immediate safety response. If an ECU detects signs of tampering (unexpected reboot, state inconsistency, physical intrusion sensor trigger), it enters quarantine and refuses to sign safety-critical commands until a Phoenix refresh confirms the integrity of its VaultKey. This fail-safe behavior prevents a compromised ECU from issuing authenticated commands that other ECUs would trust.
Smart grid deployments include smart meters, grid sensors, distributed energy resource controllers, and substation automation equipment. These devices produce signed telemetry data used for billing, grid balancing, and safety monitoring. A compromised meter signing key could be used to manipulate billing data, falsify grid state reports, or inject bogus demand-response signals.
PhoenixSig’s forward secrecy is particularly valuable in metering contexts. Even if a meter is compromised and its current state extracted, all historical telemetry signatures remain valid and verifiable. The utility can be confident that billing records from before the compromise are genuine, even while investigating and remediating the breach.
IoT devices range from powerful edge gateways to severely resource-constrained microcontrollers. PhoenixSig supports this spectrum through configurable profiles:
| Profile | Target Hardware | RAM | State Size | Signing Algorithm |
|---|---|---|---|---|
| Full | Edge gateways, industrial PCs | > 64 MB | ~8 KB | ML-DSA (fast, small signatures) |
| Standard | ARM Cortex-A class (smart meters, cameras) | 4–64 MB | ~4 KB | ML-DSA (primary) or SLH-DSA |
| Compact | ARM Cortex-M class (sensors, actuators) | 256 KB–4 MB | ~2 KB | SLH-DSA (smaller code size) |
The DyLWE state core itself is extremely lightweight: the state evolution function requires only a few hundred bytes of working memory and completes in microseconds on ARM Cortex-M4 class processors. The dominant resource cost is the PQC signing algorithm, not the PhoenixSig lifecycle layer.
Managing PhoenixSig across a large device fleet requires coordination between the devices and a backend management system. The fleet architecture follows a decentralized model:
This architecture means that even if the fleet management server is compromised or offline, every device continues to sign and recover independently. The server is a convenience for fleet visibility and policy management — not a security dependency.
IoT supply chains are notoriously vulnerable. Devices may be manufactured by third-party ODMs, assembled in facilities outside the deployer’s control, shipped through intermediaries, and installed by contracted technicians. At each stage, there are opportunities for firmware tampering, key extraction, or device substitution.
PhoenixSig mitigates supply chain risk through its VaultKey provisioning model. The VaultKey is generated inside the TEE at first boot — not during manufacturing. This means that no party in the supply chain ever has access to the VaultKey material. The device’s signing identity is established autonomously when it first powers on in the deployment environment, using entropy from its own hardware RNG.
For additional assurance, the device can produce a TEE attestation report at provisioning time, proving to the fleet management server that the VaultKey was generated inside genuine hardware and that the PhoenixSig firmware is unmodified. Devices that fail attestation are rejected before they join the fleet.
Industrial IoT devices often have operational lifetimes of 10–20 years. Over such timeframes, cryptographic algorithms may be broken, hardware vulnerabilities may be discovered, and threat models will certainly evolve. PhoenixSig is designed for this reality:
| Standard / Protocol | PhoenixSig Role |
|---|---|
| IEC 62351 (Power Systems) | Authenticated SCADA commands with PCS recovery |
| IEEE 1609.2 (V2X) | Vehicle-to-everything message signing with epoch-based keys |
| MQTT / CoAP (IoT messaging) | Signed telemetry payloads with forward secrecy |
| OPC UA (Industrial) | Session-level signing with quarantine enforcement |
| SUIT (Firmware Update) | Manifest signing with PCS-protected signing infrastructure |
| Operation | Cortex-M4 (168 MHz) | Cortex-A53 (1.2 GHz) | Notes |
|---|---|---|---|
| State evolution | < 1ms | < 0.1ms | DyLWE core only |
| Sign (ML-DSA) | ~120ms | < 15ms | Dominated by PQC algorithm |
| Sign (SLH-DSA) | ~800ms | ~100ms | Hash-based, suitable for low-frequency signing |
| Phoenix refresh | < 5ms | < 1ms | TEE entropy + VaultKey rotation |
| Verify | ~50ms | < 5ms | No TEE required |