Arm’s Mbed TLS contained a subtle but consequential side‑channel flaw — tracked as CVE‑2020‑10941 — that allowed a privileged observer to recover RSA private key material by measuring cache usage during an import operation, and the case raises lasting lessons for developers, embedded vendors, and defenders about assumptions, low‑level APIs, and secure key handling.
Background
In February–March 2020 researchers disclosed an attack against Mbed TLS that exploited observable cache activity while an RSA private key was being imported. The vulnerability affects Mbed TLS branches prior to the 2.16.5 patch level and equivalent fixed releases on other branches, and the vendor responded with coordinated security advisories and fixes. At a high level the problem is not a bug in the RSA algorithm itself but a side‑channel leakage path created by implementation choices and the use of low‑level import APIs in an adversarial execution environment.
This is an important distinction: the exploit requires the attacker to obtain fine‑grained measurements of cache usage during the key import sequence. That capability is realistic in threat models where the attacker controls or observes the host operating system — for example when a secure implementation runs inside a hardware enclave (SGX) or a secure world (TrustZone) and the untrusted normal world can trace microarchitectural events. When those conditions hold, operations that touch secret key material but do not run in constant‑time or otherwise leak operational patterns can be reconstructed off the side channels.
The Mbed TLS team published guidance identifying the affected functions and recommending immediate upgrades to patched releases (including 2.16.5 and later releases on maintained branches). They also called out safe usage patterns (such as using the high‑level key parsing APIs that only accept complete private keys) and warned about the risks of using lower‑level import routines when incomplete parameters are supplied.
What exactly does CVE‑2020‑10941 do?
The technical core, explained simply
- RSA private key import in Mbed TLS involves routines that complete and normalize an RSA key representation. Those routines can execute code paths and memory accesses whose pattern depends on secret key bits.
- An attacker with precise cache measurement capability (for instance, via an OS that observes the enclave’s cache usage or a co‑located process exploiting shared CPU resources) can correlate memory access patterns to key bits.
- By collecting fine‑grained cache traces during a single import operation, the attacker can recover the RSA private key.
In other words: while the RSA mathematics remain secure, the
implementation leaks information through the CPU cache. The leak manifests during import completion routines rather than during the canonical high‑level importing of a full, formatted private key.
Where the leakage happens
The vulnerability arises when applications use low‑level APIs to import partial or nonstandard RSA parameters (for example, calling mbedtls_rsa_import() and then mbedtls_rsa_complete()). Those lower‑level routines perform internal computations (gcd, modular inversion, exponent operations, or other normalization/completion steps) whose memory access pattern depends on secret values. These access patterns are visible to a privileged OS and therefore can be turned into key recovery with the right measurement infrastructure.
Attack prerequisites and realism
Practical exploitation requires:
- The ability to obtain fine‑grained cache usage measurements during the key import itself. This is often possible if the attacker controls or heavily influences the operating system or hypervisor.
- That the target uses one of the vulnerable import paths (low‑level imports or incomplete key completion) during its operation.
- The attacker typically does not need network access to the target in the usual sense; the attack is local or co‑resident and exploits microarchitectural side channels.
These prerequisites limit the threat to scenarios such as:
- Secure enclaves (e.g., Intel SGX) where the OS is untrusted and can observe hardware side effects.
- Embedded devices where a compromised hypervisor or co‑resident agent has access to microarchitectural events.
- Multi‑tenant platforms where co‑resident virtual machines share CPU caches and a malicious tenant can trigger measurements.
By contrast, remote attacks across the Internet without co‑residency or local observation capability are not the intended attack vector.
Scope and affected versions
- Affected software: Arm Mbed TLS versions prior to 2.16.5 (and equivalent older releases on other maintained branches).
- Fixed in: Mbed TLS 2.16.5 and later patch releases; vendor advisories also referenced fixed releases on other branches (for example later 2.7.x and 2.21.x branch releases at the time of disclosure).
- Affected operations: Importing RSA private keys using low‑level/incomplete import APIs (e.g., mbedtls_rsa_import() followed by mbedtls_rsa_complete()) where internal completion operations leak information.
- Not all uses of RSA in Mbed TLS are vulnerable; using the recommended high‑level APIs that import a complete, formatted private key avoids the vulnerable code paths.
The vendor guidance explicitly called out that mbedtls_pk_parse_key() and mbedtls_pk_parse_keyfile() — the high‑level parsers that accept standard key encodings — are safe because they import complete private keys via secure parsing. The danger is primarily in direct or programmatic assembly of RSA parameters that then call completion helpers.
Why this matters for Windows and embedded ecosystems
Mbed TLS is widely used in embedded, IoT, and specialized TLS stacks where lightweightness and portability matter. Many network appliances, embedded devices, and third‑party SDKs bundle Mbed TLS as their cryptographic foundation. The practical implications include:
- IoT and embedded devices are often deployed in untrusted physical environments where local access or firmware compromise is plausible.
- Security products, VPN appliances, or other TLS-terminating hardware using Mbed TLS might use low‑level APIs for custom key provisioning; if they do so on vulnerable releases, private keys used for authentication or device identity could be exposed to an attacker who can measure microarchitectural events.
- Even systems traditionally considered “remote‑only” become vulnerable if their trusted execution model assumes the host OS is benign; enclave or secure‑world threat models break that assumption.
Put succinctly: assume that any device using a vulnerable Mbed TLS release and performing low‑level RSA imports in an environment where an attacker can measure cache activity is at risk.
Vendor response and recommended fixes
Arm Mbed TLS responded with coordinated advisories and release patches. The practical remediation steps are:
- Upgrade immediately to patched releases (for the 2.16 branch, that means 2.16.5 or later; the vendor also provided fixed versions for other maintained branches).
- Avoid using low‑level RSA import and completion APIs when possible. Prefer the high‑level parsing APIs that accept complete keys (these are designed to avoid the problematic completion steps).
- If application code must use low‑level import routines, ensure that all parameters required to avoid completion are present (the vendor guidance specifies exactly which parameters are required depending on configuration macros such as MBEDTLS_RSA_NO_CRT).
- Consider running RSA operations in a hardened environment: use HSMs or platform KMS where keys never leave secure hardware, or ensure that co‑residency and OS compromise threat models are mitigated.
If you manage third‑party appliances or vendor‑supplied embedded gear, insist on verifiable patches from the vendor and confirm that the device no longer uses vulnerable import paths. If keys may have been imported on a vulnerable release while under attack, treat those keys as compromised and rotate/regenerate them after the platform is patched.
Step‑by‑step mitigation checklist for administrators and developers
- Inventory: Identify all products in your environment that use Mbed TLS (OEM devices, binaries, firmware images, third‑party SDKs).
- Version check: Confirm the Mbed TLS version in each product. If it’s older than the patched release for that branch, mark it vulnerable.
- Vendor coordination: For closed devices (firmware appliances, closed VPN boxes), contact the vendor for firmware updates or mitigation guidance. Require proof that low‑level RSA import APIs are not used.
- Apply patches: Deploy vendor patches or rebuild applications with patched Mbed TLS libraries.
- Replace risky imports: Change application code to use mbedtls_pk_parse_key() or equivalent high‑level APIs that import complete keys safely.
- Key rotation: If you believe keys were imported on vulnerable builds under adversarial conditions, rotate keys after patching and secure provisioning.
- Hardening: Where feasible, move key storage/operations into hardware security modules (HSMs), TPMs, or cloud KMS offerings to prevent local side‑channel exposure.
- Threat model review: If you rely on secure enclaves or trust boundaries where the host OS may be untrusted, re‑evaluate the threat model and consider microarchitectural side‑channel mitigations and defensive design changes.
Critical analysis — strengths and limits of the fix
Strengths
- Responsive vendor disclosure: Arm’s Mbed TLS team published clear advisories identifying affected code paths and recommended fixed release versions.
- Targeted fix: The vulnerability is implementation‑specific and was addressed without needing changes to the RSA standard. The fix focuses on removing the data‑dependent memory access patterns in the impacted routines or advising safer APIs.
- Clear guidance to developers: The vendor highlighted safe APIs and provided actionable instructions for developers who previously used low‑level imports.
Remaining risks and weaknesses
- Threat model assumptions: Many systems assume the operating system will not actively observe or meddle with cryptographic operations. Side‑channels break this assumption, and the risk is high in enclave and multi‑tenant environments.
- Low‑level APIs remain tempting: Developers working on constrained or bespoke platforms often use low‑level import routines for optimization or unusual key provisioning flows. Those same usages are the primary exposure vector.
- Ongoing side‑channel surface: This CVE is one of several that have affected Mbed TLS over time (including later timing and microarchitectural side channels), which exposes the difficulty of fully eliminating microarchitectural leakage across diverse CPU families and compiler toolchains.
- Embedded device patching: Many embedded or IoT devices are hard to patch in the field. Even when the library fix exists, large fleets of devices can remain vulnerable for extended periods — a perennial problem in device security.
Practical exploitation: how hard is it, really?
The attack is realistic in certain high‑threat settings but not a universal remote exploit.
Realistic scenarios:
- An attacker controls the host OS and can run cache‑probing routines while the enclave or secure process performs a key import. This is effectively trivial to arrange if the attacker has local admin or hypervisor control.
- A malicious tenant on a multi‑tenant CPU capable of precise cache timing can co‑locate and extract signals in environments lacking strong isolation.
Difficult or unlikely scenarios:
- Remote attackers with only network access and no ability to observe microarchitectural state cannot mount this attack.
- Systems where keys are provisioned using complete, standard encodings and the application uses high‑level parsing APIs are not affected by this import‑time leakage.
Therefore, real risk correlates strongly with the deployment model. Enclaves, device provisioning workflows, and custom key installation processes deserve the closest scrutiny.
Developer guidance — do’s and don’ts
Do:
- Upgrade Mbed TLS to the patched release on your branch.
- Prefer high‑level, standard key import APIs that accept complete encoded private keys.
- Use cryptographic libraries’ constant‑time primitives and follow vendor guidance on safe API usage.
- Where possible, perform cryptographic key handling in hardware (HSM/TPM) or in code paths that never expose secret internals to the OS.
- Audit any code that programmatically assembles RSA keys or calls mbedtls_rsa_import() / mbedtls_rsa_complete().
Don’t:
- Assume keys are safe simply because they are stored in memory — memory access patterns matter on modern CPUs.
- Use incomplete or experimental import flows in production, especially on systems that may run in co‑tenant or untrusted hosting environments.
- Delay patching devices because embedded fleet updates can be long and risky — prioritize devices exposed to higher threat models.
Long‑term lessons for platform and cryptography designers
- Default to safe, high‑level APIs: Libraries should prefer high‑level, opinionated APIs that avoid subtle misuse by application developers. Low‑level primitives are necessary for advanced uses but must be clearly labeled and documented with risk warnings.
- Assume adversarial co‑tenancy: Design and test cryptographic routines under threat models that include a malicious OS or co‑resident tenant. Side‑channel resistant implementations must be the default for security‑critical code.
- Continuous side‑channel testing: Maintain continuous fuzzing and side‑channel analysis across CPU microarchitectures and compiler versions; new microarchitectural features often yield unexpected leakage.
- Usability matters: Many vulnerabilities arise because secure usage is complex. Make the safe path the easy path for developers and device integrators.
Conclusion and actionable final recommendations
CVE‑2020‑10941 is a reminder that real security rests not only on cryptographic algorithms but equally on their implementations and the assumptions in the execution environment. The vulnerability itself is not a remote, unauthenticated network flaw; it is a microarchitectural side channel that becomes exploitable in privileged or co‑resident threat models. That does not make it harmless — devices using vulnerable Mbed TLS releases and performing low‑level RSA imports in enclave or embedded contexts can have their private keys extracted.
Action checklist (immediate):
- Inventory all Mbed TLS usage in your environment.
- Patch to the fixed releases for your branch (for 2.16 branch, upgrade to 2.16.5 or later).
- Replace low‑level RSA import flows with the high‑level parsing APIs wherever possible.
- Rotate any keys that may have been exposed under vulnerable conditions and re‑provision them from a secured, patched platform.
- For embedded fleets, engage vendors for firmware updates and push device hardening where possible.
This incident is a concrete example of why defenders must think beyond "is the algorithm correct?" and instead ask "who can observe the hardware and what microarchitectural artifacts might leak secret state?" The fixes are straightforward technically, but the broader work — secure APIs, hardened provisioning, and resilient fleet management — is ongoing and requires continuous attention.
Source: MSRC
Security Update Guide - Microsoft Security Response Center