Skip to content
Meaningful control of data in distributed systems.
Rust C++ Starlark Shell Other
Branch: master
Clone or download
ipetr0v Delete signal handler from `dev_oak_main.cc`
This change:
- Deletes an unnecessary signal handler from `dev/dev_oak_main.cc`
- Updates includes
Latest commit 1528e03 Feb 6, 2020
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
docs examples/hello_world: expand app config Feb 5, 2020
examples Use `oak_utils` wrapper for protobuf generation (#558) Feb 6, 2020
oak Delete signal handler from `dev_oak_main.cc` Feb 6, 2020
runner Add wrappers to `runner` script Jan 24, 2020
scripts Fix format scripts Feb 6, 2020
sdk/rust Provide blanket implementation for protobuf (#557) Feb 5, 2020
third_party Wrap Rust `protoc` in Oak utils Feb 4, 2020
toolchain Enable armv8 build using clang (#527) Jan 31, 2020
.bazelrc Enable armv8 build using clang (#527) Jan 31, 2020
.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
.rustfmt.toml Add `.rustfmt.toml` configuration file (#480) Jan 16, 2020
AUTHORS Add AUTHORS Nov 30, 2018
BUILD Fix Java equals Dec 24, 2019
CONTRIBUTING.md Update contributing guidelines (#329) Nov 22, 2019
Dockerfile Update Asylo to 0.5.2 Jan 22, 2020
INSTALL.md Clean up Install instructions (#388) Dec 19, 2019
LICENSE Add License Nov 23, 2018
PULL_REQUEST_TEMPLATE.md docs: add pull request template (#498) Jan 20, 2020
README.md Remove Travis build badge link (#331) Nov 25, 2019
WORKSPACE Enable armv8 build using clang (#527) Jan 31, 2020
android.Dockerfile Pull Android Docker in GCB Dec 19, 2019
cloudbuild.yaml Enable armv8 build using clang (#527) Jan 31, 2020

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.