Secure boot establishes authenticity (“this image is signed by a trusted key”). But many modern deployments also need attestation: a portable, verifiable way to prove what actually booted to a relying party: during onboarding, after updates, and throughout a device’s lifetime.
That’s where DICE (Device Identifier Composition Engine) comes in. DICE composes a device identity from a Unique Device Secret (UDS) or a Hardware Unique Key (HUK) and measurements from the boot process, producing attestation material that is cryptographically tied to the software state. If the measured boot state changes, the derived identity and evidence change with it.
wolfBoot now supports DICE-based PSA Initial Attestation, enabling systems to generate standard PSA attestation evidence directly from the boot chain, without turning your bootloader into a sprawling TEE project.
What DICE is for in a measured boot design
Measured boot records hashes of critical components in the boot chain (bootloader and firmware images, and optionally other pieces depending on your architecture). DICE builds on that by turning measurements into actionable evidence:
- A stable device secret (UDS/HUK) anchors identity to the physical device.
- Measurements bind that identity to what is actually executed.
- The result is an attestation token that can be verified remotely, allowing policies like “only allow this device onto the network if it booted approved firmware.”
This is especially useful when firmware updates, feature unlocks, provisioning, or service access depend on proven state, not just a one-time factory identity.
What wolfBoot delivers with DICE attestation
wolfBoot is a portable, OS-agnostic secure bootloader built around wolfCrypt for firmware authentication and secure update flows. With DICE attestation, wolfBoot expands from “verify and boot” to “verify, measure, and prove”, while keeping the design aligned with embedded constraints.
Here’s what’s included at a high level:
PSA Certified Initial Attestation API, implemented in the secure world
wolfBoot implements the PSA Certified Initial Attestation API and returns an attestation token to callers through standard PSA entry points. In TrustZone-M deployments, the token is produced by a secure-world service, keeping key material and signing operations isolated from non-secure code.
COSE_Sign1-wrapped EAT token (PSA token profile)
The emitted evidence is a COSE_Sign1-wrapped EAT token following the PSA attestation token profile. This matters for product teams because it keeps the output interoperable with existing PSA-friendly verifiers and attestation pipelines.
A practical “minimum claim set” for real workflows
wolfBoot’s token includes the key claims most deployments depend on:
- Nonce binding (challenge) for freshness (anti-replay)
- Device identity (UEID)
- Implementation ID and lifecycle when the platform provides them
- Measured boot components for wolfBoot and the boot image
wolfBoot doesn’t rely on a second measurement system just for attestation: the component measurements used in the token reuse the same image hashing pipeline already required for normal image validation. Component claims include a measurement type, the measurement value, and a short description string. This is enough for verifiers to interpret “what was measured” without dragging in board-specific knowledge.
Build-time keying options: DICE-derived key or provisioned IAK
Different products have different provisioning models, so wolfBoot supports two signing key approaches selectable at build time:
- DICE-derived attestation key (no external provisioning)
wolfBoot fetches a UDS or HUK-derived secret via a small HAL hook, then deterministically derives Compound Device Identifier (CDI) and signing key material using HMAC-based Extract-and-Expand Key Derivation Function (HKDF). This avoids per-device key injection while still anchoring identity in a hardware-rooted secret plus measured boot material. - Provisioned Initial Attestation Key (IAK)
If your manufacturing process already provisions an IAK into secure storage, wolfBoot can retrieve it via a HAL hook and sign tokens using that key instead of deriving one.
In both cases, the signing operation happens in the secure domain, and the non-secure side only sees the final token.
Small HAL surface area, shared implementation
The DICE implementation lives under src/dice/ and is shared across targets. Target families implement the subset of HAL hooks supported by their hardware. Examples include:
- a hook to retrieve or derive the UDS/HUK-based secret
- optional hooks to provide Universal Entity Identifier (UEID), implementation ID, and lifecycle
- an optional hook to retrieve a provisioned IAK (IAK mode)
For demos, wolfBoot also includes a test-only fallback that can derive a UDS from a device UID when explicitly enabled. This is useful to get started quickly, but not intended for production deployments.
UDS storage options: OBKeys for production, OTP for practicality
DICE depends on stable device-unique material. wolfBoot supports multiple approaches depending on what your SoC provides:
STM32H5 OBKeys UDS (recommended when available)
On supported STM32H5 lines, OBKeys secure storage provides protected areas appropriate for iRoT key material, including a device-unique UDS. When enabled, the STM32H5 HAL can attempt to read the UDS from OBKeys first, aligning well with production provisioning flows.
OTP UDS storage using the primer application (development + fallback)
wolfBoot also supports storing a random UDS for DICE attestation in OTP using the OTP keystore primer application. This same primer app is used to provision public keys into a dedicated FLASH OTP area, and it provides a practical path to bring up DICE attestation early, even before OBKeys provisioning is in place.
This gives teams a smooth migration story:
- Start with OTP for development and early integration.
- Move to OBKeys (or another secure storage mechanism) for production hardening.
wolfBoot as Zephyr TEE supervisor, powered by wolfCrypt, accessible via wolfPSA
DICE attestation is especially compelling when paired with a clean PSA client story. wolfBoot can be used as an ARM TEE replacement in Zephyr-based TrustZone-M systems, acting as the secure-side PSA provider.
In this model:
- wolfBoot provides the secure-side PSA service and CMSE veneers.
- A Zephyr non-secure application calls standard PSA APIs.
- wolfBoot services those requests in the secure domain.
When PSA mode is enabled, wolfBoot exposes:
- PSA Initial Attestation (DICE token generation)
- PSA Crypto API via wolfPSA in the secure domain (backed by wolfCrypt)
- PSA Protected Storage, using the same secure service pattern
This is a strong product story for teams that want PSA-style portability without inheriting a heavyweight secure runtime. You get a cohesive secure boot + secure services foundation from a single, embeddable component, wolfBoot, built on wolfSSL’s crypto stack.Where this fits: onboarding, fleet integrity, and secure update policy
DICE-based attestation lets you move from “we think it booted correctly” to “we can prove what booted.” Common uses include:
- Zero-touch provisioning: accept devices only if they attest an approved boot state
- Secure updates with policy gates: allow updates, feature flags, or credentials only after attestation
- Fleet compliance monitoring: continuously verify that devices remain in expected states
- Defense against rollback and tampering: changes in measured boot state become visible to verifiers
Getting started with wolfBoot
wolfBoot is available for evaluation and integration in the wolfSSL GitHub organization, with documentation and target guides to help you bring it up on supported MCUs. If you need commercial licensing, long-term maintenance, feature work, or help integrating wolfBoot into an existing firmware pipeline, wolfSSL provides licensing and support options. Contact us at facts@wolfssl.com for more information.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now