From 3d8038aafade7e427a8d1e056d243c564e985588 Mon Sep 17 00:00:00 2001 From: Filip Cviljak Date: Thu, 25 Dec 2025 17:30:34 +0100 Subject: [PATCH 1/5] docs: add proxy-based attestation and aTLS overview --- docs/attestation.md | 88 +++++++++++++++++++++------------------------ 1 file changed, 41 insertions(+), 47 deletions(-) diff --git a/docs/attestation.md b/docs/attestation.md index 393f71e..b357236 100644 --- a/docs/attestation.md +++ b/docs/attestation.md @@ -1,73 +1,67 @@ ---- -id: attestation -title: Attestation -sidebar_position: 4 ---- +## Attestation Overview -## Attestation +Attestation is a security mechanism that allows a client to **verify the identity and integrity of a remote system before sending sensitive data**. -Attestation is a security process used to verify that a system is running trusted software inside a trusted environment. -In Cube AI, attestation ensures that the confidential computing environment (CVM) has not been tampered with before Cube AI services start running. +In the context of confidential computing, attestation provides cryptographic proof that an application is running: +- Inside a **Trusted Execution Environment (TEE)** +- With **expected software and configuration** +- Without interference from the host operating system, hypervisor, or cloud provider -Cube AI performs attestation both **internally** during the boot sequence of the confidential virtual machine (CVM) and via a **user-facing endpoint** that allows clients to verify trust guarantees. +Attestation is a foundational building block for **zero-trust architectures**, where trust is never assumed and must always be verified. +For Cube AI, attestation ensures that sensitive prompts, embeddings, and responses are processed only by trusted and verified AI services. --- -## How Cube AI Uses Attestation Today +## Attestation and Attested TLS (aTLS) -Cube AI runs inside **hardware-backed Confidential Virtual Machines (CVMs)** based on **AMD SEV-SNP and Intel TDX**. +To allow clients to send confidential data to Cube AI securely, a secure channel based on **Attested TLS (aTLS)** is established. +aTLS is a standard TLS connection augmented with a **hardware-backed attestation report** proving that the remote service is running inside a **Trusted Execution Environment (TEE)**. -These confidential computing technologies provide: +In Cube AI, the Embeddings Service acts as the TLS server and extends its **X.509 certificate** with an attestation report generated by the underlying TEE (e.g. AMD SEV-SNP). -- Full memory encryption -- Protection from a malicious hypervisor or cloud provider -- Integrity verification of the VM state -- Hardware-enforced measurement of what software boots inside the VM +When generating the attestation report, the service embeds the **hash of its ephemeral public key** into the `report_data` field of the attestation report. +A new TLS certificate and a fresh attestation report are generated for every connection, ensuring cryptographic freshness and preventing replay attacks. -During startup: +This provides cryptographic proof that the client is communicating directly with the Cube AI service running inside a TEE, and not with the host system or any intermediary. -1. The CVM performs **hardware attestation** using platform-specific attestation mechanisms (**AMD SEV-SNP or Intel TDX**). -2. Measurements are validated internally before Cube AI components start. -3. If the environment does not match expected measurements, the system refuses to start. +--- -Because this attestation happens before any workloads run, Cube AI ensures that: +## Local Proxy-Based Attestation -- The AI backend (Ollama or vLLM) is running on trusted code -- The proxy and API services are verified -- Sensitive data and model prompts are protected from host-level access +Unlike other systems where users must manually perform attestation using a CLI tool, Cube AI fully automates the attestation process through a **Local Proxy** installed on the user's machine. ---- +The Cube AI Local Proxy: -## Why Attestation Matters +- Establishes the **aTLS connection** to the Cube AI Embeddings Service +- Retrieves and verifies the attestation report +- Validates enclave identity and security measurements +- Ensures the TLS key is cryptographically bound to the attested TEE +- Transparently forwards requests and responses -Confidential Computing provides strong isolation, but attestation ensures: +From the user's perspective, the client application communicates with the Proxy over **standard HTTPS**, while all attestation logic is handled automatically. -- The VM truly has confidential computing protections enabled -- The system hasn’t been modified by the cloud provider -- No unauthorized code is executed inside the confidential environment -- All model prompts and responses remain protected even from the host +--- -This is essential for: +## Attestation Policy Verification -- Enterprise deployments -- Regulated industries (healthcare, finance, defense, R&D) -- Zero-trust security architectures -- Protecting sensitive AI inputs and outputs +The Local Proxy enforces an **attestation policy** that defines the expected properties of the TEE. ---- +This policy includes: -## User-Facing Attestation +- Reference values for fields in the attestation report +- Expected measurements identifying the Cube AI Embeddings Service +- Verification that the TLS key is bound to the attested enclave -Cube AI exposes a user-facing attestation endpoint that allows applications -to verify that they are interacting with a trusted Cube AI instance. +Only if the attestation report satisfies the policy will the Proxy establish and maintain the aTLS connection. -### 🔹 Attestation Endpoint +--- -Applications can request an attestation report using: +## Security Guarantees -```bash -POST /attestation -``` +This design ensures that: -The returned attestation data can be validated by the client to ensure that the -Cube AI instance is running inside a trusted confidential computing environment. +- Plaintext input is visible only inside the TEE +- Embeddings are generated exclusively within the enclave +- The host OS, hypervisor, and cloud provider cannot access user data +- No manual attestation steps are required from users +- The client can trust the identity and integrity of the remote service From a69ee35eff6a9d8dfa5b1b038535858d9297e403 Mon Sep 17 00:00:00 2001 From: Filip Cviljak Date: Thu, 25 Dec 2025 17:45:11 +0100 Subject: [PATCH 2/5] docs: fix markdownlint issues in attestation.md --- docs/attestation.md | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) diff --git a/docs/attestation.md b/docs/attestation.md index b357236..e5c7fff 100644 --- a/docs/attestation.md +++ b/docs/attestation.md @@ -1,13 +1,15 @@ -## Attestation Overview +# Attestation Overview Attestation is a security mechanism that allows a client to **verify the identity and integrity of a remote system before sending sensitive data**. In the context of confidential computing, attestation provides cryptographic proof that an application is running: + - Inside a **Trusted Execution Environment (TEE)** - With **expected software and configuration** - Without interference from the host operating system, hypervisor, or cloud provider Attestation is a foundational building block for **zero-trust architectures**, where trust is never assumed and must always be verified. + For Cube AI, attestation ensures that sensitive prompts, embeddings, and responses are processed only by trusted and verified AI services. --- @@ -15,11 +17,13 @@ For Cube AI, attestation ensures that sensitive prompts, embeddings, and respons ## Attestation and Attested TLS (aTLS) To allow clients to send confidential data to Cube AI securely, a secure channel based on **Attested TLS (aTLS)** is established. + aTLS is a standard TLS connection augmented with a **hardware-backed attestation report** proving that the remote service is running inside a **Trusted Execution Environment (TEE)**. In Cube AI, the Embeddings Service acts as the TLS server and extends its **X.509 certificate** with an attestation report generated by the underlying TEE (e.g. AMD SEV-SNP). When generating the attestation report, the service embeds the **hash of its ephemeral public key** into the `report_data` field of the attestation report. + A new TLS certificate and a fresh attestation report are generated for every connection, ensuring cryptographic freshness and preventing replay attacks. This provides cryptographic proof that the client is communicating directly with the Cube AI service running inside a TEE, and not with the host system or any intermediary. @@ -32,11 +36,11 @@ Unlike other systems where users must manually perform attestation using a CLI t The Cube AI Local Proxy: -- Establishes the **aTLS connection** to the Cube AI Embeddings Service -- Retrieves and verifies the attestation report -- Validates enclave identity and security measurements -- Ensures the TLS key is cryptographically bound to the attested TEE -- Transparently forwards requests and responses +- Establishes the **aTLS connection** to the Cube AI Embeddings Service +- Retrieves and verifies the attestation report +- Validates enclave identity and security measurements +- Ensures the TLS key is cryptographically bound to the attested TEE +- Transparently forwards requests and responses From the user's perspective, the client application communicates with the Proxy over **standard HTTPS**, while all attestation logic is handled automatically. @@ -48,9 +52,9 @@ The Local Proxy enforces an **attestation policy** that defines the expected pro This policy includes: -- Reference values for fields in the attestation report -- Expected measurements identifying the Cube AI Embeddings Service -- Verification that the TLS key is bound to the attested enclave +- Reference values for fields in the attestation report +- Expected measurements identifying the Cube AI Embeddings Service +- Verification that the TLS key is bound to the attested enclave Only if the attestation report satisfies the policy will the Proxy establish and maintain the aTLS connection. @@ -60,8 +64,8 @@ Only if the attestation report satisfies the policy will the Proxy establish and This design ensures that: -- Plaintext input is visible only inside the TEE -- Embeddings are generated exclusively within the enclave -- The host OS, hypervisor, and cloud provider cannot access user data -- No manual attestation steps are required from users -- The client can trust the identity and integrity of the remote service +- Plaintext input is visible only inside the TEE +- Embeddings are generated exclusively within the enclave +- The host OS, hypervisor, and cloud provider cannot access user data +- No manual attestation steps are required from users +- The client can trust the identity and integrity of the remote service From d6eda76c72935e6a520535d424ae9161960882a3 Mon Sep 17 00:00:00 2001 From: Filip Cviljak Date: Mon, 12 Jan 2026 16:45:19 +0100 Subject: [PATCH 3/5] docs: Fix remarks --- docs/attestation.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/docs/attestation.md b/docs/attestation.md index e5c7fff..bd74788 100644 --- a/docs/attestation.md +++ b/docs/attestation.md @@ -20,7 +20,7 @@ To allow clients to send confidential data to Cube AI securely, a secure channel aTLS is a standard TLS connection augmented with a **hardware-backed attestation report** proving that the remote service is running inside a **Trusted Execution Environment (TEE)**. -In Cube AI, the Embeddings Service acts as the TLS server and extends its **X.509 certificate** with an attestation report generated by the underlying TEE (e.g. AMD SEV-SNP). +In Cube AI, the agent service running inside the TEE acts as the TLS server and extends its X.509 certificate with an attestation report generated by the underlying TEE (e.g. AMD SEV-SNP). When generating the attestation report, the service embeds the **hash of its ephemeral public key** into the `report_data` field of the attestation report. @@ -30,19 +30,20 @@ This provides cryptographic proof that the client is communicating directly with --- -## Local Proxy-Based Attestation +## Proxy-Based Attestation -Unlike other systems where users must manually perform attestation using a CLI tool, Cube AI fully automates the attestation process through a **Local Proxy** installed on the user's machine. +Unlike systems where users must manually perform attestation using a CLI tool, Cube AI automates the attestation process through a **proxy component deployed in the Cube AI infrastructure**. -The Cube AI Local Proxy: +The Cube AI Proxy: -- Establishes the **aTLS connection** to the Cube AI Embeddings Service -- Retrieves and verifies the attestation report -- Validates enclave identity and security measurements -- Ensures the TLS key is cryptographically bound to the attested TEE -- Transparently forwards requests and responses +- Forwards client connections to Cube AI services secured with **aTLS** +- Fetches and exposes attestation evidence associated with the aTLS-secured service endpoint +- Ensures that the TLS key is cryptographically bound to the attested TEE +- Provides auditability through structured logs and attestation records +- Transparently forwards client requests and responses -From the user's perspective, the client application communicates with the Proxy over **standard HTTPS**, while all attestation logic is handled automatically. +From the user's perspective, the client application communicates with Cube AI services over **standard HTTPS**. +Attestation evidence and aTLS verification can be inspected through audit logs or retrieved via the proxy without requiring any client-side deployment or manual verification steps. --- From 565164610a65b0983da65a4ff62cc8427178fe09 Mon Sep 17 00:00:00 2001 From: Filip Civljak Date: Mon, 2 Feb 2026 13:23:59 +0100 Subject: [PATCH 4/5] Add audit logs --- docs/attestation.md | 51 +++++++++++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 20 deletions(-) diff --git a/docs/attestation.md b/docs/attestation.md index bd74788..181b0ee 100644 --- a/docs/attestation.md +++ b/docs/attestation.md @@ -4,11 +4,11 @@ Attestation is a security mechanism that allows a client to **verify the identit In the context of confidential computing, attestation provides cryptographic proof that an application is running: -- Inside a **Trusted Execution Environment (TEE)** -- With **expected software and configuration** -- Without interference from the host operating system, hypervisor, or cloud provider +* Inside a **Trusted Execution Environment (TEE)** +* With **expected software and configuration** +* Without interference from the host operating system, hypervisor, or cloud provider -Attestation is a foundational building block for **zero-trust architectures**, where trust is never assumed and must always be verified. +Attestation is a foundational building block for **zero-trust architectures**, where trust is never assumed and must always be verified. For Cube AI, attestation ensures that sensitive prompts, embeddings, and responses are processed only by trusted and verified AI services. @@ -16,13 +16,13 @@ For Cube AI, attestation ensures that sensitive prompts, embeddings, and respons ## Attestation and Attested TLS (aTLS) -To allow clients to send confidential data to Cube AI securely, a secure channel based on **Attested TLS (aTLS)** is established. +To allow clients to send confidential data to Cube AI securely, a secure channel based on **Attested TLS (aTLS)** is established. aTLS is a standard TLS connection augmented with a **hardware-backed attestation report** proving that the remote service is running inside a **Trusted Execution Environment (TEE)**. In Cube AI, the agent service running inside the TEE acts as the TLS server and extends its X.509 certificate with an attestation report generated by the underlying TEE (e.g. AMD SEV-SNP). -When generating the attestation report, the service embeds the **hash of its ephemeral public key** into the `report_data` field of the attestation report. +When generating the attestation report, the service embeds the **hash of its ephemeral public key** into the `report_data` field of the attestation report. A new TLS certificate and a fresh attestation report are generated for every connection, ensuring cryptographic freshness and preventing replay attacks. @@ -36,14 +36,14 @@ Unlike systems where users must manually perform attestation using a CLI tool, C The Cube AI Proxy: -- Forwards client connections to Cube AI services secured with **aTLS** -- Fetches and exposes attestation evidence associated with the aTLS-secured service endpoint -- Ensures that the TLS key is cryptographically bound to the attested TEE -- Provides auditability through structured logs and attestation records -- Transparently forwards client requests and responses +* Forwards client connections to Cube AI services secured with **aTLS** +* Fetches and exposes attestation evidence associated with the aTLS-secured service endpoint +* Ensures that the TLS key is cryptographically bound to the attested TEE +* Provides auditability through structured logs and attestation records +* Transparently forwards client requests and responses From the user's perspective, the client application communicates with Cube AI services over **standard HTTPS**. -Attestation evidence and aTLS verification can be inspected through audit logs or retrieved via the proxy without requiring any client-side deployment or manual verification steps. +Attestation evidence can be retrieved directly through the proxy, while aTLS verification results are recorded in structured audit logs, without requiring any client-side deployment or manual verification steps. --- @@ -53,20 +53,31 @@ The Local Proxy enforces an **attestation policy** that defines the expected pro This policy includes: -- Reference values for fields in the attestation report -- Expected measurements identifying the Cube AI Embeddings Service -- Verification that the TLS key is bound to the attested enclave +* Reference values for fields in the attestation report +* Expected measurements identifying the Cube AI service running inside the TEE +* Verification that the TLS key is bound to the attested enclave + +![Event details](img/eventdetails.png) Only if the attestation report satisfies the policy will the Proxy establish and maintain the aTLS connection. --- +## aTLS Verification and Audit Logs + +Each successful aTLS handshake is recorded by the Cube AI Proxy in structured audit logs. +These audit log entries provide verifiable evidence that the connection was established with a TEE-backed Cube AI service and that attestation policy verification succeeded. + +![aTLS handshake audit log](img/atls-audit-log.png) + +Through these logs, users can audit completed aTLS handshakes and verify that no connections were established without successful attestation. + ## Security Guarantees This design ensures that: -- Plaintext input is visible only inside the TEE -- Embeddings are generated exclusively within the enclave -- The host OS, hypervisor, and cloud provider cannot access user data -- No manual attestation steps are required from users -- The client can trust the identity and integrity of the remote service +* Plaintext input is visible only inside the TEE +* Sensitive data and AI workloads are processed exclusively within the enclave +* The host OS, hypervisor, and cloud provider cannot access user data +* No manual attestation steps are required from users +* The client can trust the identity and integrity of the remote service From e5257b545d77e788f8e77b6bc3a3c883d3a97b81 Mon Sep 17 00:00:00 2001 From: Filip Civljak Date: Mon, 2 Feb 2026 13:28:07 +0100 Subject: [PATCH 5/5] Fix markdownlint CI --- docs/attestation.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/attestation.md b/docs/attestation.md index 181b0ee..9d65b89 100644 --- a/docs/attestation.md +++ b/docs/attestation.md @@ -76,8 +76,8 @@ Through these logs, users can audit completed aTLS handshakes and verify that no This design ensures that: -* Plaintext input is visible only inside the TEE -* Sensitive data and AI workloads are processed exclusively within the enclave -* The host OS, hypervisor, and cloud provider cannot access user data -* No manual attestation steps are required from users -* The client can trust the identity and integrity of the remote service +* Plaintext input is visible only inside the TEE +* Sensitive data and AI workloads are processed exclusively within the enclave +* The host OS, hypervisor, and cloud provider cannot access user data +* No manual attestation steps are required from users +* The client can trust the identity and integrity of the remote service