WARNING: Using generated NSIB public/private key-pair.

D:\ncs\v2.4.0\bootloader\mcuboot\samples\zephyr\hello-world>west build -b nrf5340dk_nrf5340_cpuapp
-- west build: generating a build system

...

-- Configuring done
-- Generating done
-- Build files have been written to: D:/ncs/v2.4.0/bootloader/mcuboot/samples/zephyr/hello-world/build/b0
=== child image b0 - end ===

CMake Warning at D:/ncs/v2.4.0/nrf/subsys/bootloader/cmake/debug_keys.cmake:36 (message):


--------------------------------------------------------------
--- WARNING: Using generated NSIB public/private key-pair. ---
--- It should not be used for production. ---
--- See CONFIG_SB_SIGNING_KEY_FILE ---
--------------------------------------------------------------

Procedures to reproduce this issue is as follows.

1. Unzipping hello-world.zip to D:\ncs\v2.4.0\bootloader\mcuboot\samples\zephyr folder.

2. cd D:\ncs\v2.4.0\bootloader\mcuboot\samples\zephyr\hello-world

3. west build -b nrf5340dk_nrf5340_cpuapp

Parents Reply Children
  • I ran into this problem too.  The source of it is here in nrf/subsys/bootloader/cmake/debug_keys.cmake:

      if(IS_ABSOLUTE ${CONFIG_SB_SIGNING_KEY_FILE})
        set(SIGNATURE_PRIVATE_KEY_FILE ${CONFIG_SB_SIGNING_KEY_FILE})
      else()
        set(SIGNATURE_PRIVATE_KEY_FILE
          ${APPLICATION_CONFIG_DIR}/${CONFIG_SB_SIGNING_KEY_FILE})
      endif()

    So the only way to make it use relative paths is to change APPLICATION_CONFIG_DIR, but then I have to duplicate prj.conf from the sample image.

    For mcuboot, it is possible to change the signing key directory by supplying mcuboot_CONF_DIR only (not mcuboot_CONF_FILE); this causes it to use prj.conf from mcuboot SDK directory as the base configuration and then look into the directory I've defined for the key file.

    It would be great if debug_keys.cmake also supported the same logic to allow getting the key from hci_rpmsg_CONF_DIR.

    PS: Also I found that the logic in here is broken in other ways; if you try to pass the key via "SB_SIGNING_KEY_FILE" environment variable or CMake command line argument, it is always overridden by the config file setting.

  • I tried to solve this by generating a config file using the absolute path and adding it as an overlay; but then the thing I ran into was that this message is being generated for the b0 and b0n images.

    CONFIG_SB_SIGNING_KEY_FILE depends on SECURE_BOOT, which depends on !IS_SECURE_BOOTLOADER.

    Therefore this config will always be undefined for b0 and b0n and always produce this error message.

    What does this mean?  I don't think b0 and b0n are signed with CONFIG_SB_SIGNING_KEY_FILE, but neither should they be signed with the default key either (because what would validate the signature?).  Is hci_rpmsg signed with CONFIG_SB_SIGNING_KEY_FILE if I don't supply an absolute path for it?

  • I found that I was hitting the error because I didn't have the key file defined for hci_rpmsg; so I fixed my overlays so that the absolute path is supplied via generated files into the child images via <img>_OVERLAY_CONFIG

    • mcuboot (CONFIG_BOOT_SIGNATURE_KEY_FILE)
    • b0 and hci_rpmsg (CONFIG_SB_SIGNING_KEY_FILE)

    I still think the scripts should be fixed to allow override via environment variable, CMake argument, or by path relative to <img>_CONF_DIR.

Related