Solutions¶
Reference designs for putting LAAVAT into a real product. Where the signing and encryption pages document one operation at a time, these describe a complete pattern: which operations to configure, how they fit together, and how to verify the result before you have hardware in front of you.
Each guide covers the same ground:
- what the design achieves, and what each component trusts
- the LAAVAT product and operations that anchor it
- the signing or issuance flow, step by step
- how to verify the output off-device, and where that stops being enough
Secure boot¶
Making a device run only firmware you authorised, from the first instruction after reset.
-
CRA-ready nRF devices
Nordic nRF52840 with b0/NSIB, MCUboot and a Zephyr application, optionally with TF-M. Two HSM-held ECDSA-P256 keys anchor a three-stage chain.
-
CRA-ready STM32H5 controllers
STM32H5 with ST's OEMiRoT, an immutable MCUboot that verifies the secure and non-secure application images. Two HSM-held ECDSA-P256 keys, one per image, with public keys provisioned into the chip's OBKeys.
-
CRA-ready i.MX8M gateways
NXP i.MX8M with HAB from ROM, a signed kernel FIT, OP-TEE Trusted Applications, and RAUC update bundles under your own CA — one product, four operations.
-
CRA-ready Raspberry Pi gateways
Raspberry Pi 4 with signed boot from the EEPROM bootloader, update images encrypted under a product key held in a secure element, and a signed update manifest — three HSM-held keys.
-
CRA-ready Zynq UltraScale+ gateways
AMD Zynq UltraScale+ MPSoC with Bootgen run as a platform operation: every partition signed with PSK and SSK keys held in the HSM, anchored in the PPK eFUSEs.
Update delivery¶
Making a device accept only updates you signed, for the whole of its supported life.
-
CRA-ready Mender OTAs
Signed
.menderartifacts delivered over Mender's OTA channel, with the manufacturer's signing key held in the HSM and verified on every device. -
Encrypted RAUC updates
RAUC
cryptbundles that only the devices of one rollout can read: a per-device key generated in OP-TEE, a certificate from a dedicated Sub CA, and bundles signed and encrypted per rollout.
Device identity¶
Making each device individually authenticable, from the factory through its whole deployed life.
-
Trusted device identities
An IDevID birth certificate issued at manufacturing over REST, and an LDevID operational certificate enrolled in the field over EST — the manufacturer and operator PKIs behind IEEE 802.1AR.
More designs will be added here. If the platform, update system or identity scheme you are working with is not covered yet, the underlying operations are usually the same — see Secure boot and CRA for what LAAVAT signs, and get in touch about your target.
How this relates to CRA compliance¶
These guides show the mechanism; the CRA Compliance section explains the obligation. Secure boot, signed updates and device identity are three parts of the same requirement — a device has to run only authorised firmware, keep accepting authorised fixes for its supported life, and be individually identifiable so that access to it can be controlled — and together they are what make "vulnerabilities can be fixed" and "unauthorised access is prevented" true rather than theoretical.
Building a device this way does not by itself make a product CRA compliant. The Annex I mapping sets out which requirements the platform supports and which remain yours.