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>
Warn when the deprecated TRUSTFENCE_DEK_PATH variable is detected, and fail the
build if it is used to disable artifact encryption. This prevents accidental
wrong compilations and guides users to replacement variables.
https://onedigi.atlassian.net/browse/DEL-9929
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit add secure storage service and helper
script to setup the secure storage at boot up.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://onedigi.atlassian.net/browse/DEL-9891
Enable signed firmware to prevent unauthenticated code on the Cortex-M4
co-processor by verifying images against custom public key from OP-TEE.
https://onedigi.atlassian.net/browse/DEL-9920
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Commit b1800736af ("trustfence: update support to
STM platforms and integrate CCMP2") renamed several variables like FIP_SIGN_KEY
to SIGN_KEY, but missed updating the `SWUPDATE_PRIVATE_KEY_TEMPLATE` assignment.
This broke .swu signing on STM targets.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Introduce a configurable variable to enable/disable secure co-processor
firmware when TrustFence is enabled.
https://onedigi.atlassian.net/browse/DEL-9813
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>
This was causing issues when installing an SWU package on ccmp1 platforms with
dualboot disabled and Trustfence enabled: the package was triggering an
encrypted rootfs update, which isn't supported on these platforms.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit af06ea16adc85285d9264468d2fd5946ed401de9)
Now all platforms support setting the GPIO name instead of an index
as the configuration for the GPIO-enabled secure console.
Repurpose the TRUSTFENCE_GPIO_ENABLE macro to directly set the GPIO
name.
Also take the opportunity to remove TRUSTFENCE_GPIO_ENABLE and
TRUSTFENCE_CONSOLE_PASSPHRASE_ENABLE commented definitions from bbclass
and conf files, and remove a duplicated TRUSTFENCE_CONSOLE_DISABLE
definition from ccmp1.inc.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Commit 998598415a moved this logic to the
trustfence.bbclass file, but in doing so, it removed the TRUSTFENCE_SIGN check
it used to have. The check is needed for two reasons:
* The signing of SWU packages only occurs when TRUSTFENCE_SIGN is enabled, so
there's no need to copy the key if it's disabled
* When building a project from scratch that has Trustfence enabled but
TRUSTFENCE_SIGN disabled, a PKI is never generated and the key doesn't exist.
Because of this, the key won't be found and an error will occur. Note that
if your project is already pointing to a populated PKI, the error won't
happen, only if there's no PKI to begin with.
Although the PKI is guaranteed to exist by the time the rootfs is populated,
make sure to check that it has been properly generated and create it if it
doesn't exist. This logic depends on the trustfence-gen-pki.sh from
trustfence-sign-tools-native, so add it as a dependency for
dey-image-recovery-initramfs. The dependency is already there for another
feature in the dey-image recipes, so simply reflect this new dependency in a
comment.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 8e52c27d5a8e8071c3a17754e91c1819bcceee15)
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>
On new platforms, trustfence will use file-based encryption instead of
full-disk encryption. Add base variables and platform defaults to allow
implementing file-based encryption.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Encrypting boot artifacts impacts the device's boot time, so disable them
by default. It is still possible to enable it in the project's config
file by setting the TRUSTFENCE_DEK_PATH option.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Unlike the rest of the NXP platforms, in u-boot, the ccimx93 allows
configuring a GPIO name to activate the console when secure console is
enabled. Those u-boot options were not translated to the trustfence code
in meta-digi.
https://onedigi.atlassian.net/browse/DEL-9063
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Add a check on the existence of the "temp-fitimg-loaded" environment
variable before setting it. It is needed, as with encrypted FIT images,
we need to decrypt them before accessing the boot script. In such cases,
u-boot sets that variable to "no" so the boot script does not override it,
and the FIT image is loaded again before the final boot to the OS.
https://onedigi.atlassian.net/browse/DEL-8945
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Trustfence class was setting the TRUSTFENCE_PASSWORD_FILE variable using the
old keys format where a unique key_pass.txt file contains all the key
passwords. However, in the new format there are one key_pass file for each
key, so using a PKI tree with the new format throws an unexpected error in the
FIP generation due to it is not able to find the required key password.
This commit sets the TRUSTFENCE_PASSWORD_FILE variable for the ccmp1 platforms
on different way.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Different mechanisms are used to sign FIT images on the ccmp1 platforms and the
ccimx93, and we manage each mechanism via a different variable. The variable
names don't really reflect which platform they affect, which makes maintenance
harder.
Rename the variables so that it's easier to identify the platforms/vendors they
affect:
* Replace TRUSTFENCE_FIT_IMG with TRUSTFENCE_SIGN_FIT_STM
* Replace TRUSTFENCE_SIGN_FIT_ARTIFACT with TRUSTFENCE_SIGN_FIT_NXP
Don't rename TRUSTFENCE_FIT_IMG_SIGN_KEYNAME
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
We rely on FIT support to implement boot artifact authentication on ccmp1
platforms, but our implementation made it impossible to enable FIT support
outside of the context of Trustfence/secure boot.
Change this so that it's possible to enable FIT support without having to sign
the FIT artifacts. Also, modify the linux-dey 5.15 recipe so that the U-Boot
DTBs with signatures get copied only when FIT signing is enabled.
https://onedigi.atlassian.net/browse/DEL-8946
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The TF-A and OP-TEE images have different suffixes depending
on whether TrustFence is enabled or not, but the suffix variables
themselves must exist independently of whether TF is enabled.
Currently, they were defined on the trustfence.bbclass, and the
variables did not exist when TF was disabled, which caused build
problems, for example, building the SWU file.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence is enabled, the boot artifacts (TFA and FIP)
have a 'signed' suffix. Handle this case so that the correct
symlinks are created and the correct artifacts are put into the
SWU file.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Signed-off-by: Hector Palacios <hector.palacios@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>
meta-digi layers use many conditionals basing on TRUSTFENCE_SIGN, but this
variable may be disabled when the signing process wants to be isolated
from the image creation.
There are cases when we still need to know if TrustFence is enabled even
if the images are not going to be signed.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
In commit df9b1cf329, the UBOOT_SIGN_ENABLE is set for all
platforms, and should be only added for FIT images.
This is making the process failing in cc8mn/cc8mm platforms
due to the UBOOT_SIGN_ENABLE is also used there to use a dtb
patched with the signature node.
https://onedigi.atlassian.net/browse/DEL-8764
Signed-off-by: Francisco Gil francisco.gilmartinez@digi.com
- Set variables required for FIT signing inside python function, under the
condition of having TRUSTFENCE_SIGN="1".
- Define two sign keys using TRUSTFENCE_ wrapper constants. Default values:
- 'fitcfg' for configuration nodes inside the FIT
- 'fitimg' for image nodes inside the FIT
- Enable FIT_SIGN_INDIVIDUAL to also sign individual images inside the FIT
- Set FIT_GENERATE_KEYS by default (kernel-fitimage.bbclass already checks
if the keys exist before generating new ones)
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This commit adds signed FIT image support for the CCMP1
platforms when using Trustfence.
https://onedigi.atlassian.net/browse/DEL-8591
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Current pattern does not match the SRKs generated for the ccimx93. The
ccimx93 does not support subordinated SGK certs, so the name of the SRKs
do not contain the "_ca_" pattern. So relax the expression used in the
trustfence bbclass to match the SRKs generated for both platforms.
# For the ccimx93
$ ls -1 crts/SRK1*crt.pem
crts/SRK1_sha512_secp521r1_v3_usr_crt.pem
# For the ccimx8x
$ ls -1 crts/SRK1*crt.pem
crts/SRK1_sha512_secp521r1_v3_ca_crt.pem
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Some platforms do not support signing external artifacts (kernel, dtb,
etc.) yet, so we need to decouple the signing of the bootloader from the
signing of the external artifacts.
This commit generalizes the code, so instead of having platform exceptions
scattered along the recipes, we create a new variable used conditionally
to sign or not the external artifacts.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Bitbake was always copying the public key 1 to the rootfs, no matter what the value specified in
the 'TRUSTFENCE_KEY_INDEX' variable was. This commit fixes the issue by enclosing the variable
between curly braces so that bitbake is able to expand it and calculate the correct key index.
Signed-off-by: David Escalona <david.escalona@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>
In the context of the class, we must use ${IMAGE_ROOTFS} instead of ${D}.
Change the calling of the function to POSTPROCESS (after the rootfs has
been created) instead of POSTINSTALL (after the packages have been
installed).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence is enabled, a PKI tree is generated.
In the case of NXP platforms, the PKI contains public certificates
from which the public key needs to be extracted using an openssl
command.
In the case of STM platforms, the PKI contains directly the
public key.
In all cases, we need the public key to be installed in the
rootfs /etc/ssl/certs/ folder, so that it can be used by
swupdate to authenticate signed SWU packages.
Up to now, this was being done on the dualboot recipe, but the
installation of the public key should really be only dependant
on the fact of TF being enabled.
This commit:
- Removes the generation of the public key from dualboot.bb.
- Generates a patch to extract the public key from the certificate
as part of the PKI tree generation (on NXP platforms).
- Installs the public key during a post install function after
the final rootfs has been created.
- For NXP platforms, extracts the public key using openssl if
it does not exist (for backwards compatibility).
Signed-off-by: Hector Palacios <hector.palacios@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 commits changes the CONFIG_CONSOLE_ENABLE_GPIO_NAME to be a string
and not an integer.
https://onedigi.atlassian.net/browse/DEL-8520
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Sometimes, it may be desired that the DEY project does not sign the
artifacts, for example, if they are going to be externally signed on a
secure server. In this case, the user sets TRUSTFENCE_SIGN="0".
On STM platforms, all the variables were being set if TRUSTFENCE_SIGN="1"
and authentication support is not enabled on TF_A otherwise.
Set TF_A_SIGN_ENABLE (which adds authentication support to TF_A) always
for STM platforms (as long as the project inherits the trustfence class)
and set FIP_SIGN_ENABLE="0" if its sibling TRUSTFENCE_SIGN="0", so that
DEY doesn't sign the FIP image either.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
For the moment, do not sign aditional artifacts, such as the ramdisk,
the kernel or the boot scripts for STM platforms.
In the specific case of the ramdisk, simply copy it over with the
expected filename extension.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Several recipes depend on the PKI creation.
Create a small recipe to just run this function which
is moved from the trustfence.bbclass.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Arturo Buzarra
Mike Engel
Gabriel Valcazar
Gonzalo Ruiz
Javier Viguera
Hector Palacios
fgilmar
David Escalona