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

[Simple_Gao]

Hi AHaug

I tried to fix the compilation error and it ran successfully. Here are my changes. Could you please help confirm whether this is correct?

[AHaug]

Hi,

I tried to build with this diff myself.

Two warnings showed up, both worth mentioning to them:

• Set your own signing key. With SIGNATURE_USING_KMU=n and no SB_CONFIG_BOOT_SIGNATURE_KEY_FILE, MCUboot embeds the public demo key and you'll see WARNING: Using default MCUboot signing key file in the build log. For production you must set SB_CONFIG_BOOT_SIGNATURE_KEY_FILE to your own .pem.
• Minor cleanup: rename the DT node from partition@6000 to partition@8000 to match its new reg address and silence the unit address ... don't match warning.

I recommend that you fix those if you intend to remove the KMU, specially number 1, i.e that you should not use the default public key which it looks like you're currently doing.

Please also weigh the security trade-off: embedding the key means you lose hardware-backed key storage, hardware-accelerated (CRACEN) verification, and the KMU key-revocation scheme. If those matter, the alternative is to keep the KMU and simply move provisioning into your production line — nrfutil device x-provision-keys doesn't require west, so it can run as one extra step in your existing nrfutil-based flashing script.

Any associated risks w.r.t security associated with this are up to your discression to evaluate.

Kind regards,
Andreas