When you run a workload as a VM, container or in a serverless environment, that workload is vulnerable to interference by any person or software with hypervisor, root or kernel access. Enarx, a new open source project, aims to make it simple to deploy workloads to a variety of trusted execution environments (TEEs) in the public cloud, on your premises or elsewhere, and to ensure that your application workload is as secure as possible.
When you run your workloads in the cloud, there are no technical barriers to prevent the cloud providers–or their employees–from looking into your workloads, peeking into the data, or even changing the running process. That’s because when you run a workload as a VM, container or serverless, the way that these are implemented means that a person or software entity with sufficient access can interfere with any process running on that machine.
There are other concerns to consider, as well. Not only do you need to trust the public cloud provider and their employees, but all of the software that’s running on their systems, because if it is malicious, or compromised, then other people or entities could be looking at or interfering with your workloads. You must trust the operating system, firmware libraries, hypervisor, application stack, third party libraries, middleware, drivers: everything on each system needs not to be malicious or compromised.
Of course, there is generally little incentive for public cloud providers to interfere with our workloads–bar requirements from law enforcement, of course–and plenty of incentive for them to run workloads properly. They work hard to try to make the system your workloads are running on as secure as possible. But their focus is not on protecting your workloads from them, but on protecting their servers from your workloads, and protecting your workloads from other tenants’ workloads. That’s not to say that they don’t take steps to protect you, but the priority–understandably, given the majority of existing threats–is on protecting against malicious workloads and tenants. The decision that businesses and organizations need to make is whether they are happy to take the business risk of having customer details, financial information, legal proceedings, payroll information, medical data, firewall settings, authentication databases or one of myriad other sensitive workloads running in the public cloud.
What’s the alternative? If you don’t want to trust the cloud service provider then running workloads on your own premises may be safer, but even that is definitely not perfect. Somebody runs your servers internally–there are operations folks, system administrators, database experts–and many of them have the possibility of accessing the very same data and processes if you run them on your premises. How happy are you for your junior system administrator to be able to see–and possibly change–your CEO’s pay and compensation package, or to leak details of an acquisition?
A Matter of Trust
What then, is the problem, exactly? A classic way to think of computer systems is to consider them as a set of layers, known as the stack. The stack is made up of various hardware, firmware and software layers, which are almost always provided by different entities.
The picture below gives an example stack for a cloud virtualization architecture where an application (your workload) is running on top of a variety of different layers. In this example, the colors represent different providers of each layer, with five different entities being represented–the number could well be higher. In order for you, the workload owner, to be sure that your application is as secure as possible, you need to be certain that none of the layers is malicious or compromised, and even if this is true, then you still need to trust the cloud service provider, who is actually running the host system.
The next diagram shows a more modern example, with the workload (“Application”) being run within a container. As is clear, there are not only more layers to be protected–or exploited, if you are a malicious actor–but also more providers: seven in this case. There are, of course, many techniques to address the security of the different layers, of which the most important is sourcing the various layers from trusted and reputable organisations, but in the end, the attack surface available to malicious actors is large.
TEEs to the Rescue?
Trusted Execution Environments (TEEs) are a fairly new technological approach to addressing some of these problems. It allows you to run applications within a set of memory pages which are encrypted by the host CPU in such a way that even the owner of the host system is supposed to be unable to peer into or modify the running processes in the TEE instance. The best known are AMD’s Secure Encrypted Virtualization (SEV) and Intel’s Software Guard eXtensions (SGX), though other silicon vendors have talked about alternatives for their architectures. The approaches taken by AMD and Intel are very different, a point to which we return below.
As noted above, use of TEEs allows you to design your application in such a way that the host cannot see into the TEE instance which is running your workload. This is an improvement over the current state of play, and when properly implemented, it basically removes the problem of having to trust your cloud service provider–or even your internal employees–but there are issues that still exist.
Before we address those, however, there’s a concerning word in the preceding paragraph: the word “properly” in the phrase “when properly implemented.” The problem is that setting up and running your workload in a TEE is far from a simple proposition. Imagine if somebody could spoof a TEE, and convince you that your sensitive workload is running in a TEE when it’s actually executing on a standard, and compromised, host system with no TEE protection. You’re arguably in a worse position than you were before TEEs, because at least then you knew to be careful with your sensitive workloads: now, you have the illusion of security, and have been conned into exposing applications that need to be protected.
This problem of spoofing of TEE instances is something that the silicon vendors have noticed, of course, and so they provide mechanisms by which the CPU (which is setting up the TEE instance) can tell the party wishing to run the workload that it is genuine, and prove it cryptographically: this is called attestation. Performing a full attestation, and checking that it is correct, is not a simple process, and designing it into an application can be complex, but let us assume that you have implemented this step, and are ready to proceed.
Given a properly attested TEE, we can now have cryptographic confidence that we are running our application in a genuine TEE instance, but this doesn’t solve all of our problems. There are at least two that still need to be addressed. The first of these is that although we have now isolated our application from some of the layers in the stack, there are still some that we rely on and therefore trust. Exactly which these are depends exactly on the TEE type and the deployment model, and these days, no application beyond the very simplest has zero dependencies, but if, for example, you are running a TEE instance with a VM, then you typically have the full Operating System running within the VM as a dependency: again, we have a kernel, userspace, etc.–this is a lot of trust to be managing!
The second problem is that you may have to design your application specifically to run within the TEE instance. Having to rewrite your application–or key parts of it–to run in a different execution environment is costly, and maintaining it difficult. The need to rewrite is diminished if you’re running within a VM environment in your TEE instance, but then you run into the problem above with the number of dependencies.
Enarx is a project which aims to address the problems identified above: using TEE instances, but in a way which allows you to reduce the number of trust relationships whilst maintaining a higher level of security and ease of use.
Enarx: Simplifying Trust Relationships
Enarx is a framework for running applications in TEE instances–which we refer to as “Keeps” within the project–without the need to implement attestation separately, without the need to trust lots of dependencies and without the need to rewrite your application. It is designed to work across silicon architectures transparently to the user (you) so that your application can run on AMD silicon just as easily as it can run on Intel silicon, without having to recompile your code. As other TEE types become available, we plan to support them as well.
Given that this is a Red Hat project, it is–and will continue to be–open source software. Given that this is a security-related project, we aim to make it as small and easily auditable as possible.
The key components of Enarx are:
- The attestation component;
- The Enarx API and core;
- The Enarx runtime environment;
- The management component.
We will examine these in detail in a more technical article, but let’s look at what Enarx is trying to achieve. If we consider one of the stacks we looked at above, here’s what Enarx aims to do: wipe out the need to trust any of the layers above the CPU/Firmware (provided by the silicon vendor, e.g. Intel or AMD), meaning that the next layer below your application that you need to trust during execution is the middleware layer (see picture below). To be clear–TEEs are, like any other security capability–not guaranteed to be perfect. You can use them to reduce your attack surface and the number of layers that need to be trusted.
Enarx has a component which sits at the middleware layer, too–the Enarx runtime environment–and we plan to make this small so that it is easily auditable. The fact that it is open source means that anybody can look over it and decide whether to trust it. We aim to work with the open source community to encourage them to perform audits to allow those who are not in a position to perform the analysis themselves to have a high level of trust in the Enarx code.
The other pieces allow for attestation, packaging and loading of your application to take place in a way which is transparent to the user. First, you ask an Enarx component to check that the host to which you’re planning to deploy is starting a genuine TEE instance. Once this is confirmed and the TEE verified, the management component encrypts the relevant part of your application, along with any required data, and sends it along to the host for execution in the Enarx Keep.
The vision we have for Enarx goes beyond just on-premises and the public cloud, and out to any systems which are TEE-enabled. We would love to enable telco-type edge use cases, mobile use cases, IoT use cases and beyond. It’s early days at the moment, but if you’re interested, we urge you to visit the project website to find out more and, hopefully, to contribute.
Enarx aims to make it simple to deploy workloads to a variety of different TEEs in the cloud, on your premises or elsewhere, and to allow you to have confidence that your application workload is as secure as possible. We will be publishing more details as the project develops.