TEE: When “Trusted” Doesn’t Mean “Secure”

This article was written following last month BadRAM attack publication, which raised trust and data privacy concerns in the context of the growing adoption of cloud computing. Using a low-cost setup, the attackers were able to compromise the newly introduced integrity guarantees of AMD SEV-SNP. In this article, we explain Ledger’s position on Trusted Execution Environments (TEEs) and how we address their security vulnerabilities.

The Trusted Execution Environment (TEE) has emerged in recent years as a cornerstone of security models across numerous fields, from machine learning to cryptography. Yet behind this promise of trust lies a more complex reality. Despite their technological advancements, TEEs struggle to ensure their fundamental properties, confidentiality and integrity, especially when integrated into shared environments.

In the field of cybersecurity, attacks targeting SGX enclaves (Intel’s Software Guard Extensions) have almost become their own attack class. Nevertheless, significant efforts are being made to bolster these technologies.

---

What is a Trusted Execution Environment?

The definition of a Trusted Execution Environment (TEE) can vary depending on the audience or market. For some, it is merely an isolated, secure space for sensitive computations, while for others, it also includes peripheral mechanisms such as memory encryption or key management.

According to Wikipedia, a TEE is defined as “a secure area of a main processor that isolates sensitive data and critical computations from the rest of the system.” This definition emphasizes two fundamental aspects:

1. Confidentiality: Data processed within the TEE is protected against unauthorized access.
2. Integrity: The code executed and the results produced within the TEE cannot be altered by external entities.

Two Different Models: Enclaves vs. Securing Virtual Machines

There are two different models of TEEs: one focuses on running a process in an isolated enclave, while the other secures entire virtual machines.

• Intel SGX: Relies on a set of instructions to isolate a workload within a specific processor enclave. These enclaves, while effective for localized tasks like key management or cryptographic algorithm execution, are limited in size and exposed to architectural attacks such as Spectre and Meltdown.
• Intel TDX and AMD SEV: Focus on securing entire virtual machines by isolating and encrypting their memory. This approach is particularly suited for shared cloud environments but heavily depends on the secure management of encryption keys within the processor.

In summary, SGX targets localized and critical use cases, while TDX and SEV focus on securing large workloads in virtualized infrastructures.

---

Security Challenges

A Security Model Built on Complex Architecture

Who hasn’t heard of Spectre or Meltdown? These spectacular attacks exploit the properties of microprocessors and are notoriously difficult to patch. Unfortunately, technologies like Intel SGX/TDX or AMD SEV, which are fundamentally tied to processor architecture, are not immune to such vulnerabilities.

The CPU Is Not the Only Weak Link

These technologies rely heavily on traditional server architectures, which inherently include components like BIOS/EFI, RAM, and potentially even storage. These dependencies have not escaped the attention of security researchers. 

For example, the recently publicized BadRAM attack demonstrated that with less than $10 and a few minutes of physical access to a server, it’s possible to bypass SEV SNP security measures.

These flaws highlight the limitations of a model that relies on the processor and associated components to guarantee enclave security. This expanded attack surface provides additional opportunities for adversaries to exploit.

---

Ledger’s Position

In the realm of cryptocurrency wallet security, the stakes are exceptionally high: there is no margin for error. A single leak or malicious manipulation of cryptographic keys can lead to irreparable losses for users.

Ledger’s Choices: Security Above All

At Ledger, we bet on dedicated, non–shared and programmable hardware for all critical operations:

• For institutional solutions (Ledger Vault): We use Hardware Security Modules (HSM) that provide a secure, provable environment with advanced physical security properties, compliant with FIPS 140-2 Level 3 certification.
• For consumer wallets (Nano, Stax, or Flex): We exclusively use Secure Elements with EAL6+ certification for the most recent models.

In addition to dedicated hardware, the programmability of our hardware also allows us to control the attack surface by developing a dedicated Operating System (Ledger OS) for security and cryptographic operations.

A Divergence From Other Institutional Actors

Some institutional wallet solutions promote their partnerships with cloud providers to secure cryptographic keys. While this may appeal commercially, here are their main arguments:

• Compatibility Arguments: Some justify these partnerships for their flexibility and independence from specific technologies. This is particularly relevant in virtualization-based TEE models, such as those offered by AMD SEV or Intel TDX.
• MPC Security: While we welcome efforts to use cryptography to strengthen security aspects, it still requires a TEE. Indeed, unfortunately, MPC remains fallible to collusion between different parties.

---

Conclusion

While TEEs represent a significant advancement in secure computing, they are not a silver bullet. The complexity of processor architectures, coupled with vulnerabilities in associated components, creates opportunities for attackers to bypass these protections. For industries like cryptocurrency, where the consequences of failure are irreversible, the reliance on TEEs in shared environments (generally cloud based) introduces risks that cannot be ignored.

At Ledger, our approach prioritizes dedicated hardware solutions to ensure the highest level of security for critical operations.

---

Vincent Bouzon (Twitter / LinkedIn)
Director of Product Security at Ledger Donjon