You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/Signing.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -134,6 +134,7 @@ When building wolfBoot and the test app with the Makefile, the `USER_*` variable
134
134
-`USER_PRIVATE_KEY`: Path to your leaf signing key (DER format)
135
135
-`USER_PUBLIC_KEY`: Path to your leaf public key (DER format)
136
136
-`USER_CERT_CHAIN`: Path to your certificate chain (DER format)
137
+
-`WOLFHSM_SECONDARY_ROOT_CA_NVM_ID`: Optional wolfHSM NVM object ID for a secondary root CA fallback
137
138
138
139
Example:
139
140
@@ -150,7 +151,7 @@ If `USER_CERT_CHAIN` is not provided when `CERT_CHAIN_VERIFY=1`, a dummy certifi
150
151
151
152
**Note:** If your private key is managed by a third party and you only have access to the public key, use `keygen -i` to import it instead. See the [Keygen tool](#keygen-tool) section above.
152
153
153
-
Certificate chain verification of images is currently limited to use in conjunction with wolfHSM. See [wolfHSM.md](wolfHSM.md) for more details.
154
+
Certificate chain verification of images is currently limited to use in conjunction with wolfHSM. For wolfHSM builds, `WOLFHSM_SECONDARY_ROOT_CA_NVM_ID=<id>` enables fallback to a second root CA only when primary root verification fails. The secondary root certificate must be provisioned in wolfHSM NVM at that ID. See [wolfHSM.md](wolfHSM.md) for more details.
154
155
155
156
#### Target partition id (Multiple partition images, "self-update" feature)
Copy file name to clipboardExpand all lines: docs/compile.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -441,6 +441,10 @@ make CERT_CHAIN_VERIFY=1 \
441
441
442
442
When `CERT_CHAIN_VERIFY=1` is set without `USER_CERT_CHAIN`, the build auto-generates a dummy 3-tier certificate hierarchy in `test-dummy-ca/` for testing. This also applies to wolfHSM NVM image generation when applicable.
443
443
444
+
For wolfHSM certificate-chain builds, `WOLFHSM_SECONDARY_ROOT_CA_NVM_ID=<id>` can be set to compile in a secondary root CA fallback. wolfBoot verifies against the primary root CA NVM ID provided by the HAL first, then retries with the configured secondary NVM ID only if the primary certificate-chain verification fails. Leave it unset for the existing single-root behavior.
445
+
446
+
The secondary root certificate must be provisioned in wolfHSM NVM at the configured object ID. The option applies only to wolfHSM certificate-chain trust validation; signature verification continues to use the cached leaf public key from whichever root verified the chain.
447
+
444
448
### Manual Key Management
445
449
446
450
For advanced scenarios (multiple keys, mixed algorithms, partition-restricted keys, or third-party managed private keys), use the `keygen` tool directly instead of the `USER_*` variables.
Copy file name to clipboardExpand all lines: docs/wolfHSM.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,7 +51,7 @@ The certificate verification process with wolfHSM works as follows:
51
51
4. A certificate chain is created consisting of the signing identity certificate and an optional number of intermediate certificates, where trust is chained back to the root CA.
52
52
5. During the signing process, the image is signed with the signer private key and the certificate chain is embedded in the firmware image header.
53
53
6. During boot, wolfBoot extracts the certificate chain from the firmware header
54
-
7. wolfBoot uses the wolfHSM server (remotely or directly, depending on configuration) to verify the certificate chain against a pre-provisioned root CA certificate stored on the HSM and caches the public key of the leaf certificate if the chain verifies as trusted
54
+
7. wolfBoot uses the wolfHSM server (remotely or directly, depending on configuration) to verify the certificate chain against a pre-provisioned root CA certificate stored on the HSM and caches the public key of the leaf certificate if the chain verifies as trusted. If `WOLFHSM_SECONDARY_ROOT_CA_NVM_ID` is configured and the primary root check fails, wolfBoot retries the certificate chain against that secondary root CA NVM object.
55
55
8. If the chain is trusted, wolfBoot uses the cached public key from the leaf certificate to verify the firmware signature on the wolfHSM server
56
56
57
57
To use certificate verification with wolfHSM:
@@ -61,6 +61,8 @@ To use certificate verification with wolfHSM:
61
61
3. Pre-provision the root CA certificate on the wolfHSM server at the NVM ID specified by the HAL `hsmNvmIdCertRootCA`
62
62
4. Sign firmware images with the `--cert-chain` option, providing a DER-encoded certificate chain
63
63
64
+
Optionally set `WOLFHSM_SECONDARY_ROOT_CA_NVM_ID=<id>` to allow certificate-chain fallback to a second wolfHSM root CA object. The secondary root certificate must be provisioned in wolfHSM NVM at the configured object ID. This fallback only affects wolfHSM certificate-chain trust validation; the image signature is still verified with the cached leaf public key from the chain that verified successfully.
65
+
64
66
To build the simulator using wolfHSM for certificate verification:
65
67
66
68
-**Client Mode**: Use [config/examples/sim-wolfHSM-client-certchain.config](config/examples/sim-wolfHSM-client-certchain.config)
@@ -84,6 +86,12 @@ This option enables use of the reserved wolfHSM public key ID for firmware authe
84
86
85
87
If this option is not defined, cryptographic operations are still performed on the wolfHSM server, but wolfBoot assumes the key material is present in the keystore and NOT stored on the HSM. This means that wolfBoot will first load keys from the keystore, send the key material to the wolfHSM server at the time of use (cached as ephemeral keys), and finally evict the key from the HSM after usage. This behavior is typically only useful for debugging or testing scenarios, where the keys may not be pre-loaded onto the HSM. The keystore for use in this mode should not be generated with the `--nolocalkeys` option.
86
88
89
+
### `WOLFHSM_SECONDARY_ROOT_CA_NVM_ID`
90
+
91
+
This Make/config option defines `WOLFBOOT_WOLFHSM_SECONDARY_ROOT_CA_NVM_ID` and enables a secondary root CA fallback for wolfHSM certificate-chain verification. wolfBoot first verifies the image certificate chain against `hsmNvmIdCertRootCA`. If that attempt fails due to a wolfHSM API error or a certificate validation failure, wolfBoot retries with the configured secondary NVM ID.
92
+
93
+
Leave this option unset to preserve the normal single-root behavior. When set, the secondary root CA certificate must already be provisioned in wolfHSM NVM at that object ID, for example `WOLFHSM_SECONDARY_ROOT_CA_NVM_ID=2`.
94
+
87
95
## HAL Implementations
88
96
89
97
In addition to the standard wolfBoot HAL functions, wolfHSM-enabled platforms must also implement or instantiate the following wolfHSM-specific items in the platform HAL:
@@ -96,6 +104,7 @@ In addition to the standard wolfBoot HAL functions, wolfHSM-enabled platforms mu
96
104
-`hsmDevIdHash`: The HSM device ID for hash operations. This is used to identify the HSM device to wolfBoot.
97
105
-`hsmDevIdPubKey`: The HSM device ID for public key operations. This is used to identify the HSM device to wolfBoot.
98
106
-`hsmKeyIdPubKey`: The HSM key ID for public key operations. This is used to identify the key to use for public key operations.
107
+
-`hsmNvmIdCertRootCA`: The wolfHSM NVM ID for the primary trusted root CA certificate when certificate-chain verification is enabled.
0 commit comments