Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Secure boot attestation: proving which firmware ran

Secure boot attestation lets a device prove to the cloud which firmware actually executed, not which firmware was supposed to be installed. Each stage of the boot chain is hashed, and the hashes are bound into a chained hardware computation that only the genuine token can produce. If any stage was modified, the final attestation value won't verify.

How the chain works

  1. The host requests a boot challenge (BootCW) from the cloud, supplying the token IDs and expected firmware hashes.
  2. The running value is XORed with the next stage's firmware hash, then passed through the token; one token call per boot stage. The token is never challenged with the raw BootCW.
  3. The final value is submitted as the attestation; the cloud recomputes the whole chain in its HSM and returns AUTH_OK only if every link matches.

Because each link depends on both the previous link and the firmware hash for that stage, a single flipped bit in any stage's firmware produces a completely different attestation.

The three examples

All live in examples/05-attest-boot-chain/:

Script Form Use when
secureboot.py Cloud-initiated Your backend drives attestation on its own schedule.
secureboot_host.py Host-initiated The device attests itself, e.g. at the end of its boot sequence. Recommended starting point.
secureboot_hrw.py HRW form The cloud computes the expected attestation for hashes you supply.

What you feed it

The firmware hashes are simply digests of whatever artifacts define your boot chain: bootloader, kernel, application image. In production, each boot stage should measure (hash) the next stage before handing over, and the device submits those measured values. The examples show the protocol mechanics; producing trustworthy measurements is the integrator's side of the contract.

What a passing result means, and what it doesn't
  • Means: a genuine token processed exactly this sequence of stage hashes; the attested chain matches what the cloud expected.
  • Doesn't mean: the hashes were honestly measured. If compromised firmware submits the "right" hashes rather than its own, attestation passes. Anchor the first measurement in something the attacker can't modify (ROM or an immutable first-stage loader).

Source code: SandGrain CyberRock - Core Functions on GitHub