{"id":"b7b261fa-50c3-45ba-acac-2cabe8619007","arxiv_id":"1908.11680","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":8.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A malicious cloud provider can extract the CPU-unique CEK key from AMD's PSP firmware and use it to impersonate SEV platforms, intercept migrations, and read guest memory on Epyc Naples CPUs.","lead":"This paper breaks AMD's Secure Encrypted Virtualization (SEV) feature on Epyc Naples servers by extracting a CPU-unique key from the firmware and then impersonating a trusted machine to a cloud customer. Anyone renting an SEV-protected virtual machine from an untrusted cloud provider should care: the paper shows the provider can read the VM's memory and disk key despite SEV's protections.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The universal claim that updated Naples systems remain vulnerable hinges on an under-evidenced assertion that no PSP rollback prevention exists; exact downgrade details are withheld, so the central premise is not independently verifiable from the paper.","rationale":"The reader identified the rollback-prevention premise as the weakest load-bearing assumption, and I agree that this is the critical hinge. My concern is more specific: the paper's evidence for 'no rollback prevention' is observational and indirect, and the exact downgrade details are withheld, so the universal statement about all Naples systems is not independently checkable from the manuscript. The external signature artifact provides good evidence that a CEK was extracted on the authors' test systems, and the responsible disclosure practice is commendable. The proposed attacks are internally coherent given the extracted CEK, and the design changes in Section 6 are reasonable. However, because the central claim's scope is 'the current series of AMD Epyc CPUs' and 'no purely software-based mitigations are possible,' the lack of public, reproducible evidence for the rollback claim is a genuine correctness risk. This does not change the overall CONDITIONAL verdict: the paper is strong enough to warrant conditional acceptance subject to release of technical details to accredited researchers and independent reproduction on fixed hardware, but the specific universal claim should be re-evaluated once rollback prevention behavior is independently verified.","tokens_in":21919,"tokens_out":4716,"duration_ms":51165,"concrete_test":"Take a Naples-based server from each of the five motherboard vendors analyzed in Section 3.2, update it to the latest UEFI/PSP firmware that includes AMD's signature verification patch, then use PSPTool to flash the known older signed vulnerable PSP OS and the patched SEV firmware. Observe whether the PSP boots the downgraded PSP OS and whether the CEK extraction still succeeds. If any current system refuses to boot the older PSP OS despite the unchanged ARK, the universal rollback premise is false and the paper's conclusion needs qualification. As a complementary check, independently verify the PoC signature at the cited GitHub repository against AMD's CEK certificate chain to confirm that the extracted key is indeed a valid CEK private key.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The decisive premise of the paper is not just that a PSP OS signature verification bug exists, but that an attacker can always install an older signed vulnerable PSP OS on a system that has already been updated to a patched firmware version. All three attacks inherit this requirement: the CEK extraction in Section 3.3, the Debug Override attack in Section 5.3, and, indirectly, the Fake SEV and Migration attacks that depend on having extracted any CEK. The paper's support for the 'no rollback prevention' claim is stated in Section 3.2 as 'our experiments showed' plus the absence of observed ARK revocation across ten UEFI images from five vendors. That is indirect evidence: it shows that no key revocation was observed, but it does not rule out a monotonic counter, a fuse-based version floor, or an OEM-specific boot path that rejects older PSP OS versions even when the signing key is unchanged. AMD's confirmation that the on-chip bootloader is not updatable also does not rule out rollback protection implemented in ROM or fuse logic, since a non-updatable ROM can still contain a version check. The paper withholds the exact details of the signature verification flaw and the downgrade procedure, so an independent reviewer cannot currently determine whether the downgrade works on all Naples systems or only on the specific firmware images the authors tested. If any shipping Naples configuration enforces rollback prevention, the claim that 'no purely software-based mitigations are possible' and the conclusion that SEV on Naples is rendered useless would need to be qualified to pre-revocation or pre-rollback-protection systems. This is the load-bearing soft spot in an otherwise well-supported attack chain.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper analyzes the firmware that implements AMD SEV remote attestation on the first-generation Epyc (Naples) processors. The authors reverse the Platform Security Processor (PSP) boot chain, identify a signature-verification flaw in the PSP OS, use it to install a patched SEV firmware with arbitrary PSP memory access, and extract the Chip Endorsement Key (CEK) private keys of three CPUs. They provide external evidence for the extraction: a signature over the paper title made with an extracted key and verifiable against AMD's certificate chain. Building on the extracted key, they present three attacks: Fake SEV (a malicious provider simulates SEV using any extracted CEK), a Migration attack (an attacker posing as a migration target decrypts exported VM memory), and a Debug Override attack (a patched SEV firmware ignores the guest's debug policy). They further argue that missing rollback protection on Naples means patched firmware does not restore security, and they propose design changes that tie the CEK to PSP OS and SEV firmware versions. The paper withholds the precise exploit details for responsible-disclosure reasons.","tokens_in":22121,"tokens_out":7984,"duration_ms":79834,"significance":"If the central claims hold, this is a significant result: it breaks the trust model of AMD SEV on the entire Naples product line, showing that a malicious cloud provider with reasonable hardware/software access can circumvent both the authenticity and the confidentiality guarantees of SEV. The externally verifiable signature is a strong artifact, and the accompanying PSPTool release is useful for follow-up research. The paper's strength is that the CEK extraction is not merely hypothesized but evidenced against AMD's own certificate infrastructure, and the attack logic for Fake SEV and Migration is coherent. The main uncertainty is the evidence for the universal 'no rollback prevention' claim and the corresponding scope of the conclusion that even patched Naples systems are unconditionally vulnerable.","major_comments":[{"comment":"The assertion that the PSP 'does not employ any rollback prevention mechanism' is load-bearing for the paper's headline claim that even patched Naples systems remain exploitable and for the Debug Override attack's statement that the attack works even after the firmware vulnerabilities are fixed (§5.3). The support provided is indirect: an unspecified set of logic-analyzer experiments and the observation that ten UEFI images from five vendors share the same ARK. These observations do not rule out a monotonic replay counter, a fuse-based version floor, or an OEM-specific boot path that rejects older PSP OS versions even when the signing key is unchanged. Please provide the full experimental protocol, the exact set of boards and firmware versions tested, and any attempts to trigger a rollback rejection; alternatively, explicitly narrow the universal claim to systems for which the absence of rollback protection was actually verified.","section":"Section 3.2"},{"comment":"The exact CEK extraction mechanism is omitted, so an independent reviewer cannot assess whether the method generalizes to all Naples systems or only to the particular firmware images the authors tested. I agree with not publishing full exploit details, and the verifiable signature is strong evidence that at least one CEK was extracted. However, the paper should state the conditions under which extraction is possible (e.g., which PSP OS versions, which motherboard firmware, which SPI-flash access assumptions), and should qualify the scope of the conclusion accordingly. As written, the central claim that the entire Naples series is 'useless' is broader than what the evidence in the paper directly supports.","section":"Section 3.3"},{"comment":"The proposed design requires the AMD Key Server to calculate version-dependent CEKs from the chip-unique SOTP value, but Sections 2.3 and 3.1 describe SOTP as an OTP fuse value that is only available inside the CPU/SEV firmware. The paper does not explain how AMD would obtain, store, or protect per-chip SOTP values, nor how the Key Server could compute SCEK without introducing a new single point of compromise. This is a feasibility gap in the proposed mitigation and should be addressed explicitly, at least by stating the provisioning assumption (e.g., SOTP escrowed at manufacturing).","section":"Section 6.2"},{"comment":"The attack models for Fake SEV and Migration correctly note that the attacker needs only one extracted CEK from any SEV-enabled system. The paper should be careful to distinguish these attacks, which do not require the victim's platform itself to be rollback-vulnerable, from the Debug Override attack, which does require installing a patched SEV firmware on the victim's host. The current text is largely clear on this point, but the abstract and conclusion phrase the result in a way that can be read as claiming that every individual Naples system can be directly compromised; the distinct preconditions should be restated prominently.","section":"Sections 5.1 and 5.2"}],"minor_comments":[{"comment":"The text supplied to me contains pervasive OCR-like artifacts (e.g., '/T_', '/f_', 'a/t_tacker') that obscure the technical content. These should be cleaned before a final version is produced.","section":"Entire manuscript"},{"comment":"The KSM-based economic motivation is plausible but would be stronger with a quantitative reference for the memory overhead that SEV introduces and for the prevalence of KSM in IaaS deployments.","section":"Section 4.2"},{"comment":"The phrase 'no purely software-based mitigations are possible' should be qualified: it is true for existing Naples hardware under the no-rollback premise, but the paper's own contribution is a firmware/hardware design change for future CPUs, so the statement could be misread as ruling out all firmware-based fixes.","section":"Abstract and Conclusion"},{"comment":"In the proposed design, the on-chip bootloader must parse the PSP OS version from the signed header and perform a KDF before provisioning the CCP. Since the on-chip bootloader is not updatable, the paper should state explicitly that these changes apply only to future CPU generations and should estimate the added ROM complexity.","section":"Section 6.2"}],"recommendation":"major_revision","confidential_remarks":"As editor: The core attack is credible and the external signature is a compelling artifact, but the universal no-rollback claim is under-evidenced as written. I recommend inviting a revision that either supplies additional verification data or narrows the claims to the systems and firmware versions actually tested. The responsible-disclosure constraints are understandable, but at a minimum the paper should specify the observable preconditions for the attacks and discuss the key-server provisioning gap in the proposed design."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague —\n\nRead this one. It's the first real break of SEV's remote attestation, not another runtime side-channel. The authors extracted the Chip Endorsement Key from three Epyc Naples CPUs and proved it with a signature verifiable against AMD's certificate chain. That external benchmark makes the extraction credible. The derived attacks — Fake SEV, migration interception, debug override — follow coherently from holding a CEK, and the first two don't require the victim's platform to be compromised. Any valid CEK works. That is a design-level flaw, and the proposed firmware-version-bound CEK with version fields in the certificate is a sensible, proportionate fix.\n\nThe soft spot is load-bearing. The claim that even patched Naples systems remain vulnerable relies on the absence of PSP rollback prevention. The paper supports that with 'our experiments showed' plus ten UEFI images from five vendors, all signed with the same ARK. That rules out observed key revocation, but it does not rule out a monotonic counter, a fuse-based version floor, or an OEM-specific boot path that rejects older PSP OS images. AMD confirming the on-chip bootloader is not updatable doesn't settle it; a ROM bootloader can still enforce a version check. And the exact downgrade details are withheld, so an independent reviewer cannot tell whether rollback works on all Naples systems or only on the specific images tested. If any shipping configuration enforces rollback, the 'no purely software-based mitigations' conclusion needs qualification.\n\nThat said, this doesn't sink the paper. The core contribution — CEK extraction and the impersonation/migration attacks — is new, documented with a released tool, and responsibly disclosed. The citation pattern is fair: prior SEV work targeted runtime protection, and CTS Labs did not connect PSP issues to SEV attestation. The universal claim is overstated relative to the evidence, but the main result holds. This deserves a serious referee. The rollback-resistance claim needs either more evidence or careful circumscription, and the withheld exploit details should go to accredited researchers. Desk rejection would be wrong.","headline":"First real break of SEV remote attestation with a CEK extraction proven against AMD's certificate chain; the universal rollback-resistance claim is the load-bearing soft spot.","tokens_in":22735,"tokens_out":2354,"would_cite":true,"duration_ms":21418,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"AMD SEV's remote attestation can be fully bypassed on Epyc Naples because the Chip Endorsement Key private key can be extracted and old vulnerable firmware can be reinstalled.","keywords":["SEV","remote attestation","Platform Security Processor","Chip Endorsement Key","firmware rollback","memory encryption","cloud security","Epyc Naples"],"falsifier":"Install the latest vendor firmware on an Epyc Naples system, then flash an older signed PSP OS that contains the reported signature-verification flaw; if the machine rejects the older image or refuses to boot rather than executing it, the rollback premise that makes CEK extraction possible is false.","tokens_in":21666,"feed_emoji":"🔓","tokens_out":7935,"duration_ms":70495,"temperature":0.7,"pith_summary":"This paper aims to establish that AMD's Secure Encrypted Virtualization (SEV) on the Epyc Naples processor line cannot protect guests from a malicious cloud provider. The load-bearing result is that the private key anchoring remote attestation, the Chip Endorsement Key (CEK), can be physically extracted from the CPU's Platform Security Processor. A signature-verification flaw in the PSP operating system, combined with the complete absence of rollback prevention, lets an attacker install an older signed vulnerable firmware even on machines that have been patched. With any extracted CEK, the paper argues, a cloud provider can fake the presence of SEV, decrypt a guest's disk key, or decrypt memory exported during migration. If this is correct, SEV on Naples gives no confidentiality or authenticity guarantee against an untrusted cloud provider, and no purely software-based fix can restore it.","feed_headline":"Extracted CPU key lets cloud providers read AMD SEV guests","feed_subtitle":"Attestation's anchor key is extractable, and patched firmware can still be rolled back to the vulnerable version.","key_machinery":"The load-bearing object is the Chip Endorsement Key (CEK), the CPU-unique ECDSA private key derived through a key derivation function from a 32-byte one-time-programmable fuse value, and signed by the AMD SEV Signing Key. It anchors the certificate chain in which the Platform Diffie-Hellman key is signed by the Platform Endorsement Key, which is in turn signed by the CEK, then by the AMD SEV Signing Key, then by the AMD Root Key. The enabling mechanism is the PSP secure-boot path: the on-chip ROM bootloader verifies the ARK public key and the PSP OS, the PSP OS loads and verifies the SEV firmware, and the SEV firmware obtains the fuse-derived secret through a syscall. Because the PSP OS signature verification has a flaw that allows custom signed components to run, and because the bootloader has no rollback prevention and cannot be updated, an attacker can always install an older signed PSP OS and a patched SEV firmware to read PSP memory and extract the CEK. The CEK's validity across all firmware versions is what turns that one-time extraction into a permanent credential.","core_discovery":"The central discovery is that the Chip Endorsement Key, the ECDSA key derived from chip-unique one-time-programmable fuses that roots the SEV certificate chain, is not protected against a compromised PSP. Using a patched SEV firmware installed through the PSP OS signature-verification vulnerability, the authors read the CEK private key from three Epyc Naples CPUs and verified the extracted keys against certificates obtained from the manufacturer's key server. Because the PSP's on-chip bootloader cannot be updated and enforces no rollback prevention, even CPUs running patched firmware can be reverted to a vulnerable signed PSP OS. The extracted CEK, whose lifetime is the lifetime of the CPU, then enables three attacks: faking SEV presence and decrypting the guest's disk key; impersonating a legitimate migration target so that any extracted CEK, not just the target's, decrypts exported VM memory; and patching the SEV firmware to override the guest policy's debug setting and read guest memory in plaintext. The paper concludes that on Naples, SEV cannot deliver its promised security when the cloud provider is untrusted.","pith_inferences":["The migration attack effectively makes the CEK a product-line master key: because attestation does not bind a target's identity to a specific CPU, one extracted CEK jeopardizes every Naples VM whose guest policy allows migration.","The rollback gap is a general design lesson beyond this product: any security processor with an unupdatable boot ROM and no version counter can be returned to a signed-but-buggy firmware state, so a monotonic fuse or version check at the root of trust is the natural class of fix.","A direct test of the paper's proposed redesign would be to show that a CEK extracted under an old firmware no longer matches the certificate served for a newer firmware version; the paper does not implement this, so that part remains a design proposal rather than a demonstrated result."],"forward_implications":["A malicious cloud provider can run guests without SEV memory encryption and still pass remote attestation, then decrypt the disk key the guest owner sends over the supposedly secure channel.","Any extracted CEK, not just the target platform's, is enough to decrypt a VM's exported memory during migration because the attacker can impersonate the migration endpoint.","Software-only fixes cannot restore security on Naples: the CEK remains valid for the CPU's lifetime and old signed PSP OS images can always be reinstalled.","The debug interface attack reads and writes guest memory in plaintext regardless of the guest policy, and it requires no helper software inside the guest.","If the manufacturer adopts the paper's proposed version-dependent CEK derivation, guest owners could refuse platforms with known-vulnerable firmware versions, which would close the attacks described here."],"supporting_citations":[{"why":"Defines the SEV API, the full key hierarchy and certificate chains, the secure-channel protocol, and the debug interface that the attacks manipulate.","marker":"[3]"},{"why":"Provides the signed CEK certificates from the manufacturer's key server that the authors use to verify their extracted private keys.","marker":"[4]"},{"why":"States the SEV attestation and memory-encryption guarantees that the paper claims to break.","marker":"[6]"},{"why":"Holds the authors' signature created with an extracted CEK as public proof that key extraction succeeded.","marker":"[9]"},{"why":"Details previously published PSP signature-verification issues that the attacks rely on as the initial firmware weakness.","marker":"[13]"},{"why":"Reports the earlier set of PSP vulnerabilities and alleged backdoors that established the buggy-firmware premise.","marker":"[21]"},{"why":"Supplies the manufacturer's public acknowledgment that the reported PSP firmware issues are real.","marker":"[24]"},{"why":"Supplies the proprietary PSP directory header format used to locate and extract the PSP OS and SEV firmware from UEFI images.","marker":"[26]"},{"why":"Is the authors' published PSP firmware analysis tool used to parse the proprietary filesystem and identify the firmware components relevant to the attack.","marker":"[32]"}],"fun_headline_variants":["SEV's root key stolen, guests exposed","Cloud provider can crack SEV attestation","AMD SEV: chip key extracted, rollback attack","CEK key leak lets cloud bypass SEV security"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The attacks depend on the premise that the PSP's on-chip bootloader cannot be updated and enforces no rollback prevention, so an attacker can always install an older signed PSP OS containing the signature-verification bug even after the vendor patches the firmware.","fun_headline_variants_meta":{"raw":{"variants":["SEV's root key stolen, guests exposed","Cloud provider can crack SEV attestation","AMD SEV: chip key extracted, rollback attack","CEK key leak lets cloud bypass SEV security"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000196,"raw_usage":{"total_tokens":1414,"prompt_tokens":1052,"completion_tokens":362,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":668,"completion_tokens_details":{"reasoning_tokens":301}},"tokens_in":668,"tokens_out":362,"duration_ms":4332,"temperature":1.0,"reasoning_tokens":301,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T10:08:48.202074+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Install the latest vendor firmware on an Epyc Naples system, then flash an older signed PSP OS that contains the reported signature-verification flaw; if the machine rejects the older image or refuses to boot rather than executing it, the rollback premise that makes CEK extraction possible is false.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the SEV API, the full key hierarchy and certificate chains, the secure-channel protocol, and the debug interface that the attacks manipulate."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the signed CEK certificates from the manufacturer's key server that the authors use to verify their extracted private keys."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"States the SEV attestation and memory-encryption guarantees that the paper claims to break."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Holds the authors' signature created with an extracted CEK as public proof that key extraction succeeded."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Details previously published PSP signature-verification issues that the attacks rely on as the initial firmware weakness."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Reports the earlier set of PSP vulnerabilities and alleged backdoors that established the buggy-firmware premise."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the manufacturer's public acknowledgment that the reported PSP firmware issues are real."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the proprietary PSP directory header format used to locate and extract the PSP OS and SEV firmware from UEFI images."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Is the authors' published PSP firmware analysis tool used to parse the proprietary filesystem and identify the firmware components relevant to the attack."}],"review_version":1}