Survey argues TEE attestation breaks can expose enclave secrets
Original title: It's time to talk about TEEs
Cited DRAM and memory attacks extracted SGX attestation keys and produced false AMD SEV-SNP reports.
A blog surveys attacks on trusted execution environments and argues operators should reconsider storing valuable secrets in TEEs. It cites enclave bugs, including Signal contact-discovery memory-safety issues, plus remote-attestation forgery against Intel SGX, AMD SEV-SNP and related platforms. Named work includes Foreshadow, SGAxe, ÆPIC Leak, BadRAM, WireTap, TEE.fail, Battering RAM and DDRrop. The author says pinning verifiers to one's own PCK certificates is a limited mitigation and that denial of service is outside several TEE threat models.
Unconfirmed: Several breaks are research demonstrations; current attacker use is not stated.
- WireTap authors say they extracted SGX attestation keys and broke Secret Network, Phala, Crust and IntegriTEE.
- BadRAM uses a tampered DIMM SPD chip, described as about $10 to reprogram.
- DDRrop is described as a DDR5 interposition attack that drops writes.
- The post says a break of one Intel CPU can affect any CPU in good standing.
Impact: Attestation-key theft and false remote attestation of enclave code
| Product | Affected |
|---|---|
| Intel SGX | — |
| AMD SEV-SNP | — |
| Intel TDX | — |
- 1.Pin scalable SGX verifiers to your own PCK certificates if that matches your deployment.
- 2.Avoid placing valuable secrets in TEEs when physical attacks are in scope.
From the original article
5 min read at alinush.github.ioThe goal is to persuade you to re-consider how you deploy TEE-based applications, if you should deploy them at all. Trusted hardware companies (Intel, AMD, etc.) mainly compete on performance, functionality and (one hopes) developer-friendliness.
By alinush.github.io via zk · alinush.github.io
A short excerpt; the article and its images belong to the publisher. Summary, key facts and assessment above are AI-written from the article and can be wrong.