Instead of building as standalone repository, wolfBoot can be built as a secure-boot library and integrated in third party bootloaders, custom staging solutions etc.
The wolfBoot secure-boot image verification has a very simple interface.
The core object describing the image is a struct wolfBoot_image, which
is initialized when wolfBoot_open_image_address() is called. The signature is:
int wolfBoot_open_image_address(struct wolfBoot_image* img, uint8_t* image)
where img is a pointer to a local (memset but otherwise uninitialized) structure of type wolfBoot_image, and
image is a pointer to where the signed image is mapped in memory, starting from the beginning
of the manifest header.
On success, zero is returned. If the image does not contain a valid 'magic number' at the beginning
of the manifest, or if the size of the image is bigger than WOLFBOOT_PARTITION_SIZE, -1 is returned.
If the open_image_address operation is successful, two other functions can be invoked:
int wolfBoot_verify_integrity(struct wolfBoot_image *img)
This function verifies the integrity of the image, by calculating the SHA hash of the image content,
and comparing it with the digest stored in the manifest header. img is a pointer to
an object of type wolfBoot_image, previously initialized by wolfBoot_open_image_address.
0 is returned if the image integrity could be successfully verified, -1 otherwise.
int wolfBoot_verify_authenticity(struct wolfBoot_image *img)
This function verifies that the image content has been signed by a trusted counterpart (i.e. that could be verified using one of the public keys available).
0 is returned in case of successful authentication, -1 if anything went wrong during the operation,
and -2 if the signature could be found, but was not possible to authenticate against its public key.
An example application is provided in hal/library.c.
The application test-lib opens a file from a path passed as argument
from the command line, and verifies that the file contains a valid, signed
image that can be verified for integrity and authenticity using wolfBoot in library
mode.
Step 1: use the provided configuration to compile wolfBoot in library mode:
cp config/examples/library.config .config
Step 2: create a file target.h that only contains the following lines:
cat > include/target.h << EOF
#ifndef H_TARGETS_TARGET_
#define H_TARGETS_TARGET_
#define WOLFBOOT_NO_PARTITIONS
#define WOLFBOOT_SECTOR_SIZE 0x20000
#define WOLFBOOT_PARTITION_SIZE 0x20000
#endif /* !H_TARGETS_TARGET_ */
EOF
Change WOLFBOOT_PARTITION_SIZE accordingly. wolfBoot_open_image_address() will discard images larger than
WOLFBOOT_PARTITION_SIZE - IMAGE_HEADER_SIZE.
Step 3: compile keytools and create keys.
make keytools
./tools/keytools/keygen --ed25519 -g wolfboot_signing_private_key.der
Step 4: Create an empty file and sign it using the private key.
touch empty
./tools/keytools/sign --ed25519 --sha256 empty wolfboot_signing_private_key.der 1
Step 5: compile the test-lib application, linked with wolfBoot in library mode, and the public key from the keypair created at step 4.
make test-lib
Step 6: run the application with the signed image
./test-lib empty_v1_signed.bin
If everything went right, the output should be similar to:
Firmware Valid
booting 0x5609e3526590(actually exiting)
An example application using filesystem access is provided in hal/library_fs.c.
The CLI application lib-fs allow querying partition states, triggering updates, and marking the boot partition as successful.
To generate and verify a signed boot partition using simulation and library_fs targets, follow these steps.
You can run these steps using the provided script at tools/scripts/build_lib_fs_example.sh:
./tools/scripts/build_lib_fs_example.sh
Alternatively, you can perform the steps manually as described below:
Step 1: Copy the configuration for simulation and build the signed boot partition:
cp config/examples/sim.config .config
make
This will generate a file with a signed boot partition named internal_flash.dd.
Step 2: Change the target back to library_fs:
cp config/examples/library_fs.config .config
Step 3: Ensure that the partition layout in sim.config matches the layout in library_fs.config.
Step 4: Clean previous build artifacts and build the CLI application:
make clean
make lib-fs
This will produce the lib-fs executable.
Step 5: Mark the BOOT partition as successfully loaded:
./lib-fs success
Step 6: Verify the integrity and authenticity of the BOOT partition:
./lib-fs verify-boot
The example configuration points the binary to access /dev/mtd0 for partition data. You can simulate this file path with modprobe mtdram total_size=16384 erase_size=128. You may need to adjust the file permissions to allow read/write access.
Run the application with one of the supported commands:
./lib-fs <command>
Available commands:
status: Show state of all partitionsget-boot: Get BOOT partition stateget-update: Get UPDATE partition stateupdate-trigger: Trigger an update (sets UPDATE partition to UPDATING)success: Mark BOOT partition as SUCCESSverify-boot: Verify integrity and authenticity of BOOT partitionverify-update: Verify integrity and authenticity of UPDATE partitionhelp: Show usage information
Show all partition states:
./lib-fs status
Trigger an update:
./lib-fs update-trigger
Mark the boot partition as successful:
./lib-fs success
Verify BOOT partition:
./lib-fs verify-boot
Verify UPDATE partition:
./lib-fs verify-update