In preparation for the implementation of the accelerator APIs. This is
ramping up to the goal of only storing the export representation in the
key slot, and not keeping the crypto implementation-specific representations
around.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
The convention from the TLS RFC is a bit unusual, so even if the test
function's introductory comment mentions that we're taking the RFC's
definition, it doesn't hurt to repeat it in crucial places.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Passing a length of 0 to it is perfectly acceptable, the macro was designed to
handle it correctly.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
We only have a single integer available for two nested loops, but the loop
sizes are small enough compared to the integer's range that we can encode both
indexes. Since the integer is displayed in decimal in case of errors, use a
power of 10 to pack the two indexes together.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Currently this breaks all.sh component test_memsan_constant_flow, just as
expected, as the current implementation is not constant flow.
This will be fixed in the next commit.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
tests/scripts/curves.pl tests the library with a single curve enabled.
This uses the legacy ECDH context and the default ECDH implementation.
For Curve25519, there is an alternative implementation, which is
Everest. Test this. This also tests the new ECDH context, which
Everest requires.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Previously curves.pl tested with all elliptic curves enabled except
one, for each curve. This catches tests that are missing dependencies
on one of the curve that they use, but does not catch misplaced
conditional directives around parts of the library.
Now, we additionally test with a single curve, for each curve. This
catches missing or extraneous guards around code that is specific to
one particular curve or to a class of curves.
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
Run some self-test both for a short Weierstrass curve and for a
Montgomery curve, if the build-time configuration includes a curve of
both types. Run both because there are significant differences in the
implementation.
The test data is suitable for Curve25519.
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
The constants used in the test worked with every supported curve
except secp192k1. For secp192k1, the "N-1" exponent was too large.
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
For some curves (semi-coincidentally, short Weierstrass curves), the
ECP module calculates some group parameters dynamically. Build the
code to calculate the parameters only if a relevant curve is enabled.
This fixes an unused function warning when building with only
Montgomery curves.
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
Replace the now-redundant internal curve type macros ECP_xxx by the
macros MBEDTLS_ECP__xxx_ENABLED which are declared in ecp.h.
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
Document that mbedtls_ecp_muladd and mbedtls_ecp_muladd_restartable
are only implemented on short Weierstrass curves.
Exclude these functions at build time if no short Weierstrass curve
is included in the build. Before, these functions failed to compile in
such a configuration.
Signed-off-by: Gilles Peskine <gilles.peskine@arm.com>
Document in config.h, and enforce in check_config.h, that
MBEDTLS_ECDSA_C requires at least one short Weierstrass curve to be
enabled. A Montgomery curve is not enough.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
* development:
Update to renamed curve constant
Remove superfluous argument to ecp_write_key
Revise comments for x509write_csr_der_internal
Avoid stack-allocation of large memory buffers
Fix Curve25519 ecp_read_key vectors to match description
Rewrite changelog for #3425 as requested
Rework mbedtls_ecp_write_key to remove unnecessary output parameter
Fix endianness and masking for Curve25519 keys handled by PSA
Document masking of Montgomery private keys in psa_export_key
Implement and test mbedtls_ecp_write_key
Use local labels in padlock.c
Add Changelog entry for PSA DH/ECC Macros rename
Rename DH Family Macros According to PSA Spec
Rename ECC Family Macros According to PSA Spec
Everything works at the byte level, not bit level. Flipping the lsb is just
one convenient way to corrupt a byte, but don't really care about individual
bits.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
In the entries (mbedtls_x509_crl_entry values) on the list constructed
by mbedtls_x509_crl_parse_der(), set entry->raw.tag to
(SEQUENCE | CONSTRUCTED) rather than to the tag of the first ASN.1
element of the entry (which happens to be the tag of the serial
number, so INTEGER or INTEGER | CONTEXT_SPECIFIC). This is doesn't
really matter in practice (and in particular the value is never used
in Mbed TLS itself), and isn't documented, but at least it's
consistent with how mbedtls_x509_buf is normally used.
The primary importance of this change is that the old code tried to
access the tag of the first element of the entry even when the entry
happened to be empty. If the entry was empty and not followed by
anything else in the CRL, this could cause a read 1 byte after the end
of the buffer containing the CRL.
The test case "X509 CRL ASN1 (TBSCertList, single empty entry at end)"
hit the problematic buffer overflow, which is detected with ASan.
Credit to OSS-Fuzz for detecting the problem.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Add a few more negative test cases for mbedtls_x509_crl_parse.
The test data is manually adapted from the existing positive test case
"X509 CRL ASN1 (TBSCertList, sig present)" which decomposes as
305c
3047 tbsCertList TBSCertList
020100 version INTEGER OPTIONAL
300d signatureAlgorithm AlgorithmIdentifier
06092a864886f70d01010e
0500
300f issuer Name
310d300b0603550403130441424344
170c303930313031303030303030 thisUpdate Time
3014 revokedCertificates
3012 entry 1
8202abcd userCertificate CertificateSerialNumber
170c303831323331323335393539 revocationDate Time
300d signatureAlgorithm AlgorithmIdentifier
06092a864886f70d01010e
0500
03020001 signatureValue BIT STRING
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This option allows to test the constant-flow nature of selected code, using
MemSan and the fundamental observation behind ctgrind that the set of
operations allowed on undefined memory by dynamic analysers is the same as the
set of operations allowed on secret data to avoid leaking it to a local
attacker via side channels, namely, any operation except branching and
dereferencing.
(This isn't the full story, as on some CPUs some instructions have variable
execution depending on the inputs, most notably division and on some cores
multiplication. However, testing that no branch or memory access depends on
secret data is already a good start.)
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The test function now depends on MBEDTLS_TEST_HOOKS, which is enabled by
config.py full, and since there are already components in all.sh exercising
the full config, this test function is sill exercised even with this new
dependency.
Since this is the first time a test function depends on MBEDTLS_TEST_HOOKS,
fix a bug in check-names.sh that wasn't apparent so far: headers from
library/*.h were not considered when looking for macro definitions. This
became apparent because MBEDTLS_STATIC_TESTABLE is defined in library/common.h
and started being used in library/ssl_msg.c, so was flagged as a likely typo.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Just move code from ssl_decrypt_buf() to the new cf_hmac() function and then
call cf_hmac() from there.
This makes the new cf_hmac() function used, opening the door for making it
static in the next commit. It also validates that its interface works for
using it in ssl_decrypt_buf().
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The dummy implementation is not constant-flow at all for now, it's just
here as a starting point and a support for developing the tests and putting
the infrastructure in place.
Depending on the implementation strategy, there might be various corner cases
depending on where the lengths fall relative to block boundaries. So it seems
safer to just test all possible lengths in a given range than to use only a
few randomly-chosen values.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Driver developer's guide: introduction on how to write a driver.
Driver integration guide: how to build Mbed TLS with drivers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
