CVE-2026-128091: AES key schedule not cleared by the TinyCrypt AES-CTR backend in MCUboot bootutil
When MCUboot is built with the TinyCrypt crypto backend (MCUBOOTUSETINYCRYPT), bootutilaesctrdrop() in boot/bootutil/include/bootutil/crypto/aesctrtinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tcaeskeyschedstruct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here.
As a result, bootstateclear(), which bootgo() calls before handing off to the application, left the image's AES content-encryption key schedule in the static bootdata state. This is the case after an encrypted upgrade in single-image builds, where bootenczeroize() is not called. bootdecryptkey() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOTENCIMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port.
The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutilwipememory().
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In the TinyCrypt backend, replace the empty bootutil_aes_ctr_drop() stub in boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h with logic that wipes the AES-CTR context (struct tc_aes_key_sched_struct) using bootutil_wipe_memory(); also wipe the ECIES-derived key-encryption key schedule left on the stack by boot_decrypt_key().
Event History
Frequently Asked Questions
Which builds are affected?
Affected builds use MCUBOOT_ENC_IMAGES with the TinyCrypt backend (MCUBOOT_USE_TINYCRYPT). TinyCrypt is the default ECDSA and Ed25519 backend in the Zephyr port, but encrypted-image support must also be enabled.
What access does an attacker need to recover a key?
An attacker needs the ability to read leftover bootloader RAM after boot. The retained AES-128 round-key schedule contains the image content-encryption key, allowing decryption of the encrypted image.
When is the image content key left in static boot state?
This occurs after an encrypted upgrade in a single-image build, because boot_enc_zeroize() is not called on that path. boot_go() clears boot state before application handoff, but the TinyCrypt cleanup hook was empty.
How can I determine whether a device is exposed?
Check whether the MCUboot build enables both MCUBOOT_ENC_IMAGES and MCUBOOT_USE_TINYCRYPT, and whether it performs encrypted upgrades in a single-image configuration. Devices where an attacker cannot read post-boot RAM do not provide the stated key-recovery capability.