- The paper shows that an attacker can extract the root VCEK seed via a software-only attack, effectively bypassing anti-rollback measures.
- It details the use of the MilanLaunchy and BadFuse exploits, leveraging firmware decryption flaws and an unprotected fuse burner interface.
- The findings challenge the security guarantees of AMD SEV-SNP by exposing vulnerabilities that necessitate robust hardware-rooted protection mechanisms.
Software-Only Extraction of the Root VCEK Seed on AMD EPYC Milan: Analysis of Attacks and SEV-SNP Trust Implications
Introduction
The paper "Insecure Despite Proven Updated: Extracting the Root VCEK Seed on EPYC Milan via a Software-Only Attack" (2605.12990) systematically deconstructs the trust foundations of AMD's SEV-SNP confidential computing architecture by presenting a practical, software-only attack chain against the root VCEK seed on EPYC Milan systems. The significance of this work is underscored by its complete circumvention of the anti-rollback and attestation guarantees central to SEV-SNP, which until now had only been challenged by physical attacks. By demonstrating the full extraction and practical misuse of the VCEK hardware root seed through software, the authors expose architectural and implementation flaws with critical ramifications for the cloud security landscape.
Background: SEV-SNP and the VCEK Trust Model
AMD SEV-SNP hardens VM isolation and integrity with hardware-backed mechanisms: RMP-based memory ownership enforcement, attestation via AMD's Secure Processor (ASP), and version-aware key derivation. Attestation reports are signed with the Versioned Chip Endorsement Key (VCEK), itself derived from a root seed by a hash iteration count encoding the platform's TCB state (indexed by Security Version Numbers, SVNs). This architectural design is intended to cryptographically bind attestation to the “current” firmware and block TCB rollback attacks, as possessing a VCEK of a lower version does not allow derivation of newer versions.
However, the root seed's security is paramount. Disclosure of the root seed would allow an adversary to fully traverse the VCEK derivation hash chain and forge attestation reports for any TCB version, thereby completely undermining remote trust in the platform.
Technical Contribution: MilanLaunchy and BadFuse Attack Chain
MilanLaunchy Exploit
The first stage of the attack leverages a previously underexplored firmware decryption flaw (CVE-2021-26315) in the Milan ASP BootROM. The authors exploit the misalignment between decryption and authentication: while Milan integrates HMAC and RSA-PSS, the RSA signature is computed solely over the encrypted firmware body and header. A brute force over 32-bit keyspace suffices to control the initial execution (installing an ARM branch instruction), redirecting execution into a custom bootloader payload. This enables stable, arbitrary code execution on the ASP, including the seamless boot of the x86 OS, ensuring practical exploitation.
AMD deployed a mitigation in MilanPI-1.0.0.3: it ceased encrypted firmware payloads and incremented the minimal bootloader SVN. However, this does not affect the exploitability of systems running legacy or downgraded bootloaders, which is central to the subsequent attack stage.
BadFuse Exploit
Armed with code execution on vulnerable ASP firmware, the authors reverse-engineered the ASP's SMN-mapped fuse controller. They identified that, while read access to the VCEK and CEK root seed fuses is blocked after initialization with a hardware latch, write access via the dedicated MMIO fuse burner remained unprotected in the reference architecture. Two data-driven software attacks are implemented:
- Custom Public Key Subversion: By burning a custom SHA-384 hash into the Custom_PK fuse slot, the system root of trust is redirected from AMD to attacker-controlled keys. The attacker then signs a malicious payload with SVN=255 and flashes it, executing arbitrary code at the SEV-SNP root trust level. They extract the root VCEK seed, defeating the version chaining.
- Bitwise Extraction Oracle: The write-only fuse interface supports fine-grained bit manipulation (blindly setting bits to '1'). By toggling each bit, rebooting, and observing resultant attestation keys, an attacker can reconstruct the entire root VCEK seed. ECC and integrity checks (Fletcher-32) designed to defend against such manipulations are found disabled in practice.
This end-to-end purely software attack decisively breaks the original design intention of SEV-SNP's VCEK architecture for campaign-wide attestation security.
Evaluation and Responsible Disclosure
The practical attack is demonstrated on Milan hardware (EPYC 7413) using only software interfaces available to a fully privileged host (including BMC and SPI-Flash access), strictly within the canonical confidential computing adversary model. To maintain responsible disclosure, all discovered vulnerabilities were reported to AMD, with proper embargo and subsequent vendor action, as detailed in the paper.
Implications
Threats to SEV-SNP Assurance
The research shows that protection of root trust fuses is not guaranteed by cryptographic design alone but hinges on correct hardware and firmware control of destructive write capabilities, a property not enforced in Milan. As a result, all critical attestation and TCB rollback assurances are nullified on affected systems: an attacker with control over the host firmware can forge attestation reports for arbitrary TCB versions, including “future” as-yet-unreleased states.
Attack Surface and Mitigation Limitations
The exploitation chain is enabled by architectural oversights in both the firmware loading sequence and fuse accessor design. Mitigations are theoretically straightforward: enforcing one-time programmable write locks on secret fuses, activating and strictly enforcing ECC and integrity mechanisms, and eliminating custom public key functionality. However, for systems with immutable BootROM logic and no hardware anti-rollback for the off-chip bootloader, full remediation post-deployment is impossible.
Practical Impact and Cloud Security
From a practical attacker's perspective, this work greatly lowers the barrier to VCEK seed extraction. Previous fault injection attacks ([16]) are rendered obsolete; a privileged software adversary suffices. The work raises acute concerns for TEE-backed workloads in public cloud environments using Milan-based confidential VMs, since remote attestation can no longer be trusted to enforce TCB update compliance or prevent rollback.
Theoretical Perspective and Future Directions
The findings highlight the need for a holistic approach to TCB minimization, where robust cryptographic protocols are coupled with provably enforced hardware access control and a minimal attack surface in TEE firmware. Beyond SEV-SNP, the problem generalizes to all designs where root secrets are accessible to updateable firmware with insufficient hardware gating.
Moving forward, thorough hardware-rooted write protections, rigorous supply chain auditing, and TCB measurements that incorporate both firmware and hardware state become essential. As confidential computing platforms evolve, schemes like DICE—where attestation keys derive not only from version registers but holistic, immutable measurements—offer a path towards stronger post-quantum resilience, albeit with tradeoffs in rollback and maintenance flexibility.
Conclusion
This paper provides a conclusive demonstration that design and implementation failures in hardware root secret management can comprehensively undermine the attestation and rollback guarantees of AMD's SEV-SNP architecture on EPYC Milan. The results impose urgent requirements for hardware-level protections and prompt a reevaluation of remote attestation trust in the presence of software-accessible fuse controllers. To restore confidence in confidential cloud and TEE infrastructures, future platforms must ensure cryptographic protocol soundness is matched by rigorous, auditable enforcement of root secret access controls.