AMD Confidential Computing With Trusted IO

Confidential computing is a term you may have heard in the past, but it is also one that a lot of the industry is sleeping on. Many cloud providers are looking towards a world in the not-too-distant future where confidential computing is ubiquitous. While it is challenging to secure a computing environment to ensure the data brought into that environment is safe from even a cloud provider, it is even more challenging to expand that past the CPU motherboard and to AI and other accelerators. As such, it was time to get into confidential computing.

As a quick note: Confidential computing is an industry-wide effort, and needs to be. At the same time, we cannot go into every unique implementation of it, so instead, we are going to use AMD SEV-SNP for our examples since AMD is already powering many of the confidential computing cloud offerings and they are rapidly growing server CPU market share. We need to say AMD is sponsoring this.

Confidential Computing: Protecting Data in Use

When it comes to data security, most of us have been trained to think in two dimensions. We protect “data at rest” by encrypting it where it is stored. This can be on self-encrypting SSDs, in encrypted storage arrays, or encrypted by the application.

We protect “data in transit” by encrypting it between two endpoints. These days, virtually every website uses HTTPS. Inside large data centers, even network flows between machines are often encrypted as default behavior.

AMD Data At Rest In Transit In Use

Those two models are in many ways the easiest to accomplish, but they leave one big vulnerability, data while it is being processed and used by an application. If you take your data from storage and then want to use it, then it is usually decrypted and copies are stored in RAM and caches of a server. This in the industry is called “data in use” and traditionally, when being used data is completely vulnerable.

Confidential Computing With Play Money And AMD EPYC Large

In the video, we illustrated this with play money as a proxy for data (since data is a valuable asset). Data at rest would be like putting it in a safe while you are not using it. Data in transit would be like taking the money (data) and putting it into an armored truck so that it is not intercepted in transit. Data in use is like taking all of that money, putting it on a table at a coffee shop, and leaving it sitting there while you pay for your coffee.

As an industry, folks realized that they needed a solution, especially for industries with strict confidentiality and sensitive data. Better put, after data at rest and data in transit became standardized, the next step was the hard one. That step is figuring out how to secure data that needs to be decrypted for processing while it is being decrypted.

Enter the TEE

Fundamental to confidential computing is the TEE or Trusted Execution Environment. The idea behind the Trusted Execution Environment is to create a virtual machine environment where the customer of that environment knows that it is secure and has not been tampered with, before bringing data to be processed there. Maybe in our example above, this would be like storing your money (data) in a bank so that it could be used in the banking system without directly exposing it to passers-by who want to pilfer funds.

AMD SEV SNP Slide

AMD has its Secure Encrypted Virtualization (SEV) and the newer SEV-Secure Nested Paging (SEV-SNP) features. Intel originally thought Software Guard Extensions (SGX) was going to be the answer. That created enclaves for applications to use with sensitive data. The challenge was that it required software changes. Folks did not want to pivot the software they were running on to get confidential computing, so Intel now has its newer Trust Domain Extensions (TDX), which align more with industry principles. Arm has its Confidential Compute Architecture (CCA), which creates “Realms” as its secure enclaves.

This hardware-based TEE creates a secure enclave to protect both the code and the data inside it. When we say protect, that is not just from other virtual machines that may be running on the same system. Even the hypervisor and cloud provider are locked out. Getting to a TEE is not automatic.

That is where remote attestation becomes important.