| #
4d2372e9 |
| 24-Apr-2024 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge "fix(cert-create): use a salt length equal to digest length for RSA-PSS" into integration
|
| #
e639ad23 |
| 08-Apr-2024 |
Donald Chan <donachan@tesla.com> |
fix(cert-create): use a salt length equal to digest length for RSA-PSS
Currently when RSA-PSS signing is invoked, a salt length of 32 bytes is assumed. This works well when SHA-256 is the digest alg
fix(cert-create): use a salt length equal to digest length for RSA-PSS
Currently when RSA-PSS signing is invoked, a salt length of 32 bytes is assumed. This works well when SHA-256 is the digest algorithm, but the standard industry practice is that the salt length should follow the digest length (e.g. 48/64 bytes for SHA-384/SHA-512).
Various cloud services' key management services (KMS) offering have such restrictions in place, so if someone wants to integrate cert_create against these services for signing key/content certs, they will have problem with integration.
Furthermore, JWS (RFC7518) defined these specific combinations as valid specs and other combinations are not supported:
- PS256: RSASSA-PSS using SHA-256 and MGF1 with SHA-256 - PS384: RSASSA-PSS using SHA-384 and MGF1 with SHA-384 - PS512: RSASSA-PSS using SHA-512 and MGF1 with SHA-512
Change-Id: Iafc7c60ccb36f4681053dbeb4147bac01b9d724d Signed-off-by: Donald Chan <donachan@tesla.com>
show more ...
|
| #
797d7446 |
| 11-Nov-2022 |
Manish V Badarkhe <manish.badarkhe@arm.com> |
Merge "refactor(security): add OpenSSL 1.x compatibility" into integration
|
| #
cf2dd17d |
| 25-Oct-2022 |
Juan Pablo Conde <juanpablo.conde@arm.com> |
refactor(security): add OpenSSL 1.x compatibility
When updated to work with OpenSSL 3.0, the host tools lost their compatibility with previous versions (1.x) of OpenSSL. This is mainly due to the fa
refactor(security): add OpenSSL 1.x compatibility
When updated to work with OpenSSL 3.0, the host tools lost their compatibility with previous versions (1.x) of OpenSSL. This is mainly due to the fact that 1.x APIs became deprecated in 3.0 and therefore their use cause compiling errors. In addition, updating for a newer version of OpenSSL meant improving the stability against security threats. However, although version 1.1.1 is now deprecated, it still receives security updates, so it would not imply major security issues to keep compatibility with it too.
This patch adds backwards compatibility with OpenSSL 1.x versions by adding back 1.x API code. It defines a macro USING_OPENSSL3, which will select the appropriate OpenSSL API version depending on the OpenSSL library path chosen (which is determined by the already-existing OPENSSL_DIR variable).
In addition, cleanup items were packed in functions and moved to the proper modules in order to make the code more maintainable and legible.
Signed-off-by: Juan Pablo Conde <juanpablo.conde@arm.com> Change-Id: I8deceb5e419edc73277792861882404790ccd33c
show more ...
|
| #
d8ba3278 |
| 17-May-2022 |
Manish Pandey <manish.pandey2@arm.com> |
Merge "refactor(security): upgrade tools to OpenSSL 3.0" into integration
|
| #
9bc52d33 |
| 02-Mar-2022 |
Juan Pablo Conde <juanpablo.conde@arm.com> |
refactor(security): upgrade tools to OpenSSL 3.0
Host tools cert_tool and encrypt_fw refactored to be fully compatible with OpenSSL v3.0.
Changes were made following the OpenSSL 3.0 migration guide
refactor(security): upgrade tools to OpenSSL 3.0
Host tools cert_tool and encrypt_fw refactored to be fully compatible with OpenSSL v3.0.
Changes were made following the OpenSSL 3.0 migration guide: https://www.openssl.org/docs/man3.0/man7/migration_guide.html In some cases, those changes are straightforward and only a small modification on the types or API calls was needed (e.g.: replacing BN_pseudo_rand() with BN_rand(). Both identical since v1.1.0). The use of low level APIs is now deprecated. In some cases, the new API provides a simplified solution for our goals and therefore the code was simplified accordingly (e.g.: generating RSA keys through EVP_RSA_gen() without the need of handling the exponent). However, in some cases, a more sophisticated approach was necessary, as the use of a context object was required (e.g.: when retrieving the digest value from an SHA file).
Signed-off-by: Juan Pablo Conde <juanpablo.conde@arm.com> Change-Id: I978e8578fe7ab3e71307450ebe7e7812fbcaedb6
show more ...
|
| #
9719e19a |
| 24-Mar-2021 |
Joanna Farley <joanna.farley@arm.com> |
Merge changes I500ddbe9,I9c10dac9,I53bfff85,I06f7594d,I24bff8d4, ... into integration
* changes: nxp lx2160a-aqds: new plat based on soc lx2160a NXP lx2160a-rdb: new plat based on SoC lx2160a
Merge changes I500ddbe9,I9c10dac9,I53bfff85,I06f7594d,I24bff8d4, ... into integration
* changes: nxp lx2160a-aqds: new plat based on soc lx2160a NXP lx2160a-rdb: new plat based on SoC lx2160a nxp lx2162aqds: new plat based on soc lx2160a nxp: errata handling at soc level for lx2160a nxp: make file for loading additional ddr image nxp: adding support of soc lx2160a nxp: deflt hdr files for soc & their platforms nxp: platform files for bl2 and bl31 setup nxp: warm reset support to retain ddr content nxp: nv storage api on platforms nxp: supports two mode of trusted board boot nxp: fip-handler for additional fip_fuse.bin nxp: fip-handler for additional ddr-fip.bin nxp: image loader for loading fip image nxp: svp & sip smc handling nxp: psci platform functions used by lib/psci nxp: helper function used by plat & common code nxp: add data handler used by bl31 nxp: adding the driver.mk file nxp-tool: for creating pbl file from bl2 nxp: adding the smmu driver nxp: cot using nxp internal and mbedtls nxp:driver for crypto h/w accelerator caam nxp:add driver support for sd and emmc nxp:add qspi driver nxp: add flexspi driver support nxp: adding gic apis for nxp soc nxp: gpio driver support nxp: added csu driver nxp: driver pmu for nxp soc nxp: ddr driver enablement for nxp layerscape soc nxp: i2c driver support. NXP: Driver for NXP Security Monitor NXP: SFP driver support for NXP SoC NXP: Interconnect API based on ARM CCN-CCI driver NXP: TZC API to configure ddr region NXP: Timer API added to enable ARM generic timer nxp: add dcfg driver nxp:add console driver for nxp platform tools: add mechanism to allow platform specific image UUID tbbr-cot: conditional definition for the macro tbbr-cot: fix the issue of compiling time define cert_create: updated tool for platform defined certs, keys & extensions tbbr-tools: enable override TRUSTED_KEY_CERT
show more ...
|
| #
b94bf967 |
| 09-Dec-2020 |
Pankaj Gupta <pankaj.gupta@nxp.com> |
cert_create: updated tool for platform defined certs, keys & extensions
Changes to 'tools/cert_create' folder, to include platform defined certificates, keys, and extensions.
NXP SoC lx2160a : base
cert_create: updated tool for platform defined certs, keys & extensions
Changes to 'tools/cert_create' folder, to include platform defined certificates, keys, and extensions.
NXP SoC lx2160a : based platforms requires additional FIP DDR to be loaded before initializing the DDR.
To enable chain of trust on these platforms, FIP DDR image needs to be authenticated, additionally.
Platform specific folder 'tools/nxp/cert_create_helper' is added to support platform specific macros and definitions.
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com> Change-Id: I4752a30a9ff3aa1d403e9babe3a07ba0e6b2bf8f
show more ...
|
| #
22eaa870 |
| 21-Jan-2020 |
Olivier Deprez <olivier.deprez@arm.com> |
Merge "cert_create: Remove some unused header files inclusions" into integration
|
| #
ba1eaabf |
| 07-Jan-2020 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
cert_create: Remove some unused header files inclusions
The chain of trust definitions are only needed in the part of the code dealing with the TBBR CoT (tbbr/* files).
Change-Id: I6f9a86bba4a2d163
cert_create: Remove some unused header files inclusions
The chain of trust definitions are only needed in the part of the code dealing with the TBBR CoT (tbbr/* files).
Change-Id: I6f9a86bba4a2d16313b6842a3ec85b7c951074bc Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
show more ...
|
| #
c428fbae |
| 13-Sep-2019 |
Soby Mathew <soby.mathew@arm.com> |
Merge changes from topic "jc/rsa-pkcs" into integration
* changes: Remove RSA PKCS#1 v1.5 support from cert_tool Add documentation for new KEY_SIZE option Add cert_create tool support for RSA
Merge changes from topic "jc/rsa-pkcs" into integration
* changes: Remove RSA PKCS#1 v1.5 support from cert_tool Add documentation for new KEY_SIZE option Add cert_create tool support for RSA key sizes Support larger RSA key sizes when using MBEDTLS
show more ...
|
| #
6a415a50 |
| 09-Sep-2019 |
Justin Chadwell <justin.chadwell@arm.com> |
Remove RSA PKCS#1 v1.5 support from cert_tool
Support for PKCS#1 v1.5 was deprecated in SHA 1001202 and fully removed in SHA fe199e3, however, cert_tool is still able to generate certificates in tha
Remove RSA PKCS#1 v1.5 support from cert_tool
Support for PKCS#1 v1.5 was deprecated in SHA 1001202 and fully removed in SHA fe199e3, however, cert_tool is still able to generate certificates in that form. This patch fully removes the ability for cert_tool to generate these certificates.
Additionally, this patch also fixes a bug where the issuing certificate was a RSA and the issued certificate was EcDSA. In this case, the issued certificate would be signed using PKCS#1 v1.5 instead of RSAPSS per PKCS#1 v2.1, preventing TF-A from verifying the image signatures. Now that PKCS#1 v1.5 support is removed, all certificates that are signed with RSA now use the more modern padding scheme.
Change-Id: Id87d7d915be594a1876a73080528d968e65c4e9a Signed-off-by: Justin Chadwell <justin.chadwell@arm.com>
show more ...
|
| #
e2ff5ef8 |
| 22-Nov-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #1165 from geesun/qx/support-sha512
Add support sha512 for hash algorithm
|
| #
2972247c |
| 09-Nov-2017 |
Qixiang Xu <qixiang.xu@arm.com> |
tools: add an option -hash-alg for cert_create
This option enables the user to select the secure hash algorithm to be used for generating the hash. It supports the following options: - sha256 (d
tools: add an option -hash-alg for cert_create
This option enables the user to select the secure hash algorithm to be used for generating the hash. It supports the following options: - sha256 (default) - sha384 - sha512
Change-Id: Icb093cec1b5715e248c3d1c3749a2479a7ab4b89 Signed-off-by: Qixiang Xu <qixiang.xu@arm.com>
show more ...
|
| #
9679297f |
| 11-Oct-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #1120 from michpappas/tf-issues#521_cert_tool_does_not_build_with_openssl_v1.1
cert_tool: update for compatibility with OpenSSL v1.1
|
| #
742c4e14 |
| 06-Oct-2017 |
Michalis Pappas <mpappas@aminocom.com> |
cert_tool: update for compatibility with OpenSSL v1.1
This patch fixes incompatibility issues that prevent building the cert_tool with OpenSSL >= v1.1.0. The changes introduced are still backwards c
cert_tool: update for compatibility with OpenSSL v1.1
This patch fixes incompatibility issues that prevent building the cert_tool with OpenSSL >= v1.1.0. The changes introduced are still backwards compatible with OpenSSL v1.0.2.
Fixes arm-software/trusted-fw#521
Signed-off-by: Michalis Pappas <mpappas@fastmail.fm>
show more ...
|
| #
54578745 |
| 07-Sep-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #1080 from soby-mathew/eb/RSA-PKCS1-5_support_1
Support legacy RSA PKCS#1 v1.5 in cert create
|
| #
a8eb286a |
| 31-Aug-2017 |
Soby Mathew <soby.mathew@arm.com> |
cert_tool: Support for legacy RSA PKCS#1 v1.5
This patch enables choice of RSA version at run time to be used for generating signatures by the cert_tool. The RSA PSS as defined in PKCS#1 v2.1 become
cert_tool: Support for legacy RSA PKCS#1 v1.5
This patch enables choice of RSA version at run time to be used for generating signatures by the cert_tool. The RSA PSS as defined in PKCS#1 v2.1 becomes the default version and this patch enables to specify the RSA PKCS#1 v1.5 algorithm to `cert_create` through the command line -a option. Also, the build option `KEY_ALG` can be used to pass this option from the build system. Please note that RSA PSS is mandated by Trusted Board Boot requirements (TBBR) and legacy RSA support is being added for compatibility reasons.
Fixes ARM-Software/tf-issues#499 Change-Id: Ifaa3f2f7c9b43f3d7b3effe2cde76bf6745a5d73 Co-Authored-By: Eleanor Bonnici <Eleanor.bonnici@arm.com> Signed-off-by: Soby Mathew <soby.mathew@arm.com>
show more ...
|
| #
47fd7cb0 |
| 05-Jun-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #964 from soby-mathew/sm/rsapss_sup
Add support for RSASSAPSS algorithm
|
| #
1f33ad4e |
| 22-May-2017 |
Soby Mathew <soby.mathew@arm.com> |
cert_create: Use RSASSA-PSS signature scheme for certificates
This patch modifies the `cert_create` tool to use RSASSA-PSS scheme for signing the certificates. This is compliant with RSA PKCS_2_1 st
cert_create: Use RSASSA-PSS signature scheme for certificates
This patch modifies the `cert_create` tool to use RSASSA-PSS scheme for signing the certificates. This is compliant with RSA PKCS_2_1 standard as mandated by TBBR.
Note that the certificates generated by using cert_create tool after this patch can be authenticated during TBB only if the corresponding mbedtls driver in ARM Trusted Firmware has the corresponding support.
Change-Id: If224f41c76b3c4765ae2af5259e67f73602818a4 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
show more ...
|
| #
e715e676 |
| 24-May-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #938 from masahir0y/tools_share
Collect headers shared between TF and host-tools into include/tools_share
|
| #
bb41eb7a |
| 22-May-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
cert: move platform_oid.h to include/tools_share for all platforms
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide a
cert: move platform_oid.h to include/tools_share for all platforms
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide any value (at least technically).
For easier use of TBBR, this commit allows platforms to reuse the OIDs obtained by ARM Ltd. This will be useful for non-ARM vendors that do not need their own extension fields in their certificate files.
The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h
Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by defining USE_TBBR_DEFS as 1. USE_TBBR_DEFS is 0 by default to keep the backward compatibility.
For clarification, I inserted a blank line between headers from the include/ directory (#include <...>) and ones from a local directory (#include "..." ).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| #
f132b4a0 |
| 04-May-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #925 from dp-arm/dp/spdx
Use SPDX license identifiers
|
| #
82cb2c1a |
| 03-May-2017 |
dp-arm <dimitris.papastamos@arm.com> |
Use SPDX license identifiers
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file.
NOTE: Files that have been imported by
Use SPDX license identifiers
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file.
NOTE: Files that have been imported by FreeBSD have not been modified.
[0]: https://spdx.org/
Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| #
7a1c268f |
| 14-Feb-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #833 from masahir0y/cert_create
Bug fix and cleanup of cert_create tool
|