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
+19Lines changed: 19 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -128,6 +128,25 @@ wolfBoot also supports verifying firmware images using certificate chains instea
128
128
129
129
To generate an image for use with this mode, pass the `--cert-chain CERT_CHAIN.der` option to the sign tool, where `CERT_CHAIN.der` is a der encoded certificate chain containing one or more certificates in SSL order (leaf/signer cert last). Note that the sign tool still expects a signing private key to be provided as described above, and assumes that the public key of the signer cert in the chain corresponds to the signing private key.
130
130
131
+
When building wolfBoot and the test app with the Makefile, certificate chain signing can be configured using the following variables:
-`USER_PRIVATE_KEY`: Path to your leaf signing key (DER format)
135
+
-`USER_PUBLIC_KEY`: Path to your leaf public key (DER format)
136
+
-`USER_CERT_CHAIN`: Path to your certificate chain (DER format)
137
+
138
+
Example:
139
+
140
+
```sh
141
+
make CERT_CHAIN_VERIFY=1 \
142
+
USER_PRIVATE_KEY=my-leaf-private-key.der \
143
+
USER_PUBLIC_KEY=my-leaf-pubkey.der \
144
+
USER_CERT_CHAIN=my-cert-chain.der
145
+
```
146
+
Note that it is up to the user to guarantee that `USER_PUBLIC_KEY` and `USER_PRIVATE_KEY` both correspond to the leaf certificate identity in the chain.
147
+
148
+
If `USER_CERT_CHAIN` is not provided when `CERT_CHAIN_VERIFY=1`, a dummy certificate hierarchy is auto-generated for testing. See the [Compiling wolfBoot](compile.md#key-generation-and-signing) documentation for full details on these options.
149
+
131
150
Certificate chain verification of images is currently limited to use in conjunction with wolfHSM. See [wolfHSM.md](wolfHSM.md) for more details.
132
151
133
152
#### Target partition id (Multiple partition images, "self-update" feature)
Copy file name to clipboardExpand all lines: docs/compile.md
+79Lines changed: 79 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -355,3 +355,82 @@ Available overrides:
355
355
-`WOLFBOOT_LIB_WOLFTPM`: Path to the [wolfTPM](https://github.com/wolfSSL/wolfTPM) library source code
356
356
-`WOLFBOOT_LIB_WOLFPKCS11`: Path to the [wolfPKCS11](https://github.com/wolfssl/wolfpkcs11) library source code
357
357
-`WOLFBOOT_LIB_WOLFHSM`: Path to the [wolfHSM](https://github.com/wolfSSL/wolfHSM) library source code
358
+
359
+
## Key Generation and Signing
360
+
361
+
### Default Key Behavior
362
+
363
+
When building wolfBoot for the first time, the build system automatically generates the cryptographic keys needed for firmware signing and verification.
364
+
365
+
-**Private Key**: `wolfboot_signing_private_key.der` - Used to sign firmware images
366
+
-**Keystore**: `src/keystore.c` - Contains the public key embedded in the bootloader
367
+
368
+
The key algorithm is determined by the `SIGN` variable (e.g., `SIGN=ECC256`, `SIGN=RSA2048`).
369
+
370
+
For most targets, the makefile also builds the wolfBoot test app and signs it with the aforementioned key.
371
+
372
+
### User-Provided Keys
373
+
374
+
Instead of auto-generating keys, you can provide your own pre-existing keys for use with the test app by using the following Makefile variables:
375
+
376
+
-`USER_PRIVATE_KEY`: Path to your private signing key (DER format)
377
+
-`USER_PUBLIC_KEY`: Path to your public key (DER format)
378
+
379
+
**Usage:**
380
+
381
+
```sh
382
+
make USER_PRIVATE_KEY=/path/to/my-signing-key.der \
383
+
USER_PUBLIC_KEY=/path/to/my-public-key.der
384
+
```
385
+
386
+
#### Requirements
387
+
388
+
- Both `USER_PRIVATE_KEY` and `USER_PUBLIC_KEY` must be provided together. You cannot supply one without the other.
389
+
- Keys must be in DER format appropriate for the selected `SIGN` algorithm
390
+
391
+
When user-provided keys are specified:
392
+
393
+
1. The build skips auto-generation of `wolfboot_signing_private_key.der`
394
+
2. The keystore (`src/keystore.c`) is generated from your public key
395
+
3. Your private key is used for all signing operations
396
+
397
+
The `USER_` variables are meant to simplify the wolfBoot "demo" behavior where wolfBoot boots a simple test app.
398
+
399
+
### User-Provided Certificate Chain
400
+
401
+
When using certificate chain verification (`CERT_CHAIN_VERIFY=1`), you can also provide your own certificate chain:
402
+
403
+
-`USER_CERT_CHAIN`: Path to your certificate chain (DER format, wolfHSM order with leaf last)
404
+
405
+
**Usage:**
406
+
407
+
```sh
408
+
make CERT_CHAIN_VERIFY=1 \
409
+
USER_PRIVATE_KEY=/path/to/leaf-signing-key.der \
410
+
USER_PUBLIC_KEY=/path/to/leaf-public-key.der \
411
+
USER_CERT_CHAIN=/path/to/my-cert-chain.der
412
+
```
413
+
414
+
**Requirements:**
415
+
416
+
-`USER_CERT_CHAIN` requires both `USER_PRIVATE_KEY` and `USER_PUBLIC_KEY` to be set
417
+
- The user-supplied private and public keys must correspond to the identity of the leaf certificate in the chain
418
+
419
+
When `CERT_CHAIN_VERIFY=1` is set without `USER_CERT_CHAIN`, the build system auto-generates a dummy 3-tier certificate hierarchy (root CA, intermediate, and leaf) in the `test-dummy-ca/` directory for testing purposes. This is then used to sign the test app.
420
+
421
+
### Manual Key Generation
422
+
423
+
As an alternative to the `USER_*` variables, you can manually fulfill the build dependencies:
The build system will detect these existing files and skip auto-generation when make is subsequently invoked. This approach is required when more advanced options like multiple public keys in the keystore are required. In these cases, the keystore generation using the keygen tool and image signing via the sign tool must be performed manually.
Copy file name to clipboardExpand all lines: docs/keystore.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -221,3 +221,13 @@ Returns the permissions mask, as a 32-bit word, for the public key stored in the
221
221
wolfBoot supports certain platforms that contain connected HSMs (Hardware Security Modules) that can provide cryptographic services using keys that are not stored in the device NVM or readable by wolfBoot, for example, wolfHSM. In these scenarios, wolfBoot key tools should be used to generate the keys, which can then be manually loaded into the HSM (see [--exportpubkey](#exporting-the-public-key-to-a-file)). At runtime, wolfBoot will still use the keystore to obtain information about the public keys, specifically the size of the key and the key type, but does not need access to the actual key material.
222
222
223
223
To support this mode of operation, the `keygen` tool supports the `--nolocalkeys` option, which instructs the tool to generate a keystore entry with a zeroed key material. It still generates the `.der` files for private and public keys, so the wolfBoot key tools can sign images, but the `keystore.c` file that is linked into wolfBoot will contain all zeros in the `pubkey` field. Because the key material isn't present in the keystore, the keypair used to sign the image and stored on the HSM for verification can be updated in the field without needing to rebuild wolfBoot against a new `keystore.c`, as long as the signature algorithm and key size does not change. Most targets that use this option will automatically add it to the key generation options or explicitly mention this step in the build documentation.
224
+
225
+
## Using User-Provided Keys with the Keystore and Build System
226
+
227
+
By default, when running `make` for the first time, wolfBoot automatically generates:
228
+
- A signing keypair at `wolfboot_signing_private_key.der`
229
+
- The keystore module at `src/keystore.c` containing the corresponding public key
230
+
231
+
This default behavior can be overridden using the `USER_PRIVATE_KEY` and `USER_PUBLIC_KEY` Makefile variables, allowing you to use externally-managed keys for building the test application and keystore.
232
+
233
+
See [compile.md](./compile.md#key-generation-and-signing) for more information
0 commit comments