NCS v3.3.0] Inquire about the possibility of bypassing KMU key verification for single-slot operation

Hi Nordic Support Team,

We are currently evaluating the nRF54L05 DFU single-slot sample in NCS v3.3.0.

Our question is: Is it technically possible to configure the single-slot DFU or MCUboot to operate without the KMU key verification process? We would like to understand if there is any Kconfig option or build flag that allows bypassing the KMU for development or specific use cases.

Any clarification on this would be greatly appreciated.

Best regards,

Ryan

Parents
  • Hello Ryan,

    It is technically possible but I am not sure if it has been tested. It looks like it should be sufficient to add SB_CONFIG_BOOT_SIGNATURE_TYPE_NONE=y to your build. Please give this a try and let me know if it works or not.

    Thanks,

    Vidar

  • Dear Vidar,

    Thank you for your prompt suggestion regarding disabling KMU key verification via `SB_CONFIG_BOOT_SIGNATURE_TYPE_NONE=y`. I have tried adding this option to my build configuration for the nRF54L05 single‑slot DFU sample (NCS v3.3.0). However, the build now fails with the following Kconfig warnings/errors (I’ve pasted the exact console output below):

    ```
    warning: UPDATEABLE_IMAGE_NUMBER (defined at
    D:/ncs/v3.3.0/nrf/modules/..\samples\common\mcumgr_bt_ota_dfu/Kconfig:87, subsys/dfu/Kconfig:97) was
    assigned the value '1' but got the value ''. Check these unsatisfied dependencies:
    (((BOARD_THINGY53_NRF5340_CPUAPP || BOARD_THINGY53_NRF5340_CPUAPP_NS) && SOC_SERIES_NRF53 &&
    NCS_SAMPLE_MCUMGR_BT_OTA_DFU) || (!MCUBOOT && IMG_MANAGER)) (=n). See
    docs.zephyrproject.org/.../kconfig.html and/or look up
    UPDATEABLE_IMAGE_NUMBER in the menuconfig/guiconfig interface. The Application Development Primer,
    Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
    helpful too.


    warning: MCUBOOT_UPDATE_FOOTER_SIZE (defined at subsys/dfu/Kconfig:55) was assigned the value '0x0'
    but got the value ''. Check these unsatisfied dependencies: MCUBOOT_IMG_MANAGER (=n), IMG_MANAGER
    (=n). See docs.zephyrproject.org/.../kconfig.html and/or
    look up MCUBOOT_UPDATE_FOOTER_SIZE in the menuconfig/guiconfig interface. The Application
    Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices sections of
    the manual might be helpful too.
    ```

    My analysis so far:
    - It seems that setting `SB_CONFIG_BOOT_SIGNATURE_TYPE_NONE` (or its equivalent `CONFIG_BOOT_SIGNATURE_TYPE_NONE`) might indirectly disable some MCUboot/IMG_MANAGER related features, causing the dependencies for `UPDATEABLE_IMAGE_NUMBER` and `MCUBOOT_UPDATE_FOOTER_SIZE` to become unsatisfied.
    - Perhaps the single‑slot operation relies on certain image management features that expect signature verification to be present; bypassing it may require additional adjustments, e.g., manually defining these Kconfig symbols or using a different configuration fragment.

    Could you please advise on the correct way to disable KMU verification for this specific sample? Is there an official Kconfig combination that works without triggering these dependency warnings, or do we need to patch the sample’s Kconfig logic? Any further guidance or an example configuration file would be greatly appreciated.

    Thank you for your time and support.

    Best regards,
    Ryan

  • Dear Ryan,

    The original single slot sample will also show these 2 kconfig warnings (UPDATEABLE_IMAGE_NUMBER and MCUBOOT_UPDATE_FOOTER_SIZE) when the app image is built, but neither of these should cause the build to fail. Please review the build log to see what actually caused the build to be aborted. 

    You should normally expect SDK samples to build without any warnings but for single slot DFU we have to make changes to the build scripts to be able to get rid of these warnings. 

    Best regards,

    Vidar

    EDIT: I tried the same here and found that I had to do a few more changes to get it to build and run:

    diff --git a/sysbuild.conf b/sysbuild.conf
    index 1c6ad63..7205468 100644
    --- a/sysbuild.conf
    +++ b/sysbuild.conf
    @@ -7,4 +7,7 @@
     SB_CONFIG_BOOTLOADER_MCUBOOT=y
     SB_CONFIG_MCUBOOT_MODE_FIRMWARE_UPDATER=y
     SB_CONFIG_FIRMWARE_LOADER_IMAGE_BLE_MCUMGR=y
    -SB_CONFIG_BOOT_SIGNATURE_TYPE_PURE=y
    +#SB_CONFIG_BOOT_SIGNATURE_TYPE_PURE=y
    +SB_CONFIG_BOOT_SIGNATURE_TYPE_NONE=y
    +SB_CONFIG_MCUBOOT_SIGNATURE_USING_KMU=n
    +SB_CONFIG_MCUBOOT_GENERATE_DEFAULT_KEY_FILE=n
    \ No newline at end of file
    diff --git a/sysbuild/mcuboot/boards/nrf54l15dk_nrf54l15_cpuapp.conf b/sysbuild/mcuboot/boards/nrf54l15dk_nrf54l15_cpuapp.conf
    index 5285c7a..fc6e8d7 100644
    --- a/sysbuild/mcuboot/boards/nrf54l15dk_nrf54l15_cpuapp.conf
    +++ b/sysbuild/mcuboot/boards/nrf54l15dk_nrf54l15_cpuapp.conf
    @@ -5,13 +5,15 @@
     #
     CONFIG_SYS_CLOCK_EXISTS=n
     CONFIG_NRF_GRTC_TIMER=n
    -CONFIG_PSA_CORE_LITE=y
    -CONFIG_CRACEN_IKG=n
    +CONFIG_PSA_CRYPTO_DRIVER_CRACEN=n
    +CONFIG_BOOT_VALIDATE_SLOT0=n
    +#CONFIG_PSA_CORE_LITE=y
    +#CONFIG_CRACEN_IKG=n
     CONFIG_FPROTECT=y
     
     # Disable run-time CRACEN provisioning of TRNG data.
     # KMU slots 248, 249 shall be pre-provisioned while programming with secret TRNG values instead.
    -CONFIG_CRACEN_PROVISION_PROT_RAM_INV_SLOTS_ON_INIT=n
    +#CONFIG_CRACEN_PROVISION_PROT_RAM_INV_SLOTS_ON_INIT=n
     
     CONFIG_BOOT_WATCHDOG_FEED=n
     

    Note that with this configuration there is no boot validation of the application.

  • Dear Vidar,

    Thank you very much for your detailed guidance and the configuration diffs you provided. I applied the modifications to sysbuild.conf and the board-specific MCUboot config file as you suggested, and I am happy to report that the build now completes successfully without errors.

    The single‑slot DFU sample runs as expected on our nRF54L05 device, and the KMU key verification is indeed bypassed—which is exactly what we needed for our development and testing phase. I also noted your reminder that this setup disables all boot validation, so we will only use it for internal evaluation and not in production.

    I really appreciate your prompt and thorough assistance. This resolves our current question.

    Best regards,

    Ryan

Reply
  • Dear Vidar,

    Thank you very much for your detailed guidance and the configuration diffs you provided. I applied the modifications to sysbuild.conf and the board-specific MCUboot config file as you suggested, and I am happy to report that the build now completes successfully without errors.

    The single‑slot DFU sample runs as expected on our nRF54L05 device, and the KMU key verification is indeed bypassed—which is exactly what we needed for our development and testing phase. I also noted your reminder that this setup disables all boot validation, so we will only use it for internal evaluation and not in production.

    I really appreciate your prompt and thorough assistance. This resolves our current question.

    Best regards,

    Ryan

Children
No Data
Related