---
title: BadFuse Attack on Fuse-Backed Trust Mechanisms
url: https://www.emergentmind.com/topics/badfuse-attack
type: topic
---

# BadFuse Attack on Fuse-Backed Trust Mechanisms

Searching arXiv for the cited BadFuse-related papers to ground the article in the current literature.
The **BadFuse attack** denotes a class of attacks that subvert security assumptions attached to fuse-backed or one-time-programmable trust anchors. In its most specific and consequential formulation, BadFuse is an end-to-end attack on **AMD EPYC Milan** that chains the **MilanLaunchy** exploit with an unprotected fuse-burn interface to extract the **256-bit VCEK root seed**, after which an adversary can derive **Versioned Chip Endorsement Keys** for arbitrary TCB versions and forge valid **SEV-SNP** attestation reports [2605.12990]. Related literature uses the same attack label for physically extracting secrets from **antifuse OTP** arrays via **FIB passive voltage contrast** and for **voltage-glitch** subversion of fuse-gated boot logic on **Nvidia Tegra X2** [2501.13276], [2108.06131]. This suggests that “BadFuse” is best understood not as a single mechanism, but as a recurring attack motif centered on defeating the security role assigned to fuses, OTP state, and fuse-mediated policy decisions.

## 1. Terminological scope and threat model

In the EPYC Milan context, BadFuse targets the final cryptographic root underlying **SEV-SNP** attestation. The paper states that AMD’s anti-rollback design binds attestation reports to the platform’s **TCB version** through the **VCEK**, which is derived from a fused hardware root seed and the aggregate SVN of the **ASP bootloader**, **SEV firmware**, and **CPU microcode** [2605.12990]. The intended security property is that a platform can attest not only to identity but also to software freshness, so that rollback to older firmware versions remains detectable.

In the antifuse OTP context, the attack label is applied to a different substrate: **CMOS one-time-programmable memories based on antifuses** that vendors have described as “high security” storage for serial numbers, firmware-verification keys, and encryption keys. The cited work demonstrates that these assumptions fail under **focused ion beam passive voltage contrast**, even for commodity devices at the **40 nm** node [2501.13276].

In the Tegra X2 context, the attack label is applied to the use of **voltage fault injection** against fuse-checked secure-boot control flow. There, the target is not a root seed stored in fuses but the logic that interprets fuse state, specifically the bits disabling a hidden **UART download bootloader** and the bit that locks writes to protected iROM remapping controls [2108.06131].

A plausible implication is that fuse-backed trust should be analyzed at three distinct layers: **storage confidentiality**, **write-path integrity**, and **runtime interpretation of fuse state**. The cited works show that compromise at any one of these layers can nullify the intended security benefit of fused state.

## 2. Cryptographic role of the VCEK root seed on EPYC Milan

**SEV-SNP** augments **SEV** and **SEV-ES** with hardware-enforced integrity via the **Reverse Map Table (RMP)** and provides confidentiality and integrity for guest VM memory against a malicious hypervisor. Remote attestation is performed by the **AMD Secure Processor (ASP)**, an on-chip ARM core at **EL1**, which signs an attestation report over the VM’s configuration, **RMP** state, and platform **TCB version** using a **Versioned Chip Endorsement Key (VCEK)** unique to the silicon instance and the current TCB version [2605.12990].

At power-up, the immutable **Layer 0 BootROM** holds a **32-byte “VCEK root seed”** in fused on-chip ROM at **SMN 0x5D0C4**. The root seed is not exposed in the clear to higher firmware layers. The per-version seed is derived by a backward hash chain of up to **256 iterations**:

$$
\begin{aligned}
\mathrm{TmpSeed}_{255} &= \mathrm{RootSeed},\\
\mathrm{TmpSeed}_{i-1} &= H\bigl(\mathrm{TmpSeed}_i\bigr)\quad(i=255,254,\dots,1),\\
\mathrm{VCEK}_{\mathrm{Seed}(\mathrm{cur})} &= H\bigl(\texttt{0x00000000}\,\|\,\mathrm{TmpSeed}_{\mathrm{cur}}\bigr).
\end{aligned}
$$

The paper states that **SHA-256** is the hash function used in Milan and that the one-way nature of $H$ prevents older firmware from deriving newer seeds, while allowing a newer seed to derive all older ones. This asymmetry is the basis of rollback detection in attestation [2605.12990].

The fuse-controller layout is central to the attack. Within the ASP’s **SMN** mapping for secret fuses at **0x5D000–0x5E000**, **0x5D044 (32 B)** holds the **CEK root seed**, **0x5D0C4 (32 B)** holds the **VCEK root seed**, and **0x5D0F8–0x5D0FC** store control bits, **ECC-enable flags**, and **Fletcher checksums**. After BootROM reads these fuse words into SRAM, a hardware latch forces subsequent reads from **0x5D000–0x5E000** to return all zeros. However, the same region remains writable through a dedicated **“fuse burner”** unit at **MMIO 0x5E000–0x5E020**, which the paper reports is left unprotected by default [2605.12990].

## 3. Attack chain: MilanLaunchy as the software-only precondition

The AMD BadFuse attack is not a standalone primitive; it is explicitly chained from **MilanLaunchy**. The prerequisite exploit is based on **CVE-2021-26315** in the Milan ASP **BootROM**, where **RSA-PSS verification covers only the encrypted body and header, not the decrypted plaintext**. The BootROM decrypts the **Wrapped IKEK** with **AES-128-ECB**, decrypts the **Wrapped MEK** with **AES-128-ECB**, decrypts the firmware body with **AES-128-CBC(MEK,IV)** to obtain plaintext, and then verifies **\{EncryptedBody‖Header\}** under RSA-PSS rather than the plaintext [2605.12990].

The consequence is that flipping bits in the **Wrapped IKEK** can force arbitrary “random” plaintext in the first **AES-CBC** block while preserving RSA-PSS validity, because the signed material is the XOR-related ciphertext rather than the resulting plaintext. The paper states that brute-forcing **32 bits** of the first decryption key, at approximately **$2^{32}$** effort, allows control of the first decrypted **32 bits** in SRAM, corresponding to one **32-bit ARM instruction**. A branch such as **`b 0x20000`** can then redirect execution into attacker-controlled SRAM [2605.12990].

Once code execution at **EL1** in the off-chip bootloader has been achieved, the BadFuse stage manipulates the fuse burner through MMIO. The required sequence is to poll the busy state at **SMN 0x5E000**, write burn-enable to **0x5E014**, select the target fuse word via **0x5E004** with a bit-index encoding, toggle the **“burn”** bit at **0x5E004**, and then poll completion again in **0x5E000**. The paper states that no hardware or software guard prevents writes to the **VCEK seed region** [2605.12990].

The extraction method relies on a single-bit oracle. Because attempting to rewrite a fuse bit already blown to **1** is a no-op, the attacker burns one candidate bit at a time, performs a **cold reboot** to clear ASP latches, and requests a fresh attestation report to observe whether the derived VCEK changed. The pseudocode given in the paper initializes **`Vbase = fetch_current_vcek_seed()`**, iterates over **`i in 0..255`**, performs **`burn_fuse_bit(i)`**, reboots, fetches **`Vcurr`**, and sets **`seed[i] = 0`** if **`Vcurr != Vbase`**, else **`seed[i] = 1`**; the current VCEK value is obtained by requesting an attestation report through the **SEV-SNP ABI**, extracting the **VCEK public key**, and comparing its public value to the baseline [2605.12990].

A critical enabling condition is that although **ECC** and **Fletcher-32** redundancy were designed into the fuse words, the paper reports that **Milan ships with them disabled**, so no uncorrectable-error fault is raised when arbitrary bits are toggled [2605.12990].

## 4. Attestation forgery and failure of rollback prevention

With the full **256-bit RootSeed** recovered, the attacker can run the same hash-chain KDF locally to compute **$\mathrm{VCEK\_Seed}(\mathrm{cur})$** for any **$\mathrm{cur} \in [0..255]$**. The paper then states that **SEV-SNP** reports are **ECDSA-P384** signatures over the report body using the derived **VCEK private key** for version **cur**. If $m$ denotes the report message, the attacker computes

$$
(r,s) = \mathrm{ECDSA\_Sign}_{\mathrm{VCEK\_Priv}(cur)}(m).
$$

Because the adversary controls the private key material implied by the recovered seed, the system can fabricate reports claiming any **TCB version**, including **future, unreleased ones** [2605.12990].

The security significance is direct. The paper characterizes the essence of rollback prevention as binding the report signing key to the current **SVN** via a one-way KDF. Recovering the **root seed itself** removes that binding as a security boundary: any version-specific key can be regenerated off-chip, so the anti-rollback model no longer constrains what can be attested [2605.12990].

The experimental figures in the paper are operationally important because they show that the attack is not merely theoretical. The bitwise oracle requires **256 cold reboots** and **256 ABI report requests**. On an **EPYC 7413 on TYAN S8036GM2NE**, the paper states that each iteration, including power cycle, takes **under 20 s**, and that full seed extraction completes in **under 2 hours** with **100% reliability** on **unmodified Milan silicon** [2605.12990].

A common misconception is that protection against direct fuse reads is sufficient to protect a root seed. The Milan result shows that read blocking after BootROM access does not suffice when the adversary can still manipulate fuse state through an inadequately restricted write path and infer secret bits from resulting cryptographic behavior.

## 5. Related BadFuse patterns in OTP extraction and glitch-induced fuse bypass

The antifuse work shows a distinct but structurally analogous BadFuse pattern: instead of exploiting a writable fuse-burn path, it exploits the physical readout properties of **40 nm CMOS gate dielectric breakdown antifuses** through **passive voltage contrast (PVC)** under **FIB** imaging [2501.13276]. In the cited bitcell model, an unprogrammed cell behaves as **$C_{\mathrm{core}}$** in series with **$R_{\mathrm{off}} \gg 10^{12}\ \Omega$**, while a programmed cell forms a conductive filament with **$R_{\mathrm{prog}} \sim 1\,\mathrm{k}\Omega–10\,\mathrm{k}\Omega$**. Under ion-beam charging, the surface potential obeys **$V_{\mathrm{surf}} = I_{\mathrm{beam}} / G_{\mathrm{leak}}$** at steady state, with the programmed state exhibiting larger leakage and therefore lower surface potential. The attack exploits the resulting contrast in secondary-electron yield.

The array geometry imposes an important limitation: each **Metal 1 via** on a bit-line contact is shared by two vertically adjacent cells, so the PVC readout yields the **bitwise OR** of the north/south pair. Even with this constraint, the paper reports **Contrast-to-Noise Ratio (CNR): >100 gray levels** in **8-bit SEM images**, **imaging error rate: <10^-6 per bit**, throughput of **one 2 kbit plane** in approximately **1 hour** of FIB PVC time, and a **full 24-plane** compromise in approximately **2–3 days** [2501.13276]. This directly challenges the longstanding claim that antifuses are “significantly more difficult” to extract than Flash or mask ROM.

The Tegra X2 work shows the third pattern: fuse state remains intact, but **voltage glitching** causes the processor to mis-handle the result of a fuse check [2108.06131]. The relevant fuses are **FailureAnalysisMode (FAM)**, **PreProductionMode (PPM)**, and **SECURE_BOOT**. In production devices, **FAM=1** and **PPM=1** disable the hidden **“NvBootUartDownload()”** path, while **SECURE_BOOT=1** locks writes to **PIROM_START** and **ACCESS_PIROM**. The attack uses an **FPGA**, a high-speed crowbar circuit with an **Infineon IRF8736** MOSFET on **VDD_SYS_SOC**, and synchronization via **RESET_IN** to inject a glitch approximately **2.63 ms** after reset with width around **11.3 µs** and amplitude corresponding to a drop from **0.95 V** by approximately **0.9 V** [2108.06131].

The paper gives two concrete early successes after an **8 h brute-force pass** at **$\tau_{\mathrm{offset}} = 2.633800\ \mathrm{ms}, \Delta t = 11.32\ \mu\mathrm{s}$** and **$\tau_{\mathrm{offset}} = 2.625900\ \mathrm{ms}, \Delta t = 11.34\ \mu\mathrm{s}$**, each with success rate **1/10^5**, and then reports that constraining **$\tau_{\mathrm{offset}} \in [2.5852\ \mathrm{ms} \dots 2.6348\ \mathrm{ms}]$** produced approximately **1 success per second on average** for **$\Delta t \in \{11.30, 11.32, 11.34\ \mu\mathrm{s}\}$** [2108.06131]. Here the security failure lies in temporal faultability of the logic that enforces fuse-based policy.

| Variant | Target | Mechanism |
|---|---|---|
| AMD EPYC Milan | VCEK root seed at **0x5D0C4** | Software-only code execution plus writable **fuse burner** and VCEK-difference oracle |
| 40 nm antifuse OTP | Antifuse memory contents | **FIB passive voltage contrast** readout of programmed vs. unprogrammed cells |
| Nvidia Tegra X2 | Fuse-gated boot decisions | **Voltage fault injection** against early BootROM fuse checks |

Taken together, these results indicate that the security role of fuses can fail through **logical write abuse**, **physical state extraction**, or **fault-induced misinterpretation**.

## 6. Mitigations, limitations, and broader significance

For EPYC Milan, the paper proposes several mitigations: **hardware fuse write-protect bits** for the VCEK seed region; enabling and enforcing **ECC + Fletcher-32** checks on fuse reads such that mismatches or uncorrectable errors cause a **permanent ASP halt**; removing the **“Custom_PK”** override fuse function; and auditing the BootROM decryption flow so that the signature covers the **plaintext**, as in **Zen 4+** [2605.12990]. The paper also mentions an alternative migration of VCEK derivation to a **DICE-style** model that incorporates firmware measurements, while noting that this would sacrifice rollback flexibility.

For antifuse OTP, the reported countermeasures are array-level and circuit-level: **split-bit mapping** so that OR readout yields all ones, **dedicated single-cell contacts** to eliminate via sharing, **grounded M2 shielding**, thicker dielectric or **multi-layer antifuse stacks**, **reactive on-die monitors** that detect charge injection or FIB current, and cryptographic designs that store only a **per-device root key** rather than raw secrets in fuse memory [2501.13276].

For Tegra-style glitching, the proposed defenses include **triple-redundant fuse bits with majority voting**, cross-rail **voltage monitors**, analog comparators with **<10 ns** detection windows, watchdog reset on glitch alarm, duplicated branch conditions, random delays, maximal-Hamming-distance constants, and loop-integrity checks [2108.06131]. The paper explicitly notes that software hardening forcing two independent timing alignments reduces overall success from **$P_{\mathrm{hit}}$** to **$P_{\mathrm{hit}}^2$**.

A broader misconception addressed by these works is that fuses are intrinsically “tamper-resistant” because they are non-volatile, physically one-time programmable, or checked by immutable ROM. The literature shows a more conditional picture. A fuse may be difficult to read directly yet still be vulnerable if its **write path** is insufficiently constrained, if its **physical state** can be inferred by imaging, or if the **control-flow decisions** depending on it can be faulted. In this sense, the BadFuse literature shifts attention from the mere presence of fused state to the end-to-end integrity of the entire mechanism that stores, consumes, and enforces it.

Source: https://www.emergentmind.com/topics/badfuse-attack