Previous size was 3584 bytes which is not acceptable on constrained systems
(especially on the stack). This was a misguided attempt at minimizing the
number of calls to the RNG function in order to minimize impact on
performance, but clearly this does not justify using that much RAM and a
compromise had to be found.
While at it, loose the 'curve' argument in internal randomized functions, for
the same reasons we lost 'num_words' in uECC_vli_mult_rnd(): we only have one
curve so we don't need this, and hardcoding it saves a bit of code size and
speed, which is welcome to slightly reduce the impact of the counter-measure
on both of them.
This is a counter-measure to make horizontal attacks harder. Horizontal
attacks work with a single trace by noticing when intermediate computations
within that trace happen on the same operands.
We'll try to make that harder for an attacker to achieve that by introducing
random delays based on extra computation and extra random accesses to input in
the multi-precision multiplication (which is the dominant operation and the target of
horizontal attacks known so far). This should make it hard for the attacker to
compare two multiplications.
This first commit introduces the new function for multiplication with random
delay - future commits will ensure it is used all the way up to the top-level
scalar multiplication routine.
Why: this protects against potential side-channels attacks. This
counter-measure is for example effective against Template SPA. Also, the
bignum arithmetic as implemented in TinyCrypt isn't entirely regular, which
could in principle be exploited by an attacker; randomizing the coordinates
makes this less likely to happen.
Randomizing projective coordinates is also a well-known countermeasure to DPA.
In the context of the scalar multiplication in ECDSA, DPA isn't a concern
since it requires multiple measurements with various base points and the same
scalar, and the scalar mult in ECDSA is the opposite: the base point's always
the same and the scalar is always unique. But we want protection against the
other attacks as well.
How: we use the same code fragment as in uECC_shared_secret in ecc_dh.c,
adapted as follows: (1) replace p2 with k2 as that's how it's called in this
function; (2) adjust how errors are handled.
The code might not be immediately clear so here are a few more details:
regularize_k() takes two arrays as outputs, and the return value says which one
should be passed to ECCPoint_mult(). The other one is free for us to re-use to
generate a random number to be used as the initial Z value for randomizing
coordinates (otherwise the initial Z value is 1), thus avoiding the use of an
extra stack buffer.
The certificate has a corrupted public key and signature.
Generating it through Makefile isn't trivial and since it is
a corrupted certificate, that shouldn't be accepted, there
shouldn't be a need to generate it again anyway.
Only add test when both are enforcing. This is configured in baremetal.h
and is checked in the check_cmdline_compat, would render other cases
with baremetal.h to skipped.
Record checking fails if mbedtls_ssl_check_record() is called with
external buffer. Received record sequence number is available in the
incoming record but it is not available in the ssl contexts `in_ctr`-
variable that is used when decoding the sequence number.
To fix the problem, temporarily update ssl context `in_ctr` to
point to the received record header and restore value later.
Override define MBEDTLS_ENTROPY_MAX_SOURCES from 1 to 3 in baremetal_test.h
mbedtls_entropy_init adds 2 sources already so max must be 3 so that
one source can be added with mbedtls_entropy_add_source.
-Add config option for AES encyption only to config.h. Feature is
disabled by default.
-Enable AES encrypt only feature in baremetal.h configuration
-Remove AES encypt only feature from full config
- Unset MBEDTLS_PADLOCK_C in aes_only_128_bit_keys test to get RAM
optimised version tested
- Use compiler flag "-O1" instead of "-Wall -Wextra" to see warnings
Do not reserve additionl space for mbedtls_aes_context if config
option AES_ONLY_128_BIT_KEY_LENGTH is used and PADLOCK_C is not used.
This reduces RAM usage by 96 bytes.
In baremetal configuration reserve space for 10 128-bit keys in order
to save 112 bytes of heap.
- Do not include MBEDTLS_AES_ONLY_128_BIT_KEY_LENGTH to full config
as it requires also MBEDTLS_CTR_DRBG_USE_128_BIT_KEY
- Update check_config to check availability of flags:
MBEDTLS_AES_ONLY_128_BIT_KEY_LENGTH
MBEDTLS_CTR_DRBG_USE_128_BIT_KEY
