Recent research on Intel and AMD TEEs falling to cheap physical interposers exposes practical weaknesses in enclave security: Battering RAM uses a sub-$50 DDR4 interposer to rewrite encrypted memory on the fly in Intel Scalable SGX and AMD SEV-SNP, even extracting SGX’s provisioning key; WireTap taps the DDR4 bus and recovers an SGX ECDSA attestation key, letting attackers forge quotes that verify as genuine. Chip vendors have long treated hands-on-the-board attacks as “out of scope”, but that’s exactly the scenario cloud and custody systems hoped TEEs would address.
Signing checks beyond enclave isolation
The boundary is wrong
A TEE isolates code from the OS, while verifying the intended transaction still requires checks across the UI, RPC stack, and interface between the host and enclave. Classic work on Iago attacks shows how a malicious kernel can steer a ‘protected’ app by feeding it crafted syscall results. SGX-specific work on controlled-channel page-fault tracing and ECALL/OCALL interface side-channels reinforces the point: the interface itself leaks and can be abused. A malicious host can still misrepresent the transaction presented for signing.
Repeated integrity and attestation failures
SGX and friends have seen repeat “break-glass” moments that cut to integrity and attestation: Foreshadow/L1TF pulled secrets out of L1 cache and undermined attestation, Plundervolt induced faults via software undervolting to recover keys, and SGAxe (with related CacheOut) recovered attestation keys and forged quotes. The new Battering RAM PDF and WireTap’s write-up extend that record with cheap hardware on the memory bus.
Most real losses come from signing the wrong message
The ".5B Bybit theft was a supply-chain + UI job: malware and build-pipeline tampering changed what signers saw and approved. NCC Group’s analysis describes how the transaction approval view was manipulated; multiple summaries point to Safe’s frontend code being altered. Ledger Insights reports the same: contracts were unaffected; the UI was compromised. Preventing this kind of tampering requires independent transaction verification.
“Attacks at the TEE interface” are everyday reality
- Iago: untrusted syscalls drive trusted code into bad states.
- Page-fault tracing: the OS learns enclave control flow deterministically.
- ECALL/OCALL side-channels: interface size/timing patterns reveal sensitive inputs.
All three live right where a signing app would parse, assemble, and confirm call data.
Hardware wallets beat TEEs on one crucial point: a trusted display
If you’re approving value, verify on the device. That\u2019s the whole idea behind Ledger’s “clear signing” and the persistent warnings about blind signing: treat the computer as hostile, and only trust the secure screen. If your device can\u2019t parse and show human-readable details, don’t approve high-risk calls.
The right foundation: smart accounts with onchain, pre-execution checks
Moving intent checks onchain makes each submitted transaction subject to contract-enforced policy even if the UI misrepresents it.
- Account abstraction (ERC-4337) lets your account run custom verification logic for each
UserOperationthe policy runs before value moves. Bundlers simulate validation and reject ops that fail; clients are expected to skip anything that fails sim. - Guards and policy modules on Safe can enforce allowlists, rate limits, “no
delegatecall”, upgrade approvals, and other rules at execution time.
The account rejects transactions that violate its policy, such as a call to an unapproved contract, a disallowed function, or an amount above the limit.
“Weren’t Safe contracts hacked?”
There is no confirmed exploit of Safe’s core Solidity contracts. The Bybit case was a front-end/supply-chain compromise that changed what signers approved; Safe emphasized that contracts were unaffected.
What to do today
- Use smart accounts for treasuries and ops; turn on policy guards and keep high-risk calls behind thresholds. Start with ERC-4337 wallets or Safe guards.
- Multiple independent signers + hardware wallets, and always read the device screen. Avoid blind signing for anything that moves real money. See Ledger on clear signing.
- Assume the UI can lie. For large transfers, confirm callData on an explorer or a second interface before approval, as the Bybit incident illustrates.
- Lock down delivery and dev access. The Bybit kill chain ran through developer workstations, tokens, and build artifacts. Read the broader supply-chain analyses from CSIS and Elastic Security Labs.
TEE uses and limits
TEEs can reduce server-side data exposure in some setups, while intent needs separate checks and attestation remains exposed to attacks ranging from Foreshadow to Plundervolt to SGAxe and now Battering RAM and WireTap. For transaction signing, onchain policy provides execution checks that complement enclave isolation.
PS: What we’re building at OKcontract
We’re building a fully onchain pre-execution verification layer for smart accounts: policy checks run during validateUserOp, using Safe guards or modules. That makes the system resistant to frontend lies and single-key compromise; the chain enforces the rules during execution.