nrf5340 - MCUboot secure boot with production keys

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Fri, 05 Jul 2024 09:34:53 GMT

It's weird. In the subsequent tests I've not seen the "Not enough free space" warning anymore.

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Thu, 04 Jul 2024 17:24:01 GMT

It says that there is not enough free space to perform a swap upgrade. Seems like it is trying to place the FW image into the s0/s1 slot intended for mcuboot, given the reported number of bytes available.

Warning messages from MCUBoot in your log:

W: Not enough free space to run swap upgrade
W: required 253952 bytes but only 65536 are available

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Thu, 04 Jul 2024 15:40:11 GMT

OK, I've added

CONFIG_UART_CONSOLE=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_LOG_MODE_MINIMAL=y

Then I checked it out trying a DFU using a not-signed application image

*** 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 2
Booting (0x8200).*** Booting nRF Connect SDK 7d80c8bcf3c8 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 1, Swap type: test
I: Starting swap using move algorithm.
W: Not enough free space to run swap upgrade
W: required 253952 bytes but only 65536 are available
I: Bootloader chainload address offset: 0x30000
I: Jumping to the first image slot*** Booting nRF Connect SDK 7d80c8bcf3c8 ***
[00:00:00.215,698] <inf> hostgw: initialized
[00:00:00.220,581] <inf> hostgw: start thread (priority: 1)
[00:00:00.237,091] <dbg> hostgw: hgw_thread: timeout, buffer size: 1 bytes.

	*********************************
	*       XXXXXXXXXXXXXX          *
	*********************************
	product name : Q
	part number  : C09094-01-99
	serial number: 1234509876
	ble address  : E7:7B:3A:2F:63:D5 (random)
	ble serial   : 2020016037
	fw version   : 1.0-beta17
	fw commit    : 154e35853e82d4b7cae3f3bcfc60c3e81a171983
	hw revision  : A
	hw config    : 0
	auth sw ver  : -.-.-.-
	auth fw ver  : -.-.-.-
	Ta (0.1C)    : 272
	Rh (perc)    : 51
	Pb (mmHg)    : 742

[00:02:14.711,395] <wrn> control: starting dfu..		<-- STARTING DFU OF AN APPLICATION IMAGE WHICH IS NOT SIGNED

*** 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 2
Booting (0x8200).*** Booting nRF Connect SDK 7d80c8bcf3c8 ***
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Image index: 1, Swap type: test
I: Starting swap using move algorithm.
W: Not enough free space to run swap upgrade
W: required 253952 bytes but only 65536 are available
I: Bootloader chainload address offset: 0x30000
I: Jumping to the first image slot*** Booting nRF Connect SDK 7d80c8bcf3c8 ***
[00:00:00.216,217] <inf> hostgw: initialized
[00:00:00.221,069] <inf> hostgw: start thread (priority: 1)
[00:00:00.237,579] <dbg> hostgw: hgw_thread: timeout, buffer size: 1 bytes.

	*********************************
	*       XXXXXXXXXXXXXX          *
	*********************************
	product name : Q
	part number  : C09094-01-99
	serial number: 1234509876
	ble address  : E7:7B:3A:2F:63:D5 (random)
	ble serial   : 2020016037
	fw version   : 1.0-beta17
	fw commit    : 154e35853e82d4b7cae3f3bcfc60c3e81a171983
	hw revision  : A
	hw config    : 0
	auth sw ver  : -.-.-.-
	auth fw ver  : -.-.-.-
	Ta (0.1C)    : 271
	Rh (perc)    : 51
	Pb (mmHg)    : 742

The firmware update gets failed (I know that).
The problem is that from the mcuboot log there is no cues that something went wrong.

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Thu, 04 Jul 2024 12:58:17 GMT

You've set CONFIG_LOG_BACKEND_UART to '=n', which prevents the logger from writing anything to your uart terminal.

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Thu, 04 Jul 2024 06:27:38 GMT

Hi Vidar, please find here the build/mcuboot/zephyr/.config. Yes, the last part of the console output is from the application

devzone.nordicsemi.com/.../mcuboot_5F00_config.zip

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Mon, 01 Jul 2024 14:14:27 GMT

To confirm which symbols are selected, you can check the generated configuration file build/mcuboot/zephyr/.config. Was the last part of your debug output from the application?

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Mon, 01 Jul 2024 12:02:55 GMT

At build time I get

..
Merged configuration '/home/gabriele/spiro-dev/apps/spiro/child_image/mcuboot.conf'
..

This is mcuboot.conf content

CONFIG_SERIAL=y
CONFIG_UART_CONSOLE=n
CONFIG_MCUBOOT_SERIAL=n
CONFIG_FPROTECT=n
CONFIG_BOOT_SERIAL_UART=n
CONFIG_LOG_BACKEND_UART=n
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_CONSOLE_HANDLER=n

CONFIG_BOOT_MAX_IMG_SECTORS=256
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

### Enable ECDSA signing/verification
CONFIG_BOOT_SIGNATURE_KEY_FILE="../../../../cosmed_priv_ecdsa.pem"
CONFIG_BOOT_SIGNATURE_TYPE_RSA=n
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y
CONFIG_BOOT_SIGNATURE_TYPE_ED25519=n
CONFIG_BOOT_VALIDATE_SLOT0=y
CONFIG_FW_INFO_FIRMWARE_VERSION=2
CONFIG_FW_INFO=y

# Logging options
CONFIG_LOG=y
CONFIG_MCUBOOT_LOG_LEVEL_INF=y

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Mon, 01 Jul 2024 11:03:01 GMT

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:

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Mon, 01 Jul 2024 10:41:17 GMT

In mcuboot.conf I already have

CONFIG_LOG=y
CONFIG_MCUBOOT_LOG_LEVEL_INF=y

Isn't it enough ?

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Mon, 01 Jul 2024 09:02:28 GMT

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.

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Mon, 01 Jul 2024 08:01:53 GMT

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 ?

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Mon, 01 Jul 2024 07:55:36 GMT

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.

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Mon, 01 Jul 2024 07:37:07 GMT

Hi Vidar,

is there anything wrong I can fix or improve ?

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Fri, 28 Jun 2024 08:52:33 GMT

[quote user="gabrielef@cosmed.it"]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. [/quote]

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

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Thu, 27 Jun 2024 10:08:59 GMT

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 ?

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Wed, 26 Jun 2024 06:55:06 GMT

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

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Tue, 25 Jun 2024 13:34:37 GMT

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 !

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Tue, 25 Jun 2024 09:56:56 GMT

CONFIG_SERIAL should not be required for the default bootloader configuration, so I'm not sure why this was required.

You can make it relative to your project source directory: https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/nrf/config_and_build/bootloaders/bootloader_adding.html#d207e671

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Mon, 24 Jun 2024 13:53:35 GMT

I've solved by setting this in mcuboot.conf

CONFIG_SERIAL=y

One last question.
I want to avoid to set an absolute path in myproject.conf like

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

How to make it relative, i.e. not showing the host user name ?

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Mon, 24 Jun 2024 09:37:26 GMT

It looks like the program hangs in MCUBoot. I suggest you try to debug the device in VS code to see where it hangs. You may also consider disabling secure boot (CONFIG_SECURE_BOOT=n) to simplify debugging.

RE: nrf5340 - MCUboot secure boot with production keys

Gabriele — Fri, 21 Jun 2024 14:47:43 GMT

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 ?

RE: nrf5340 - MCUboot secure boot with production keys

Vidar Berg — Fri, 21 Jun 2024 13:55:42 GMT

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