Since our mbedtls code is not a pure upstream version, let's add a note
about this in the SBOM manifest description, which will be included in
the generated SPDX file. We used the same approach e.g. for freertos.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This is an initial version of the sbom.yml file for Espressif's mbedtls.
It's used by the esp-idf-sbom[1] tool to generate an SBOM file in the SPDX
format for esp-idf projects.
[1] - https://github.com/espressif/esp-idf-sbom
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
ESP32C2 has a hardware ECC accelerator that supports NIST P-192 and NIST P-256 curves,
which can increase the performance of the point multiplication and point
verification operation.
Provision is also added to fallback to software implementation in
case the curve is not from the supported curves
(cherry picked from commit e46cff44a1)
For exponential mod (API mbedtls_mpi_exp_mod) operation, some ESP target
chips needs to have ability for both hardware and software implementation.
Hardware implementation provided performance advantage but it can only
support upto 3072 bit operations (e.g., ESP32-C3) and hence we fallback
to software implementation in such cases (e.g., 4096 bit operations).
Earlier this was handled using linker "--wrap" flag but that does not
work in all scenarios as API `mbedtls_mpi_exp_mod` is being used in
same tranlation (compilation unit).
This approach was found to be next best option with minimal changes in
mbedTLS library.
(cherry picked from commit 30c6840e0e)
Upon further consideration we think that a remote attacker close to the
victim might be able to have precise enough timing information to
exploit the side channel as well. Update the Changelog to reflect this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
The signature and naming of the Montgomrey initialisation function in
development and in the LTS was different. Align them for easier
readability and maintenance.
Signed-off-by: Janos Follath <janos.follath@arm.com>
Any timing variance dependant on the output of this function enables a
Bleichenbacher attack. It is extremely difficult to use safely.
In the Marvin attack paper
(https://people.redhat.com/~hkario/marvin/marvin-attack-paper.pdf) the
author suggests that implementations of PKCS 1.5 decryption that don't
include a countermeasure should be considered inherently dangerous.
They suggest that all libraries implement the same countermeasure, as
implementing different countermeasures across libraries enables the
Bleichenbacher attack as well.
This is extremely fragile and therefore we don't implement it. The use
of PKCS 1.5 in Mbed TLS implements the countermeasures recommended in
the TLS standard (7.4.7.1 of RFC 5246) and is not vulnerable.
Add a warning to PKCS 1.5 decryption to warn users about this.
Signed-off-by: Janos Follath <janos.follath@arm.com>
So far we needed it only locally here, but we will need calculating RR
for safe unblinding in RSA as well.
Signed-off-by: Janos Follath <janos.follath@arm.com>
mbedtls_ssl_cache_get() and mbedtls_ssl_cache_set() returned 1 on many error
conditions. Change this to returning a negative MBEDTLS_ERR_xxx error code.
Completeness: after this commit, there are no longer any occurrences of
`return 1` or `ret = 1`.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
When ECDSA_SIGN_ALT but not ECDSA_VERIFY_ALT, mbedtls_ecdsa_can_do was not being defined causing mbedtls_ecdsa_verify_restartable to always fail
Signed-off-by: JonathanWitthoeft <jonw@gridconnect.com>
Also correct 'distro to 'dist' and update ubuntu to jammy and python
to 3.10 to hopefully fend off future issues. Too much got removed
when disabling travis and the Coverity scan build was failing on 'make
generated-files', due to lack of installed python dependencies
Signed-off-by: Paul Elliott <paul.elliott@arm.com>
Frantisek Hrbata