Confidential Computing for Cloud Data Protection-Dr Jekyll or Mr Hyde?
- Denisse Soker
- 4 minute read
Within every typical cloud adoption plan, migration of sensitive workloads is something organizations tend to put on hold. This is no surprise, given the fact that such projects tend to raise severe and complex security challenges. In order to accelerate the migration of this type of workloads cloud service providers have been recently offering, in addition to data encryption at rest and in transit, protection of data-in-use, by isolating computations to a hardware-based Trusted Execution Environment (TEE). This technology has recently gained recognition by Gartner and was categorized in their most recent Hype Cycles as Confidential Computing. In this blog post we will take a closer look at confidential computing, while analyzing the advantages and challenges for organizations that want to use it to protect their data in the cloud.
The Confidential Computing Crown - TEEs
TEEs provide a secure environment, where the code is validated and executed, while all memory and resources are isolated from all other components. Since the code that runs in the Trusted Execution Environment is signed, there is no way to modify it without signing it again. The encryption key is stored in a safe environment called "root of trust" within the TEE.
Some of the CPU manufacturers - like Intel and AMD - have bet on this technology as the “next-gen” of data security and developed their own hardware based TEEs. Intel’s TEE technology is based on the secure enclave called SGX (Secure Guard Extension). SGX is an extension of the CPU instruction set. It allows user-level as well as operating system code to define private regions of memory (enclaves), whose contents are protected and unable to be either read or saved by any process outside the enclave itself, including processes running at higher privilege levels. SGX involves encryption by the CPU of a portion of memory. The enclave is decrypted on the fly only within the CPU itself, and even then, only for code and data running from within the enclave itself. The processor thus protects the code from being "spied on" or examined by other code.
Data Encryption for Cloud Computing - with TEEs
Traditionally cloud service providers offered a variety of security solutions for securing data in transit and at rest, but the processing of the data was still performed in plain text. Enterprises that have substantial experience and have migrated most of their workloads have been taking advantage of these services. However, in order to finalize cloud adoption projects - the need to handle the security challenges sensitive workloads impose has to be resolved.
To provide a solution for these sensitive workloads, cloud providers started offering TEEs and confidential computing solutions to enable their customers relatively independent management of their own environments. The confidential computing offering is relevant on IaaS (Infrastructure as a Service) only, which is the only model in which the client has autonomous control of their entire environment, up to the instance level.
How TEEs are used by applications
One of the key considerations to keep in mind when evaluating TEEs, is the need to change application code, so that the sensitive processes will run on the TEE of the CPU. For example, to use the SGX instruction set, you would need to modify the code at some points of the data flow to call the SGX's APIs - this way, sensitive data will be processed in the secure enclave only. After making these modifications, the code will have to be recompiled.
To alleviate this burden, new frameworks arised - those intent to offer the ability to connect to APIs without the need to recompile the code, as it uses a standard compilation. This reduces the overhead to some extent since recompiling the code would require changes to the CI/CD and testing environments - but it doesn’t completely solve the original pain.
Multi Cloud Data Encryption and Confidential Computing Challenges
Although confidential computing sounds like the perfect solution for protecting sensitive data in the cloud, it still poses some challenges.
- Development overhead – TEEs is not a good solution for applications that could fit a "lift and shift" cloud deployment. You cannot simply migrate an application that is running in your datacenter to the cloud as it is. As mentioned before, to support TEEs there is no choice but to re-architect the application. Although one could argue that moving any application to the cloud requires some sort of "re-architecture" effort, the code changes required to implement TEEs add considerable overhead to the development efforts.
- Limited support for third-party applications – modifying, recompiling, and re-architecting your own application is one thing, but what happens if your application uses third-party solutions or if you want to move your third-party applications to the cloud? You simply can't re-architect or modify a third-party application and therefore the ability to use TEEs relies on the willingness of the said third party to to support the same TEE frameworks that your cloud service provider supports.
- Limited "regions" support – TEEs are not yet supported across all regions. You should check if the regions that are important to your deployment, whether it's for availability reasons or due to privacy regulation, are supported.
- Security – as a relatively new technology, TEEs still suffer from security vulnerabilities that have been detected and reported. Here are some of many examples of these reports. One of the latest examples is the SGAxe attack - designed to specifically retrieve data from Intel processors. Other less recent examples are ROP vulnerability and Load value injection attack.
- Cloud lock-in – not all cloud providers support the same TEE technology and related frameworks. This means that you can migrate between cloud providers that use the same technology, but you will not be able to migrate the TEE connected application to a cloud provider that uses a different framework without introducing substantial changes to your application.
As the cloud matures, we are seeing cloud service providers increasing their efforts to enable the accommodation of more sensitive workloads. As we've seen, hardware-based confidential computing still has its challenges and "growing pains". However, the concept of protecting data "in use" or “in memory” is not limited to hardware-based confidential computing. In fact, there are new technologies in this field that perform end-to-end encryption (including "in-use" and “in memory”) without any development overhead, while ensuring that the encryption keys never leave the organization's domain.