This version supports i.MX8ULP and i.MX9x devices.
NOTICE: changed the "srk_ca" parameter in ahab_pki_tree.sh from "yes" to
"no". This script is shared between cc8x and ccimx93. The imx93 does not
support that option at the moment (generation of subordinate SGK certs)
and for the cc8x we were generating them but never used them to sign
the artifacts.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Merge the patches for the PKI tree generation scripts, to ease
maintenance (still keeping two separate patches for HAB4/AHAB).
Signed-off-by: Javier Viguera <javier.viguera@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>
The recipe fails to build for the target, but that is expected, as this
is a tool you need to run in the host or from the toolchain/SDK, so
rework the recipes to restrict only for native and nativesdk.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Yocto 4.0 only supports OpenSSL 3.0.x while NXP's CST (code signing
tool) is still using OpenSSL 1.1.x. So the build fails when using the
Yocto-build OpenSSL. Instead, build OpenSSL 1.1.1 as part of the build of
the CST and link statically against libcrypto, so the resulting binaries
(cst, srktool) do not depend on any specific OpenSSL version installed
on the development computer.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
In order to perform the standalone signature process, it was required
to rebuild the Toolchain with Trustfence support enabled.
CST source code is now available for downloading in the Digi FTP, so add
Trustfence sign scripts and cst/srktool to the default toolchain for it
to be used for standalone signature without rebuilding.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
(cherry picked from commit 2c9b721fb9ce38dcd0034e22d95db6e0ee068955)
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This commit fixes the following warning:
WARNING: meta-digi/meta-digi-arm/recipes-bsp/trustfence-cst/trustfence-cst_3.3.1.bb:
Recipe trustfence-cst sets S variable with trailing slash '/tmp/work/aarch64-dey-linux/trustfence-cst/3.3.1-r0/cst-3.3.1/',
remove it
https://jira.digi.com/browse/DEL-7508
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Since there is only 1 supported version of cst, the include file is
only used once.
Move all the recipe implementation to the *.bb recipe and remove the
*.inc file.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Since cst-3.3.1 is now distributed with a BSD-3-Clause license, it is allowed
to distribute its source code from the Digi FTP.
Fetch the tarball from that location.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
CST was being built linking to the openssl libcrypto library from the host.
When the openssl version in the host didn't match the version in the SDK,
the SDK build failed like this:
Error:
Problem 1: package nativesdk-packagegroup-sdk-host-1.0-r12.0.x86_64_nativesdk requires nativesdk-trustfence-cst, but none of the providers can be installed
- conflicting requests
- nothing provides libcrypto.so.1.0.0()(64bit) needed by nativesdk-trustfence-cst-3.3.1-r0.0.x86_64_nativesdk
- nothing provides libcrypto.so.1.0.0(OPENSSL_1.0.0)(64bit) needed by nativesdk-trustfence-cst-3.3.1-r0.0.x86_64_nativesdk
- nothing provides libcrypto.so.1.0.0(OPENSSL_1.0.1)(64bit) needed by nativesdk-trustfence-cst-3.3.1-r0.0.x86_64_nativesdk
Problem 2: package nativesdk-packagegroup-qt5-toolchain-host-1.0-r0.0.x86_64_nativesdk requires nativesdk-packagegroup-sdk-host, but none of the providers can be installed
- package nativesdk-packagegroup-sdk-host-1.0-r12.0.x86_64_nativesdk requires nativesdk-trustfence-cst, but none of the providers can be installed
- conflicting requests
- nothing provides libcrypto.so.1.0.0()(64bit) needed by nativesdk-trustfence-cst-3.3.1-r0.0.x86_64_nativesdk
- nothing provides libcrypto.so.1.0.0(OPENSSL_1.0.0)(64bit) needed by nativesdk-trustfence-cst-3.3.1-r0.0.x86_64_nativesdk
- nothing provides libcrypto.so.1.0.0(OPENSSL_1.0.1)(64bit) needed by nativesdk-trustfence-cst-3.3.1-r0.0.x86_64_nativesdk
Fix that by adding the native dependencies include and lib folders to
the CST build. Also add openssl-native as a dependency for the SDK build,
otherwise it wont link to the SDK libcrypto library.
Additionally, to allow running CST in a host machine where the openssl version
does not match the version in the SDK, libcrypto library is statically linked.
https://jira.digi.com/browse/DEL-7346
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
(cherry picked from commit a95b3ad602)
The CST package requires byacc to compile, and even though this dependency is
met when building images for the target, said dependency needs to be made
explicit when the package is built for the SDK in order to avoid build errors.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This version supports encryption for devices with Advanced High Assurance Boot
(AHAB) capabilities. This commit also updates and simplifies Digi custom
patches.
https://jira.digi.com/browse/DEL-7175
Signed-off-by: Arturo Buzarra <arturo.buzarra@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>
This version supports OpenSSL v1.1.0 by default, which is used in DEY 2.6.
Trying to build older versions of the package will result in failures, so
remove support for said versions entirely.
Our patches apply cleanly except for the hab4_pki_tree.sh automation patch,
which needs a small tweak so it can get applied over the latest version of the
script.
https://jira.digi.com/browse/DEL-6476
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Generate and include the host tools in the SDK when Trustfence is enabled.
This makes it easier to use the standalone signing and encrypting scripts.
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
When parsing the recipe, a warning is shown because the tarball is only found
in the downloads folder. However this is expected as it cannot be distributed.
As a workaround, add the tarball to the SRC_URI variable only when Trustfence
is active. That way the warning is not shown in all other cases.
This was incorrectly removed in commit 14fc51147f.
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
This will allow to get the package from a premirror in case it is not
already downloaded in the DL_DIR.
https://jira.digi.com/browse/DEL-3051
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Refresh the patches with GIT so they apply cleanly using "git am".
Otherwise they fail with:
Applying: openssl_helper: use /dev/urandom as seed source
error: corrupt patch at line 16
Patch failed at 0003 openssl_helper: use /dev/urandom as seed source
Applying: hab4_pki_tree.sh: usa a random password for the default PKI generation
warning: keys/hab4_pki_tree.sh has type 100755, expected 100644
Notice that they were not failing in Yocto, as it does not use "git am"
to apply patches, but it's better to have the patches correctly done.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This package is native only, this patch ensures it can only be built
natively and fix the following problems:
* Add openssl-native rather than openssl to the dependencies.
* Use the $(CC) $(LDFLAGS) and $(CFLAGS) that Yocto provides to avoid a
compilation error.
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
This allows to automatically create a secure PKI tree without user
interaction.
https://jira.digi.com/browse/DUB-618
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
NXP Code signing Tool for the High Assurance Boot library is needed for
signing and encrypting different artifacts (U-Boot image, uImage, ...).
As the CST cannot be included in DEY, the user needs to download the
tarball and add it to the recipe folder.
https://jira.digi.com/browse/DUB-618
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
Javier Viguera
Hector Palacios
Gonzalo Ruiz
Arturo Buzarra
Gabriel Valcazar
Mike Engel
Jose Diaz de Grenu