Change the name of these confs to be version agnostic,
we will later use these configs to enforce the mbedtls
minimum version
Change-Id: I1f665c2471877ecc833270c511749ff845046f10
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
Make this function return values from crypto_ret_value.
The previous method of returning the mbedtls error code
on failure meant that the authentication module couldn't
correctly parse failures from this function.
Change-Id: I9fe6eba1fc79e8f81004f8cd202781aea907e963
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
The buffer size allocated for the raw ECDSA signatures
was too small for P-384 signatures. This led to mbedtls
aborting the generation of the raw sig.
Fix this by increasing the buffer size to the required
value.
Change-Id: I06a9cfe1f4cb2603c5fbe945714e90460c24edb8
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
This new version uses the multipart PSA AEAD API;
the authentication tag is verified via
a call to psa_aead_verify.
Change-Id: If4b7e6258223ae6fead1794d3e8d0004f0f387b3
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
MbedTLS 3.6.1 fixed the issue which previously
produced this warning, so this hack is no longer
necessary.
Change-Id: I934adefbf2fed16e16b9d98bc8674125b70b08fc
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
There is no need for the bl2 static c file for
CCA and Duaroot CoT, remove them from the repo
Change-Id: I251d085034dae0f6b3c6cefdbb129a9e1dd0530b
Signed-off-by: Xialin Liu <Xialin.Liu@ARM.com>
Separate the bl1 and bl2 CoT into individual C files for the
upcoming tool, i.e. the CoT device tree-to-source file generator.
Change-Id: I0d24791991b3539c7aef9a562920dc62fecdc69a
Signed-off-by: Xialin Liu <Xialin.Liu@ARM.com>
This new version uses fewer internal functions
in favour of calling equivalent mbedtls APIs.
Change-Id: I0c2c20a74687211f2d554501f57898da07b01739
Signed-off-by: Ryan Everett <ryan.everett@arm.com>
When the verify_signature function is called with the RSASSA_PSS
signature algorithm and a somewhat well-formed public key, invalid
signatures can be incorrectly verified due to this change [1].
This is primarily because of the introduction of the following code,
where a return check is missing before the goto:
if (pk_alg == MBEDTLS_PK_RSASSA_PSS) {
rc = pk_bytes_from_subpubkey((unsigned char **) &pk_ptr, &pk_len);
goto end2;
}
This code executes before the call to psa_verify_message. The
unconditional goto end2; branch leads to the immediate return of rc.
If the call to pk_bytes_from_subpubkey succeeds (i.e., the key is
formatted correctly), the signature is verified regardless of its
actual content.
This change [1] was included in the v2.11 release. Therefore, anyone
using this release with the PSA Crypto implementation must apply
this patch to ensure proper signature verification.
[1]: https://review.trustedfirmware.org/plugins/gitiles/TF-A/
trusted-firmware-a/+/55aed7d798f3d48d6aa08d58eb46c4cda318bcfb/drivers/
auth/mbedtls/mbedtls_psa_crypto.c#447
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Reported-by: Ryan Everett <ryan.everett@arm.com>
Change-Id: Ib484d97a04b7a82dd72592c8b5b153d577d01fc9
Remove the 'HW_CONFIG' reference from the BL1 CoT file, as BL1
does not play any role in loading the hw_config image. This
reference was incorrectly added to the BL1 CoT file.
Change-Id: I9c1d9abce65844eaa1f41ab4f98d3c258ab7a8d2
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Further, remove reliance of mbedtls_md_psa_alg_from_type on
the actual values of the PSA_ALG_... defines.
And work around a prior bug that would try to import a
SubjectPublicKeyInfo into a PSA key. Instead, we import the
SubjectPublicKey itself.
Change-Id: Ib345b0bd4f2994f366629ed162d18814fd05aa2b
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
Deprecation notice was sent to the community and no objection was
raised, so removing mbedtls 2.x support.
Change-Id: Id3eb98b55692df98aabe6a7c5a5ec910222c8abd
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
The version 2 of the FWU metadata structure has a field bank_state in
the top level of the structure which can be used to check if a given
bank is in the either of Trial State, Accepted State, or in an Invalid
State. This is different from the binary states of Valid/Accepted
States that the bank could be in, as defined in the earlier version of
the specification.
Replace the fwu_is_trial_run_state() API with
fwu_get_active_bank_state() to get the state the current active bank
is in. The value returned by this API is then used by the caller to
take appropriate action.
Change-Id: I764f486840a3713bfe5f8e03d0634bfe09b23590
Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
The usage of this macro hinders the accuracy of code coverage
data. Lines of code calling this macro always appear as covered because
the test condition within it always gets executed; however, the branch
is not necessarily taken. Consequently, we lose branch coverage
information on these error code paths.
Besides, it is debatable whether such a simple macro really improves
code readability or on the contrary obfuscates the code...
For these reasons, this patch inlines the macro code everywhere it was
called.
It also adds some error messages in all these places to help narrowing
down authentication failures. These messages only get displayed and
compiled into the binaries when building TF-A with 'LOG_VERBOSE' level
of verbosity. We use the same message string everywhere in order to
limit the memory footprint increase for 'LOG_VERBOSE' builds.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: I461078bb8c6fd6811d2cbefbe3614e17e83796f2
CryptoCell-712 and CryptoCell-713 drivers have been deprecated since
TF-A v2.9 and their removal was announced for TF-A v2.10 release.
See [1].
As the release is approaching, this patch deletes these drivers' code as
well as all references to them in the documentation and Arm platforms
code (Nuvoton platform is taken care in a subsequent patch). Associated
build options (ARM_CRYPTOCELL_INTEG and PLAT_CRYPTOCELL_BASE) have also
been removed and thus will have no effect if defined.
This is a breaking change for downstream platforms which use these
drivers.
[1] https://trustedfirmware-a.readthedocs.io/en/v2.9/about/release-information.html#removal-of-deprecated-drivers
Note that TF-A v3.0 release later got renumbered into v2.10.
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Change-Id: Idabbc9115f6732ac1a0e52b273d3380677a39813
The ECDSA algorithm signature verification in the PSA differs
from the RSA algorithm in its handling of data formats. In the
case of RSA, an encoded ASN1.0 buffer is passed to the PSA API,
which then decodes the buffer. However, for ECDSA, the PSA API
expects a raw format.
To accomodate this requirement, introduce several static APIs
that allows to retrieve -
1. ECDSA public key data pointer along with its size, and also,
the ECC family in PSA format from the public key.
2. R and S pair of the ECDSA signature along with its size
Change-Id: Icc7d5659aeb3d5c1ab63c3a12c001e68b11a3a86
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Use KEY_SIZE 384 to enable ECDSA P384 key support by
setting MBEDTLS_ECP_DP_SECP384R1_ENABLED.
Selected by setting KEY_ALG=ecdsa and KEY_SIZE=384.
Change-Id: I382f34fc4da98f166a2aada5d16fdf44632b47f5
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
A PSA crypto API is used for signature verification, namely
psa_verify_message, which calculates the signature and verify it
for the given signed message.
Note, this functionality is as of now tested for RSA based Key
algorithm, subsequent patches will provide the signature verification
support for all the key algorithms available in TF-A (provided by KEY_ALG
build option).
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: I16214e3cac6a7af445530a6dbd66cfc6ceedcfc6
A PSA crypto API is used for hash verification, namely
'psa_hash_compute', which internally calculates hash of the given
data payload.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ic90e43e68b836ee2add4b868663cfca2340c8108
A PSA crypto API is used for hash verification, namely
psa_hash_verify, which internally calculates and verifies the hash
of the given data payload.
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Change-Id: Ib48aa6b74b59aea6036333ff00f6ca566b910e60
Initialised Mbedtls PSA cryto during Crypto init using
function call 'psa_crypto_init'.
MbedTLS currently requires a Random Number Generator (RNG) once
PSA Crypto support is enabled. However, TF-A itself doesn't engage
in cryptographic operations that demand randomness. Consequently,
we simulate the presence of an external TRNG (through the configuration
option 'MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG) while, in reality, we offer
a dummy implementation of mbedtls_psa_external_get_random() that always
returns an error.
Change-Id: Ife6d03909c0e6081438d2b2519ef500e5dcdb88f
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
An ad-hoc MbedTLS PSA crypto driver is registered by compiling
a new driver file, namely mbedtls_psa_crypto.c when PSA_CRYPTO=1.
As of now, this file is the same as mbedtls_crypto.c, but subsequent
patches will update crypto functions in this file to trigger
PSA crypto APIs.
Change-Id: I404c347990661d87dcf5d0501d238e36914ec3ee
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
This is a preparatory patch to provide MbedTLS PSA Crypto
API support, with below changes -
1. Added a build macro PSA_CRYPTO to enable the MbedTLS PSA
Crypto API support in the subsequent patches.
2. Compile necessary PSA crypto files from MbedTLS source code
when PSA_CRYPTO=1.
Also, marked PSA_CRYPTO as an experimental feature.
Change-Id: I45188f56c5c98b169b2e21e365150b1825c6c450
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
crypto_mod_verify_signature() expects a pointer to the full pk.
In case of stm32mp1 crypto_verify_signature() will call
get_plain_pk_from_asn1() on the converted pk which fails.
Fixes: f1e693a775
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Change-Id: Ia9bdaa10e1b09f9758e5fa608a063b5212c428c3
Once the Public Key has been verified, call 'plat_mboot_measure_key'
to measure and publicise it.
Change-Id: I46ea71dcbba96db3706602ccd89f22596ae68416
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Trusted Board Boot supports multiple hash algorithms, including SHA-256,
SHA-384, and SHA-512. These algorithms produce hashes of different
lengths, so the resulting DER-encoded hash objects are also of different
lengths. However, the common Trusted Board Boot code only stores the
contents of the object, not its length. Before commit
f47547b354, this was harmless: ASN.1
objects are self-delimiting, and any excess padding was ignored.
f47547b354 changed the code to reject
excess padding. However, this breaks using a shorter hash in a build
that supports longer hashes: the shorter hash will have padding after
it, and verify_hash() will reject it. This was found by an Arm
customer: TF-A v2.9 refused to boot, even though TF-A v2.6 (which did
not have f47547b354) worked just fine.
Storing the length of the hash turns out to be quite difficult.
However, it turns out that hashes verified by verify_hash() always come
from the ROTPK or an X.509 certificate extension. Furthermore, _all_
X.509 certificate extensions used by Trusted Board Boot are ASN.1
DER encoded, so it is possible to reject padding in get_ext(). Padding
after the ROTPK is harmless, and it is better to ignore that padding
than to refuse to boot the system.
Change-Id: I28a19d7783e6036b65e86426d78c8e5b2ed6f542
Fixes: f47547b354 ("fix(auth): reject invalid padding in digests")
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Modifying the CCA CoT description to put the CCA content certificate
under the new CCA NV counter.
Change-Id: Ib962cef5eaa15bb9ccce86012f21327d29d4adad
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Have only one definition for REGISTER_CRYPTO_LIB macro, with all the
possible fields. Worst case adds 4 u64 to crypto_lib_desc.
While at it, correct some MISRA violations:
MC3R1.R12.1: (advisory) The precedence of operators within expressions
should be made explicit.
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I1342a20e6eef2354753182c2a81ff959e03e5c81
Following discussions in the reviews of the patch that introduced
plat_convert_pk() function [1], it was decided to deprecate it to
avoid weak function declaration.
A new optional function pointer convert_pk is added to crypto_lib_desc_t.
A new function crypto_mod_convert_pk() will either call
crypto_lib_desc.convert_pk() if it is defined, or do the same
as what was done by the weak function otherwise.
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17174
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com>
Change-Id: I9358867f8bfd5e96b5ee238c066877da368e43c6
Compared the full ROTPK with the ROTPK obtained from the certificate
when the platform supports full ROTPK instead of hash of ROTPK.
Additionally, changed the code to verify the ROTPK before relying on
it for signature verification.
Change-Id: I52bb9deb1a1dd5b184d3156bddad14c238692de7
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Previously, extensions were parsed twice: once with error checking for
validation, and a second time without error checking to extract the
extension data. This is error prone and caused TFV-10 (CVE-2022-47630).
A simpler approach is to have get_ext() be responsible for all extension
parsing, and to treat a NULL OID as an indicator that get_ext() is only
being called for validation. cert_parse() checks that get_ext() returns
IMG_PARSER_OK and fails otherwise.
Change-Id: I65a2ff053a188351ba54799827a2b7bd833bb037
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
The previous code was correct but unnecessarily verbose.
Change-Id: Ia19c667811a7c3b6957a0274d36076b0b16e36b7
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
The unique IDs are handled identically, so just use a for loop to get
both of them.
Change-Id: I44baaa4747ca7f314d364a79dfcbce97315f5a92
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
TF-A support for mbedtls3.x has been overdue by number of releases.
As per mbedtls support it was advised to use latest and greatest
mbedtls-3.3. But mbedtls-3.x breaks API compatibility with
mbedtls-2.x
To maintain comptability for mbedtls-2.x and enable mbedtls-3.x
support add a functionality into makefile to determine the major version
of mbedtls and use that to selective include or compile files
that are present.
With mbedtls-3.x numerous other config changes have been done.
Some of the config options deprecated or enabled by default.
Thus we decided to introduce a new 3.x config file part of this
change for building TF-A with mbedtls-3.3.
For futher information on migrating to mbedtls 3.x refer to:
https://github.com/Mbed-TLS/mbedtls/blob/development/docs/3.0-migration-guide.md
Change-Id: Ia8106d6f526809df927d608db27fe149623258ed
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
In preparation for supporting mbedtls 3.3, usage of
mbedtls_pk_rsassa_pss_options[1] is made private and is broken on 3.3
However looking closely into the usage in 'verify_signature' function
is no hard reason behind usage of this struct and they could be easily
replaced with independent variables.
This Minor refactor to avoid using the struct mbedtls_pk_rsassa_pss_options
and use independent variable will provide compatibility with both 2.x
and 3.x
[1]: https://github.com/Mbed-TLS/mbedtls/issues/7040
Change-Id: If0107d860d11d13cba7fd5d7941e7142e70c7b11
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
Currently we include MBEDTLS_CONFIG_FILE directly and if a custom
config file is used it will included.
However from mbedtls-3.x onwards it discourages usage of
MBEDTLS_CONFIG_FILE include directly, so to resolve this and keep 2.28
compatibility include version.h which would include the custom config
file if present and also would expose us with mbedtls-major-version
number which could be used for selecting features and functions for
mbedtls 2.28 or 3.3
Change-Id: I029992311be2a38b588ebbb350875b03ea29acdb
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
* changes:
fix(libc): remove __putchar alias
fix(console): correct scopes for console symbols
fix(auth): use NULL instead of 0 for pointer check
fix(io): compare function pointers with NULL
fix(fdt-wrappers): use correct prototypes
This was triggered by sparse tool:
drivers/auth/mbedtls/mbedtls_x509_parser.c:481:42: warning:
Using plain integer as NULL pointer
Signed-off-by: Yann Gautier <yann.gautier@st.com>
Change-Id: I392316c2a81ef8da7597e35f136e038f152d19d1
get_ext() does not check the return value of the various mbedtls_*
functions, as cert_parse() is assumed to have guaranteed that they will
always succeed. However, it passes the end of an extension as the end
pointer to these functions, whereas cert_parse() passes the end of the
TBSCertificate. Furthermore, cert_parse() does *not* check that the
contents of the extension have the same length as the extension itself.
Before fd37982a19 ("fix(auth): forbid junk after extensions"),
cert_parse() also does not check that the extension block extends to the
end of the TBSCertificate.
This is a problem, as mbedtls_asn1_get_tag() leaves *p and *len
undefined on failure. In practice, this results in get_ext() continuing
to parse at different offsets than were used (and validated) by
cert_parse(), which means that the in-bounds guarantee provided by
cert_parse() no longer holds.
This patch fixes the remaining flaw by enforcing that the contents of an
extension are the same length as the extension itself.
Change-Id: Id4570f911402e34d5d6c799ae01a01f184c68d7c
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
auth_nvctr() does not check that the buffer provided is long enough to
hold an ASN.1 INTEGER, or even that the buffer is non-empty. Since
auth_nvctr() will only ever read 6 bytes, it is possible to read up to
6 bytes past the end of the buffer.
This out-of-bounds read turns out to be harmless. The only caller of
auth_nvctr() always passes a pointer into an X.509 TBSCertificate, and
all in-tree chains of trust require that the certificate’s signature has
already been validated. This means that the signature algorithm
identifier is at least 4 bytes and the signature itself more than that.
Therefore, the data read will be from the certificate itself. Even if
the certificate signature has not been validated, an out-of-bounds read
is still not possible. Since there are at least two bytes (tag and
length) in both the signature algorithm ID and the signature itself, an
out-of-bounds read would require that the tag byte of the signature
algorithm ID would need to be either the tag or length byte of the
DER-encoded nonvolatile counter. However, this byte must be
(MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE) (0x30), which is
greater than 4 and not equal to MBEDTLS_ASN1_INTEGER (2). Therefore,
auth_nvctr() will error out before reading the integer itself,
preventing an out-of-bounds read.
Change-Id: Ibdf1af702fbeb98a94c0c96456ebddd3d392ad44
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
This makes the code a little bit smaller. No functional change
intended.
Change-Id: I794d2927fcd034a79e29c9bba1f8e4410203f547
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Certificates must not allow trailing junk after them.
Change-Id: Ie33205fb051fc63af5b72c326822da7f62eec1d1
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
This is already checked by the crypto module or by mbedTLS, but checking
it in the X.509 parser is harmless.
Change-Id: Ifdbe3b4c6d04481bb8e93106ee04b49a70f50d5d
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
