Commit 3fdb245765 ("trustfence: add encrypted
boot artifact support for CCMP13 platform") broke PKI tree generation when
encryption is disabled. Fix it for ccmp15.
https://onedigi.atlassian.net/browse/DEL-10022
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit updates the secure boot support for STM platforms based on the
STM32 MPU Ecosystem v6.1.1. It introduces support for encrypted boot artifacts,
including TF-A and FIP for the ConnectCore MP13 platform.
https://onedigi.atlassian.net/browse/DEL-8535
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Add RSA key generation support for the Cortex-M4 co-processor on
ConnectCore MP15 platforms as part of DEY TrustFence framework.
https://onedigi.atlassian.net/browse/DEL-9920
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Add a variable analogous to TRUSTFENCE_SIGN to enable/disable artifact
encryption. Deprecate TRUSTFENCE_DEK_PATH in favor of TRUSTFENCE_KEYS_PATH to
use a more generic name and avoid overloading it as an on/off flag. Add per-key
variables for encryption key filenames to avoid hardcoded names and allow
platform overrides.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Adds support for signing and encrypting Cortex-M firmware on STM platforms,
following the STM32 MPU Ecosystem v6.1.0. This update enables secure boot of
co-processor binaries on ConnectCore MP2, enhancing firmware protection.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit updates the secure boot support for STM platforms based on the
STM32 MPU Ecosystem v6.1.0. It introduces support for encrypted boot artifacts,
including TF-A and FIP, and enables this functionality for the ConnectCore MP2
platform.
This enhancement allows secure boot deployments with both authentication and
encryption for improved protection of critical boot components.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit updates secure boot support based on the STM32 MPU Ecosystem v6.0
and integrates support for the ConnectCore MP2 platform.
https://onedigi.atlassian.net/browse/DEL-9442
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The ccmx91 uses the same AHAB-containerizing command as the ccimx93,
so fix the code to remove the hardcoding check for the ccimx93.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This commits adds the CCMX91 platform to the DEY
build system. Furthermore, it creates generic ccimx9
support to be used for the CCiMX91 and CCiMX93
platform.
https://onedigi.atlassian.net/browse/DEL-9106
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
This commit fixes a race condition where, if you have an existing PKI tree with
the new format (one key_pass file for each key), the script detects that the
PKI tree is incomplete because it is always trying to find the key_pass.txt
file with the old format. This commit adds an additional validation step to
verify the new keys format.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The script to sign the boot artifacts lacked the support to configure the
revocation mask. The at-the-moment supported platforms did not need it,
but the ccimx93 does need it, so implement it in this commit.
https://onedigi.atlassian.net/browse/DEL-8704
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
With the introduction of the ccimx93 support in the following commits, the
srktool parameters not only differ for HAB/AHAB devices but also between
devices using AHAB (for example, different parameters for ccimx8x and
ccimx93). Thus, move this information to the platform-specific data table.
https://onedigi.atlassian.net/browse/DEL-8704
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
It is a cosmetic change, as there is no change in functionality, but
convert the if..elif..fi structure to a table with the platform-specific
data, so it's easier to maintain and extend.
https://onedigi.atlassian.net/browse/DEL-8704
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
For signing SWU files we need to set a couple of variables:
- SWUPDATE_PRIVATE_KEY_TEMPLATE to the private key file
- SWUPDATE_PASSWORD_FILE to the password of the private key
The latter must only contain one password, whereas the current key_pass.txt
file had (for the ccmp13) the eight keys separated by a white space.
This commit:
- If the file key_pass.txt exists, it extracts each key into a separate
file key_pass0X.txt.
- If the keys don't exist, generates separate files per key.
- Changes the permissions of password files to 400.
- Adapts the sign script to use the single password files.
- Fixes a few quotes
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
PKI tree generation for the STM32MP15 cpu provides the undesired file
"publicKeysHashHashes.bin", which is only required by STM32MP13. This commit
generates the PKI tree according to the KeyGen tool documentation to avoid
generate this extra file and avoid confusing the end user.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Any errors in the PKI tree generation are not reported to bitbake, so the
script fails silently. This commit adds a validation of the script execution,
and if it fails, it aborts the execution and notifies to bitbake.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The KeyGen tool to generate 8 key pairs requires 8 consecutive passwords,
however, when the shell expands the passwords variable, it interprets it as a
single string instead of 8 different strings and fails.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Create a new script for the generation of PKI tree for STM platforms
and leave the trustfence-sign-artifact script exclusively for signing.
The new gen-pki script only requires the platform as an argument and the
path to where to save the tree (if it doesn't exist) in
CONFIG_SIGN_KEYS_PATH.
This commit also reverts commit 13c136dbc5 by getting rid of the
trustfence-genpki-native.bb recipe and moving back the PKI generation
functions into trustfence.bbclass. This recipe didn't quite guarantee
that the PKI was generated on time for the recipes that required the
keys to exist, anyway.
Instead, the PKI generation function must be called right after
do_compile() of recipe tf-a-stm32mp to be ready for do_deploy() where
the key is used.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This script can be called stand-alone or from DEY.
Syntax is :
trustfence-sign-artifact.sh -p <platform> [-t input-unsigned-image> <output-signed-image>]
If files are omitted, it at least generates random keys if they do not
exist.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This is in preparation of using the same script name for different SOC
vendors (NXP and STM).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The stand-alone signing script 'trustfence-sign-artifact.sh' checks
if a valid PKI tree exists (by checking the existance of four SRK
files) and if they don't, it calls trustfence-gen-pki.sh (which is
a wrapper over different generators (for HAB or AHAB) to create one.
Recipes such as 'dualboot' or 'recovery-initramfs' may need to call
openssl functions over the PKI tree. These recipes do not currently
generate the PKI tree; they expect it to be already in place.
This might not be the case if the trustfence-sign-artifact.sh script
has not been called yet.
Originally, a fake dependency on virtual/kernel recipe was made to
force it, but it doesn't quite work since the calling only happens
on deploy() while regular DEPENDS doesn't wait for this task.
If the PKI does not exist, a recipe that requires the PKI tree will
fail.
The solution is to create a function on the trustfence.bbclass that
allows any recipe to check for the existance of a PKI tree and
generate it if it doesn't exist. This is repeated inside the
trustfence-sign-artifact.sh, but it needs to be in both places
because this script must work stand-alone.
The generation of the PKI tree takes some seconds so this commit
adds a lock dir to prevent race conditions when called from
different recipes.
It also removes the fake dependency on virtual/kernel and adds a
dependency on trustfence-cst-native (which is the recipe that
provides the PKI generation tool).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-8430
(cherry picked from commit 6a8bf7afff)
Artifact encryption is now supported for ccimx8mn and ccimx8mm.
This reverts commit 1134e4c07c.
https://onedigi.atlassian.net/browse/DEL-7915
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
(cherry picked from commit 588005bb4b2200e79b180f77671304d9c5bdf509)
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The sign mode needed for each platform is invariable, and since the platform
is already a mandatory parameter for the script, we can store this information
implicitly. Reflect this change in every recipe where the script is used, but
keep the variable at the Yocto level since it's still needed in several places.
https://onedigi.atlassian.net/browse/DEL-7862
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The AHAB decryption process takes the encrypted file from the address defined
in U-Boot and decrypts it into the address defined in this script. If both
addresses are the same, the decryption process ends up failing. This
happens even for signed-only images.
Maintain the original addresses in this script so they do not collide.
This reverts commit c970d87d5a.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Re-use RAMDISK address for authenticating the rootfs instead
of allocating a new address (if authenticating a rootfs, we're
not using a ramdisk).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Attempting to boot encrypted artifacts on these platforms will result in HAB
events caused by CAAM errors. This is due to the CAAM being configured for
non-secure contexts (in regards to Trustzone) while the HAB expects it to be
configured for secure contexts.
For now, only sign artifacts for these platforms even if the project has the
encryption feature enabled.
https://jira.digi.com/browse/DUB-993
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
In order to revoke SRKs in platforms with AHAB we need to set a mask
during the signing/encryption process.
Create new TRUSTFENCE_SRK_REVOKE_MASK variable to export the
SRK_REVOKE_MASK variable required by the imx-boot signing script.
The revoke mask is not necessary for signing/encryption of other artifacts,
so set it by default to 0x0.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Add support to sign and encrypt OS artifacts for AHAB devices.
https://jira.digi.com/browse/DEL-7371
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Perform AHAB signing process without altering the original file.
https://jira.digi.com/browse/DEL-7024
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
LINUX_ARM64 images include the padding length in the size property of
their header, so for these images read the header size property instead
of calculating it with 'stat'.
https://jira.digi.com/browse/DEL-7024
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
If CONFIG_SIGN_MODE is unset, we were assuming the sign mode to be AHAB
whereas it is preferable to abort the signing process and notify with an
error message.
https://jira.digi.com/browse/DEL-7024
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
The signing script is used for signing multiple artifacts, not just the
kernel, so rename it for a broader use.
https://jira.digi.com/browse/DEL-7047
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
The only script that needs to generate the SRK_efuses is the sign.sh
script in the U-Boot code. For the rest of signed non-bootable artifacts
this is not required and it was creating the SRK_efuses file on every
recipe where the script was called, like linux-dey and others, which
eventually resulted in a conflict when copying the artifacts to the shared
deploy-image-dir.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
* prefix TRUSTFENCE_ to variable SIGN_MODE for DEY
* prefix CONFIG_ to variable SIGN_MODE for script
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
- The IVT table address inside the kernel image must be aligned at 0x1000
bytes. The calculation of this offset was not working when the kernel image
size was multiple of 0x1000 bytes. In this case the IVT table was moved an
extra offset of 0x1000 bytes, causing U-Boot to fail to validate the image
as the IVT table was not in the expected location.
This fix uses the same offset calculation algorithm as U-Boot, ensuring both,
the sign script and U-Boot will look for the IVT at the same address.
https://jira.digi.com/browse/DEL-3972
Signed-off-by: David Escalona <david.escalona@digi.com>
Arturo Buzarra
Javier Viguera
Mike Engel
Hector Palacios
Gonzalo Ruiz
Gabriel Valcazar
David Escalona
Diaz de Grenu, Jose