This is fix for the MBEDTLS_AES_SETKEY_DEC_ALT macro switch is including the aes xts methods
and building with a custom mbedtls_aes_setkey_dec function will disable the aes xts methods.
The fix is separating the aes xts methods and the MBEDTLS_AES_SETKEY_DEC_ALT can only
switch the presence of the mbedtls_aes_setkey_dec function.
Signed-off-by: gabor-mezei-arm <gabor.mezei@arm.com>
Mbed TLS requires users of DTLS to configure timer callbacks
needed to implement the wait-and-retransmit logic of DTLS.
Previously, the presence of these timer callbacks was checked
at every invocation of `mbedtls_ssl_fetch_input()`, so lowest
layer of the messaging stack interfacing with the underlying
transport.
This commit removes this recurring check and instead checks the
presence of timers once at the beginning of the handshake.
The main rationale for this change is that it is a step towards
separating the various layers of the messaging stack more cleanly:
datagram layer, record layer, message layer, retransmission layer.
Signed-off-by: Hanno Becker <hanno.becker@arm.com>
The calculation of the expected key size when not using the test_size_function
was not correct. The function has now been updated to handle all cases
properly to ensure the expected key size is correct for key pairs, public
keys, and symmetric keys.
Cleaned up some comments and removed unused includes.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
Previous guard was using original naming and did not
get updated to the new name. Guard is now using correct
definition of TEST_DRIVER_KEY_CONTEXT_SIZE_FUNCTION.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
Removed TBD comment that is no longer relevant since
that portion of the code has been updated.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
Updated get_expected_key_size in psa_crypto_driver_wrappers to properly
handle using the new size_function from PSA crypto drivers. Created
initial infrastructure to support size_function for the PSA crypto
drivers.
Signed-off-by: John Durkop <john.durkop@fermatsoftware.com>
The CCM specification (NIST SP 800-38C) mandates that the formatting of
the additional data length l(a) changes when it is greater _or equal_ to
2^16 - 2^8 (>= 0xFF00). Since such lengths are not supported in mbed TLS,
the operation should fail in such cases.
This commit fixes an off-by-one error which allowed encryption/decryption
to be executed when l(a) was equal to 0xFF00, resulting in an
incorrect/non-standard length format being used.
Fixes#3719.
Signed-off-by: Fredrik Strupe <fredrik.strupe@silabs.com>
* #3742 After input of a key as SECRET in the derivation, allow the
derivation result to be used as key.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
* #3741 Allow key agreement inside derivation with a key that's allowed
for the relevant agreement.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
This reverts commit 9c46a60e6c.
When the library is dynamically linked against Glibc (as is usually
the case with Glibc), it now requires a recent Glibc at runtime if it
was compiled with a recent Glibc. This is a loss of functionality for
no demonstrated benefit.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In psa_generate_key_internal() for ECC keys, remove the check that the
bit-size according to Mbed TLS is equal to the requested bit-size.
This check was necessary back when the PSA API encoded curves and key
sizes independently, in order to reject combinations such as SECP256R1
with a 512-bit size. Since the curve encoding changed to specifying a
curve family and a size separately, the Mbed TLS curve id (grp_id) and
the curve data (curve_info) are now determined from the size, and
checking that (curve_info->bit_size == bits) is now only a redundant
sanity check.
This check is actually buggy, because PSA Crypto and Mbed TLS don't
have exactly the same notion of key size. PSA thinks Curve25519 is
255-bit and secp224k1 is 225-bit, but Mbed TLS thinks they're 256-bit
and 224-bit respectively. Removing the check allows key generation to
work for these curves.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
mbedtls_ecp_curve_list() now lists Curve25519 and Curve448 under the names
"x25519" and "x448". These curves support ECDH but not ECDSA.
This was meant ever since the introduction of mbedtls_ecdsa_can_do()
in 0082f9df6f, but
2c69d10bac had removed the claim
that Montgomery curves support ECDH except through Everest.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
... as opposed to PSA_ERROR_BAD_STATE.
The spec on psa_cipher_finish() states that PSA_ERROR_INVALID_ARGUMENT
should be returned when:
"The total input size passed to this operation is not valid for this
particular algorithm. For example, the algorithm is a based on block
cipher and requires a whole number of blocks, but the total input size
is not a multiple of the block size."
Currently, there is a distinction between encryption and decryption
on whether INVALID_ARGUMENT or BAD_STATE is returned, but this is not
a part of the spec.
This fix ensures that PSA_ERROR_INVALID_ARGUMENT is returned
consistently on invalid cipher input sizes.
Signed-off-by: Fredrik Strupe <fredrik.strupe@silabs.com>
Starting with commit 49e94e3, the do/while loop in
`rsa_prepare_blinding()` was changed to a `do...while(0)`, which
prevents retry from being effective and leaves dead code.
Restore the while condition to retry, and lift the calls to finish the
computation out of the while loop by by observing that they are
performed only when `mbedtls_mpi_inv_mod()` returns zero.
Signed-off-by: Peter Kolbus <peter.kolbus@garmin.com>
According to https://www.bearssl.org/ctmul.html even single-precision
multiplication is not constant-time on some older platforms.
An added benefit of the new code is that it removes the somewhat mysterious
constant 0x1ff - which was selected because at that point the maximum value of
padlen was 256. The new code is perhaps a bit more readable for that reason.
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
The previous code used comparison operators >= and == that are quite likely to
be compiled to branches by some compilers on some architectures (with some
optimisation levels).
For example, take the following function:
void old_update( size_t data_len, size_t *padlen )
{
*padlen *= ( data_len >= *padlen + 1 );
}
With Clang 3.8, let's compile it for the Arm v6-M architecture:
% clang --target=arm-none-eabi -march=armv6-m -Os foo.c -S -o - |
sed -n '/^old_update:$/,/\.size/p'
old_update:
.fnstart
@ BB#0:
.save {r4, lr}
push {r4, lr}
ldr r2, [r1]
adds r4, r2, #1
movs r3, #0
cmp r4, r0
bls .LBB0_2
@ BB#1:
mov r2, r3
.LBB0_2:
str r2, [r1]
pop {r4, pc}
.Lfunc_end0:
.size old_update, .Lfunc_end0-old_update
We can see an unbalanced secret-dependant branch, resulting in a total
execution time depends on the value of the secret (here padlen) in a
straightforward way.
The new version, based on bit operations, doesn't have this issue:
new_update:
.fnstart
@ BB#0:
ldr r2, [r1]
subs r0, r0, #1
subs r0, r0, r2
asrs r0, r0, #31
bics r2, r0
str r2, [r1]
bx lr
.Lfunc_end1:
.size new_update, .Lfunc_end1-new_update
(As a bonus, it's smaller and uses less stack.)
While there's no formal guarantee that the version based on bit operations in
C won't be translated using branches by the compiler, experiments tend to show
that's the case [1], and it is commonly accepted knowledge in the practical
crypto community that if we want to sick to C, bit operations are the safest
bet [2].
[1] https://github.com/mpg/ct/blob/master/results
[2] https://github.com/veorq/cryptocoding
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
* Reworked the cipher context once again to be more robustly defined
* Removed redundant memset
* Unified behaviour on failure between driver and software in cipher_finish
* Cipher test driver setup function now also returns early when its status
is overridden, like the other test driver functions
* Removed redundant test cases
* Added bad-order checking to verify the driver doesn't get called where
the spec says it won't.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
As pointed out by Ronald. The key slot is populated using
get_key_from_slot, and after calling the driver the slot is
validated to not contain an external key, so calling
get_transparent_key is superfluous.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Added zeroization of the wrapper context on failure/abort, and reliance on
the crypto core to not call an uninitialised wrapper.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
Once an operation has been 'accepted' by a driver, the remainder is bound
to the same driver, since driver-specific context structs cannot be shared.
This provides a pretty good gate mechanism for the fallback logic, too.
Signed-off-by: Steven Cooreman <steven.cooreman@silabs.com>
