Conclave Architecture

Architecture overview

This page covers the basic architecture of Conclave, a Confidential Computing platform.

Primary entities

There are three main entities in any Conclave application.

1. Enclaves
2. Hosts
3. Clients

Enclaves are protected regions of memory in which you can write the confidential part of an application. Although enclaves reside in a host program, a host or its owner cannot view or modify the code running in an enclave. An enclave runs inside its own JVM, separate from the host's JVM.

Hosts are programs that load enclaves. They are untrusted and assumed to be malicious at all times. Hosts use a standard JVM like HotSpot. The host and the enclave run inside the same operating system process. Clients communicate with enclaves through the host. It is recommended to keep most of the application logic inside the host, with the enclave containing only the confidential part of the logic.

Clients are the remote applications that communicate with the enclave via the host, by sending and receiving encrypted messages. In a typical Conclave application, clients provide the user interface. Conclave doesn't mandate any particular network protocol for communication between clients and hosts. However, the content of a message is defined using the Conclave Mail API.

Conclave's purpose is to enable clients to securely share data with an enclave, which will faithfully execute a specified algorithm without revealing anything to the potentially malicious host on which it runs.

Along with these three high-level entities, real Conclave deployments might have other participants:

1. Intel.
2. Optionally, a cloud provider.
3. Optionally, an auditor.

Intel. Intel provides the CPU hardware and runs specific servers to provide the host with certificates guaranteeing the authenticity of the chip. Intel provides this guarantee on initial setup and whenever the client requests the authenticity of the remote attestation.

For instance, if the host's SGX software stack is out-of-date and has known vulnerabilities or if the BIOS configuration is not correct, Intel's servers will report it to the client after verifying the host's remote attestation.

Cloud provider. A cloud provider needs to support SGX for Conclave to be usable. They may operate their provisioning servers that take over from Intel's servers. You can find the instructions to use Conclave on Microsoft Azure here.

Auditor. In a pure enclave-oriented model, the user is responsible for understanding what the enclave does before using it by reading the enclave's source code. In practice, the user may wish to outsource this to a third-party auditor.

In the above diagram, the orange-shaded boxes are untrusted and could attack the enclave. In Conclave's threat model, the host, the operating system, the BIOS, the drivers, and other peripherals are untrusted.

In contrast, the blue-shaded boxes are part of the Trusted Computing Base (TCB), which is the set of components that must be non-malicious for the system to work. In this threat model, the TCB includes the enclave, the CPU, and Intel.

The operating system schedules the enclave onto the CPU and provides resources but is otherwise locked out of the enclave's operation. The enclave runs in an embedded-style environment. It cannot load DLLs/.so files or make system calls. So, there's no way for the enclave to load files or interact with the operating system directly. Instead, the enclave must ask the host to load any files and cryptographically prevent a malicious host from modifying the data.

Conclave simplifies this process in which a client communicates with an enclave through an untrusted host.

!!!Note

As the enclave's runtime environment is different from a standard HotSpot JVM, you need to avoid advanced features 
like the Java Flight Recorder in your enclave code.

Important concepts in Conclave

Consider these questions on the working of Conclave:

• How does a client know it's really talking to an enclave?
• How does a client decide whether to trust any given enclave?
• What is the flow of communication in a typical application?
• How does data get from a client to an enclave without the host being able to spy on it?
• What deployment modes are available on the journey from unit testing to production?
• Can you deploy Conclave to the cloud?

The following sections answer the above questions.

Remote attestation

Clients need to be sure that they are communicating with a real enclave. They cannot rely on the host to assert that this is the case because the host could be malicious. Instead, Conclave uses a process called remote attestation.

First, clients need to obtain an EnclaveInstanceInfo object. You can download this object on-demand from the host, or it could be published somewhere.

The EnclaveInstanceInfo object encapsulates a remote attestation. The remote attestation includes the following information:

• The hash of the code inside the enclave.
• The hash of the key of any party who has signed that code.
• The security status of the machine on which the enclave is running.
• A public key whose private counterpart is known only to the enclave.

The remote attestation encapsulated within the EnclaveInstanceInfo object is signed by Intel. So the client can have confidence in the enclave even though they obtain the EnclaveInstanceInfo from an untrusted host.

The client tests the EnclaveInstanceInfo against a set of constraints. Constraints are represented by an EnclaveConstraint object, which can be read from or written to a domain-specific language suitable for embedding in config files, command line options, and so on.

When the client approves the set of constraints, it creates encrypted messages using the key in the EnclaveInstanceInfo object. The client establishes communication with the enclave by sending and receiving encrypted messages through the host using Conclave Mail.

Deciding whether to trust an enclave

Conclave makes it easy to write clients that understand remote attestations. Conclave provides multiple options to set constraints to decide which enclaves to trust. To ensure that the clients communicate only with trusted enclaves, users can choose any of the three below models.

In the first model, the application developer gives the application's source code to the customer. The customer reviews the code to check if it is non-malicious. After verification, the customer compiles the code using the Conclave SDK to determine the hash of the enclave that should be running on the remote server. The customer can then use this hash as their enclave constraint. The client will connect to the enclave only if the remote attestation has the same hash. Otherwise, the client will refuse to communicate with the enclave.

In the second model, the customers employ a trusted third-party auditor to review the enclave code. Customers might also ask auditors to compile the enclave for them. The auditors give the compiled enclave to the application developer and the hash to the customer.

Customers can use a third approach in cases where the enclave code changes frequently. In this model, the auditor reviews the code associated with each new enclave update and signs the enclave if it is secure. The customer uses a signature constraint that tells the client to trust any enclave signed by that auditor.

Protocol sequence diagram

A typical interaction in a Conclave application looks like the below illustration.

)

1. When you use SGX in a machine for the first time, the host interacts with the cloud provider or Intel to retrieve certificates to prove authenticity.
2. The host then sends a remote attestation (EnclaveInstanceInfo) to the client.
3. The client verifies the remote attestation and optionally asks Intel if the hardware setup of the machine is still secure or if there are known vulnerabilities (see renewability). This step can be repeated as often as the client wants.
4. The client communicates to the enclave through the host by using encrypted messages and responses.

Conclave Mail

Clients must securely communicate with enclaves without the host spying on the messages. Conclave uses Conclave Mail to send and receive encrypted messages between a client and an enclave. Conclave Mail makes communication between enclaves and clients easier, more secure, and more efficient when compared to classical architectures like HTTPS. Learn more about Conclave Mail here.

Testing and debugging

Conclave provides full unit testing support for enclaves. You can compile enclaves in one of these four modes:

• Release: Fully encrypted and protected memory used for the production version of an application.
• Debug: It's the same as release mode, but it has special instructions that allow the enclave memory to be read and modified. This mode provides no protection but is a faithful recreation of the production environment that you can use for testing.
• Simulation: This mode doesn't use SGX hardware at all. Simulation mode is helpful during development when SGX-capable hardware may not be available. You need a Linux environment or a Linux Docker container to run enclaves in simulation mode.
• Mock: In mock mode, the enclave class runs in the same JVM as the host. So, interactions between the enclave and the host are regular function calls. You can step through using a debugger and enjoy a regular Java development experience. See here for more information on using and configuring mock mode.

You can read more about enclave modes here.

Adding logs to enclaves

To add logs to an enclave, you can use:

1. The in-memory filesystem to retain your logs in memory and then export them occasionally to a trusted client or another enclave.

2. The persisted filesystem to persist your logs. When you want to analyze the logs, you need to send the logs from the enclave to a trusted client.

Alternatively, in sensitive applications, you can decide that nobody should receive the logs when in release mode.

Inside the enclave, System.out and System.err are wired to the host console, but there's no access to the filesystem. In release mode, Conclave suppresses any output to stdout and stderr inside the enclave. So you can add logs to stdout and stderr without worrying that it may leak production information outside the enclave.

Deployment

You can get SGX-capable virtual machines from cloud providers. Currently, Microsoft Azure provides the easiest, up-to-date source of SGX VMs.

A Conclave host application includes the enclave bundled into the same JAR and the native libraries required for working with the kernel driver and Intel infrastructure. So, you can deploy a Conclave application by using regular Java deployment procedures. For example, use Gradle's assemble plugin to create a tarball/zip of your application or create a fat jar using the shadow plugin.