Commit Graph

8 Commits

Author SHA1 Message Date
Hector Palacios 998598415a dey-image: generate public key after rootfs install
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>
2023-08-21 09:21:30 +02:00
Hector Palacios 4e361ff449 trustfence-cst: fix issue with binutils 2.38 objcopy
There is an issue in binutils 2.38 objcopy when called
with '--weaken' flag:

  https://sourceware.org/bugzilla/show_bug.cgi?id=27493

To circumvent it, patch the trustfence-cst config.mk to
call specifically with 'weaken-symbol err_msg' which is
apparently the only symbol that's overriden by the code.

Signed-off-by: Hector Palacios <hector.palacios@digi.com>

https://onedigi.atlassian.net/browse/DEL-8033
https://onedigi.atlassian.net/browse/DEL-8332
2023-01-30 12:20:12 +01:00
Javier Viguera 47215862cf trustfence-cst: fix build in DEY 4.0
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>
2022-07-06 11:58:21 +02:00
Gonzalo Ruiz eb76c33166 trustfence-cst: build CST using libcrypto from SDK
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)
2020-12-18 17:19:46 +01:00
Arturo Buzarra 68720f869b trustfence-cst: add support for cst v3.3.1
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>
2020-09-03 12:04:30 +02:00
Mike Engel 5beec04b6a trustfence: Add Trustfence support for CCMX8X
This commit adds Trustfence support for the CCMX8X
platform.

Signed-off-by: Mike Engel <Mike.Engel@digi.com>

https://jira.digi.com/browse/DEL-6917
2020-02-04 12:20:38 +01:00
Gabriel Valcazar ec7511ee8f trustfence-cst: add support for cst v3.1.0
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>
2019-03-06 10:58:33 +01:00
Jose Diaz de Grenu 14fc51147f trustfence-cst: add support for CST 2.3.3
https://jira.digi.com/browse/DEL-5337

Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
2017-11-23 14:15:14 +01:00