Deep Dive into Intel CSME: When the Hardware Root of Trust Itself Fails

> From CVE-2019-0090's IOMMU race condition to the 2025 full compromise of the Fuse Encryption Key (FEK) — Intel's six-year "hardware isolation" security model was shattered by a fundamental design paradox: you hid the key inside a safe, then wrote the safe's combination on its door.

1. The Vulnerability Was Baked into the Hardware Design

On March 20, 2025, Positive Technologies published a striking report: *"Last barrier destroyed, or compromise of Fuse Encryption Key for Intel Security Fuses."* This was not another buffer overflow — it announced that the last line of defense in Intel's CSME security architecture had been pierced by a physical-level design flaw.

To understand the severity, we need to go back to 2019.

CVE-2019-0090: A Race Condition Window Opens Pandora's Box

Intel CSME (Converged Security and Management Engine), as the platform's Root of Trust, rests on a core security assumption: CSME's SRAM and memory regions are invisible to the host CPU and other IP blocks, enforced by the IOMMU.

But CVE-2019-0090 revealed a fatal fact:

> When CSME exits reset, the IOMMU is disabled by default. IOMMU protection is only enabled after the CSME ROM executes.

This creates a time window — microseconds between CSME exiting reset and the ROM enabling the IOMMU — during which any IP block with RS1 (Root Space 1) DMA capability can directly read and write CSME SRAM.

Positive Technologies successfully exploited this on Cannon Lake:

1. Implant malicious firmware: load attacker-controlled firmware on the Integrated Sensor Hub (ISH) 2. Trigger a CSME reset: via a manufactured command or by waiting for recovery from a low-power state 3. DMA attack window: read CSME SRAM via RS1 DMA transactions before the IOMMU is enabled 4. ROP chain execution: use the read data to build a ROP attack and control CSME ROM execution flow

Intel's mitigation was blunt: on newer platforms (Ice Lake, Comet Lake, Tiger Lake, etc.), the IOMMU is enabled by default. Older platforms can only rely on firmware patches — which cannot eliminate a hardware-level race condition.

But CVE-2019-0090 Was Only Level One

Positive Technologies initially believed CVE-2019-0090 only bypassed the first tier of CSME's security model. Encrypted Security Fuses could be read, but the Fuse Encryption Key (FEK) was stored in the Secure Key Storage (SKS) hardware module, with CSME firmware unable to access its plaintext.

SKS's design philosophy: keys are generated and used in hardware, but their plaintext is never exposed to CSME SRAM — similar to an HSM. If this design held, CVE-2019-0090 would have been "limited harm."

The 2025 research proved otherwise: SKS itself has an architectural flaw that allows full FEK extraction.

2. Breaking the FEK: From "Inaccessible" to Known-Plaintext Attack

SKS's Dual-Mode Disaster

Intel's Secure Key Storage supports two key modes:

• Secure Mode: the key activates SKS protection; CSME cannot read plaintext, only perform crypto operations with it
• Non-Secure Mode: the key does not activate SKS protection, allowing CSME to read the results of crypto operations

Non-Secure Mode was intended for hash operations like SHA/HMAC, whose results must be readable by CSME firmware. The problem: keys in Non-Secure Mode can be overwritten, and the crypto engine does not protect the original key.

FEK Has Secure Mode = 0

Positive Technologies found that the FEK's Secure Mode attribute is set to 0 — Non-Secure Mode.

This is explicitly documented in Intel's official documentation. Intel's justification: the FEK is needed to decrypt the EPID private key (an ECDSA private key), and the OCS (Offload and Crypto Subsystem) hardware does not support ECDSA, so the EPID key must be handled in software inside CSME memory. Therefore the FEK cannot be locked in Secure Mode.

But this justification masks the real problem: the AES engines (AES_A, AES_P) actually support reading result data in Secure Mode. The FEK could have been set to Secure Mode while still allowing decrypted data to be read — a serious coordination failure between Intel's firmware developers and hardware engineers.

Known-Plaintext Attack: 256 × 32 Attempts to Extract a 32-Byte Key

Since the FEK is in Non-Secure Mode, an attacker can:

1. Control the input plaintext: send arbitrary plaintext to the AES engine 2. Observe the ciphertext: compare results before and after overwriting the key 3. Brute-force byte by byte: for the 32-byte AES key, try 256 possibilities per byte and check whether the ciphertext changes 4. Full extraction: at most 256 × 32 = 8,192 attempts recover the complete 32-byte FEK

Positive Technologies demonstrated this on Apollo Lake and Gemini Lake platforms, and published the FEK values for both platforms directly in the report.

The Most Fatal Point: the FEK Is Not Unique

> The FEK is identical for all processors of the same microarchitecture.

An attacker only needs to break one Apollo Lake device to obtain the FEK for all Apollo Lake devices. The same applies to Gemini Lake/Refresh.

Once the FEK leaks, encrypted Security Fuses are no longer safe. An attacker can:

• Decrypt the Chipset Key
• Extract the EPID private key (used to prove platform authenticity)
• Forge CSME firmware signatures
• Bypass Boot Guard, PTT/TPM, and all CSME-based security mechanisms

Intel's security model relies on SVN (Security Version Number) for TCB recovery — when a vulnerability is found, firmware version numbers are bumped, old keys revoked, new keys distributed. But if the FEK leaks, attackers can recompute all derived keys for any SVN. TCB recovery completely fails.

3. The Fundamental Paradox of the Hardware Security Model

Intel CSME embodies the ideal of defense-in-depth:

• Hardware isolation (dedicated processor, SRAM, IOMMU)
• Chain of trust (ROM → RBE → kernel, signed verification at each stage)
• Key hierarchy (FEK → Chipset Key → Wrapping Key → per-module keys)
• Anti-rollback (SVN version control against firmware downgrade)

But the 2025 research exposed a fatal weakness: the root key itself cannot be upgraded.

The FEK is burned into hardware fuses and cannot be changed after manufacture. If the FEK leaks, the root of the entire trust chain is pulled out — like telling everyone your house's foundation password and then discovering the foundation cannot be replaced.

Why Can't Intel Fix It?

Intel's April 3, 2025 security advisory states:

> "All reported vulnerabilities have been mitigated. Systems with all firmware updates applied... are not susceptible."

But Positive Technologies immediately countered:

> "This is a hardware design problem and cannot be fixed by modifying CSME firmware."

Intel's "mitigation" actually reduces exploitability rather than eliminating the vulnerability:

1. End of Manufacturing (EOM): system manufacturers must enable Flash Descriptor write protection and disable CSME manufacturing APIs 2. Firmware updates: patch the CVE-2019-0090 exploitation chain 3. Physical access requirement: emphasizing that the attack requires physical contact

But none of this changes one fact: the FEK on affected platforms has leaked and can never be rotated. With the FEK and the encrypted Security Fuses (extractable via voltage fault injection), an attacker can fully compromise the platform.

4. Impact Assessment: Who Should Worry?

Direct Scope

Positive Technologies' research targeted Apollo Lake and Gemini Lake/Refresh Atom platforms, widely used in:

• Embedded devices
• Industrial control
• IoT gateways
• Budget laptops

But the threat model extends further. While the FEK leak is so far only confirmed on Atom platforms, Positive Technologies notes:

> "The insecure FEK problem exists at the hardware level and is an architectural problem."

If Intel used the same SKS/OCS design philosophy on other platforms (Core, Xeon), similar flaws may exist. No public evidence yet shows Core platform FEKs extracted, but the design-level risk cannot be ignored.

Realistic Attack Scenarios

1. Supply chain attacks: attacker obtains devices at the factory or in logistics, extracts the FEK, implants undetectable malicious CSME firmware 2. Second-hand device risk: a "new" device may already be compromised, with no software tool able to detect it 3. Enterprise environments: controlling vPro/AMT remote management lets attackers bypass all OS-level security monitoring 4. DRM/content protection: HDCP, SGX, and other mechanisms relying on the EPID private key to prove platform authenticity fail

5. Mitigation Reality: What Can Users Do?

Immediate Actions

1. Check your platform: Apollo Lake / Gemini Lake / Gemini Lake Refresh = highest risk 2. Update BIOS/ME firmware: can't fix the FEK leak, but closes the CVE-2019-0090 exploitation chain 3. Verify EOM completion: check that Flash Descriptor is locked and CSME manufacturing APIs are disabled 4. Physical security: prevent unauthorized physical access — FEK extraction requires physical access

Long-Term Options

1. Neutralization with me_cleaner: on non-vPro devices, use me_cleaner to remove AMT and networking features, drastically reducing attack surface 2. Platform migration: consider AMD (smaller PSP attack surface, though also closed-source) or ARM platforms 3. Watch open alternatives: RISC-V + open-source firmware (coreboot, Oreboot) — immature ecosystems, but high transparency

6. Conclusion: When the "Root of Trust" Itself Must Be Trusted

Intel CSME's story reveals a deep paradox about security:

> You built a perfect safe to protect the key — but the password protecting the safe was designed to be non-upgradable and extractable.

CVE-2019-0090 opened the first door — the IOMMU race condition let attackers read encrypted Security Fuses. The 2025 FEK break proved that even with that door closed, the safe's own design is flawed.

This is not a code bug — it is an architectural design failure:

1. The FEK should not have been set to Non-Secure Mode 2. Non-Secure Mode should not allow keys to be overwritten and extracted 3. Root keys should be unique, rotatable — or at minimum different per platform

Intel's "Below-OS" security fortress, built over six years, was dismantled by a 32-byte AES key and a race condition window. Not because attackers got stronger, but because defenders designing root trust mechanisms failed to grasp the non-compromisable nature of the "root."

For ordinary users: your device may have an unfixable vulnerability, hidden at a hardware level you cannot see or control.

For security researchers: hardware security assessment can no longer stop at "isolation means safe" — it must dig into key lifecycle management, architectural threat modeling, and above all, the non-revocability of root keys.

For Intel: closed-source + unauditable + non-upgradable root key = systemic risk.

---

References:

• Positive Technologies: "Last barrier destroyed, or compromise of Fuse Encryption Key for Intel Security Fuses" (2025-03-20)
• Intel Security Announcement 2025-04-03-001
• Intel CSME Security White Paper 14.0/15.0/16.0
• INTEL-SA-00213 (CVE-2019-0090)