How familiar are you with secure computing?

How familiar are you with secure computing? Have you used an enclave before? If you haven’t, then this is the right blog post for you.  Launching a secure service can be a daunting task. You’ve got to make a lot of decisions about system design, infrastructure, data storage policies, regulatory barriers…and of course, cost. It seems like there’s very little a software engineer can trust when it comes to developing technical infrastructure.

It seems like every month we’re made aware of new leaks and vulnerabilities on platforms like SSL. This isn’t just limited to specific organizations or application designs either. The Linux kernel has had over 60 vulnerabilities in 2021 and there’s been another server VMware vulnerability as I write this article.  If you’re threat modeling for sophisticated actors or foreign government operations, it’s probably time to think about swapping your architecture for secure computing platforms. Depending on the circumstances, if an attacker can corrupt the operating system, or worse, the kernel, they can control the computer.

In a perfect industry, these technical issues would be the only ones to worry about—but they are only part of the problem. As developers, it’s easy to think about programs the way that a mathematician might. We have confidence in the software we write because we test it thoroughly. But as we saw above, data can be taken, protocols can be breached, and information can be leaked.

For example, in the securities market, many banks operate “dark pools,” essentially private exchanges for large market participants. One risk to those participants is that the hosts of some of these exchanges will front-run trades in violation of SEC rules. Even with a contract in place, the trust is with the institutions, and that trust is not always well-founded.  The truth is the hosts of certain kinds of data have incentives to misuse it. The computing world has only recently started to grapple with this problem, which is where tools like Conclave come in.

What is an enclave?

An enclave is a secure computing environment for the safe processing of data. Enclaves can verify exactly what algorithm will process the data it's given. Imagine an ideal CPU that runs specific programs that match the exact hash of the software they were prepared with. In addition, the data going in and out of this enclave is encrypted. The host machine couldn’t read it even if it wanted to.

This special CPU enclave works just like a normal Intel processor with the same set of instructions. In this case it’s implemented by Intel’s software guard extensions (SGX).

Having a secure system like this is great, but it’s not useful to your users if you still must be trusted to host and maintain the system. But what if you could also prove to your users that the code you are hosting does exactly what you claim it does? This is possible for enclaves that support the ability to verify the cryptographic hash of the entire sum of code running within the enclave. Conclave accomplishes this through remote attestation, enabling users to have complete confidence in the software they’re using.

What is the enclave guarding against?

The primary uses for an enclave are instances where the host operating system can’t be trusted, or where an entity maintaining a computer for a particular use case can’t be trusted.

Enclaves protect against both external attacks over the web and attacks from “trusted” places like the kernel, operating system and the hypervisor. The CPU is in theory the only place safe from compromise at every level of the computing stack, and there’s not much that users can do other than switch to software that puts security at the top of its list.

The concept of the enclave assumes that the entire computing environment in which it will be run is hostile. The design of the tool is such that it can’t be run unless it's within a specific CPU-level enclave (such as Intel SGX).

Physical security and side-channel attacks

A side-channel attack is an attack that gains information using the implementation of a computer system instead of leveraging weaknesses in the software itself. It may not come as a surprise that the physicist’s role is again crucial here. Common attacks are things like cache attacks, power monitoring, timing attacks, acoustic cryptoanalysis and more.

One of the most fascinating examples of this I’ve come across is that theoretically, it’s possible to get into a secure enclave if you have the physical chip and try to read the memory with an electron microscope, but this approach would require serious effort and potentially spoil the data. Of course, the attacker must have the physical device. Ideally, when the chip is manufactured, it creates its own key and uses that for all of its encryption going forward.

We don’t think about this much on the software side, but when it comes to the physical device itself you may wonder how an enclave is secured. From the outset, when data is stored in an enclave it’s encrypted in memory. It is only this enclave that contains the key to read anything at the outset. What a lot of the hardware manufacturers do is design the chip such that it wipes any data on it once it’s physically tampered with. The idea is to store critical information in battery-backed static RAM so it spoils when tampered with or powered off.

You can see more information on this kind of hardware security on page 5 of this Microsemi design document. While I’m no expert, I’d imagine the approach of other semiconductor manufacturers is similar. If you’re curious to learn more about side channel attacks, I’d recommend reading the Conclave docs.

What is Conclave?

Conclave introduces a set of abstractions to enable a developer to interact with an enclave, along with a toolkit for development and emulation of secure computing applications that run within enclaves.

Conclave gives developers some basic abstractions within the architecture. To paraphrase the docs:

• Clients exchange encrypted messages with enclaves by interacting with the host over the network.
• Host programs just load enclaves. From a security perspective hosts are assumed to be malicious at all times.
• Enclaves are classes that are loaded into a dedicated sub-JVM with a protected memory space, running inside the same operating system process as the host JVM. Because they don't share heaps, the host may only exchange byte buffers with the enclave. Direct method calls also don't work out of the box: that would require you to add some sort of RPC system on top. In this way it's similar to interacting with a server over a network, except the enclave is fully local.

With all of this in mind, the architecture diagram below should start to come into focus:

Where do things go from here?

This is one of the first tools of its kind to be made available for developers. You can use Conclave to build out secure computing applications that have never existed before.

The classic example of this kind of problem is the “zero knowledge proof.” Imagine we wanted to write a program that would tell us which of the two of us has more money? Assuming we didn’t want to reveal our numbers that would actually be quite tricky. One of the nice things about Conclave is it can make solving this kind of problem quite trivial. The entire enclave is simply a machine that compares two numbers. The enclave can be run by either of us, but our numbers are never revealed to each other, only the answer.

This is only an instructive example. You can actually write fully trustable client server programs where you can be sure that the host of a product or service will only use your data in exactly the way you expect. For example, you can isolate secure and private keys from the host machine instead of them being stored in the regular filesystem. Another popular example is private machine learning. Hospitals and other medical groups would be able to exchange medical data to build more robust statistical models without leaking any private or identifying patient information. You can also have provably private searches, such as searching a database where a query is only handled by the enclave, and even the operator of that machine wouldn’t be able to know what the query was.

The use cases really are fascinating, and we’ve only just scratched the surface of what’s possible. If this kind of computing sounds interesting to you, I highly recommend downloading Conclave and trying it for yourself.

Want to learn more?

Here are some additional resources you might find helpful:

• The Conclave docsite
• This presentation from Azimuth Computing
• This blog post on secure enclaves from Mike Ash
• The AWS nitro enclave project
• This blog post from R3's CTO, Richard Gendal Brown, titled "Introducing Conclave"