I counted more than a dozen other organizations providing assurances that were similarly confusing, misleading, or false. Even Moore—a security veteran with more than three decades of experience—told me: “The surprising part to me is that Intel/AMD would blanket-state that physical access is somehow out of scope when it’s the entire point.”
In fairness, some TEE users build additional protections on top of the TEEs provided out of the box. Meta, for example, said in an email that the WhatsApp implementation of SEV-SNP uses protections that would block TEE.fail attackers from impersonating its servers. The company didn’t dispute that TEE.fail could nonetheless pull secrets from the AMD TEE.
The Cloudflare theft protection, meanwhile, relies on SME—the engine driving SEV-SNP encryption. The researchers didn’t directly test SME against TEE.fail. They did note that SME uses deterministic encryption, the cryptographic property that causes all three TEEs to fail. (More about the role of deterministic encryption later.)
Others who misstate the TEEs’ protections provide more accurate descriptions elsewhere. Given all the conflicting information, it’s no wonder there’s confusion.
How do you know where the server is? You don’t.
Many TEE users run their infrastructure inside cloud providers such as AWS, Azure, or Google, where protections against supply-chain and physical attacks are extremely robust. That raises the bar for a TEE.fail-style attack significantly. (Whether the services could be compelled by governments with valid subpoenas to attack their own TEE is not clear.)
All these caveats notwithstanding, there’s often (1) little discussion of the growing viability of cheap, physical attacks, (2) no evidence (yet) that implementations not vulnerable to the three attacks won’t fall to follow-on research, or (3) no way for parties relying on TEEs to know where the servers are running and whether they’re free from physical compromise.
