<!-- Oak Logo Start -->
<!-- An HTML element is intentionally used since GitHub recommends this approach to handle different images in dark/light modes. Ref: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#specifying-the-theme-an-image-is-shown-to -->
<!-- markdownlint-disable-next-line MD033 -->
<h1><picture><source media="(prefers-color-scheme: dark)" srcset="oak-logo/svgs/oak-logo-negative.svg?sanitize=true"><source media="(prefers-color-scheme: light)" srcset="oak-logo/svgs/oak-logo.svg?sanitize=true"><img alt="Project Oak Logo" src="oak-logo/svgs/oak-logo.svg?sanitize=true"></picture></h1>
<!-- Oak Logo End -->

# Remote Attestation

**Remote Attestation** is a process that enables clients to gain trust in the
server workload by verifying that _"the intended software is running on the
intended hardware"_, i.e. it allows clients to remotely verify the authenticity
and integrity of the Trusted Execution Environment (TEE) and the workload
running inside a TEE before any sensitive data is exchaged.

## Core Concepts

Remote Attestation is done by requesting the following artifacts from the server
and verifying them on the client-side:

1. [`Evidence`](../proto/attestation/evidence.proto): Message that contains a
   cryptographic proof of the hardware and software identity. This includes
   quotes from the hardware root of trust (such as quotes from
   [AMD SEV-SNP](https://www.amd.com/en/developer/sev.html) or
   [Intel TDX](https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html))
   and measurements of the Trusted Computing Base (TCB), which is the collection
   of firmware and software. Evidence also binds this identity to cryptographic
   keys that are used to establish an end-to-end encrypted channel between the
   client and the TEE. For more information about Oak end-to-end encryption see
   [Oak Encrypted Session SDK](../oak_session/README.md).

2. [`Endorsements`](../proto/attestation/endorsement.proto): Message that
   contains statements from trusted parties that vouch for the authenticity and
   integrity of the hardware and software. This includes certificates from the
   hardware manufacturer that endorse the TEE platform and certificates that
   correspond to the Binary Transparency. For more information about how Oak
   provides Binary Transparency see
   [Transparent Release](https://github.com/project-oak/oak/tree/main/docs/tr/README.md).

These messages are often combined into an
[`EndorsedEvidence`](../proto/session/messages.proto) message that is being sent
to the client. To verify the `EndorsedEvidence` client relies on a set of
[`ReferenceValues`](../proto/attestation/reference_value.proto), which are
expectations about various properties of the workload, i.e. binary measurements,
versions, configuration parameters and etc.

It's also important to note that Remote Attestation doesn't necessarily have to
be "Server to Client", it can be done in any direction, even with both client
and server providing attestation evidence to each other (i.e. _Bidirectional
Attestation_).

Remote attestation process involves 3 main entities:

- **Attester**: Entity internal to the TEE that generates the `Evidence`
  message.
- **Endorser**: Entity that generates the `Endorsements` message (can either be
  inside or outside the TEE).
- **Verifier**: Entity that provides remote attestation verification.

More information about the Remote Attestation process can be found in the
[RFC9334](https://datatracker.ietf.org/doc/html/rfc9334). And for more
information about how Remote Attestation is linked to Binary Transparency see
our [Confidential Computing Transparency](https://arxiv.org/abs/2409.03720)
paper.

## Implementation

Oak provides the following SDKs that are needed for Remote Attestation:

- [Oak Attestation SDK](../oak_attestation/README.md): which is used to generate
  remote attestation artifacts in the TEE.
- [Oak Attestation Verification SDK](../oak_attestation_verification/README.md):
  which is used to define remote attestation verification logic.
- [Oak Encrypted Session SDK](../oak_session/README.md): which is used to
  establish an end-to-end encrypted channel after a successful attestation.
