Commit graph

10211 commits

Author SHA1 Message Date
Manuel Pégourié-Gonnard a6115087a0 Move G from struct curve to its own constant 2019-11-26 12:53:13 +01:00
Manuel Pégourié-Gonnard 356d8594d7 Move n from struct curve to its own constant 2019-11-26 12:52:57 +01:00
Manuel Pégourié-Gonnard 4d8777cbb6 Move p from curve structure to its own constant
This removes an indirection, which both makes the code smaller and decreases
the number of glitching opportunities for an attacker.
2019-11-26 12:51:58 +01:00
Manuel Pégourié-Gonnard 30833f2a07 Remove num_n_bits member from curve structure 2019-11-21 15:37:22 +01:00
Manuel Pégourié-Gonnard 72c1764c00 Remove num_bytes member from curve structure
Reduces code size and size of the structure.
2019-11-21 15:37:22 +01:00
Manuel Pégourié-Gonnard 1765933ab2 Remove num_words member from curve structure
Saves code size, and makes the curve structure simpler.
2019-11-21 15:37:22 +01:00
Manuel Pégourié-Gonnard 1c6f7eae2d Remove function pointers from curve structure
They're not needed in practice, and removing them decreases the code size
slightly and provides less opportunities for an attacker.
2019-11-21 15:37:22 +01:00
Manuel Pégourié-Gonnard e714332563 Add pre and post-validation to mult_safer()
Validating the input is always a good idea. Validating the output protects
against some fault injections that would make the result invalid.

Note: valid_point() implies that the point is not zero.

Adding validation to mult_safer() makes it redundant in
compute_shared_secret().
2019-11-21 15:37:22 +01:00
Manuel Pégourié-Gonnard 41ab8cb6cb Centralize everything to EccPoint_mult_safer()
This will make easier to add future counter-measures in a single place.

In practice this change means that:

- compute_public_key() now uses projective coordinate randomisation, which it
  should as this is a protection against Template Attacks for example.
- mult_safer() now checks that the result is not the point at infinity, which
  it can as the result is indeed never expected to be that
2019-11-21 15:37:22 +01:00
Manuel Pégourié-Gonnard 72a8c9e7dc Force some compilers to respect volatile reads
Inspection of the generated assembly showed that before this commit, armcc 5
was optimizing away the successive reads to the volatile local variable that's
used for double-checks. Inspection also reveals that inserting a call to an
external function is enough to prevent it from doing that.

The tested versions of ARM-GCC, Clang and Armcc 6 (aka armclang) all keep the
double read, with our without a call to an external function in the middle.

The inserted function can also be changed to insert a random delay if
desired in the future, as it is appropriately places between the reads.
2019-11-21 15:14:59 +01:00
Manuel Pégourié-Gonnard ca7b5ab5ef Use double-checking of critical value in pk_verify()
Also change the flow so that the default return value is a failing one.
2019-11-21 15:14:59 +01:00
Manuel Pégourié-Gonnard 324c6e9cc9 Add error code MBEDTLS_ERR_PLATFORM_FAULT_DETECTED
This can be used by Mbed TLS functions in any module to signal that a fault
attack is likely happening, so this can be appropriately handled by the
application (report, fall back to safer mode or even halt, etc.)
2019-11-21 15:14:59 +01:00
Manuel Pégourié-Gonnard e6d6f17738 Add double-checking of critical value in uECC_verify()
This hardens against attacks that glitch the conditional branch by making it
necessary for the attacker to inject two consecutive faults instead of one. If
desired, we could insert a random delay in order to further protect against
double-glitch attacks.

Also, when a single glitch is detected we report it.
2019-11-21 15:14:59 +01:00
Manuel Pégourié-Gonnard 2b6312b7d9 Harden return value of uECC_vli_equal()
Previously it was returning 0 or 1, so flipping a single bit in the return
value reversed its meaning. Now it's returning the diff itself.

This is safe because in the two places it's used (signature verification and
point validation), invalid values will have a large number of bits differing
from the expected value, so diff will have a large Hamming weight.

An alternative would be to return for example -!(diff == 0), but the
comparison itself is prone to attacks (glitching the appropriate flag in the
CPU flags register, or the conditional branch if the comparison uses one). So
we'd need to protect the comparison, and it's simpler to just skip it and
return diff itself.
2019-11-21 15:12:44 +01:00
Manuel Pégourié-Gonnard 10d8e8ed64 Use safer return values in uECC_verify()
This is a first step in protecting against fault injection attacks: the
attacker can no longer change failure into success by flipping a single bit.
Additional steps are needed to prevent other attacks (instruction skip etc)
and will be the object of future commits.

The return value of uECC_vli_equal() should be protected as well, which will
be done in a future commit as well.
2019-11-21 15:12:44 +01:00
Manuel Pégourié-Gonnard c05f1506f4 Introduce return values for tinycrypt functions
Currently functions that may return success or failure tend to do so by
returning 0 or 1. If an active physical attacker can flip a bit in memory or
registers at the right time, they may easily change a failure value into a
success value, with potentially catastrophic security consequences.

As typical attackers can only flip a few bits, an element of protection
against such attacks is to ensure a sufficient Hamming distance between
failure values and the success value. This commit introduces such values,
which will put to use in critical functions in future commits.

In addition to SUCCESS and FAILURE, a third value ATTACK_DETECTED is
introduced, which can be used later when suspicious-looking events are noticed
(static data changed when it shouldn't, double condition checking returning
inconsistent results, etc.).

Values are chosen so that Hamming distances are large, and that no value is
the complement of another, in order to avoid unwanted compiler optimisations.

Note: the error values used by Mbed TLS are already safe (assuming 32-bit
integers) as they are of the form -x with x in the range [1, 2^15) so their
Hamming distance with the success value (0) is at least 17, so it's hard for
an attacker to turn an error value into the success value (or vice-versa).
2019-11-21 15:10:02 +01:00
Simon Butcher a3877007e6 Merge remote-tracking branch 'public/pr/2876' into baremetal 2019-11-20 12:00:18 +00:00
Simon Butcher c759b88194 Merge remote-tracking branch 'public/pr/2889' into baremetal 2019-11-20 12:00:06 +00:00
Simon Butcher b2af693900 Merge remote-tracking branch 'public/pr/2910' into baremetal 2019-11-20 11:59:55 +00:00
Simon Butcher 4965466614 Merge remote-tracking branch 'public/pr/2930' into baremetal 2019-11-20 11:59:46 +00:00
Manuel Pégourié-Gonnard 1e96b46b03 Disable use of HRNG in SCA-hardened mem-functions
This is a temporary work-around for an integration issue.

A future task will re-integrate randomness into these functions are their
entire point is to be randomized; this is really just temporary.
2019-11-19 11:49:05 +01:00
Manuel Pégourié-Gonnard c881486bb2 Fix off-by-one number of extra operations
This caused a performance issue.
2019-11-05 10:32:37 +01:00
Manuel Pégourié-Gonnard ad166d8db7 Also check curve in verify()
This is the only function that performs computations without calling
EccPoint_mult_safer() and that didn't have that guard yet.
2019-11-04 15:53:24 +01:00
Manuel Pégourié-Gonnard 913534837a Hardcode numwords in vli_modInv 2019-11-04 15:53:22 +01:00
Manuel Pégourié-Gonnard 3e20adf533 Hardcode numwords in vli_modMult 2019-11-04 15:53:20 +01:00
Manuel Pégourié-Gonnard 10349e4912 Hardcode numwords in vli_mmod 2019-11-04 15:53:19 +01:00
Manuel Pégourié-Gonnard 1b0875d863 Hardcode numwords in vli_modSub 2019-11-04 15:53:17 +01:00
Manuel Pégourié-Gonnard 0779be7f31 Hardcode numwords in vli_modAdd 2019-11-04 15:53:14 +01:00
Manuel Pégourié-Gonnard 5e3baf2303 Hardcode numwords in vli_rshift1 2019-11-04 15:53:12 +01:00
Manuel Pégourié-Gonnard 2cb3eea922 Hardcode numwords in vli_cmp 2019-11-04 15:53:10 +01:00
Manuel Pégourié-Gonnard 129b42ea2e Hardcode numwords in vli_sub 2019-11-04 15:53:09 +01:00
Manuel Pégourié-Gonnard 2eca3d367b Hardcode numwords in vli_equal 2019-11-04 15:53:07 +01:00
Manuel Pégourié-Gonnard a752191191 Hardcode numwords in vli_cpm_unsafe 2019-11-04 15:53:03 +01:00
Manuel Pégourié-Gonnard cbbb0f034b Hardcode numwords in vli_set() 2019-11-04 15:52:43 +01:00
Manuel Pégourié-Gonnard 2bf5a129cf Hardcode numwords in semi-internal vli_numBits() 2019-11-04 15:52:43 +01:00
Manuel Pégourié-Gonnard 94e48498ef Hardcode numwords in semi-internal vli_clear() 2019-11-04 15:52:43 +01:00
Manuel Pégourié-Gonnard f3899fc0ea hardcode numwords in semi-internal vli_isZero 2019-11-04 15:52:43 +01:00
Manuel Pégourié-Gonnard 02d9d21fd6 Hardcode numwords in internal vli_add
Saves 40 bytes
2019-11-04 15:52:37 +01:00
Manuel Pégourié-Gonnard 78a7e351fe Use macros for number of bits and words 2019-11-04 12:31:37 +01:00
Manuel Pégourié-Gonnard c3ec14c87f Harcode curve in semi-internal modMult function
Saves 80 bytes of code size.
2019-11-04 12:23:11 +01:00
Manuel Pégourié-Gonnard 3645ac93f5 Start hardcoding curve in internal functions
Saves 68 byte of code size.
2019-11-04 12:20:22 +01:00
Manuel Pégourié-Gonnard 27926d63b7 Remove less-safe mult function from public API
This doesn't change code size, but makes it easier to remove unneeded
parameters later (less possible entry points).
2019-11-04 11:26:46 +01:00
Manuel Pégourié-Gonnard ef238283d5 Add ECCPoint_mult_safer() function
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.
2019-11-04 11:19:30 +01:00
Manuel Pégourié-Gonnard c78d86b499 Remove some internal functions that aren't needed
This saves 10 bytes of code size, and makes it a bit easier to remove unused
parameters later (fewer prototypes to change).
2019-11-04 10:18:42 +01:00
Manuel Pégourié-Gonnard 86c4f81408 Improve documentation of internal function 2019-10-31 13:07:58 +01:00
Manuel Pégourié-Gonnard d5e503ec33 Rename wait_state_t to ecc_wait_state_t
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).
2019-10-31 13:07:58 +01:00
Manuel Pégourié-Gonnard d467116e59 Make wait_state smaller
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.
2019-10-31 13:07:52 +01:00
Manuel Pégourié-Gonnard 938f53f1fb Actually use randomized mult when relevant
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.
2019-10-31 13:07:52 +01:00
Manuel Pégourié-Gonnard 14ab9c2879 Add random delays to multi-precision multiplication
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.
2019-10-31 13:07:52 +01:00
Manuel Pégourié-Gonnard 6ee7a4e01c Validate peer's public key in ECDH
This protects against invalid curve attacks.

(It's also a tiny step in the direction of protecting against some fault
injection attacks.)
2019-10-31 13:07:52 +01:00