nrf5340 - MCUboot secure boot with production keys

[Gabriele]

Hi,
I'm working on nRF5340, NCS v2.6.1, Zephyr v3.4.99.
The net core is running the child image HCI RPMsg controller.
Th app core is running application and child image mcuboot.

I know that by default MCUboot uses generated NSIB key pair <ncs>/bootloader/mcuboot/root-rsa-2048.pem, not to be used for production.
Therefore, for production, my goal is to hash and sign image using custom keys and let MCUBoot to validate it at boot time.

Generating the key was pretty simple using

$ ./scripts/imgtool.py keygen -k mycompany.pem -t rsa-2048

Then I put the key file at path /home/gabriele/myproject/mycompany.pem

In myproject/child_image/mcuboot.conf I set

CONFIG_BOOT_SIGNATURE_KEY_FILE="/home/gabriele/myproject/mycompany.pem"
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_VALIDATE_SLOT0=y

In /home/gabriele/myproject/prj.conf I set

CONFIG_SECURE_BOOT=y
CONFIG_SB_SIGNING_KEY_FILE="/home/gabriele/myproject/mycompany.pem"

At build time I get the following error in the end

[153/158] Linking C executable zephyr/zephyr_pre0.elf
[154/158] Generating linker.cmd
[155/158] Generating isr_tables.c, isr_tables_vt.ld, isr_tables_swi.ld
[156/158] Building C object zephyr/CMakeFiles/zephyr_final.dir/misc/empty_file.c.obj
[157/158] Building C object zephyr/CMakeFiles/zephyr_final.dir/isr_tables.c.obj
[158/158] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       24538 B      34176 B     71.80%
             RAM:        3488 B        64 KB      5.32%
           SRAM1:          0 GB        64 KB      0.00%
        IDT_LIST:          0 GB        32 KB      0.00%
[232/243] Building C object zephyr/CMakeFiles/zephyr_final.dir/isr_tables.c.obj
[233/243] Creating public key from private key used for signing
[235/243] Completed 'b0n_subimage'
[236/243] Creating data to be provisioned to the Bootloader, storing to provision.hex
[238/243] Generating zephyr/b0n_container.hex
[239/243] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      177528 B       222 KB     78.09%
             RAM:       47604 B        64 KB     72.64%
           SRAM1:          0 GB        64 KB      0.00%
        IDT_LIST:          0 GB        32 KB      0.00%
[240/243] Generating zephyr/app.hex
[240/243] Creating signature of application
[241/243] Creating validation for zephyr.hex, storing to
[243/243] Generating zephyr/merged_CPUNET.hex
[368/394] Building C object zephyr/CMakeFiles/zephyr_final.dir/isr_tables.c.obj
[369/394] Creating data to be provisioned to the Bootloader, storing to provision.hex
Traceback (most recent call last):
  File "/home/gabriele/spiro-dev/nrf53sdk/ncs/zephyr/../nrf/scripts/bootloader/provision.py", line 199, in <module>
    main()
  File "/home/gabriele/spiro-dev/nrf53sdk/ncs/zephyr/../nrf/scripts/bootloader/provision.py", line 180, in main
    hashes = get_hashes(
  File "/home/gabriele/spiro-dev/nrf53sdk/ncs/zephyr/../nrf/scripts/bootloader/provision.py", line 140, in get_hashes
    digest = sha256(VerifyingKey.from_pem(f.read()).to_string()).digest()[:16]
  File "/home/gabriele/spiro-dev/nrf53sdk/zephyr/python-env/lib/python3.8/site-packages/ecdsa/keys.py", line 318, in from_pem
    return cls.from_der(
  File "/home/gabriele/spiro-dev/nrf53sdk/zephyr/python-env/lib/python3.8/site-packages/ecdsa/keys.py", line 393, in from_der
    raise der.UnexpectedDER(
ecdsa.der.UnexpectedDER: Unexpected object identifier in DER encoding: (1, 2, 840, 113549, 1, 1, 1)
[371/394] Completed 'hci_ipc_subimage'
FAILED: zephyr/provision.hex /home/gabriele/spiro-dev/apps/spiro/build/zephyr/provision.hex 
cd /home/gabriele/spiro-dev/apps/spiro/build/zephyr && /home/gabriele/spiro-dev/nrf53sdk/zephyr/python-env/bin/python /home/gabriele/spiro-dev/nrf53sdk/ncs/zephyr/../nrf/scripts/bootloader/provision.py --s0-addr 0x14200 --s1-addr 0x68100 --provision-addr 0xff8100 --public-key-files /home/gabriele/spiro-dev/apps/spiro/build/zephyr/nrf/subsys/bootloader/generated/public.pem --output /home/gabriele/spiro-dev/apps/spiro/build/zephyr/provision.hex --max-size 0x280 --num-counter-slots-version 20
[373/394] Generating ../../zephyr/net_core_app_update.bin
image.py: sign the payload
[374/394] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      320356 B     343808 B     93.18%
             RAM:      229084 B       440 KB     50.84%
        IDT_LIST:          0 GB        32 KB      0.00%
[375/394] Generating ../../zephyr/net_core_app_signed.hex
image.py: sign the payload
ninja: build stopped: subcommand failed.

Can anyone give a help ?

[Vidar Berg]

Hello,

Please check if 'CONFIG_BOOT_SIGNATURE_TYPE_RSA' is indeed selected in build/mcuboot/zephyr/.config. This line " File "/home/gabriele/spiro-dev/nrf53sdk/zephyr/python-env/lib/python3.8/site-packages/ecdsa/keys.py", line 393, in from_der
raise der.UnexpectedDER(" indicates that the build system is trying to use ECDSA instead of RSA.

Best regards,

Vidar

[Gabriele]

yes Vidar, it is.

So, I generated a ECDSA key and switch to 

CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_BOOT_SIGNATURE_TYPE_RSA=n

The build ends successfully but, at flashing time, I just get this on the console.

*** Booting nRF Connect SDK 7d80c8bcf3c8 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Verifying signature against key 0.
Hash: 0x8f...99
Firmware signature verified.
Firmware version 1
Setting monotonic counter (version: 1, slot: 0)
Booting (0x8200).

What's going on ?

[Gabriele]

I've double checked CONFIG_SERIAL=y is needed.
I also wanted to test MCUBoot efficacy in preventing firmware update under signature mismatch.
First of all, I build and installed a firmware with

mcuboot.conf
  CONFIG_BOOT_SIGNATURE_KEY_FILE="../../../../mycompany.pem"
myproject.conf
  CONFIG_SB_SIGNING_KEY_FILE="../../mycompany.pem"

Then I tryed to flash another firmware with

mcuboot.conf
  CONFIG_BOOT_SIGNATURE_KEY_FILE="../../../../mycompany.pem"
myproject.conf
  CONFIG_SB_SIGNING_KEY_FILE="../../hackering.pem"

The result is as follows

*** Booting nRF Connect SDK 7d80c8bcf3c8 ***
Attempting to boot slot 0.
Attempting to boot from address 0x8200.
Firwmare has been invalidated: 0x91020000.
Failed to validate, permanently invalidating!
Attempting to boot slot 1.
No fw_info struct found.
No bootable image found. Aborting boot.

This is good, in the sense that a public key mismatch has been detected and the update blocked.
The problem is that the device cannot reboot anymore !

[Vidar Berg]

Could you please post your bootloader configuration file (build/mcuboot/zephyr/.config) here?

[Gabriele]

Hi, Vidar

I made some progress. I've verified that the firmware update, controlled by immutable MCUboot, fails if and only if I introduce on purpose any corruption or invalid signature on the application firmware. This makes me confident the secure boot is working fine.

A problem is that the message I get on the console is always the same, either if the firmware update succeed or fails. It is correct ? I expected to have different messages (see figure)

Please find attached the current config of application and mcuboot. Can you check it ?

4186.config.zip

[Vidar Berg]

Gabriele said:

I made some progress. I've verified that the firmware update, controlled by immutable MCUboot, fails if and only if I introduce on purpose any corruption or invalid signature on the application firmware.

You are enabling the immutable bootloader with CONFIG_SECURE_BOOT=y, and using mcuboot as the second stage bootloader. 

The immutable bootloader will only validate the mcuboot image.

https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/nrf/config_and_build/bootloaders/bootloader.html 

[Gabriele]

Hi Vidar,

is there anything wrong I can fix or improve ? 

[Vidar Berg]

Hi,

If you want to test and verify the boot validation mechanism in the immutable bootloader, you need to invalidate mcuboot image, not the application image.

[Gabriele]

In reality I meant to validate the application image, not the mcuboot image. I think it makes more sense, because the malicious guy would attempt to hack the application in first place. How to do that ? 

[Vidar Berg]

The "Firmware signature verified" message seen in your debug log is from the immutable bootloader after verifying the mcuboot image. You can enable logging in mcuboot to see the status of the applicaiton FW validation.

[Gabriele]

In mcuboot.conf I already have 

CONFIG_LOG=y
CONFIG_MCUBOOT_LOG_LEVEL_INF=y

Isn't it enough ?

[Vidar Berg]

Yes, it should be, but I didn't see any logs from MCUBoot in the image you posted. Is this section printed by the app: 

?