|
| 1 | +.. _ug_nrf54l_ecies_x25519: |
| 2 | + |
| 3 | +MCUboot AES image encryption with ECIES-X25519 key exchange |
| 4 | +########################################################### |
| 5 | + |
| 6 | +.. contents:: |
| 7 | + :local: |
| 8 | + :depth: 2 |
| 9 | + |
| 10 | +MCUboot on the nRF54L15 SoC can support encrypted images using AES. |
| 11 | +Images are encrypted using AES, and ECIES-X25519 is used for key delivery (exchange) within the image. |
| 12 | +When image encryption is enabled, you can choose to upload signed or encrypted images to be swapped during boot. |
| 13 | +If MCUboot finds an encrypted image in the secondary slot, it decrypts the image during the slot swapping process. |
| 14 | +An image that was encrypted before being swapped into the primary slot is re-encrypted if the swap is later reverted. |
| 15 | + |
| 16 | +Limitations |
| 17 | +*********** |
| 18 | + |
| 19 | +The current implementation has the following limitations: |
| 20 | + |
| 21 | +* On the nRF54L15 SoC, ECIES-X25519 key exchange is supported only when the ED25519 signature algorithm is selected. |
| 22 | + This is the default configuration. |
| 23 | +* Encryption is not supported when using MCUboot in direct-xip mode. |
| 24 | +* Storing the ECIES-X25519 device private key in the Key Management Unit (KMU) is currently not supported. |
| 25 | +* HMAC and HKDF tools currently use the SHA-256 hash algorithm. |
| 26 | + |
| 27 | +HMAC and HKDF impact on TLV and key exchange |
| 28 | +******************************************** |
| 29 | + |
| 30 | +An encrypted image includes a TLV that contains the public key for ECIES-X25519 key exchange, the encrypted AES key, and the MAC tag of the encrypted key. |
| 31 | +The key used to encrypt the AES key is derived using HKDF, and the MAC tag is generated using HMAC. |
| 32 | + |
| 33 | +While the use of SHA-256 does not pose a security concern and has a minimal impact on performance, it increases the code size. |
| 34 | +This is because SHA-256 support must be included in addition to SHA-512, which is already used by the ED25519 signature algorithm. |
| 35 | + |
| 36 | +Additionally, pre-installed MCUboot instances will not be able to boot images that use TLVs generated with different hash algorithms. |
| 37 | + |
| 38 | +Building application with image encryption |
| 39 | +****************************************** |
| 40 | + |
| 41 | +To build an application that uses MCUboot with image encryption enabled, run the following command: |
| 42 | + |
| 43 | +.. parsed-literal:: |
| 44 | + :class: highlight |
| 45 | +
|
| 46 | + west build -b *board_target* -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DSB_CONFIG_BOOT_ENCRYPTION=y |
| 47 | +
|
| 48 | +The :kconfig:option:`SB_CONFIG_BOOT_ENCRYPTION` option enables encryption support in MCUboot. |
| 49 | + |
| 50 | +The key exchange method is determined by the type of signature key selected. |
| 51 | +For the nRF54L15 SoC, the ED25519 signature algorithm is the default setting. |
| 52 | + |
| 53 | +When encryption is enabled, the encrypted image files :file:`zephyr.signed.encrypted.bin` and :file:`zephyr.signed.encrypted.hex` are generated in the application build directory. |
| 54 | + |
| 55 | +The BIN file is a binary image suitable for Device Firmware Update (DFU) operations using :ref:`MCUmgr<dfu_tools_mcumgr_cli>`. |
| 56 | + |
| 57 | +When the :kconfig:option:`SB_CONFIG_BOOT_ENCRYPTION_KEY_FILE` option is enabled, you must provide an ECIES-X25519 private key in PEM format. |
| 58 | +This key is built into the MCUboot image during the build process. |
| 59 | +See the following example: |
| 60 | + |
| 61 | +.. parsed-literal:: |
| 62 | + :class: highlight |
| 63 | +
|
| 64 | + west build -b *board_target* -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y -DSB_CONFIG_BOOT_ENCRYPTION=y -DSB_CONFIG_BOOT_ENCRYPTION_KEY_FILE=\"<path to key.pem>\" |
| 65 | +
|
| 66 | +.. note:: |
| 67 | + * The public key, derived from the specified private key file, is added to the image and later used on the device to derive the decryption key for the application image. |
| 68 | + This public key is automatically derived from the private key by imgtool, which is invoked by the build system when signing the image. |
| 69 | + * The sysbuild option :kconfig:option:`SB_CONFIG_BOOT_ENCRYPTION` sets the MCUboot configuration option :kconfig:option:`CONFIG_BOOT_ENCRYPT_IMAGE`. |
| 70 | + Similarly, the :kconfig:option:`SB_CONFIG_BOOT_ENCRYPTION_KEY_FILE` option sets both :kconfig:option:`CONFIG_BOOT_ENCRYPTION_KEY_FILE` for MCUboot and :kconfig:option:`CONFIG_MCUBOOT_ENCRYPTION_KEY_FILE` for the default application. |
| 71 | + |
| 72 | + These values are then passed to imgtool for encrypting the application image. |
| 73 | + |
| 74 | + You cannot override these options using MCUboot or application-level Kconfig options, as they are enforced by sysbuild. |
| 75 | + |
| 76 | +Enabling encryption in |nRFVSC| projects |
| 77 | +**************************************** |
| 78 | + |
| 79 | +To correctly set up encryption in |nRFVSC|, you must familiarize yourself with `How to work with build configurations`_. |
| 80 | +When configuring build options, ensure to include :kconfig:option:`SB_CONFIG_BOOT_ENCRYPTION` and :kconfig:option:`SB_CONFIG_BOOT_ENCRYPTION_KEY_FILE` Kconfig options using extra CMake arguments. |
| 81 | + |
| 82 | +If you are modifying an existing project, you must regenerate it to activate new settings. |
0 commit comments