This repository has been archived by the owner on Apr 9, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add Endorsement in Confidential Computing use case
- Loading branch information
Showing
3 changed files
with
68 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |