External signing method with sysbuild

[PragatiGarg-eaton]

Hi,

I am working on building and flashing the MCUBOOT+ application using sysbuild on nucleo_u575zi_q and nucleo_h743zi.
And, I am looking for a standard approach where we can sign the binaries externally by utilizing the sysbuild method.

• Currently, I am able to sign the binaries locally utilizing the sysbuild approach, which invokes the imgtool program. But, facing challenges while signing the binaries externally (from standard corporate method). As during the (west) building of the binaries, we need to handle the user prompts for user name and password during the building itself, which is currently getting aborted and then failing.

• From the documentation, I found out about the 'rimage' method. Would it be useful here? If so, how should I proceed further? https://docs.zephyrproject.org/latest/develop/west/sign.html#rimage

Question: How can we sign the binaries externally by utilizing sysbuild approach?

OS: Windows
zephyr version: 3.2.0

Links:
https://docs.zephyrproject.org/latest/build/sysbuild/index.html#sysbuild-targets

[PragatiGarg-eaton]

@erwango, can you please look into this.

[nordicjm]

I don't know what you mean by username and password prompts because there is no prompt when signing but the default signing script is https://github.com/zephyrproject-rtos/zephyr/blob/main/cmake/mcuboot.cmake which can be overridden by setting the SIGNING_SCRIPT target property. In your own script, you can use whichever tools you want for signing. And no, rimage is for a different system.

[PragatiGarg-eaton]

For standard corporate based signing, user inputs and password are required for the authentication. This has been handled in our signing script, which we are calling from https://github.com/zephyrproject-rtos/zephyr/blob/main/cmake/mcuboot.cmake already.

But, here the concern is, even though we utilize the SIGNING_SCRIPT target property method, it will ultimately call our script, where user login creds will be needed while performing the west build. So how can we manage this?

[nordicjm]

I would doubt that would work since the point of the signing is it should be completely unattended (i.e. no GUI display) and would assume it is invoked via a pipe (without a window). You'd probably need to call a program that then executes another process to do signing if you wanted it to be able to use the display.

[PragatiGarg-eaton]

Hi @nordicjm,@shubhamkulkarni97, I was exploring few more options to accomplish this. Few ways are working fine too.

But in one way, where I want to generate the unsigned image along with mcuboot binary using sysbuild : I enabled the CONFIG_MCUBOOT_GENERATE_UNSIGNED_IMAGE = y in the west build -b <board_name> -p --sysbuild -- -DCONFIG_MCUBOOT_GENERATE_UNSIGNED_IMAGE.
But at (

zephyr/cmake/mcuboot.cmake

Line 23 in bf6c2fc

if(NOT "${CONFIG_MCUBOOT_GENERATE_UNSIGNED_IMAGE}")

) GENERATE_UNSIGNED_IMAGE is being added with NOT logic, which will not allow me to return from

zephyr/cmake/mcuboot.cmake

Line 184 in bf6c2fc

zephyr_mcuboot_tasks()

function and generate an unsigned image. Then how can I utilize this?

I also tried by eliminating the NOT condition, it works fine for sysbuild, but then it is creating problem with default build command: west build -b <board_name> -p . Logic goes forward and starts signing the application even with default west build command.

Please share your suggestions here on how can I generate the unsigned image along with mcuboot binary using sysbuild.

[JPHutchins]

It is a bit obfuscated because it's in a pytest harness, but generally producing extra images unsigned or signed by arbitrary keys is going to involve cmake calling imgtool.

zephyr/tests/boot/mcuboot_multiple_keys/pytest/test_multiple_keys.py

Lines 80 to 93 in da9b7b9

	def resign_application(app_build: Path, key_name: str) -> Path:
	"""Re-sign the built application with a different key and return the new
	image. Models a production custodian signing the release binary out-of-band:
	the build's imgtool command is reused verbatim except for the key (resolved
	against the build's signing-key directory) and the output path."""
	argv: Final = _imgtool_sign_argv(app_build)
	key: Final = argv.index("--key")
	signing_key: Final = Path(argv[key + 1]).parent / key_name
	output: Final = app_build / "zephyr" / "zephyr.signed.resigned.bin"
	subprocess.run(
	[*argv[: key + 1], str(signing_key), *argv[key + 2 : -1], str(output)],
	check=True,
	)
	return output

The security model being used is one of custody, in which the developers would never be capable of producing a signed application image. Instead, developers are able to produce a bootloader that has two public keys -- one for development, the other the public half of the tightly-held production key -- and able to produce an app signed by the developer key, not by the production key. Units produced at factory would be produced with a bootloader that will only verify the production key.