TEEs were never the answer for signing blockchain transactions

The splashy piece on Intel and AMD TEEs falling to cheap physical interposers isn’t a plot twist so much as the epilogue. Two fresh results show why: 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.

Why TEEs don’t fix transaction signing

The boundary is wrong

A TEE isolates code from the OS. It doesn’t guarantee that the thing you sign is the thing you meant to sign. The untrusted path — UI, RPC stack, and host — enclave interface — remains wide open. 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. Keys fenced inside an enclave don’t help if the host lies about what’s being signed.

The track record isn’t comforting

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 just extend that line — now 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, not a failure of the Safe contracts. Ledger Insights reports the same: contracts were unaffected; the UI was compromised. TEEs don’t stop any of that.

“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

You don’t fix signing by burying a key deeper in silicon; you fix it by moving intent checks onchain so a lie in the UI can’t bypass policy.

• Account abstraction (ERC-4337) lets your account run custom verification logic for each UserOperation the 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 more — at execution time.

If a transaction violates policy wrong target, wrong function, oversize amount — it won’t execute, even if malware dressed it up nicely in a browser tab.

“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 — the Bybit incident shows why.
• 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.

Where TEEs still fit — and where they don’t

TEEs can reduce server-side data exposure in some setups, but they don’t police intent, and their attestation chains keep taking hits — from Foreshadow to Plundervolt to SGAxe and now Battering RAM and WireTap. For transaction signing, the durable guarantees live on-chain in enforceable policy, not in opaque enclaves.

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, not the browser.