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 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.
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.
More designs will be added here, across both secure boot and update delivery. If the platform or update system 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 and signed updates are the two halves of the same requirement — a device has to run only authorised firmware, and keep accepting authorised fixes for its supported life — and together they are what make "vulnerabilities can be fixed" 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.