Firmware Signing and Secure Update

Firmware and control artifacts are signed, version-monotonic, and delivered through the gated import path, so only authorized, non-rollback updates ever reach the machine.

Updates are a privileged, rare event

Updating firmware on a control FPGA is one of the highest-consequence routine operations in the plant: it changes what runs on the actuation path. Kronos makes updates infrequent, signed, verified at load, monotonic in version, and delivered only through the controlled air-gap bridge under two-person control. There is no over-the-internet auto-update to OT.

The update pipeline

• Build with provenance and SBOM - see SBOM and provenance.
• Sign with a post-quantum firmware key (SLH-DSA root) - see PQC signatures.
• Import via the air-gap ceremony, re-signed with an OT-domain key at the import station.
• Verify at load and enforce version monotonicity - see bitstream integrity.
• Re-attest after update so peers confirm the new measurement matches policy - see attestation.

Rollback protection

# Refuse older versions even if validly signed (anti-rollback)
def apply_update(img):
    if not verify_firmware_sig(img):        return REJECT
    if img.version <= device.current_version: return REJECT   # monotonic
    if not import_ceremony_ok(img):          return REJECT   # 2-person + diode
    stage_and_reboot(img)                    # secure boot re-verifies on start

Why monotonicity matters

A validly signed but older firmware may contain a known vulnerability. Without a monotonic version check, an attacker could downgrade to that version and exploit it - a valid signature is not the same as a safe artifact. Kronos blocks downgrades at both apply time and boot time.

Design status: signing, monotonic checks, and the ceremony-gated pipeline run in the twin and staging. Production firmware keys and the physical import station are FOAK build scope; no live reactor firmware update has occurred.