History log of /rk3399_ARM-atf/tools/cert_create/src/cert.c (Results 1 – 25 of 36)
Revision Date Author Comments
# 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


12