Skip to content
Meaningful control of data in distributed systems.
Rust C++ Python Shell Other
Branch: master
Clone or download
daviddrysdale scripts: build :all targets in run_tests
Omits the //oak/server/asylo:all target as this can't be built purely
on the host system.

Fixes #346.
Latest commit 6874c1e Dec 6, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs Change oak_main signature to take a handle param (#342) Dec 2, 2019
examples Change oak_main signature to take a handle param (#342) Dec 2, 2019
oak Mark fuzzing target as needing manual build Dec 6, 2019
scripts scripts: build :all targets in run_tests Dec 6, 2019
sdk/rust Change oak_main signature to take a handle param (#342) Dec 2, 2019
third_party Maintain wabt patches in oak tree (#338) Nov 28, 2019
toolchain Use latest version of buildifier (#309) Nov 4, 2019
.bazelrc Update Asylo dependency to current version (#326) Nov 22, 2019
.clang-format Add explicit PointerAlignment for clang-format (#29) Mar 29, 2019
.devcontainer.json Add .devcontainer.json file (#131) Jul 5, 2019
.dockerignore Add rust-clippy to CI and set docker UID (#86) May 29, 2019
.gitignore Refactor scripts and Bazel configuration (#264) Oct 9, 2019
.prettierrc.yaml Autoformat and check Markdown files (#256) Oct 8, 2019
.travis.yml Move CI from Travis to GCB Nov 24, 2019
AUTHORS Add AUTHORS Nov 30, 2018
CONTRIBUTING.md Update contributing guidelines (#329) Nov 22, 2019
Dockerfile Use latest version of buildifier (#309) Nov 4, 2019
INSTALL.md Autoformat and check Markdown files (#256) Oct 8, 2019
LICENSE Add License Nov 23, 2018
README.md Remove Travis build badge link (#331) Nov 25, 2019
WORKSPACE Maintain wabt patches in oak tree (#338) Nov 28, 2019
cloudbuild.yaml Move CI from Travis to GCB Nov 24, 2019

README.md

Project Oak

Build Status Fuzzing Status

The goal of Project Oak is to create a specification and a reference implementation for the secure transfer, storage and processing of data.

In traditional systems, data may be encrypted at rest and in transit, but they are exposed to any part of the system that needs to process them. Even if the application is securely designed and data are encrypted, the operating system kernel (and any component with privileged access to the machine that handles the data) has unrestricted access to the machine hardware resources, and can leverage that to bypass any security mechanism on the machine itself and extract secret keys and data.

As part of Project Oak, data are end-to-end encrypted between enclaves, which are isolated computation compartments that can be created on-demand, and provide strong confidentiality, integrity, and attestation capabilities via a combination of hardware and software functionality. Enclaves protect data and code even from the operating system kernel and privileged software, and are intended to protect from most hardware attacks.

Additionally, data are associated with policies when they enter the system, and policies are enforced and propagated as data move from enclave to enclave.

Further information is included in the following documents:

  • Oak Concepts describes the key concepts involved in Oak applications.
  • Oak ABI documents the core Oak ABI.
  • Oak SDK describes the SDK that is provided on top of the Oak ABI, to allow more convenient development of Oak applications.
  • Oak Development covers practical steps for getting a development Oak system up and running.
  • Programming Oak discusses programming for the Oak system.

Terminology

  • Enclave: A secure CPU compartment that can be created on-demand, containing code and data; it enforces isolation from the host and other enclave instances running on the same system. It guarantees confidentiality and integrity of both data and code running within it, and it is capable of creating hardware-backed remote attestations to prove to other parties a measurement (i.e. hash) of the code and data within the enclave itself. Also known as Trusted Execution Environment (TEE).
  • Enclave Manufacturer: The entity in charge of manufacturing the CPU or System on a Chip (SoC) supporting enclaves.
  • Platform Provider: The entity in charge of maintaining and running the combined hardware and software stack surrounding the TEE, for instance in a cloud context.
  • Trusted Computing Base (TCB): The set of hardware, firmware, software components critical to the security of the system; bugs or vulnerabilities inside the TCB may jeopardise the security properties of the entire system.
  • Independent Software Vendor (ISV): The entity or person providing the code for the service running on top of the Project Oak; in the most common case this may be a third party developer.

Threat Model

  • untrusted:
    • most hardware (memory, disk, motherboard, network card, external devices)
    • Operating System (kernel, drivers, libraries, applications)
    • platform provider (hardware, software, employees)
    • third-party developers
  • trusted-but-verifiable:
    • Project Oak codebase (and its transitive dependencies)
  • trusted:
    • enclave manufacturer (and therefore at least some hardware / software)
  • partly or conditionally trusted:
    • end users

Side channels are out of scope for Project Oak software implementation. While we acknowledge that most existing enclaves have compromises and may be vulnerable to various kinds of attacks (and therefore we do need resistance to side channels) we leave their resolution to the respective enclave manufacturers and other researchers.

End users are considered "partly trusted" in that we assume that when two users exchange data, there is a pre-existing basic trust relationship between them; in particular we assume that the recipient of the data is not going to intentionally circumvent robust protection mechanisms on their device in order to extract the received data.

You can’t perform that action at this time.