# Confidential Computing
source: https://developer.mastercard.com/blog/confidential-computing/index.md

Authors: Sebastien Le Callonnec. In this post we're going to talk about Confidential Computing, which is a Privacy-Enhancing Technology (PET). It is part of a series on Data Responsibility, and if you haven't already done so, I'd recommend you read the first part of the series: Introduction to Privacy Enhancing Technologies. We will look at what is confidential computing, and how it can be implemented to protect your data and your application. We will also look at the Attestation process, which is critical to the Confidential Computing guarantees. Finally, we will look at a small example using an Open-Source library called Occlum. What is Confidential Computing? The definition of the Confidential Computing Consortium is that "Confidential Computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment." Let's first look at the first part, protection of data in use. Up until recently, the industry only looked at two aspects of data protection: Data at Rest: records are routinely stored encrypted in databases/files. This is a requirement of PCI-DSS: personal information must be ciphered before being stored. So today we use encryption mechanism like AES to encrypt data, with keys safely stored in HSMs. Data in Transit: another important aspect of protecting data is making sure that records that move from one service to another, for example from your machine to a server, is secure, and encrypted. This has been done for years with TLS. All traffic between those two points is encrypted. But what about "data in use"? When records are being processed by an application, they are copied into memory, where they can be accessed by privileged users. You can see an example of how to do this in the walkthrough video at the end of this post. This is the problem that Confidential Computing is trying to solve; a problem that is especially relevant for teams that bring workloads to the Public Cloud, where they have no control over the infrastructure and the machines, and who accesses them. Here in the stack, where Kubernetes and Docker are used in a Cloud environment to deploy an application, any part can be tampered with: the underlying hardware can be swapped to fake some device; the host OS can be altered to simulate a system call and return incorrect values. Even at the top of the stack, your application is vulnerable to tampering: as you do not control the environment, you have no guarantee that the code that is currently executing is the one that has been shipped and deployed by the application teams. Confidential Computing uses a hardware-protected region of the memory, called an enclave, to deploy and execute your application, and providing the following guarantees: Data Confidentiality: the data used during processing is held in an encrypted region of the memory, and therefore cannot be accessed by anyone outside of that enclave, not even privileged processes. Data Integrity: Records used during the computation cannot be altered. No record can be deleted or added, and existing data cannot be changed. Code Integrity: the code that executes is the code written by application team, and it cannot be modified in any way. A Word on Hardware Before we get into more details about Confidential Computing, let's now look at the hardware, which is the second part I have highlighted in the Confidential Computing Consortium definition. What sort of hardware does Confidential Computing require? Our journey starts with a component called a TPM, the Trusted Platform Module. This is a computer chip that can securely store artefacts used to authenticate; it can contain cryptographic material like passwords, certificates, encryption keys, etc. and can be used to carry out cryptographic operations. This is used for example by UEFI Secure Boot to verify that the code launched by a computer at startup can be trusted. Another example of its use is Full Disk Encryption / BitLocker, which securely stores the key used to encrypt and decrypt data on disks in the TPM. HSMs, or Hardware Security Modules are secure appliances that are quite common in the financial industry. Their purpose is to store cryptographic secrets, but also perform cryptographic operations in a dedicated device connected to the network. There are different types of HSMs. Some of the most secure ones are used for payments, for example to protect customers' PIN. Secure Elements are chips that are designed to store secrets, such as PIN codes, passwords, etc. and prevent any access to them from any unauthorised party. It can execute a small number of applications which need to be pre-installed -- they cannot be modified once installed. Finally, Trusted Execution Environment is an isolated processing environment within a specific chip where applications can execute in a secure manner. It is usually an area in a processor isolated from the rest of the system, included the OS, which cannot access that area, regardless of the level of execution of that process. And this is what we are talking about here, as we look at Confidential Computing: we are looking at a hardware element capable of executing tasks in a completely secure area, with data protected in memory using encryption. Examples of this are the Intel SGX or AMD EPYC processors. How to make an application confidential? When building Confidential Computing application, there are two different approaches: The first approach is to use the SDK provided by the processor provider, such as the Intel SGX SDK. This allows you to write natively applications that will execute within an enclave, completely protected from the rest of the application; The second approach is to convert an existing application into a package that can be executed as a confidential computing application. The first approach consists in separating your application into 2 parts: the part that will execute within the enclave, and the rest which executes normally and interacts with the first part. This allows you to define very precisely which sections of the application needs to be secured, which gives you more control and granularity, therefore better performance and resource management. The downside is that it requires specific skills to understand the model and be able to implement this kind of applications. The second approach is a "lift and shift" approach: it converts an existing application into a fully Confidential application that can be executed in an enclave. This is a simpler and faster approach to make an app confidential with little to no change, but there is a performance impact to running the whole thing in the enclave. Going into more details, the first approach typically requires to use of an SDK or a library provided by the processor provider. The SDK usually uses a system language such as C, C++ or Rust, and makes you define: The entry points into the confidential application: these will be the only way to interact with the application that runs within the enclave; The actual logic being executed within the enclave. The entry point can then return data to the original application. But how can the "untrusted" part of the application be sure that it is calling a truly "trusted" part of the app, and not something that pretends to be a "confidential" application? This is done through the process of attestation, which we'll be looking at later. The other approach relies on a layer between the application and the enclave to be able to execute as a confidential application. A common approach is to use something called LibOS, a library that behaves as an OS from the application perspective and is responsible for performing all the actions to create the enclave, inject data and code, and execute securely within that enclave. This is a particularly appropriate approach when executing an application in a Docker container, as you just need to wrap your application, so it executes with the LibOS inside the container. Therefore, the application itself does not change; it is merely an additional part of your application packaging. This fits very well within a CI/CD model, where, as separate steps, you can make your application "confidential" and then verify measurements and attestations once deployed. What is attestation? Now that we have seen what a Confidential Computing application is, and how to make an application confidential, the next question that we need to answer is: how I can be sure that an application is indeed running within a secure enclave, protected by hardware. The answer to this question is attestation which is a mechanism whereby a remote use can verify that an application runs on real secure hardware, with up-to-date firmware, with the expected code, and in the expected initial state. There are two types of attestation: Local Attestation: this is performed when two enclaves are running on the same machine and want to exchange data and secrets. Remote Attestation: this is where the Attester entity produces details about itself that are shared with another entity ("Relying Party") through an Attestation service. The Attestation service uses cryptographic methods to verify the details produced by the Attester. For example, Intel SGX uses two different protocols for remote attestation: Enhanced Privacy ID (EPID) and Data Center Attestation Primitives (DCAP). EPID is the original Intel attestation used to attest an enclave, while keeping its identity private, by using a group signature scheme. DCAP on the other hand is more common in Data Centres environments, as it relies on Intel infrastructure only during the initial setup -- data centres can own their own attestation infrastructure, without the need to rely on external services. Tools to implement Confidential Computing There are few products that can be used to make an application confidential. They are usually built upon the primitives provided by the Trusted Execution Environment (TEE) processors providers. They facilitate the packaging of existing applications into confidential containers, ready to be used on a TEE-enabled infrastructure and produce and verify attestation. Our example uses an Open-Source library called Occlum, a LibOS solution built on Rust. Now let's see all this in action with a real example. This is a simple Spring Boot application that encrypts a string. I will show how to dump the memory to uncover the secret used in the encryption. Then I will wrap the application using the open-source library Occlum and try to dump the memory again. Downsides of Confidential Computing We have seen the benefits of using Confidential Computing; namely that the data and code execute in a hardware-protected enclave, therefore preventing any tampering, but also ensuring that the data in use cannot be accessed by an unauthorised party -- including a superuser. Like in every technology, there are also downsides to it. The first thing to understand is that, while the technology is now relatively mature, there are still vulnerabilities affecting the hardware or its firmware that are continuously discovered. Attacks like side-channel attacks have been performed in the past, by observing the effects of the execution of a program and learn secrets indirectly. While highly complex to perform, these attacks are still possible, and may be more difficult to remediate, given that these may affect hardware and associated firmware. This leads to the next issue, which is vendor lock-in. While some of the products we have seen claim that they are vendor-agnostic, by the very nature of Confidential Computing specific hardware is required, which cannot be easily changed, and usually requires specific firmware, SDKs etc. upon which the various products are built. Performance can be an issue, especially if the application you are running within the enclave (including LibOS) is large. In this instance, it may require some changes to the code to isolate the more sensitive part from the rest of the application and only execute the sensitive part within an enclave. This is good engineering practice, and I highly recommend this approach in any case. It is worth noting that while Confidential Computing protects data and code, it assumes that the code execution itself does not do anything to compromise that data, maliciously or by mistake. If the code is compromised before it even gets deployed to a secure enclave, it could find ways to leak or alter that data, which defeats the whole purpose of Confidential Computing.