# The Verification Stack ## Three of the stack’s 50 mechanisms fail if a chip gives up its key. Published attacks have extracted identity or attestation keys from four families of security hardware; for NVIDIA’s data-centre GPUs, a search on 7 October 2026 found no published extraction. The stack’s 50 mechanisms in seven layers, from physical integrity at the bottom to institutional checks at the top. Factory key provisioning, set in italic, is an assumption the standards record.The stack’s 50 mechanisms in seven layers, from physical integrity at the bottom to institutional checks at the top. Factory key provisioning, drawn dotted, is an assumption the standards record. Select any box to read it in the card.Tap any square to read it below. Assume this failsNone: the stack intactChallenge inspection · none failChip consolidation · none failChip registry · 11 failContainment and surveillance · none failDeclarations and inventories · none failEnd-use checks · none failKYC for compute providers · none failNational technical means · none failOn-site inspection · none failPersonnel interviews · none failPersonnel monitoring · none failProduction monitoring · none failSampled chip inspection · 9 failTraining-run declarations · 2 failTransfer reporting · 12 failWhistleblower programmes · none failAnalog-sensor accounting · none failCapture-and-commit records · 1 failsModel evaluations · none failNetwork taps · none failNeutral data centre · 1 failsOther location methods · none failProof-of-training · none failProvider-side accounting · none failVendor fleet telemetry · none failWorkload classification · 1 failsWorkload re-execution · none failZero-knowledge proofs · none failDelay-based location · none failInterconnect limits · none failOffline licensing · 1 failsOn-chip compute metering · 2 failOperating limits · none failRemote disable · none failUnilateral backdoor · none failVerified shutdown · none failWeight-snapshot logging · none failChip serial numbers · 12 failHardware fingerprinting · none failRemote attestation · 1 failsWorkload attestation · none failConfidential computing · none failGuarantee processor · none failMulti-party authorisation · none failOn-chip rule enforcement · none failFactory key provisioning · 4 failHardware identity key · 3 failHardware integrity checks · 1 failsHardware root of trust · 7 failTamper evidence · 8 failTamper response · 1 fails - Shipping or in practice today - Demonstrated - Proposed - Argued against - _Italic_: an assumptionAn assumption - Assumed to fail - Fails with it - Dependency, pointing to the part that needs it - Dependency, pointing to the part stronger with it - The failure’s path - The part in the card Draw all 39 dependencies If Hardware identity key fails, these fail with it: 1. Remote attestation needs it, 4 of the 35 documents that state how mechanisms relate Quotes 2. Workload attestation needs it, 2 of the 35 documents Quotes 3. Delay-based location needs it, 9 of the 35 documents Quotes A dependency is one mechanism needing another, or stronger with it. Count a dependency when it is stated in Any document 197 dependencies · 30 mechanisms fail2 or more documents 39 dependencies · 3 mechanisms fail3 or more documents 19 dependencies · 2 mechanisms fail At this setting, 39 dependencies count; 158 stated by one document do not. Never counted: 109 stated for one design only and 62 that Scrutica inferred. Restore the stack Silicon root of trust · shipping in hardware today #### Hardware identity key Assumed to fail. In 2 or more documents, three mechanisms need it; it needs two others and is stronger with one. These fail with it 1. Remote attestation needs it, 4 of the 35 documents that state how mechanisms relate Quotes 2. Workload attestation needs it, 2 of the 35 documents Quotes 3. Delay-based location needs it, 9 of the 35 documents Quotes A dependency is one mechanism needing another, or stronger with it. Count a dependency when it is stated in Any document 197 dependencies · 30 mechanisms fail2 or more documents 39 dependencies · 3 mechanisms fail3 or more documents 19 dependencies · 2 mechanisms fail At this setting, 39 dependencies count; 158 stated by one document do not. Never counted: 109 stated for one design only and 62 that Scrutica inferred. Restore the stack A secret cryptographic key held inside the chip (fused or stored at manufacture) that lets the chip sign challenges, so a remote party can tell that a message really comes from that physical chip. Its value depends on the key staying unextractable. > A device-specific public and private key pair are created on the device, ideally using a dedicated security module. The public key is shared externally. [Aarne et al. 2024, p. 14](https://s3.us-east-1.amazonaws.com/files.cnas.org/documents/CNAS-Report-Tech-Secure-Chips-Jan-24-finalb.pdf#page=17) It needs - Factory key provisioning, 2 of the 35 documents that state how mechanisms relate Quotes - Hardware root of trust, 2 of the 35 documents and 2 more that imply it (Scrutica’s reading; not counted) Quotes - Is stronger with Tamper response, 3 of the 35 documents Quotes Needed by the three listed above. More dependencies and other relations (18) Not counted at this setting - Is needed by Confidential computing, 1 of the 35 documents Quote - Strengthens Hardware root of trust, 1 of the 35 documents Quote - Is needed by Workload classification, 1 of the 35 documents Quote - Is needed by Interconnect limits, 4 of the 35 documents say it holds for one design only (not counted) Quotes - Is stronger with Tamper evidence, 2 of the 35 documents say it holds for one design only (not counted) Quotes - Is needed by Offline licensing, 3 of the 35 documents, none counted: 1 that says it holds for one design only and 2 that imply it (Scrutica’s reading) Quote - Is needed by Chip registry, 1 of the 35 documents says it holds for one design only (not counted) Quote - Is needed by Declarations and inventories, 1 of the 35 documents says it holds for one design only (not counted) Quote - Strengthens Declarations and inventories, 1 of the 35 documents says it holds for one design only (not counted) Quote - Is needed by On-chip compute metering, 1 of the 35 documents says it holds for one design only (not counted) Quote - Is needed by Weight-snapshot logging, 1 of the 35 documents says it holds for one design only (not counted) Quote - Is needed by Hardware root of trust, 1 of the 35 documents implies it (Scrutica’s reading; not counted) - Is needed by On-site inspection, 1 of the 35 documents implies it (Scrutica’s reading; not counted) - Strengthens Workload attestation, 1 of the 35 documents implies it (Scrutica’s reading; not counted) Other relations - Can be replaced by Chip serial numbers, 1 of the 35 documents Quote - Enables Weight-snapshot logging, 1 of the 35 documents Quote - Can be replaced by Hardware fingerprinting, 1 of the 35 documents Quote - Weakens Delay-based location, 1 of the 35 documents implies it (Scrutica’s reading; not counted) Eleven verified published results break it; three more, partly verified, claim to; one more recovered part of an identity key. Show them on the attack recordResults not counted (4) Partly verified: Intel CSME boot-ROM IOMMU window, SGX.Fail and Intel SGX Fuse Key0 extraction on Gemini Lake. Part of an identity key only: Google Project Zero / Google Cloud security review of the AMD Secure Processor. Of the 35, 13 propose it, 1 argues against relying on it for location checks and 4 discuss it; 9 of the 14 reports charted below take a position. The documents, by position (18) Proposed in Aarne et al. 2024, Brass and Aarne 2024, Brass 2025, Petrie et al. 2025, Petrie and Aarne 2025, Baker et al. 2025, Scher and Thiergart 2024, Shavit 2023, Petrie 2024, O’Gara et al. 2025, Feldgoise et al. 2026, Avellar and Grunewald 2026 and Rahman and Tajdari 2026. Argued against relying on it for location checks in Tee and Happel 2026. Discussed in Kulp et al. 2024, Harack et al. 2025, Heim et al. 2024 and Cankaya 2026. Quotations (7) It establishes > Cryptographic proof of identity, which is used to verify that the replies the landmarks are getting are actually coming from the real asset. [Brass and Aarne 2024, p. 17](https://www.iaps.ai/s/LocationVerificationforAIChips.pdf#page=18) It leaves open > While it is difficult to be confident, existing chips are likely insecure: they do not appear to have undergone extremely rigorous testing, and the threat model assumed in this report is that of the most capable nation-state actors. [Scher and Thiergart 2024, p. 16](https://intelligence.org/wp-content/uploads/2024/11/Mechanisms-to-Verify-International-Agreements-About-AI-Development-27-Nov-24.pdf#page=16) Why ‘shipping in hardware today’ > This device-unique private Identity Key (IK) is burned into fuses of each H100; the public key is retained, but all copies of these private keys are destroyed during the manufacturing process. [NVIDIA, Confidential Compute on NVIDIA Hopper H100 (WP-11459-001 v1.0), p. 22](https://images.nvidia.com/aem-dam/en-zz/Solutions/data-center/HCC-Whitepaper-v1.0.pdf#page=22) Statements about different attackers Are today’s chips secure enough to host governance mechanisms? Against physical attacks repeated across thousands of chips > Public documentation suggests that NVIDIA’s H100 AI chip already has these security features [Petrie 2024, PDF p. 1](https://arxiv.org/pdf/2404.18308v2#page=1) > Without additional hardware modifications, the system is susceptible to physical hardware attacks. However, these attacks might require expensive equipment and could be difficult to reliably apply to thousands of AI chips. [Petrie 2024, PDF p. 1](https://arxiv.org/pdf/2404.18308v2#page=1) Against the most capable nation-state actors, or sophisticated physical attacks [Scher and Thiergart 2024, p. 16](https://intelligence.org/wp-content/uploads/2024/11/Mechanisms-to-Verify-International-Agreements-About-AI-Development-27-Nov-24.pdf#page=16) (quoted under ‘It leaves open’) > Note in particular that the implementation on NVIDIA’s Hopper chips is not intended to be robust against sophisticated physical attacks. [Harack et al. 2025, p. 50](https://aigi.ox.ac.uk/wp-content/uploads/2025/07/Verification_for_International_AI_Governance.pdf#page=51) Terms recorded for it in the documents (4) - device-specific public and private key pair - Unique secret keys - a chip’s private key - a private key for the chip The [hardware register](https://scrutica.com/verification/hardware) records which accelerators document an identity key. Each column is a report, by year; each row a mechanism; each mark is the report’s position and opens the page that states it. Select a mechanism’s name to list its positions with their pages.Columns are reports, by year; rows are mechanisms. Select a row to list its positions with their pages. - Proposes - Discusses - Mentions in passing - Argues against - Proposes, with an objection in the same report - Hardware identity key, selected on the stack flexHEG I–III: the three\-part report _Flexible Hardware-Enabled Guarantees for AI Compute_ (2025) Kulp et al. 2024, on what it proposes ([p. 58](https://www.rand.org/content/dam/rand/pubs/working_papers/WRA3000/WRA3056-1/RAND_WRA3056-1.pdf#page=69)): “We do not have sufficient confidence in HEM based solutions to recommend them for use, but we are confident that the topic warrants further research.”

Positions of 14 reports on the 50 mechanisms, each linked to the page that states it

Mechanism	Shavit 2023	Fist and Grunewald 2023	Egan and Heim 2023	Kulp et al. 2024	Aarne et al. 2024	Sastry et al. 2024	Heim et al. 2024	Brass and Aarne 2024	Scher and Thiergart 2024	flexHEG I–III, 2025	Kulp et al. 2025	Harack et al. 2025	Baker et al. 2025	Scher et al. 2026a
	Physical integrity
Tamper evidence	p. 7	Technical annex		p. ixp. 58	p. 2	p. 39			p. 69	I, p. 19	p. 12	p. 60	p. 20
Tamper response				p. 31p. 58	p. 2				p. 6	I, p. 7		p. 157	p. 6
Silicon root of trust
Hardware identity key	p. 9			p. 19	p. 14		p. 30	p. 17	p. 69	I, p. 7		p. 42	p. 20
Hardware integrity checks									p. 17	I, p. 6		p. 15	p. 6
Hardware root of trust	p. 13			p. 20p. 58	p. 3	p. 57		2025 brief, p. 3	p. 68	II, p. 41		p. 49	p. 3
Firmware integrity
Confidential computing	p. 13		p. 13	p. 19	p. 2		p. 30	p. 20	p. 6	I, p. 18		p. 2	p. 15
Guarantee processor									p. 5	I, p. 3		p. 53	p. 21
Multi-party authorisation						p. 5				II, p. 3
On-chip rule enforcement					p. 13				p. 29	II, p. 6I, p. 24I, p. 25III, p. 27			p. 13p. 5
Identity and attestation
Chip serial numbers	p. 7	Technical annex		p. 44p. 58	p. 15	p. 39		p. 7	p. 69p. 69	II, p. 25		p. 44		PDF p. 26
Hardware fingerprinting	No position in the 14 reports
Remote attestation	p. 8			p. 19p. 58	p. 3	p. 56	p. 30	p. 7	p. 69	I, p. 19		p. 48	p. 21	PDF p. 9
Workload attestation	p. 9			p. 47	p. 10	p. 41	p. 29p. 29		p. 6	I, p. 19	p. vi	p. 111	p. 4	PDF p. 23
On-chip governance
Delay-based location					p. 10			p. 4	p. 4	I, p. 19	p. vi	p. 52
Interconnect limits	p. 9			p. ixp. 58	p. 10	p. 5		p. 9	p. 5	II, p. 25	p. vi	p. 108	p. 59	PDF p. 32
Offline licensing				p. viiip. 58	p. 2	p. 55		p. 9	p. 28	II, p. 38	p. vi	p. 108	p. 21	PDF p. 47
On-chip compute metering				p. 32p. 58	p. 10		p. 28		p. 28	I, p. 18	p. 9		p. 42
Operating limits	p. 9			p. 35p. 58	p. 27	p. 54		p. 9	p. 25	II, p. 38	p. 11	p. 122		PDF p. 32
Remote disable				p. 37	p. 9p. 10	p. 5		p. 3		I, p. 33		p. 101		PDF p. 31
Unilateral backdoor				p. 38	p. 2
Verified shutdown									p. 25	I, p. 34		p. 105	p. 18	PDF p. 31PDF p. 34
Weight-snapshot logging	PDF p. 1				p. 12				p. 6	I, p. 26		p. 41
Off-chip and workload checks
Analog-sensor accounting						p. 26	p. 29		p. 26	II, p. 10		p. 61	p. 4	PDF p. 31
Capture-and-commit records	p. 9								p. 40	II, p. 34		p. 13	p. 57
Model evaluations									p. 39	I, p. 18		p. 16	p. 26	PDF p. 25
Network taps									p. 77	II, p. 13		p. 14	p. 3
Neutral data centre	p. 12								p. 26	III, p. 32		p. 13
Other location methods		Technical annex	p. 12		p. 5			p. 5	p. 71					PDF p. 48
Proof-of-training	PDF p. 1		p. 20	p. 47	p. 16	p. 41	p. 39		p. 85	I, p. 28		p. 104	p. 43
Provider-side accounting			p. 3			p. 38	p. 4		p. 5	II, p. 2	p. 10		p. 65	PDF p. 32
Vendor fleet telemetry	No position in the 14 reports
Workload classification	p. 9		p. 12	p. 37	p. 13	p. 5	p. 23		p. 26p. 93	II, p. 44	p. 9	p. 32	p. 32	PDF p. 6
Workload re-execution	p. 22p. 10				p. 35				p. 5	II, p. 14		p. 118	p. 26	PDF p. 31
Zero-knowledge proofs	p. 22p. 4					p. 58	p. 39		p. 116	II, p. 6		p. 80	p. 64
Institutional checks
Challenge inspection												p. 41	p. 32	PDF p. 21
Chip consolidation				p. 31					p. 4			p. 85		PDF p. 6
Chip registry	p. 6	Recommendation 1		p. 45	p. 3	p. 5	p. 34	p. 6	p. 15	III, p. 4	p. vi	p. 16	p. 14	PDF p. 26
Containment and surveillance	p. 13				p. 28		p. 20		p. 15	III, p. 11		p. 60	p. 32	PDF p. 31
Declarations and inventories						p. 38	p. 31	p. 8	p. 15	I, p. 31		p. 60	p. 3	PDF p. 26PDF p. 9
End-use checks		Recommendation 2			p. 9	p. 39		2025 brief, PDF p. 1	p. 136	I, p. 11		p. 95	p. 8
KYC for compute providers			PDF p. 1	p. 8	p. 31	p. 5	p. 21		p. 83			p. 115	p. 57	PDF p. 48
National technical means			p. 14			p. 25		p. 12	p. 15p. 142	III, p. 15		p. 10	p. 4	PDF p. 5
On-site inspection	p. 13	Technical annex		p. 28	p. 21	p. 77	p. 39		p. 4	III, p. 14	p. vi	p. 13	p. 52	PDF p. 6
Personnel interviews						p. 42			p. 46			p. 39	p. 4p. 29	PDF p. 6
Personnel monitoring									p. 75	III, p. 11		p. 11
Production monitoring	PDF p. 1					p. 74			p. 4	III, p. 4		p. 35		PDF p. 5
Sampled chip inspection	p. 2	Recommendation 1		p. 28	p. 2				p. 15	III, p. 12	p. 11	p. 41	p. 26
Training-run declarations	PDF p. 1		p. 11	p. 38	p. 2	p. 5	p. 17		p. 26	III, p. 25		p. 103	p. 2	PDF p. 5
Transfer reporting	p. 13	Technical annex				p. 39	p. 34	2025 brief, p. 3	p. 67	III, p. 14		p. 35	p. 26	PDF p. 25
Whistleblower programmes			p. 14			p. 71	p. 34		p. 46	II, p. 55		p. 39	p. 3	PDF p. 25

About the columns The columns are the reports named in Scrutica’s research brief, by year; the three flexHEG papers share one, as do the IAPS location report and its 2025 brief. Positions come from 34 documents: the 17 these columns hold, and 17 more that only the mechanism cards above list; 32 of them are among the 35 documents that state how mechanisms relate, and the other 2 state no relation. Three of the 34 were read in selected sections only. Each mark is one of the 123 published results, at its date, in the row of the hardest access it needed; a physical result is drawn in the cheapest band that holds the setup cost its source states. - Extracted an identity or attestation key - Forged attestation - Bypassed secure boot or rollback protection - Bypassed a performance limiter - Read or altered protected data - Hollow: partly verified against its sources - Ringed: TEE.fail, the result in the card Show results onAll platforms · 123Trusted execution environments in CPUs · 64GPUs and GPU systems · 29Trusted Platform Modules · 5Boot code and signing keys · 20Standalone security chips · 10 Show results on All platforms 123 resultsTrusted execution environments in CPUs 64 resultsGPUs and GPU systems 29 resultsTrusted Platform Modules 5 resultsBoot code and signing keys 20 resultsStandalone security chips 10 results Eight results are counted under two or more platforms and four under none, so the platform counts add to 128 for the 123 results. Previous94 of 123 results, in date orderNext Disclosed 28 Oct 2025 · IEEE Symposium on Security and Privacy 2026 #### TEE.fail Chuang et al., _TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition_ It extracted an identity or attestation key from Intel SGX and TDX, with privileged software and physical access; its source puts the equipment at $1,000 or less. Defeated Key extraction, forged attestation, integrity and confidentiality. Key taken Intel SGX and TDX: Intel’s device-specific Provisioning Certification Key, from its Provisioning Certification Enclave. In the stack Breaks Hardware identity key, on Intel SGX and TDX; Remote attestation and Confidential computing, on the platforms listed as affected. The stack’s parts are generic and do not distinguish vendors. Show what fails with them Scrutica’s inference (no source states it): it also bears on Delay-based location, Workload attestation and On-chip compute metering. Platforms (3) - Intel Xeon Scalable 4th/5th Gen and Xeon 6 with DDR5 (TDX, SGX); attack demonstrated on 5th Gen Xeon Scalable - AMD EPYC Zen 4 and Zen 5 with SEV-SNP and DDR5 (authors’ statement); attack demonstrated on Zen 5 with Ciphertext Hiding - Relayed, no key taken: NVIDIA Confidential Computing attestation (H100) as consumed by dstack-based applications The keys it extracts are Intel’s, from SGX and TDX machines. NVIDIA’s attestation, as dstack-based applications consume it, was relayed from GPUs the attackers did not own: > Basically, the fact that Nvidia’s attestation reports are not bound to the identity of a specific CVM means we can ‘borrow’ Nvidia attestations from devices that aren’t ours. [tee.fail](https://tee.fail/), FAQ, Oct 2025 Quotations (6), all from the authors Needed > Moreover, our attack can be done in under $1000 by computer hobbyists using equipment readily available on the secondhand market. [tee.fail](https://tee.fail/files/paper.pdf), p. 1, Sec. 1.1 > Performing the above steps on our target machine described in Section 3 in an UpToDate attestation status, our attack took about 2 minutes to create the ciphertext mapping, and 13 minutes to execute the PCE and trace the ECDSA signing. [tee.fail](https://tee.fail/files/paper.pdf), Sec. 6 Defeated > More specifically, we break SGX and TDX security guarantees by extracting attestation keys from machines in a fully trusted UpToDate attestation status. [tee.fail](https://tee.fail/files/paper.pdf), p. 2, Sec. 1.1 Key taken > Combining this observation with Intel’s use of deterministic AES-XTS encryption, we are able to use our memory interposition setup to break the confidentiality of the PCE enclave, extracting its Provisioning Certification Key (PCK). [tee.fail](https://tee.fail/files/paper.pdf), p. 2, Sec. 1.1 > The PCE derives a device-specific provisioning certification key (PCK) via EGETKEY on a root provisioning key and CPU version info. This PCK is a 256-bit ECDSA key and is used to certify the QE’s identity and its attestation key. [tee.fail](https://tee.fail/files/paper.pdf), p. 9, Sec. 6.2 > As TEE.fail does not directly attack any Nvidia CC elements, there are no mitigations from the Nvidia CC side. In answer to Are there any mitigations? How do I protect myself with Nvidia CC? · [tee.fail](https://tee.fail/), FAQ, Oct 2025 Vendor responses (3) > This most recent research, released in a paper titled ‘TEE.fail: Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition’, does not change Intel’s previous out of scope statement for these types of physical attacks. Intel · [intel.com](https://www.intel.com/content/www/us/en/security-center/announcement/intel-security-announcement-2025-10-28-001.html), 28 Oct 2025 > AMD does not plan to provide mitigations since physical vector attacks are out of scope for AMD SEV-SNP. AMD · [amd.com](https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3040.html), 28 Oct 2025 > Intel has indicated that it is impossible to issue a microcode to update the inner workings of the memory encryption engine. Intel, as reported by the authors · [tee.fail](https://tee.fail/files/paper.pdf), Oct 2025 NVIDIA: no public statement found as of 7 October 2026. #### Identity and attestation keys extracted, by family of security hardware A family is counted when a verified result has extracted a device-unique key that the hardware uses to prove its identity or attest its state. - Identity or attestation key extracted, verified - Partly verified, so not counted - A result on GPUs or GPU systems - AMD Secure ProcessorInsecure Until Proven Updated 2019, One Glitch to Rule Them All 2021 and MilanLaunchy + BadFuse 2026. - Intel CSME and PTTTPM-Fail 2019. - Intel SGX and TDXForeshadow 2018, SGAxe 2020, ÆPIC Leak 2022, Battering RAM 2025, WireTap 2025 and TEE.fail 2025. - RISC-V KeystonePhysical Memory Please 2026. - NVIDIA’s data-centre GPUs (Hopper, Blackwell). No published extraction of an identity or attestation key. Searches for attacks on H100-class confidential computing and for GPU attestation-key extraction last ran on 7 October 2026, and none of the 29 results the record holds on GPUs and GPU systems extracts one. Not counted: 3 partly verified, 2 other kinds of key, 6 other families Partly verified - Intel CSME and PTT · Intel CSME boot-ROM IOMMU window 2019. - Intel SGX and TDX · SGX.Fail 2022 and Intel SGX Fuse Key0 extraction on Gemini Lake 2024. Other kinds of key from the four families - AMD Secure Processor · Google Project Zero / Google Cloud security review of the AMD Secure Processor 2022 (part of an identity key: parts of the SEV Platform Endorsement Key’s private ECDSA scalar). - Intel SGX and TDX · Downfall 2023 (another kind of key: an SGX sealing key from a test enclave, with no attestation key decrypted). Families with no counted extraction - Google Titan M · Attacking Titan M with Only One Byte 2022 (another kind of key: keys protected by StrongBox, with no statement that the device attestation key was among them). - Infineon security controller · EUCLEAK 2024 (another kind of key: one account’s FIDO credential key, with no report that the attestation key was extracted). - NXP secure element · A Side Journey to Titan 2021 (another kind of key: a per-account FIDO credential key). - Raspberry Pi RP2350 · Antifuse OTP secret extraction by focused-ion-beam passive voltage contrast 2025 (no whole key: the bitwise OR of two adjacent antifuse rows). - Samsung TrustZone Keymaster · Samsung TrustZone Keymaster key extraction 2022 (another kind of key: hardware-protected keys of Android apps, among them the private key of a FIDO2 WebAuthn credential). - STMicroelectronics TPM · TPM-Fail 2019 (another kind of key: an ECDSA signing key of no stated kind). The quotation each family is counted on (4) - AMD Secure ProcessorUsing this patched SEV firmware, we extracted the SEV state, see Section 3.1, including the CEK private key of three different AMD Epyc CPUs.Insecure Until Proven Updated 2019, [arxiv.org](https://arxiv.org/pdf/1908.11680), PDF p. 7, Section 3.3 - Intel CSME and PTTWe generated a unique ECDSA attestation key (AK) using the Intel fTPM device on the VPN server.TPM-Fail 2019, [usenix.org](https://www.usenix.org/system/files/sec20-moghimi-tpm.pdf), p. 2067 - Intel SGX and TDXUsing Foreshadow we have successfully extracted the attestation keys, used by the Intel Quoting Enclave to vouch for the authenticity of enclaves.Foreshadow 2018, [foreshadowattack.eu](https://foreshadowattack.eu/) - RISC-V KeystoneUsing this primitive, we demonstrate end-to-end attacks on the popular RISC-V Keystone TEE, achieving full enclave memory disclosure and, ultimately, completely undermining remote attestation guarantees by extracting the long-term platform measurement key.Physical Memory Please 2026, [ojs.ub.rub.de](https://ojs.ub.rub.de/index.php/uASC/article/download/12712/12391/16024), Abstract About the record (5 results left off) 123 published results from 122 publications, each placed by the hardest access it needed; 25 are only partly verified. Five more in the record are left off: four defeat no stated property, and one could not be verified.