This blog takes a log of the current state and the future of confidential computing and how it will change our perception of secure computing.
Executive summary
As like the opening image, companies rightfully guard their secrets like a 3 headed dog. Especially when it comes to implementing regulatory requirements. They not only fear the public perception when they lose personal information they are also liable for such incidents. This makes adding services in a public cloud extremely challenging. This is why most insurances and banks (regulated companies in general) tend to keep it all in a private cloud.
Within this context Confidential Computing is another buzzword getting more and more attention. With it Cloud, Hardware and Software providers have come together to enable the secure execution of applications and its data in a cloud environment.
Through the separation of responsibility of those 3 parties it is easier to trust this secure execution and to prove it to the regulators. How this works is explained in the rest of this article.
Let us now assume that it protects the execution of services in the cloud. What does it mean for the companies? They can now treat a public cloud environment with enabled confidential computing like an extension of the on premise data centers. Service can be offloaded into the cloud on a consumption based model. Services, if they support confidential computing, in the cloud can be used with no difference. So for example you can run an AI model for example one which detects fraud using the CPUs and the GPUs in the cloud. No need to add GPUs to your data center.
With a spreading support of confidential computing to more and more cloud environments the usage of it becomes generally available. This will lead to a more basic decision of using confidential computing for all your services. It will become the new standard in how cloud environments and maybe even your on premise data centers are operated.
Data needs protecting
Up to now in the good old days where there were only on premise data centers, you had all the necessary information. You knew where the server was located and you also knew who holds the key to the server room and who can administer that server and the applications running on it. But in the cloud age you have given this right to the cloud provider. But who tells you that they are as trustworthy as your own employees and are not forced to do something by a third country agency or party? So there is a need to secure data while it is outside of your area of influence.
When we are looking at how data is used we have 3 states of data. We need to have a look at those 3 states to make sure that in each of those steps data is secure.
- Data at rest: When data is saved to a file and a file it needs to be encrypted so that no one can access its content. There are methods available to do this today.
- Data in transit: When data is transferred or loaded into an application here also it needs to be secured so no one can access it. You can encrypt the communication channel and or the payload in that channel. Again there are methods to do this today.
- Data in use: So when the application code is executed and data is used during the execution it needs to be ensured that that data or the application logic cannot be tempered with. Here comes confidential computing into play.
Data in use and confidential computing
So how do you secure data in use? This is your application running on a system in a cloud environment. The data per se is not protected. There are many ways to access this data. But for example a cloud administrator can force a memory dump and then is able to read what currently is in the area of memory. To protect this information the memory needs to be secured or hidden, so that no one can see and interact with it. Here is where the hardware providers come into play. They created CPUs which have a confidential computing extension. Of those Intel and AMD offer the most versatile fields of usage as they are used within the public cloud and within on premise data centers equally. There are also others like AWS, ARM and IBM processors who are used in either one or the other* and with this it makes it harder for the software providers to support them.
The confidential enabled CPU provides a Trusted Execution Environment. This area has special protection by a specialized API and hardware mechanisms. In this environment only authorized code can be executed. The code and data is encrypted until a cpu owned decryption key is made available. Only when the access to it is attested/authenticated then that key is provided and the whole memory area is hidden from the outside. So no administrator or outside code can interact with it and with it making it secure.
Trusting a confidential computing environment.
We have had a look at the hardware specific part. Now when we use such an environment, we still have to trust the cloud provider to switch this environment on. But the goal is not to trust an external provider at all. How can this be accomplished?
This is done via Attestation. How does attestation work? For this have a look at the graphic below. It shows a very simplified sequence of steps in the attestation. For further information have a look at this: https://www.redhat.com/en/blog/understanding-confidential-containers-attestation-flow
- The Trusted Execution Environment (TEE) wants to decrypt a component it wants to start for example like a Pod. To get the decryption key it contacts The Key Broker Service. With this request it sends evidence created by the cpu which is signed by the cpu.
- The key broker service sends the evidence to the verifier which has data to compare the evidence to what is expected.
- It returns that this is authentic evidence and testifies that the TEE is running in a confidential environment.
- The Key Broker Services then requests the needed key.
- The Key management service returns the key.
- And the Key Broker Service returns that key to the TEE for it to decrypt the pod and start it.
So when the attestation of the evidence does not follow through then no key is returned to the TEE. The encrypted data cannot be read. No readable information is shared with the TEE.
One caveat is that as a client of the TEE most cloud providers will make a local attestation service available. But this again creates the need to trust that cloud provider. For this you need to implement a remote attestation service. This means that the Key Broker Service, the Verifier and the Key Management Service are on a different platform than the TEE. So for this you most likely need to have those services in your datacenter which make it easier to ensure safety. You can of course also separate responsibilities and share the secure information to different providers, one has the keys, another has the verifier and attestation service and the third has the Trusted Execution Environment so all 3 would need to work together to decrypt the information.
The outlook
So what does this mean for the IT infrastructure in the future?
Currently more and more CPUs provide a confidential commuting environment. And more cloud environments make those CPUs available. With the everlasting need to modernize compute environments this means in the not so far away future most will have support for confidential computing. Customers can decide if they would like to use those services most likely just by checking a box in the setup of their VMs. With this expected ease of use will come an extended use of this feature.
When we now look at current regulations the need to provide confidentiality in cloud compute environments becomes more a must have if you want to use the cloud environment at all. Have a look at the european Digital Operational Resiliency Act ( DORA ) here: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52020PC0595 Chapter II Section II Article 8 Paragraph 2
…”Financial entities shall design, procure and implement ICT security strategies, policies, procedures, protocols and tools that aim at, in particular, ensuring the resilience, continuity and availability of ICT systems, and maintaining high standards of security, confidentiality and integrity of data, whether at rest, in use or in transit.”…
The mentioned confidentiality of data in use can be implemented by different organizational ways. But using a standardized technical way like confidential computing will make the checking of regulatory requirements much easier. So there will be a move towards using those services.
And then even later if it is easy to use and you have the necessary remote attestation services in place why not use it all the time?
Summary
In this article you gathered a basic understanding of confidential computing. What attestation is and how important it is to implement a remote attestation service to become independent of the cloud provider.
So one question remains. What will happen then? Using services in the cloud will become less focused on the security aspect. As confidential computing can provide a standardized way to enable a secure protected environment the focus will shift towards a data centric view again.
Questions like: Where is the majority of my data? Is a partitioning of that data possible? Can I move those data partitions towards my compute environment? Or does the environment need to move towards the data?
In the end confidential computing is going to reduce the perceived complexity of using cloud services and fulfill the basic goal of cloud computing.
Providing a flexible, secure and user centric environment to provide better services to our customers and with it reach our business goals.
*= this is the current state as of the end of 2023 and might change within the next months / years.