How can the provisioning of the key file be skipped in the single_slot project during flashing？

[Simple_Gao]

Hi Nordic

Our project is preparing for mass production and we've encountered an issue while designing the flashing solution. Our project is based on the NCS 3.3.0 single_slot project, using the nRF54L15-CAAA. During flashing, we found that after programming the merged.hex file, we also need to execute the command nrfutil device x-provision-keys --traits jlink --key-file .\build\keyfile.json for the program to run. This adds significant inconvenience to our production process, and we would like to skip this step. How should we modify the setup

[AHaug]

Hi,

The key provisioning is a required step for the nRF54L15. Are you asking if you can provision them at a later point, or are you asking if you can skip it completely?

Kind regards,
Andreas

[Simple_Gao]

skip it completely，I can accept the lack of encryption and signature verification.

[AHaug]

Noted, thank you for clarifying.

https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrf/app_dev/device_guides/kmu_guides/kmu_provisioning_overview.html#alternative-provisioning-method-during-development if you happen to be flashing with west, then you can follow these steps to use the built in key instead. To simplify development, you can enable SB_CONFIG_MCUBOOT_GENERATE_DEFAULT_KEY_FILE, which auto-generates a keyfile.json and provisions keys automatically during west flash --erase or west flash --recover — avoiding fully manual provisioning steps.

I assume that you're not using west/NCS tools since this is for mass production preparation?

If you're going to keep the KMU, then I would recommend you to wrap both commands in the production script, i.e 

nrfutil device program --firmware merged.hex --serial-number %SN% --options chip_erase_mode=ERASE_ALL
nrfutil device x-provision-keys --serial-number %SN% --key-file keyfile.json

This is not something I can recommend and must be up to your own discression. If you do not use KMU you can compile the public key into the MCUboot image itself.

SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=n

Then the public key is embedded in the bootloader image, which is part of merged.hex, so a single flash fully programs the device.

Trade-offs to weigh before choosing this:

• You lose hardware-backed, non-readable key storage (the whole security point of the KMU).
• You lose hardware-accelerated ED25519 verification via CRACEN/KMU (slower, less secure boot).
• You can't later use KMU-based key revocation (CONFIG_BOOT_KEYS_REVOCATION).

To reiterate, for a product going to mass production this is usually not recommended unless your threat model genuinely doesn't need secure boot.

Kind regards,
Andreas

[Simple_Gao]

hi AHaug

Thank you for your reply，but after adding SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=n, the compilation fails. Is there something wrong with my operation?I added the setting to the mcuboot buid

Building zephyr
west build --build-dir t:/code/ncs/single_slot/build --domain mcuboot

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\ncs\toolchains\936afb6332\opt\bin\Scripts\west.exe\__main__.py", line 5, in <module>
  File "C:\ncs\toolchains\936afb6332\opt\bin\Lib\site-packages\west\app\main.py", line 1199, in main
    app.run(argv or sys.argv[1:])
  File "C:\ncs\toolchains\936afb6332\opt\bin\Lib\site-packages\west\app\main.py", line 278, in run
    self.run_command(argv, early_args)
  File "C:\ncs\toolchains\936afb6332\opt\bin\Lib\site-packages\west\app\main.py", line 584, in run_command
    self.run_extension(args.command, argv)
  File "C:\ncs\toolchains\936afb6332\opt\bin\Lib\site-packages\west\app\main.py", line 739, in run_extension
    self.cmd.run(args, unknown, self.topdir, manifest=self.manifest,
  File "C:\ncs\toolchains\936afb6332\opt\bin\Lib\site-packages\west\commands.py", line 200, in run
    self.do_run(args, unknown)
  File "C:\ncs\v3.3.0\zephyr\scripts\west_commands\build.py", line 239, in do_run
    self._sanity_check()
  File "C:\ncs\v3.3.0\zephyr\scripts\west_commands\build.py", line 551, in _sanity_check
    self._sanity_check_source_dir()
  File "C:\ncs\v3.3.0\zephyr\scripts\west_commands\build.py", line 535, in _sanity_check_source_dir
    srcrel = os.path.relpath(self.source_dir)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen ntpath>", line 783, in relpath
ValueError: path is on mount 't:', start on mount 'c:'

 *  The terminal process terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it. 

I also got an error when adding it to the sysbuild for single_slot.

[AHaug]

Hi,

It would be a slightly more complicated task than to add this config. Are you certain you want to change the full design of how you do signatures so close to mass production?

Could you build the full project instead of just the mcuboot domain?

Simple_Gao said:

I also got an error when adding it to the sysbuild for single_slot.

What is this error? Is this also just when building mcuboot?

Kind regards,
Andreas