The Key Manager hardware peripheral in its current form needs further
design changes before it can be offered as a production feature.
Until a revised peripheral design is available, withdraw ESP-IDF
support for it on all Key Manager capable targets.
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support, so the
CI configs that pin the RSA signing scheme and key fail the app signing
scheme/key check on these targets.
- flash_enc_wifi_2.data_partition_verification: add C2/C61 sdkconfig
overlays that switch to the ECDSA P-256 signing scheme and key (no
force-enable needed as Secure Boot V2 itself is not enabled here).
- on_update_no_sb_rsa: disable the build on targets without
SOC_SECURE_BOOT_V2_RSA, mirroring simple_ota_example, since this
config specifically exercises the RSA scheme.
The signing step (espsecure sign-data) derives the signature block type
from the key file itself, so selecting e.g. the RSA app signing scheme
with an ECDSA signing key produced a successfully built image that only
failed signature verification at boot.
Check the key at configure time and fail with a clear error when:
- the key family (RSA vs ECDSA) does not match the selected app signing
scheme
- the ECDSA curve does not match the selected ECDSA key size for the
ECDSA (V1/V2) schemes
- the key cannot be parsed as an unencrypted PEM private key
esp_crypto_shared_gdma_done() polled the AXI RX raw interrupt status
(in_done) but never cleared it, so after the first transfer the set bit
made every subsequent call return immediately without waiting.
The spiram-xip IROM/DROM alignment tests assumed the XIP region always
leaves an alignment gap before the next MMU page: they executed into the
gap and expected an instruction access fault followed by a register dump.
When the section ends exactly on an MMU page boundary there is no gap - the
device prints "<IROM/DROM> alignment gap not added into heap" and returns,
the framework restarts cleanly (esp_restart_noos, no panic), and the test
timed out waiting for a register dump.
ESP_FAULT_ASSERT(C) was silently deleted by the optimizer when C is a cached
flag/status already proven by a preceding `if (!C) return/goto`: the compiler
folds C to a constant and drops all three checks, removing the fault-injection
protection with no warning.
Audited every esp_* PSA driver against its corresponding software driver in
mbedtls/library (psa_crypto_cipher.c, psa_crypto_aead.c, psa_crypto_mac.c,
psa_crypto_hash.c, psa_crypto_ecp.c, psa_crypto_rsa.c) and fixed gaps in
workflow ownership, error-path cleanup, sensitive-data wiping, and BAD_STATE
gating per the PSA Crypto API spec.
esp_aes (cipher): fix padding oracle in cipher_finish by replacing leaky
branches with mbedtls_ct_* primitives; abort wipes the driver-level ctx,
not just the inner mbedtls_aes_context; setup routes errors through abort.
esp_aes_gcm (AEAD): zeroize the 16-byte full_tag scratch; restore the
*output_length = finish_output_size assignment that the SW reference keeps
for future ciphers; NULL the inner ctx pointer after free in abort; gate
update/finish on a live ctx with PSA_ERROR_BAD_STATE.
esp_ecdsa: keep abort-at-exit in the one-shot wrappers so the stack-copy
of the hash (needed for little-endian byte order on HW) is wiped per
PSA spec 6.3.3, drop the over-defensive public-key qx/qy wipes that the
SW driver does not perform.
esp_cmac / esp_hmac_transparent / esp_hmac_opaque (MAC): make abort
idempotent, route setup errors through abort, gate update/finish/
verify_finish on PSA_ERROR_BAD_STATE, wipe M_last and intermediate hmac[]
buffers on completion or HW failure. HMAC opaque gains alg + computed
fields to mirror the SW psa_crypto_mac.c state machine. HMAC transparent
explicitly aborts the inner SHA context before reusing it for the outer
hash.
esp_sha: switch the per-op live indicator to (sha_ctx != NULL) so the
public esp_sha_operation_type_t enum keeps its original ordinal values;
free + NULL sha_ctx on every error path; gate update/finish/clone on a
live ctx; wipe per-algorithm core/parallel-engine scratch buffers
(W[], A[], state) on HW-engine failure.
esp_md5: replace bare memset in abort with mbedtls_platform_zeroize.
esp_rsa_ds: complete() no longer frees sig_buffer (abort owns that);
start() routes failures through abort; asymmetric_decrypt funnels all
cleanup through a single exit: label. RSA-DS utilities wipe the
decrypted-plaintext scratch on v15 / OAEP unpad failure.
ESP32-C2 and ESP32-C61 have no RSA based Secure Boot V2 support
so the virt_sb_v2_and_fe configs cannot use the default RSA signing key.
Add target-specific sdkconfig overlays that switch to the ECDSA P-256 key;
on ESP32-C61 the ECDSA scheme must additionally be force-enabled
SECURE_BOOT_V2_ECDSA_INSECURE).
The "custom certificate bundle - weak hash" test relied on DigiCert
Global Root CA being present as a trust anchor in cacrt_all.pem (the
only SHA-1-self-signed root in the chain it loaded). The recent
cacrt_all.pem refresh moved that root to cacrt_deprecated.pem, so the
chain could no longer anchor and the test started failing.
On ESP32-P4 rev < 3.0, Key Manager is software-disabled, but the public
esp_key_mgr.h APIs had no runtime check.
Calls using HMAC/DS/PSRAM key types fell through to
HAL_ASSERT("Unsupported ...") paths in key_mgr_ll.h. Gate
each public API with key_mgr_ll_is_supported() and return
ESP_ERR_NOT_SUPPORTED cleanly instead.
The Key Manager holds a key usage register, thus, the Key Manager peripheral
clock must be enabled even for efuses-based key operations to route the
crypto operations to correctly to the efuses (default is Key Manager)
Instead of performing the cache-to-memory (C2M) operation on the output buffer,
even a cache invalidate (M2C) is sufficient to ensure that no write-back occurs
during the DMA write operation
The key_mgr_ll_set_xts_aes_key_len() function was incorrectly using
REG_SET_FIELD() with the key_len enum value directly. Since
KEYMNG_FLASH_KEY_LEN is a 1-bit register field (0=128-bit, 1=256-bit),
writing ESP_KEY_MGR_XTS_AES_LEN_128 (value 3) resulted in the LSB (1)
being stored, incorrectly configuring 256-bit mode.
Fixed by using a switch statement to properly map:
- ESP_KEY_MGR_XTS_AES_LEN_128 → REG_CLR_BIT (0)
- ESP_KEY_MGR_XTS_AES_LEN_256 → REG_SET_BIT (1)
Thus, matching the correct ESP32-C5 implementation.
when the external input and output buffers are unaligned.
This also fixes as a recursion loop that occurs when the size of the input
buffer is not aligned to dcache_line_size but is aligned to AES_BLOCK_BYTES
- Update the Key Manager key types to be generic
- Define a new enum to determine the length of the keys
- Refactor the Key Manager driver support generic key types and key lengths
- Also store key deployment mode in the key recovery info
harshal.patil
