Merge pull request #668 from danielinux/dice

Add support for DICE attestation + PSA attestation

Author: dgarske

.github/workflows/trustzone-emulator-tests.yml

@@ -8,7 +8,7 @@ jobs:
   trustzone-emulator-tests:
     runs-on: ubuntu-latest
     container:
-      image: ghcr.io/danielinux/m33mu-ci:1.2
+      image: ghcr.io/danielinux/m33mu-ci:1.3
     steps:
       - uses: actions/checkout@v4
 
@@ -48,3 +48,20 @@ jobs:
         working-directory: test-app/emu-test-apps
         run: |
           TARGET=stm32l5 ./test.sh
+
+      - name: Clean and build test with DICE attestation (stm32h5)
+        run: |
+          make clean distclean
+          cp config/examples/stm32h5-tz-psa.config .config
+          make
+          m33mu wolfboot.bin test-app/image_v1_signed.bin:0x60000 --uart-stdout --expect-bkpt 0x7f --timeout 300
+
+      - name: Clean and build test with DICE attestation + OTP (stm32h5)
+        run: |
+          make clean distclean
+          cp config/examples/stm32h5-tz-psa-otp.config .config
+          make
+          make -C tools/keytools/otp TARGET=stm32h5 otp-keystore-primer.bin otp-keystore-gen
+          ./tools/keytools/otp/otp-keystore-gen
+          m33mu tools/keytools/otp/otp-keystore-primer.bin --persist --timeout 10 || true
+          m33mu wolfboot.bin test-app/image_v1_signed.bin:0x60000 --uart-stdout --expect-bkpt 0x7f --timeout 300 --persist

CMakeLists.txt

@@ -557,6 +557,10 @@ set(WOLFBOOT_SOURCES "include/loader.h"
                      "src/image.c"
                      "src/loader.c")
 
+if(DEFINED WOLFCRYPT_TZ_PSA AND NOT WOLFCRYPT_TZ_PSA STREQUAL "0")
+    list(APPEND WOLFBOOT_SOURCES "src/dice/dice.c")
+endif()
+
 # build bin-assemble tool Windows
 set(BINASSEMBLE ${CMAKE_CURRENT_BINARY_DIR}/bin-assemble${HOST_EXE})
 set(BINASSEMBLE_OBJDIR "${CMAKE_CURRENT_BINARY_DIR}/obj_bin_assemble")

Makefile

@@ -36,6 +36,10 @@ OBJS:= \
 	./src/libwolfboot.o \
 	./hal/hal.o
 
+ifeq ($(WOLFCRYPT_TZ_PSA),1)
+OBJS+=./src/dice/dice.o
+endif
+
 ifneq ($(TARGET),library)
 	OBJS+=./hal/$(TARGET).o
 endif

config/examples/mcxn-tz.config

@@ -10,7 +10,7 @@ MCUXPRESSO_CPU?=MCXN947VDF_cm33_core0
 MCUXPRESSO_DRIVERS?=$(MCUXPRESSO)/devices/MCX/MCXN/MCXN947
 MCUXPRESSO_PROJECT_TEMPLATE?=$(MCUXPRESSO)/examples/_boards/frdmmcxn947/project_template
 DEBUG?=0
-DEBUG_UART?=1
+DEBUG_UART?=0
 VTOR?=1
 CORTEX_M0?=0
 CORTEX_M33?=1
@@ -34,13 +34,13 @@ WOLFBOOT_SECTOR_SIZE?=0x2000
 
 # Default configuration
 # 64KB boot, 80KB keyvault, 8KB NSC, 60KB partitions, 8KB swap
-WOLFBOOT_KEYVAULT_ADDRESS?=0x10000
+WOLFBOOT_KEYVAULT_ADDRESS?=0x12000
 WOLFBOOT_KEYVAULT_SIZE?=0x14000
-WOLFBOOT_NSC_ADDRESS?=0x24000
+WOLFBOOT_NSC_ADDRESS?=0x26000
 WOLFBOOT_NSC_SIZE?=0x2000
-WOLFBOOT_PARTITION_SIZE?=0xF000
-WOLFBOOT_PARTITION_BOOT_ADDRESS?=0x26000
-WOLFBOOT_PARTITION_UPDATE_ADDRESS?=0x35000
+WOLFBOOT_PARTITION_SIZE?=0xE000
+WOLFBOOT_PARTITION_BOOT_ADDRESS?=0x28000
+WOLFBOOT_PARTITION_UPDATE_ADDRESS?=0x36000
 WOLFBOOT_PARTITION_SWAP_ADDRESS?=0x44000
 
 # Alternate larger configuration for debugging or ARMASM
@@ -49,7 +49,7 @@ WOLFBOOT_PARTITION_SWAP_ADDRESS?=0x44000
 #WOLFBOOT_KEYVAULT_SIZE?=0x14000
 #WOLFBOOT_NSC_ADDRESS?=0x34000
 #WOLFBOOT_NSC_SIZE?=0x2000
-#WOLFBOOT_PARTITION_SIZE?=0xF000
+#WOLFBOOT_PARTITION_SIZE?=0xE000
 #WOLFBOOT_PARTITION_BOOT_ADDRESS?=0x36000
 #WOLFBOOT_PARTITION_UPDATE_ADDRESS?=0x45000
 #WOLFBOOT_PARTITION_SWAP_ADDRESS?=0x54000

config/examples/stm32h5-tz-psa-otp.config

@@ -0,0 +1,38 @@
+ARCH?=ARM
+TZEN?=1
+TARGET?=stm32h5
+SIGN?=ECC256
+IMAGE_HEADER_SIZE?=1024
+WOLFBOOT_UNIVERSAL_KEYSTORE=1
+HASH?=SHA256
+DEBUG?=0
+VTOR?=1
+CORTEX_M0?=0
+CORTEX_M33?=1
+NO_ASM?=0
+NO_MPU=1
+EXT_FLASH?=0
+SPI_FLASH?=0
+ALLOW_DOWNGRADE?=0
+NVM_FLASH_WRITEONCE?=1
+WOLFBOOT_VERSION?=1
+V?=0
+SPMATH?=1
+RAM_CODE?=1
+DUALBANK_SWAP?=0
+WOLFBOOT_PARTITION_SIZE?=0xA0000
+WOLFBOOT_SECTOR_SIZE?=0x2000
+WOLFBOOT_KEYVAULT_ADDRESS?=0x0C040000
+WOLFBOOT_KEYVAULT_SIZE?=0x1C000
+WOLFBOOT_NSC_ADDRESS?=0x0C05C000
+WOLFBOOT_NSC_SIZE?=0x4000
+WOLFBOOT_PARTITION_BOOT_ADDRESS?=0x08060000
+WOLFBOOT_PARTITION_UPDATE_ADDRESS?=0x0C100000
+WOLFBOOT_PARTITION_SWAP_ADDRESS?=0x0C1A0000
+FLAGS_HOME=0
+DISABLE_BACKUP=0
+FLASH_OTP_KEYSTORE=1
+WOLFCRYPT_TZ=1
+WOLFCRYPT_TZ_PSA=1
+ARMORED=1
+WOLFBOOT_UDS_UID_FALLBACK_FORTEST=0

config/examples/stm32h5-tz-psa.config

@@ -33,3 +33,4 @@ WOLFCRYPT_TZ=1
 WOLFCRYPT_TZ_PSA=1
 IMAGE_HEADER_SIZE?=1024
 ARMORED=1
+WOLFBOOT_UDS_UID_FALLBACK_FORTEST=1

docs/DICE.md

@@ -0,0 +1,122 @@
+# DICE Attestation
+
+This document describes the DICE-based PSA attestation service in wolfBoot,
+including the token format, keying options, and how to access the service from
+non-secure code.
+
+## Protocol overview
+
+wolfBoot implements the PSA Certified Attestation API and emits a
+COSE_Sign1-wrapped EAT token following the PSA Attestation Token profile.
+The minimum claim set includes:
+
+- Nonce binding (challenge).
+- Device identity (UEID).
+- Implementation ID and lifecycle when available.
+- Measured boot components for wolfBoot and the boot image.
+
+The attestation token is produced by the secure world service and signed with
+an attestation key derived by DICE or supplied as a provisioned IAK.
+
+## Implementation summary
+
+The implementation lives under `src/dice/` and is shared across targets. The
+service is invoked through the PSA Initial Attestation API and builds the
+COSE_Sign1 token using a minimal CBOR encoder.
+
+- Claim construction and COSE_Sign1 encoding: `src/dice/dice.c`.
+- PSA Initial Attestation service dispatch: `src/arm_tee_psa_ipc.c`.
+- NSC wrappers for the PSA Initial Attestation API: `zephyr/src/arm_tee_attest_api.c`.
+
+Measured boot claims reuse the image hashing pipeline already used by
+wolfBoot to validate images. Component claims include a measurement type,
+measurement value, and a description string.
+
+## Keying model
+
+wolfBoot supports two keying modes selected at build time.
+
+### DICE derived key (default for no provisioning)
+
+- UDS/HUK-derived secret is fetched via `hal_uds_derive_key()`.
+- CDI and signing key material are derived deterministically using HKDF.
+- The attestation keypair is derived deterministically and used to sign the
+  COSE_Sign1 payload.
+
+This path requires no external provisioning and binds the attestation key to
+UDS plus measured boot material.
+
+### Provisioned IAK
+
+If a platform already provisions an Initial Attestation Key (IAK), wolfBoot
+can use it directly to sign the token.
+
+The attestation service calls `hal_attestation_get_iak_private_key()` to
+retrieve the private key material from secure storage (or a manufacturer
+injection flow). The IAK is used instead of the DICE derived key.
+
+## HAL integration (per-target)
+
+These HAL hooks are optional and have weak stubs for non-TZ boards. Target
+families must implement the appropriate subset based on hardware support.
+
+- `hal_uds_derive_key(uint8_t *out, size_t out_len)`
+  - Returns a device-unique secret (UDS/HUK-derived) for DICE key derivation.
+  - Test-only fallback: when `WOLFBOOT_UDS_UID_FALLBACK_FORTEST=1`, targets
+    may derive UDS from the device UID for demo purposes. This should not be
+    used in production builds.
+  - HKDF hash selection follows the configured measurement hash; for
+    `WOLFBOOT_HASH_SHA3_384`, HKDF uses SHA3-384 as well.
+- `hal_attestation_get_ueid(uint8_t *buf, size_t *len)`
+  - Returns a stable UEID. If unavailable, the UEID is derived from UDS.
+- `hal_attestation_get_implementation_id(uint8_t *buf, size_t *len)`
+  - Optional implementation ID for the token.
+- `hal_attestation_get_lifecycle(uint32_t *lifecycle)`
+  - Optional lifecycle state for the token.
+- `hal_attestation_get_iak_private_key(uint8_t *buf, size_t *len)`
+  - Optional provisioned IAK private key (used in IAK mode only).
+
+## STM32H5 OBKeys UDS (optional)
+
+STM32H5 devices provide OBKeys secure storage areas tied to temporal isolation
+levels (HDPL). The HDPL1 area is intended for iRoT keys and is the recommended
+location for a device-unique UDS when `WOLFBOOT_UDS_OBKEYS=1` is enabled. OBKeys
+secure storage is only available on STM32H5 lines except STM32H503.
+
+Provisioning uses STs secure data provisioning flow:
+
+1. Create an OBKeys provisioning file (`.obk`) using STM32TrustedPackageCreator
+   (CLI supports `-obk <xml>` input).
+2. Program the `.obk` file using STM32CubeProgrammer CLI with the `-sdp` option.
+
+3. After provisioning, move the device to the CLOSED state as appropriate for
+   production.
+
+When `WOLFBOOT_UDS_OBKEYS=1`, the STM32H5 HAL first attempts to read UDS from
+OBKeys using a platform hook (`stm32h5_obkeys_read_uds`). Integrate this hook
+with your RSSe/RSSLib provisioning flow (DataProvisioning API) as described in
+ST documentation.
+
+## NSC access (non-secure API)
+
+The non-secure application calls the PSA Initial Attestation API wrappers:
+
+- `psa_initial_attest_get_token_size()`
+- `psa_initial_attest_get_token()`
+
+These are provided in `zephyr/include/psa/initial_attestation.h` and are
+implemented as NSC calls in `zephyr/src/arm_tee_attest_api.c`.
+
+When `WOLFCRYPT_TZ_PSA=1`, the NS application can also use PSA Crypto through
+`zephyr/include/psa/crypto.h` via the NSC dispatch path
+(`zephyr/src/arm_tee_crypto_api.c`). PSA Protected Storage uses
+`zephyr/include/psa/protected_storage.h` in the same fashion.
+
+## Test application
+
+The STM32H5 TrustZone test application in `test-app/` exercises PSA crypto,
+attestation, and store access. It requests a token at boot and can perform
+PSA crypto operations from the non-secure side.
+
+See `docs/Targets.md` for the STM32H5 TrustZone scenarios and how to enable
+PSA mode.

docs/STM32-TZ.md

@@ -33,6 +33,15 @@ The `WOLFCRYPT_TZ_PSA` option provides a standard PSA Crypto interface using
 wolfPSA in the secure domain. The key storage uses the same secure flash
 keystore backend as PKCS11, exposed through the wolfPSA store API.
 
+### PSA Initial Attestation (DICE)
+
+When `WOLFCRYPT_TZ_PSA=1` is enabled, wolfBoot exposes the PSA Initial
+Attestation API to non-secure applications. The attestation token is built
+using the DICE flow in `src/dice/` and returned as a COSE_Sign1 token.
+
+See [DICE Attestation](DICE.md) for the full protocol description, HAL hooks
+(UDS, UEID, lifecycle, implementation ID), and provisioned IAK support.
+
 ### Image header size
 
 The `IMAGE_HEADER_SIZE` option has to be carefully tuned to accommodate for the

docs/Targets.md

@@ -1543,6 +1543,10 @@ non-secure callables (NSC).
 
 The example configuration for this scenario is available in [/config/examples/stm32h5-tz.config](/config/examples/stm32h5-tz.config).
 
+When `WOLFCRYPT_TZ_PSA=1` is enabled, the STM32H5 test application exercises PSA
+Crypto, PSA Protected Storage, and PSA Initial Attestation from the non-secure
+side. See [DICE Attestation](/docs/DICE.md) for details on the attestation flow
+and APIs.
 For more information, see [/docs/STM32-TZ.md](/docs/STM32-TZ.md).
 
 ### Scenario 3: DUALBANK mode

hal/hal.c

@@ -25,6 +25,7 @@
 #include "hal.h"
 #include "string.h"
 #include "printf.h"
+#include "wolfboot/wolfboot.h"
 
 /* Test for internal flash erase/write */
 /* Use TEST_EXT_FLASH to test ext flash (see spi_flash.c or qspi_flash.c) */
@@ -279,3 +280,37 @@ int hal_flash_test_dualbank(void)
 #endif /* DUALBANK_SWAP */
 
 #endif /* TEST_FLASH */
+
+WEAKFUNCTION int hal_uds_derive_key(uint8_t *out, size_t out_len)
+{
+    (void)out;
+    (void)out_len;
+    return -1;
+}
+
+WEAKFUNCTION int hal_attestation_get_lifecycle(uint32_t *lifecycle)
+{
+    (void)lifecycle;
+    return -1;
+}
+
+WEAKFUNCTION int hal_attestation_get_implementation_id(uint8_t *buf, size_t *len)
+{
+    (void)buf;
+    (void)len;
+    return -1;
+}
+
+WEAKFUNCTION int hal_attestation_get_ueid(uint8_t *buf, size_t *len)
+{
+    (void)buf;
+    (void)len;
+    return -1;
+}
+
+WEAKFUNCTION int hal_attestation_get_iak_private_key(uint8_t *buf, size_t *len)
+{
+    (void)buf;
+    (void)len;
+    return -1;
+}