Confidential Computing Explained. Part 2 : Attestation

Confidential computing explained:

Part 1: Introduction

Part 2: attestation

Part 3: data in use protection

I — Introduction

The previous article introduced the potential of Confidential Computing, with a global view to understanding how it helps handle sensitive data confidentially.

The above scheme used in the last article sums it up :

• The user encrypts the data using a key not known to the service provider
• They send the encrypted data to the service provider
• The service provider then uses an enclave on the data in a way that prevents the service provider from seeing the data in clear
• Finally, the transformed data is re-encrypted, and the encrypted result is sent back to the client

It may seem simple when presented like that, but as you can tell, many complex mechanisms work behind the scenes to make such a process possible.

This concept of handling data in a secured environment so that the service provider itself cannot have access to it thanks to hardware features. Such technology enables service providers to launch enclaves and load them with code while ensuring the confidentiality of the data manipulated inside the enclave. That way, data owners can be sure that the processed data is not clear and that it is not readable to third parties. You can find more details on that specific feature in our technical articles and documentation. What needs to be understood is that enclaves are similar to magic hats in that they allow data manipulation without the need to see them in clear.

We will here focus on one of the more important and valued core features of Intel SGX’s enclaves: code integrity with attestation.

II — The problem

Let’s now assume 3 elements: the enclave can handle sensitive data without the service provider being able to peek directly inside, there is a secured communication channel between the enclave and the user, and finally, the enclave applies a code provided by the service provider to process data.

With all this, a data owner can send, for instance, medical data securely to an enclave, it can be analyzed securely inside with an algorithm provided by a third party, and the result is sent back confidentially.
,
Then a few questions emerge:

• How can we know that someone is not saying they are using an enclave while they are not, to trick you into sending data to them while they will have access to it?
• How can we know that there is no backdoor in the code loaded inside the enclave? Indeed, this is the actual Garbage In, Garbage Out; if I put malicious code inside a secure environment, I am still able to leak data.

To answer these issues, Intel provides an ingenious mechanism: code attestation. This process allows anyone external to the platform hosting the enclave to verify that he is talking to a genuine enclave hosted in an infrastructure outside, for example, in the Cloud, and that this enclave has the right code loaded inside.

III — Attestation

Following on from the ring and the magic hat analogy. Now, the magician wants to handle his client’s ring using a magic hat, but he would like to guarantee that his client's belongings are protected at all times. To handle the ring in such a way, the magic hat must be used on top of the sealed box containing the ring that customers will send. Then, the question is, how can such a magic hat be crafted?

To create such an authentic magic hat, the magician needs a very specific felt: Intel Magic Felt. The only hats considered magic hats are crafted using Intel Magic Felt. These felts are provided in packs; each pack has a special component only known to Intel which makes each felt pack unique.

Consequently, the magician will purchase Intel Magic Felt packs and design tailor-made hats to match the needs of their clients. At the end of the production line, the magic hat is tagged on a small ticket. This ticket attests to the material used, as well as the doings of the hat once placed on objects. As the felt is an Intel Magic Felt, it is labeled with a proprietary signature only Intel can grant. That way, other felt manufacturers cannot replicate Intel’s label. This was made possible thanks to Intel-specific components included in each felt pack.

As a result, anyone who wants to make sure that their magic hat is an actual magic hat simply needs to ask Intel. Then, Intel will provide them with the following information:

• Whether or not the hat was shown to them is made with Intel Magic Felt
• If yes, what the magic hat does. Hats crafted with magic felt are unique and are specifically labeled with their dedicated tasks.

One key step for service providers is convincing their customers that they indeed use the right magic hats to handle confidential belongings. The process is the following:

1. The label of the magic hat that will be used on the user's belongings will be provided by the service provider. Note that those are not forgeable by the service provider thanks to specific properties of the magic felt.
2. This label will then be sent to Intel by the user to verify its authenticity.
3. Intel determines whether or not the label of the hat is associated with a genuine magic hat. Intel has a list of magic felt they have sold; that way, they know if a given magic hat comes from one of their felt production sites.
4. Only then the user can safely send his belongings to the service provider and be certain that the magic hat will only do what it is supposed to do.

Let’s imagine that in a malicious scenario, the magician asks their clients to send their precious belongings to a fake or malicious magic hat. Then, even before anything is given to the magician, thanks to code attestation, we would be able to know that there’s a problem. It will tell us if it is a fake hat or if what it says does not match.

This analogy is very close to what happens with Intel SGX. In addition to hardware protection of enclave contents through memory isolation and encryption, tamper-proof secrets are written on the CPU to prove that an enclave is genuine.

In practice, the process is a little more involved than that. But, if you understand all this, it is already a great thing! So stay tuned because we will start digging into the technical details next!

Want to turn your SaaS into a zero-trust solution?