Skip to main content
Version: 1.6

Overview

Attestation in Privatemode is a cornerstone of the API's security architecture, ensuring that all AI workloads are executed in a trusted environment. The attestation process verifies the integrity and authenticity of AI workers and the underlying infrastructure before any data processing or transfer begins. By leveraging attestation, the Privatemode API ensures that only verified and trusted code can operate, safeguarding both the confidentiality and integrity of your data.

Attestation flow in Privatemode​

The attestation process in Privatemode is designed to provide end-to-end security along the entire service supply chain. Verification of attestation evidence is always based on a manifest. Both the client and the attestation service need to have a manifest configured before they can verify attestation data. In the following, when we refer to client, we mean the proxy, which handles the configuration of the client-side manifest and manages the attestation process for you.

The steps to verify the Privatemode API are as follows:

  1. Client request: The process begins when the client software initiates a prompt to Privatemode, starting with a demand for attestation. The client verifies the identity and integrity of the attestation service by comparing its hardware attestation report, which is a current hardware-enforced fingerprint of the service state, against the client's manifest that contains the expected reference values, i.e., the expected fingerprint of a trusted service. This fingerprint is based on the software, firmware, and configurations of the service. If there are discrepancies, the service can't be trusted. The client also verifies that the manifest configured in the attestation service is identical to its own. Once the client confirms the attestation service's integrity, it securely transmits the encryption keys to the attestation service.

  2. Attestation service verification: The attestation service verifies the GenAI endpoint's integrity by comparing its attestation report against the configured manifest.

  3. Key distribution: Once the attestation service confirms the endpoint's integrity, it securely grants it access to the necessary encryption key. The client-side initially encrypts the prompt and sends it to the GenAI endpoint. This attestation-based key release ensures that the GenAI endpoint can decrypt and process the data only within a verified, trusted environment.

  4. Data processing: With successful attestation and key distribution, the GenAI endpoint processes the encrypted data within its confidential VM. This ensures that all operations are conducted in a trusted and protected environment, maintaining the security and integrity of the entire process.

Privatemode attestation flow

A user verifies the attestation service and securely transmits the prompt encryption key. The attestation service attests the AI endpoint and securely distributes the prompt encryption key to it.

Components of attestation​

  • Manifest: The manifest is a detailed record that lists the expected measurements and configurations for the attestation service and the AI workers. It serves as a reference point for a client to verify the attestation service and for the attestation service to verify the endpoint's environment before any data processing begins. This is done by comparing the expected measurements (expected fingerprint of a trusted service state) to the actual one received. By ensuring that only trusted configurations are allowed to execute, the manifest forms a critical part of Privatemode's security model.

  • Encryption and key management: Privatemode tightly integrates encryption and key management with attestation. Encryption keys are distributed to the GenAI endpoint only after successful attestation, ensuring that data remains protected at all times. This process ensures that sensitive data is accessible only to verified and trusted endpoints, with keys securely transferred from the client to the attestation service and then to the GenAI endpoint.

  • Trust anchors: Trust anchors are the fundamental elements in the attestation process, providing the necessary foundation for establishing a chain of trust. These include hardware-based roots of trust and predefined reference values, ensuring that only known and trusted entities can process sensitive data.

Chain of trust​

In summary, there's a chain of trust based on cryptographic signatures that goes from the user to the GenAI backend via the attestation service. This is illustrated in the following diagram. The GenAI endpoint is denoted as AI workers here. The client software corresponds to the proxy.

Verification policies​

So far, we’ve established that the client software verifies the attestation service, and the attestation service in turn verifies the AI workers. This whole process runs on configurable policies. Essentially, a verification policy outlines the expected software hashes and other parameters a service should match to be deemed trustworthy. A service can then check another service's integrity by simply obtaining a fingerprint of its current state and configuration. By leveraging confidential computing, it's ensured that this fingerprint is a hardware-enforced, cryptographically binding proof, making it an unforgeable measurement of the service’s state (including code) and configuration. By checking this against the defined policy, the service is considered trustworthy or not.

For the client software, the verification policy includes the expected hash of the attestation service’s software along with other parameters, in particular the expected attestation service's policy for verifying AI workers that process the encrypted prompts. The client software will only trust an attestation service if its hash matches what’s expected. By extension, the client software then knows that the attestation service will only accept specific AI workers (as it has checked the integrity of the attestation service's policies for accepting AI workers).