Strict AMD SEV-SNP Hardware Attestation & Root-of-Trust Validation Before Key Release

Q: How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Trusting hypervisor-supplied VCEK certs, bypassing AMD ARK/ASK root verification, or omitting REPORT_DATA cryptographic binding) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q: Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q: Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

Strict AMD SEV-SNP Hardware Attestation & Root-of-Trust Validation Before Key Release

--- description: Strict AMD SEV-SNP Hardware Attestation & Root-of-Trust Validation Before Key Release - Enforces strict validation of AMD SEV-SNP attestation reports against AMD Key Distribution Service (KDS) hardware certificate chains (ARK/ASK/VCEK) before releasing cryptographic keys to guest virtual machines. Guarantees measurement register verification (launch digest), report data binding against client session nonces, debug policy disallowance, and TCB version compliance to eliminate hypervisor-mediated man-in-the-middle and replay attacks. globs: src/attestation/**/*.{ts,js,rs,go}, src/kms/**/*.{ts,js,rs,go}, src/security/**/*.{ts,js,rs,go}, src/enclave/**/*.{ts,js,rs,go} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/amd-sev-snp-attestation-boundary-guardrail" --- # Strict AMD SEV-SNP Hardware Attestation & Root-of-Trust Validation Before Key Release > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Trusting hypervisor-supplied VCEK certs, bypassing AMD ARK/ASK root verification, or omitting REPORT_DATA cryptographic binding ## System Constraints You are a Principal Hardware Security and Cryptography Architect enforcing AMD SEV-SNP Confidential Compute Measurement Attestation Boundaries. You must mandate zero-trust key provisioning invariants: untrusted hypervisors MUST NEVER receive decryption keys without full cryptographic verification of AMD ARK->ASK->VCEK x509 chains, CRL status, ECDSA report signatures, exact launch measurement comparison, debug bit suppression, and REPORT_DATA binding to ephemeral handshake nonces. ## Strict Guidelines - Engineers MUST ALWAYS cryptographically verify the Versioned Chip Endorsement Key (VCEK) certificate chain up to the hardcoded AMD Root Signing Key (ARK) via the AMD SEV Signing Key (ASK). - Engineers MUST NOT trust VCEK or certificate chains supplied directly by untrusted host hypervisors without independent cryptographic validation against AMD's public root key and official CRLs. - Services MUST verify that REPORT_DATA in the SEV-SNP attestation report matches the exact SHA-512 hash of the client's ephemeral public key or session nonce to prevent replay attacks. - Code MUST verify that the guest POLICY enforces DEBUG == 0, disallowing runtime hypervisor memory inspection or guest debugging. - Components MUST compare the guest MEASUREMENT (launch digest) against trusted reference values (golden digest) and assert that the reported TCB meets or exceeds the minimum security baseline. ## Bad vs Good Implementations ### SEV-SNP Attestation Verification and Key Provisioning #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The code parses raw measurement bytes from an untrusted buffer without verifying the AMD hardware certificate chain (ARK->ASK->VCEK), completely omits ECDSA signature verification of the report, does not validate REPORT_DATA against a cryptographically bound session nonce (allowing replay attacks), and fails to verify that the guest debug policy is disabled. ```typescript import { createHash } from 'node:crypto'; interface AttestationRequest { report: Buffer; vcekCertPem: string; sessionKey: string; } export async function provisionDecryptionKey(req: AttestationRequest): Promise<string> { // VULNERABILITY: Directly parsing hypervisor-supplied buffers without verifying AMD root of trust, // skipping report signature verification, ignoring REPORT_DATA nonce binding, and ignoring DEBUG policy. const measurement = req.report.subarray(0x90, 0xC0).toString('hex'); const EXPECTED_MEASUREMENT = process.env.GOLDEN_MEASUREMENT!; if (measurement !== EXPECTED_MEASUREMENT) { throw new Error('Measurement mismatch'); } // DANGEROUS: Key released to potentially compromised or spoofed hypervisor/guest return process.env.ENCLAVE_DECRYPTION_KEY!; } ``` #### Production Standard (Correct) > **Standard**: Validates the full AMD hardware root of trust (ARK verifies ASK, ASK verifies VCEK), checks the ECDSA SHA-384 hardware signature over report bytes, binds REPORT_DATA to an ephemeral handshake key, asserts that the SEV-SNP guest debug policy bit is cleared, and verifies both golden launch measurement and TCB baseline before key release. ```typescript import { createHash, createVerify, X509Certificate } from 'node:crypto'; interface SnpReport { version: number; guestPolicy: bigint; reportData: Buffer; measurement: Buffer; reportedTcb: bigint; signature: Buffer; rawSignedBytes: Buffer; } interface VerifiedAttestationContext { goldenMeasurement: Buffer; ephemeralPublicKey: Buffer; amdRootArkCert: X509Certificate; minTcbVersion: bigint; } export async function verifySnpAndReleaseKey( report: SnpReport, vcekCert: X509Certificate, askCert: X509Certificate, ctx: VerifiedAttestationContext ): Promise<string> { // 1. Verify AMD Certificate Chain: ARK -> ASK -> VCEK if (!askCert.verify(ctx.amdRootArkCert.publicKey)) { throw new SecurityError('AMD ASK is not signed by trusted AMD Root Key (ARK)'); } if (!vcekCert.verify(askCert.publicKey)) { throw new SecurityError('AMD VCEK is not signed by verified AMD ASK'); } // 2. Cryptographically verify SEV-SNP Report signature against VCEK public key const verifier = createVerify('SHA384'); verifier.update(report.rawSignedBytes); const isSignatureValid = verifier.verify(vcekCert.publicKey, report.signature); if (!isSignatureValid) { throw new SecurityError('Invalid SEV-SNP attestation report signature'); } // 3. Prevent Replay: REPORT_DATA must strictly bind to SHA-512 of ephemeral session key const expectedReportData = createHash('sha512').update(ctx.ephemeralPublicKey).digest(); if (!report.reportData.equals(expectedReportData)) { throw new SecurityError('REPORT_DATA mismatch: replay attack detected or key binding failed'); } // 4. Assert Policy Invariants: DEBUG bit (bit 19) MUST be 0 const DEBUG_POLICY_MASK = 1n << 19n; if ((report.guestPolicy & DEBUG_POLICY_MASK) !== 0n) { throw new SecurityError('Insecure guest policy: debug mode is enabled'); } // 5. Enforce Golden Measurement and TCB Baseline if (!report.measurement.equals(ctx.goldenMeasurement)) { throw new SecurityError('Untrusted guest image: launch measurement mismatch'); } if (report.reportedTcb < ctx.minTcbVersion) { throw new SecurityError('VCEK/Platform TCB is below required security baseline'); } return process.env.ENCLAVE_DECRYPTION_KEY!; } class SecurityError extends Error { constructor(message: string) { super(message); this.name = 'SecurityError'; } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Strict AMD SEV-SNP Hardware Attestation & Root-of-Trust Validation Before Key Release

Strict AMD SEV-SNP Hardware Attestation & Root-of-Trust Validation Before Key Release defines an industrial-grade behavioral standard for security engineering. Enforces strict validation of AMD SEV-SNP attestation reports against AMD Key Distribution Service (KDS) hardware certificate chains (ARK/ASK/VCEK) before releasing cryptographic keys to guest virtual machines. Guarantees measurement register verification (launch digest), report data binding against client session nonces, debug policy disallowance, and TCB version compliance to eliminate hypervisor-mediated man-in-the-middle and replay attacks. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Trusting hypervisor-supplied VCEK certs, bypassing AMD ARK/ASK root verification, or omitting REPORT_DATA cryptographic binding Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure Mode	AI Symptom (The Anti-Pattern)	Severity	Production Impact & Remedy
AI Hallucination & Deprecation Drift	Trusting hypervisor-supplied VCEK certs, bypassing AMD ARK/ASK root verification, or omitting REPORT_DATA cryptographic binding	Critical	Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture Inconsistency	AI assistants produce mixed paradigms across files, creating fragmented codebase conventions.	Medium	Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.

Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

Engineers MUST ALWAYS cryptographically verify the Versioned Chip Endorsement Key (VCEK) certificate chain up to the hardcoded AMD Root Signing Key (ARK) via the AMD SEV Signing Key (ASK).

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.