This avoids the need for each calling site to manually regularize the scalar
and randomize coordinates, which makes for simpler safe use and saves 50 bytes
of code size in the library.
Even though this is type name is purely internal to a single C file, let's
reduce the potential for clashes with other wait state types which might be
added elsewhere in the library and become visible here (for example through
platform_util.h).
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.
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
Ultimately, mbedtls_hardware_poll() is going to be provided by the
OS/environment when running on target. But for on-host programs and tests, we
need to define (a fake version) in each program that we want to be able to
link.
A previous commit took care of ssl_client2 and ssl_server2. But if we want to
be able to compile all programs, we need to modify each of them. This doesn't
seem useful, so instead let's just build the programs we need for testing -
this means only udp_proxy needs fixing in addition to what's already done.
This issue went unnoticed in the PR that introduced the new all.sh component,
because at that time the platform_memxxx() functions were not actually used in
the library (nor in programs), so the linker could live with
mbedtls_hardware_poll() not being defined, as it wasn't called anywhere. This
changed when we started using the new platform_memxxx() functions in the
library.
- out_ctr is public because it's transmited over the wire in DTLS (and in TLS
it can be inferred by a passive network attacker just by counting records).
- handshake mask is not a secret because it can be inferred by a passive
network attacker just logging record sequence number seen so far.
