Add Endorsement in Confidential Computing use case

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:
 

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](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.