diff --git a/README.md b/README.md index 20d30f85..b1454b64 100644 --- a/README.md +++ b/README.md @@ -12,8 +12,8 @@ The goal of release transparency is to generate and transparently publish non-fo about a released binary. We refer to this kind of metadata as the endorsement statement. It can be used in scenarios where the identity of a binary must be verified before use. One prominent use case is remote attestation. See -[Oak’s remote attestation protocol](https://github.com/project-oak/oak/blob/main/docs/remote-attestation.md) -for instance. +[Oak’s remote attestation protocol](https://github.com/project-oak/oak/blob/main/docs/remote-attestation.md), +and [how release transparency fits into the picture](docs/usecase.md). The life cycle of an endorsement statement has three phases as shown in the diagram below: diff --git a/docs/images/CC_SLSA.png b/docs/images/CC_SLSA.png new file mode 100644 index 00000000..7f4e28a7 Binary files /dev/null and b/docs/images/CC_SLSA.png differ diff --git a/docs/usecase.md b/docs/usecase.md new file mode 100644 index 00000000..e5ccce3a --- /dev/null +++ b/docs/usecase.md @@ -0,0 +1,66 @@ +# Release Transparency for Confidential Computing + +[Confidential computing](https://confidentialcomputing.io/) is a privacy-preserving computation +principle that leverages Trusted Execution Environments (TEE) to protect data as it is being +processed. A TEE is a secure area within a main processor that runs an isolated environment parallel +to the main operating system. Through this hardware-level isolation, the TEE guarantees that data +and code loaded into its memory cannot be read or tampered with by malicious processes. + +In addition, a TEE attests to the identity of the software running inside it by providing a +cryptographic measurement of that software. The TEE then signs the measurement with a signing key +only accessible to it, to prove itself as the origin of the measurement. + +Relying on this technology, [Project Oak](https://github.com/project-oak/oak) is developing a secure +runtime, and a remote attestation process to attest to the identity of the runtime, and the workload +running inside it. + +Clients connecting to a server running the Oak secure runtime can use this information to verify the +identity of the server-side stack, i.e., the cryptographic measurement of the Oak secure runtime and +the workload running inside it that handles the user data. However, additional evidence is required +to verify the integrity of this stack. + +The transparent release process, utilizes SLSA provenances to protect against software supply chain +attacks, and provide evidence of the integrity and trustworthiness of the Oak secure runtime. More +specifically, for each released version of the Oak secure runtime, the Oak team generates and signs +an endorsement statement for the binary, using a key accessible only to the Oak team. The +endorsement statement references the binary’s provenance statement and can only be generated if the +provenance statement passes some verification checks. + +When establishing a connection to the server, this endorsement statement is provided to the client +for verification, alongside the cryptographic measurement from the TEE. In particular, the client, +as part of verifying the received attestation report, checks that the binary identities in the +attestation report and the endorsement statement are the same. This, together with verifying the +signature of the endorsement statement, guarantees that the Oak secure runtime is open source, has a +publicly published non-forgeable SLSA v1.0 provenance with adherence to SLSA Build Track 3 +associated with it, and is transparently released. + +The following is a simplified visualization of this scenario. Note that we have not demonstrated the +workload running inside the Oak secure runtime. + +![Provenance verification](docs/images/CC_SLSA.png) + +## Verification Steps + +In a complete solution, both the provenance and the endorsement statement need to be verified. The +provenance statement needs to be verified by the Oak team when issuing the endorsement statement, +and the endorsement statement is verified by the client when establishing a connection to the +server, as described above. In both cases, the minimum verification involves verifying the signature +and its proof of inclusion in a public transparency log. See the +[slsa-verifier](https://github.com/slsa-framework/slsa-verifier) for more details on signature +verification for the provenances. Signature verification for endorsements is similar. + +The [slsa-verifier](https://github.com/slsa-framework/slsa-verifier) further validates the +information about the source code of the binary.This is about the extent of the verification offered +by the provenances generated using generic SLSA3 provenance generator and SLSA v0.2 format. With the +new container-based SLSA3 builder and the SLSA v1.0 provenance format, it is now possible to perform +additional verification before generating the endorsement statement. In Oak for instance, we want to +make sure the build command does not use any potentially malicious tool. This is achieved by +comparing the build command against a set of allow-listed tokens. A more comprehensive list of +checks against expectations using the SLSA v1.0 format is provided in its +[documentation](https://slsa.dev/spec/v1.0-rc2/verifying-artifacts#step-2-check-expectations). + +Finally, if the build was reproducible, the provenance statement generated by container-based SLSA3 +builder can be verified by rebuilding the binary. The Docker-based build tool offers this +functionality via the verify command: it rebuilds the binary using the provenance’s build definition +and checks that the resulting artifacts have the same digests specified in the subject of the +provenance.