You can also encrypt signed images to achieve a greater degree of security. The encryption process obscures image data so it cannot be seen or used by unauthorized users.
For security reasons, only signed images can be encrypted.
Two different keys are used in the process:
-
Data Encryption Key (DEK): The key used to encrypt firmware images.
-
Hardware Unique Key (HUK): A secure internal unreadable key that is unique per device. It is not configurable and it is already programmed in every device. It is used to secure the DEK.
For security, the HUK can only be used on closed devices. On open devices, an insecure test key is used instead.
| Encrypted images should only be used on closed devices. Encrypted U-Boot images will boot on open devices, but that would not make a Secure Boot setup. Encrypted kernel images will not boot on open devices. |
DEK management
The DEK gets encrypted with the HUK and stored in the U-Boot partition when you flash this partition. Whenever you want to use a new DEK, both the U-Boot image and the DEK must be flashed together. This usually happens in one of the following scenarios:
-
When using encrypted images for the first time
-
When you want to change the DEK and use a new one
The following diagram illustrates a simplification of this process:
You can also update only the encrypted U-Boot image without changing the DEK. This is useful when updating the firmware of modules already deployed to production.
Flash encrypted artifacts
Once a DEK is securely stored in the target (within the uboot partition), the rest of encrypted artifacts (Linux kernel, DTBs, bootscript and initramfs, if used) can be flashed as usual and they will be automatically decrypted with the DEK stored in the U-Boot partition during boot.
The process for the kernel image is depicted in the following graphic. (This works in a similar way for the rest of the boot artifacts.)
For more detail about secure boot mechanisms, see NXP secure boot application notes.
