Meaningful control of data in distributed systems.
Oak is a software platform for building distributed systems providing externally verifiable (or falsifiable) claims about system behaviors in a transparent way.
Oak provides building blocks that are used to build Enclave Applications, i.e. applications that are isolated from the host on which they run, and are remotely attestable.
In this doc we focus on distributed systems composed of heterogeneous "nodes"; a node may be an Enclave Application running on a server (e.g. private data center, public cloud provider, etc.), a regular application running on a client device (e.g. phone, laptop), a regular HTTP or gRPC service, a storage system, etc. When two nodes talk to each other, either or both of them may be Enclave Applications. For each interaction between two nodes, we refer to them as "initiator" and "responder". We avoid the terms "client" and "server" for those roles, because in some cases the "initiator" node may actually be running on a "server" - all combinations are possible.
An Enclave Application in an Oak distributed system can remotely attest itself to other nodes: this consists in providing evidence of its own software and hardware identity, bound to local cryptographic keys (stored in tamper-proof hardware, guaranteeing that keys cannot be exfiltrated or copied), ultimately signed by one or more software or hardware roots of trust available on the host of that node. The software identity of an Enclave Application consists of measurements (i.e. digests / hashes) of the executable binaries that contribute to it, as well as additional data (e.g. configuration).
Oak focuses on VM-based Trusted Execution Environments (TEEs) (e.g. AMD SEV-SNP, Intel TDX) as hardware root of trust for Enclave Applications. This allows an Enclave Application to provide a remote attestation report signed by hardware-bound keys in the TEE, which are not accessible by the service provider. These keys are ultimately rooted in the TEE manufacturer (e.g. AMD, Intel); this reduces (ideally, removes) the need to trust the service provider of that node in order to validate its evidence, by distributing trust across multiple non colluding actors.
At startup, each Enclave Application generates a local key pair, and binds the public key to its own evidence. When a node intends to communicate with an Enclave Application (as either initiator or responder), an end-to-end encrypted channel is established between the two nodes. As part of the channel establishment, each node also provides its own evidence (if any) to the other node, and may use the evidence provided by the other node to establish its trustworthiness, before deciding whether to exchange data with it.
This encrypted and attested channel provides:
In order to minimize the attack surface and the Trusted Computing Base (TCB) of an Enclave Application, Oak encourages a split architecture:
Enclave Application: a binary built (reproducibly) from open source code, running inside the TEE. The Enclave Application has access to the decryption keys bound to the attestation evidence; it decrypts incoming requests from other nodes, processes them, encrypts responses and sends them back over the communication channel. This is the binary that is associated with externally verifiable claims. No other binary has access to incoming requests in plaintext.
Host Application: a binary that runs on the host (untrusted) server environment that acts as the front-end for the Enclave Application; it exposes a gRPC endpoint which is externally reachable by other nodes. This binary only ever handles encrypted data; its main job is to create and maintain an instance of the Enclave Application in the TEE, and forward encrypted data to and from the Enclave Application. It may also contain proprietary logic that is needed to interact with the control plane or other internal systems necessary to run on the service provider infrastructure.
This architecture means the service provider would not be able to swap the Enclave Application binary with a different (potentially malicious) one without being detected. If the service provider were to introduce a backdoor in the Enclave Application, it would have to sign the binary and publish it in a verifiable log via the Transparent Release process, which would make the backdoor irreversibly visible to external observers.
A canonical use of Oak is to build privacy-preserving sealed computing applications.
In a sealed computing application, a node (usually a client device) sends data to an enclave application (usually a server), which processes data without the service provider hosting the enclave application being able to see the inputs, outputs, or side effects of the computation.
The following is a simplified architectural diagram.
Oak supports two flavors of Operating Systems within the TEE, on which Enclave Applications may be deployed:
Oak Restricted Kernel: a very minimal custom written microkernel that only supports a single CPU and a single application. It places very severe restrictions on what the application can do by only exposing a very limited set of syscalls to the application. Oak Restricted Kernel applications are suitable for cases where review of the entire trusted code base inside the TEE is critical, and the limited features and reduced performance is an acceptable trade-off. Ideally it should be possible for a single expert human reviewer to review the code of the Oak Restricted Kernel in its entirety in a couple of weeks.
Oak Containers: The Enclave Application is provided as part of an OCI runtime bundle. This includes a full Linux kernel and a Linux distribution with a container runtime engine inside the TEE. Using the OCI runtime bundle as a compatibility layer provides a more familiar development experience and more flexibility. Oak Containers also supports multiple CPUs in the TEE and is therefore suitable for cases with high performance requirements. The drawback of this approach is that the size of the entire trusted code base running in the TEE is significantly larger, as it is not feasible for a single human reviewer to review the code for the entire Linux kernel and Linux distribution. The trust model for this approach relies on the security of the broader Linux ecosystem. The additional features and flexibility that the Linux kernel provides to the application also makes it more difficult to reason about the behavior of an application, which in turn makes the review process more complicated.
