Secure Boot for MCUs Using OpenSSL Public and Private Keys
Implementing secure boot in a microcontroller (MCU) environment with public-key cryptography
ensures that only authenticated firmware is executed. OpenSSL is a popular cryptographic
toolkit used to generate and manage key pairs for such processes. Below is a practical step-by-
step approach to developing secure boot for an MCU using OpenSSL-generated public and
private keys.
Overview of Secure Boot
Secure boot is a process that ensures only trusted, signed firmware is executed by the
MCU during startup.
It relies on asymmetric cryptography: The firmware image is signed using a private key;
during boot, the MCU verifies the firmware using a corresponding public key stored securely
on the device [1] [2] .
Key Steps for Implementation
1. Generate the Key Pair with OpenSSL
Use OpenSSL to create a public-private key pair:
# Generate a 2048-bit RSA private key
openssl genrsa -out private_key.pem 2048
# Extract the corresponding public key
openssl rsa -in private_key.pem -pubout -out public_key.pem
Alternatively, for ECC keys:
openssl ecparam -name prime256v1 -genkey -noout -out ecdsa_private.pem
openssl ec -in ecdsa_private.pem -pubout -out ecdsa_public.pem
The private key will be used by the firmware developer to sign all firmware images. The public
key will be embedded in the MCU for verification [2] [3] [4] .
2. Sign the Firmware Image
Before releasing or updating firmware:
The developer signs the compiled firmware image with the private key:
openssl dgst -sha256 -sign private_key.pem -out firmware.sig firmware.bin
This command generates a digital signature (firmware.sig) for the firmware binary
(firmware.bin) [2] .
3. Embed the Public Key in the MCU
Convert the public key to a suitable format for the MCU—often as a C header file:
# Convert to DER format
openssl rsa -in public_key.pem -pubout -outform DER -out public_key.der
# Convert DER to a C array
xxd -i public_key.der > src/public_key.h
Flash the public key (or its hash, depending on the MCU architecture) into a secure,
immutable memory region (like eFuse, OTP memory, or protected flash). This establishes a
root of trust, as the private key never leaves the signing environment [5] [2] [4] .
4. MCU Bootloader Verification Logic
Upon every boot, the MCU's bootloader reads the firmware and its signature.
The bootloader uses the embedded public key to verify the firmware signature:
Verifies that the firmware was signed with the trusted private key.
If verification fails, the boot process is halted, and the firmware is not executed [1] [2] .
This cryptographic check is often performed using standard cryptographic libraries, or
custom verification routines based on the available cryptographic hardware support on the
MCU [2] [3] .
5. (Optional) Using Certificates
For added trust, you can generate a self-signed certificate:
openssl req -new -x509 -key private_key.pem -out cert.pem -days 365
Embed the certificate in the firmware and use it to validate upgrade chains or as a flexible
mechanism for public key rotation [2] .
Summary Table: Secure Boot Flow with OpenSSL
Secure Boot Step OpenSSL Example Command Where Performed
Generate Private/Public Key
openssl genrsa or openssl ecparam Developer workstation
Pair
Sign Firmware Image openssl dgst -sha256 -sign ... Developer workstation
Secure Boot Step OpenSSL Example Command Where Performed
MCU (flash, eFuse,
Embed Public Key in MCU xxd -i or MCU tool for secure storage
OTP)
Firmware Verification at (Bootloader logic with public key, RSA_verify or MCU bootloader
Boot ECDSA)
Developer + MCU
(Optional) Certificate Usage openssl req -new -x509
firmware
Key Considerations
Private Key Protection: Always keep the signing private key in a secure environment—
never embed or expose it outside production environments [5] [6] .
MCU Support: MCU must support the cryptographic algorithms selected (RSA, ECDSA,
etc.) and provide a secure storage option for the public key or its hash [5] [3] .
Bootloader Role: The security of the system depends on the integrity and correctness of
the bootloader logic that performs signature checking [5] [3] [2] .
Example Workflow (Summary)
1. Key Generation: Use OpenSSL to generate keys and optionally create certificates.
2. Firmware Signing: Sign each firmware update with the private key.
3. Provisioning: Embed the public key in MCU secure memory during manufacturing.
4. Boot-Time Verification: Bootloader uses the public key to check firmware signature; only
valid, unmodified code can run.
Implementing secure boot with OpenSSL and asymmetric cryptography on MCUs is a standard,
robust approach. It leverages proven cryptographic practices, strengthens firmware update
security, and is adaptable to a wide range of MCU architectures and use cases [1] [5] [2] [3] [4] .
⁂
1. https://www.numberanalytics.com/blog/ultimate-guide-secure-boot-microcontrollers
2. https://www.linkedin.com/pulse/unlocking-security-openssl-implementing-secure-boot-rajesh-bhagat-
ch6kc
3. https://static.crysys.hu/publications/files/setit/thesis_bme_Gedeon20bsc.pdf
4. https://community.st.com/t5/stm32-mpus-products-and-hardware/key-format-for-secure-boot/td-p/21
3740
5. https://www.ti.com/lit/an/swra651/swra651.pdf
6. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-
creation-and-management-guidance?view=windows-11
