rpi-verity-verifier

Boot-time verifier for signed dm-verity root hashes on Raspberry Pi.

At provisioning time, rpi-fastbootd computes a dm-verity root hash and signs it — along with the full set of veritysetup parameters (salt, block sizes, data_blocks, hash_area_offset) — using the device's OTP-bound ECDSA P-256 key. The signature and its parameters are persisted as a packed binary blob at /persistent/<slot>.verity.rhsig.

At boot, this package's initramfs script runs in local-premount/95-rpi-verity, reads the blob, verifies the signature against the device's own OTP public key (fetched via rpi-fw-crypto), checks device and slot binding, and only then opens dm-verity via veritysetup open. On any failure it reboots the device — no fail-open path.

Preconditions

This package requires, and enforces at runtime:

1. Secure boot enforced — customer OTP public-key hash programmed; the booted boot.img is signature-verified by firmware. Detected by reading /sys/bus/nvmem/devices/nvmem_cust0/nvmem: all-zero means not provisioned.
2. lock_device_private_key=1 in the signed config.txt — firmware sets ARM_CRYPTO_KEY_STATUS_READ_LOCKED before any userspace runs, closing the OTP-privkey-exfiltration window. Verified via rpi_fw_crypto_get_key_status.
3. Provisioning has produced a signed blob for the active slot at /persistent/<slot>.verity.rhsig. Absence is treated as failure.

Packages

• rpi-verity-verifier — the production binary + initramfs integration.
• rpi-verity-verifier-dev — permissive variant for development images; logs failures and continues rather than rebooting. Never install in prod.
• librpi-verity-verifier-dev — blob format headers + identity helper; used by rpi-fastbootd at build time for the signing side.

Threat model

See README.Debian for the full threat model. Summary: defeats offline-image tampering and pre-root attacks, with two acknowledged gaps within that scope (see docs/HARDENING_ROADMAP.md):

• An attacker with write access to /persistent can replay any previously-signed blob for the same slot on the same device (no anti-rollback).
• The active-slot decision is carried by an unsigned symlink, so the same attacker can flip between slots and boot whichever signed blob they prefer.

Closing both requires firmware support (a monotonic counter) and a blob-format change. The post-root threat — root extracting the OTP private key — is separately out of scope: the Pi firmware crypto service is not a TEE.

Integration

• docs/INTEGRATION_RPI_IMAGE_GEN.md — how to enable verity in an rpi-image-gen image: required config.txt directives, kernel config, initramfs layering, CI sanity check.
• docs/INTEGRATION_OTA.md — what an OTA client must do to deliver updates to a verity-protected device: on-device signing, slot ordering invariants, rollback semantics.
• docs/HARDENING_ROADMAP.md — known gaps in the offline-tampering defence and the firmware / format work needed to close them.

Related

• rpi-fastbootd issue #10 — motivation.
• rpi-fastbootd — the signer side.