The ECDSA peripheral before ECO5 of esp32h2 does not perform the ECDSA
sign operation in constant time. This allows an attacker to read the
power signature of the ECDSA sign operation and then calculate the
ECDSA key stored inside the eFuse. The commit adds a countermeasure
for this attack. In this case the real ECDSA sign operation is
masked under dummy ECDSA sign operations to hide its real power
signature
1) pre-shift GCM last4 to use 32-bit shift
On 32-bit architectures like Aarch32, RV32, Xtensa,
shifting a 64-bit variable by 32-bits is free,
since it changes the register representing half of the 64-bit var.
Pre-shift the last4 array to take advantage of this.
2) unroll first GCM iteration
The first loop of gcm_mult() is different from
the others. By unrolling it separately from the
others, the other iterations may take advantage
of the zero-overhead loop construct, in addition
to saving a conditional branch in the loop.
Disabling this config can reduce footprint for the cases where
mbedtls_strerror() is used and hence the debug strings are getting
pulled into the application image.
- Even if the config MBEDTLS_HARDWARE_AES is enabled, we now support fallback
to software implementation of GCM operations when non-AES ciphers are used.
Updates config to define the new MBEDTLS_SSL_CID_TLS1_3_PAD_GRANULARITY
option, which replaced the previously used
MBEDTLS_SSL_CID_PADDING_GRANULARITY. The old option is continuing to be
used as the new one exceeds the maximum length for an option name in
esp-idf.
See https://github.com/Mbed-TLS/mbedtls/pull/4490 for more information.
Signed-off-by: Daniel Mangum <georgedanielmangum@gmail.com>
For ESP32-H2 case, the hardware k mode is always enforced through
efuse settings (done in startup code).
For ESP32-P4 case, the software k mode is not supported in the peripheral
itself and code was redundant.
Set max TLS version in the SSL context during setup phase. Dynamic
buffer feature overrides the `mbedtls_ssl_setup` API and hence
this change is required per upstream 3.5.0 codebase change.
Add changes to use fast_pbkdf2 as default for PMK calculations.
fast_pbkdf2 is significantly faster than current implementations
for esp chips.
Also removes unnecessary code for pbkdf-sha256 and pbkdf-sha512.
For certain data lengths, the last input descriptor was not getting appended
correctly and hence the EOF flag in the DMA descriptor link list was
set at incorrect location. This was resulting in the peripheral being
stalled expecting more data and eventually the code used to timeout
waiting for the AES completion interrupt.
Required configs for this issue:
CONFIG_MBEDTLS_HARDWARE_AES
CONFIG_SOC_AES_SUPPORT_DMA
This observation is similar to the issue reported in:
https://github.com/espressif/esp-idf/issues/10647
To recreate this issue, start the AES-GCM DMA operation with data length
12280 bytes and this should stall the operation forever.
In this fix, we are tracing the entire descriptor list and then appending the
extra bytes descriptor at correct position (as the last node).
DMA operation completion must wait until the last DMA descriptor
ownership has been changed to hardware, that is hardware is completed
the write operation for entire data. Earlier for the hardware GCM case,
the first DMA descriptor was checked and it could have resulted in some
race condition for non interrupt (MBEDTLS_AES_USE_INTERRUPT disabled) case.
SHA hardware DMA mode calculation had off-by-one error for specific
input lengths. This was causing last chunk of the input data not being
fed to the hardware accelerator and hence resulting in an incorrect
final result.
Closes: https://github.com/espressif/esp-idf/issues/11915
