diff --git a/images/cloud-cert-chain.png b/images/cloud-cert-chain.png deleted file mode 100644 index 9da1027..0000000 Binary files a/images/cloud-cert-chain.png and /dev/null differ diff --git a/phala-cloud/attestation/api-quickstart.mdx b/phala-cloud/attestation/api-quickstart.mdx index 649dde1..4bfd697 100644 --- a/phala-cloud/attestation/api-quickstart.mdx +++ b/phala-cloud/attestation/api-quickstart.mdx @@ -1,9 +1,9 @@ --- -description: Get a shareable Intel DCAP quote verified with Phala Cloud's API in 5 minutes +description: Learn how to verify Intel TDX attestation quotes using Phala Cloud's API. title: Cloud Attestation API --- -## Verify Your Quote in 5 Minutes +## Verify your quote You have an attestation quote and want to verify it using Phala Cloud's API. This guide gets you working fast. diff --git a/phala-cloud/attestation/get-attestation.mdx b/phala-cloud/attestation/get-attestation.mdx index 976f1b2..344f7f3 100644 --- a/phala-cloud/attestation/get-attestation.mdx +++ b/phala-cloud/attestation/get-attestation.mdx @@ -1,69 +1,110 @@ --- -description: Generate Intel SGX and TDX attestation quotes using DStack SDK and Phala Cloud platform -title: Generate Attestation +description: Learn how to get CVM attestation on Phala Cloud using dashboard or dstack SDK. +title: Get Attestation --- -The cloud will generate a default RA report for your application when it is bootstrapped. You can view this report on the dashboard under the **Attestation** tab and verify it by clicking the **Check** **Attestation** button. +## Introduction - - cert-chain - +There are two ways to retrieve the attestation report of your CVM on Phala Cloud: -There are two steps needed to generate a new RA report, rather than using the default one, which allows you to prove the execution of your code. +1. **Dashboard** - View the default attestation report on the dashboard +2. **dstack SDK** - Generate a new attestation report programmatically within your application -### Config docker compose file +Choose the method that best fits your workflow. The dashboard is great for quick verification, while the SDK enables dynamic attestation generation in your applications. -This Docker Compose file spins up a Jupyter Notebook environment, and importantly, it's configured the `volumes` to connect to the Dstack API by mounting its socket file (`/var/run/tappd.sock`) into the container. This allows the Jupyter Notebook running inside the TEE to interact with the Dstack service like generate a remote attestation, get a TLS key, or generate a key for chains like ETH (`ECDSA, K256 curve`) or SOL (`ed25519`). +## View attestation report on dashboard -For development convenience, this setup grants sudo privileges inside the container (`environment`), runs the Jupyter server with root user permissions (`user`), and starts the notebook with token-based authentication using the `TOKEN` environment variable (`command`). +You can view the attestation report on the dashboard under the **Attestation** tab and verify it by clicking the **Check Attestation** button. -```yaml -version: '3' -services: - jupyter: - image: quay.io/jupyter/base-notebook - ports: - - 8080:8888 - volumes: - - /var/run/tappd.sock:/var/run/tappd.sock - environment: - - GRANT_SUDO=yes - user: root - command: "start-notebook.sh --NotebookApp.token=${TOKEN}" -``` - -### Generate RA report inside your application code +## Generate attestation programmatically -In your application, you can generate the RA report using the [Dstack SDK](https://www.npmjs.com/package/@phala/dstack-sdk?activeTab=readme), which supports Python, JS, and Go. The `user-data` argument allows you to attach your own data to the RA report. +### Using dstack SDK -```javascript -import { TappdClient } from '@phala/dstack-sdk'; +In your CVM application, you can generate attestation reports programmatically using the [dstack SDK](https://www.npmjs.com/package/@phala/dstack-sdk?activeTab=readme), which supports Python, JavaScript, and Go. The `user-data` argument allows you to attach custom data to the attestation report. -const client = new TappdClient(); + +```javascript TypeScript +import { DstackClient } from '@phala/dstack-sdk'; -// Show the information of the Base Image. -await client.info(); - -// Get a TDX quote for the given custom data and hash algorithm. -const quoteResult = await client.tdxQuote('user-data', 'sha256'); -console.log(quoteResult.quote); // TDX quote in hex format -console.log(quoteResult.event_log); // Event log -const rtmrs = quoteResult.replayRtmrs(); // Replay RTMRs -``` +const client = new DstackClient(); -You can implement the above code in your application as an public API that anyone can call to generate a new RA report. +// Get TEE instance information +const info = await client.info(); +console.log('App ID:', info.app_id); +console.log('Instance ID:', info.instance_id); +console.log('App Name:', info.app_name); +console.log('TCB Info:', info.tcb_info); -### Next Steps +// Generate remote attestation quote with custom data +const applicationData = JSON.stringify({ + version: '1.0.0', + timestamp: Date.now(), + user_id: 'alice' +}); -Once you have your quote generated, you can: +const quote = await client.getQuote(applicationData); +console.log('TDX Quote:', quote.quote); +console.log('Event Log:', quote.event_log); -1. **[Verify with API](/phala-cloud/attestation/api-quickstart)** - Upload your quote to Phala Cloud for verification -2. **[Understand the Data](/phala-cloud/attestation/overview)** - Learn what each field in your quote means -3. **[API Reference](/phala-cloud/phala-cloud-api/attestations)** - Complete verification service documentation - -### Use Cases +// Verify measurement registers +const rtmrs = quote.replayRtmrs(); +console.log('RTMR0-3:', rtmrs); +``` -The `user-data` field enables powerful applications: -- **Key Binding**: Set a public key as user-data, then sign messages with the private key -- **Identity Proof**: Include application identifiers or certificates -- **Challenge Response**: Respond to verification challenges from remote parties +```python Python +import json +import time +from dstack_sdk import DstackClient + +# Create synchronous client - automatically connects to /var/run/dstack.sock +client = DstackClient() + +# Get TEE instance information +info = client.info() +print('App ID:', info.app_id) +print('Instance ID:', info.instance_id) +print('App Name:', info.app_name) +print('TCB Info:', info.tcb_info) + +# Generate remote attestation quote +application_data = json.dumps({ + "version": "1.0.0", + "timestamp": time.time(), + "user_id": "alice" +}) + +quote = client.get_quote(application_data.encode()) +print('TDX Quote:', quote.quote) +print('Event Log:', quote.event_log) + +# Verify measurement registers +rtmrs = quote.replay_rtmrs() +print('RTMR0-3:', rtmrs) +``` + + +You can implement this code in your application as a public API that anyone can call to generate new attestation reports on demand. + +## Next steps + +Once you have your attestation quote generated, you can: + + + + Learn how to verify your attestation quote using Phala Cloud's API + + + + Get started with Phala Cloud's attestation verification API + + diff --git a/phala-cloud/attestation/overview.mdx b/phala-cloud/attestation/overview.mdx index 50b0b3b..a130d2d 100644 --- a/phala-cloud/attestation/overview.mdx +++ b/phala-cloud/attestation/overview.mdx @@ -1,230 +1,59 @@ --- -description: Understanding remote attestation reports, verification process, and key fields in TEE security -title: Understanding Attestation +description: Learn about attestation and how to get and verify your CVM attestation on Phala Cloud. +title: Overview --- +## Why attestation matters -## Introduction +Attestation (also called Remote Attestation) is a critical security mechanism in TEE environments. It allows a remote verifier to confirm that an application is running inside a genuine, secure TEE with the expected configuration and code. -Remote Attestation (RA) is a critical security mechanism in Trusted Execution Environments (TEEs) like Intel TDX. It allows a remote verifier to confirm that an application is running inside a genuine, secure TEE with the expected configuration and code. This guide explains the key fields in TEE attestation reports, with a specific focus on Intel TDX attestation as used by Phala Cloud. +With attestation, you get cryptographic proof that: -Let’s get into it! +- **TEE hardware stack is authentic** - Your CVM runs on genuine Intel hardware with TEE protections enabled +- **TEE software stack is untampered** - The entire software stack from OS to application code is verified +- **Environment is secure** - Your workloads run in a protected TEE environment -## Attestation Report Overview +## How attestation works -An attestation report (or "quote") is a cryptographically signed document containing evidence about the TEE environment, including hardware measurements, runtime measurements, and application-specific data. The Attestation Key sealed by the manufactory in the Quoting Enclave will be used to sign the quote when received request from Challenger. When the remote Challenger receives this report, it can validate that the environment meets expected security properties before trusting it with sensitive data or operations. +Attestation creates a cryptographic proof that binds together: - - - +1. **TEE hardware stack** - Intel TDX CPU measurements and security features +2. **TEE software stack** - OS image, application code, and runtime environment +3. **Custom data** - Optional user-provided data for application-specific verification -Source: [https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html](https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html) +This proof can be independently verified by anyone to confirm the security and authenticity of your CVM. -### Key Fields in a TDX Attestation Report +## Quick start -Here is an example report generated on Phala Cloud: + + + Learn how to retrieve attestation reports using dashboard or dstack SDK + -```bash -{ - "tee_tcb_svn": "06010300000000000000000000000000", - "mr_seam": "5b38e33a6487958b72c3c12a938eaa5e3fd4510c51aeeab58c7d5ecee41d7c436489d6c8e4f92f160b7cad34207b00c1", - "mr_signer_seam": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "seam_attributes": "0000000000000000", - "td_attributes": "0000001000000000", - "xfam": "e702060000000000", - "mr_td": "c68518a0ebb42136c12b2275164f8c72f25fa9a34392228687ed6e9caeb9c0f1dbd895e9cf475121c029dc47e70e91fd", - "mr_config_id": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "mr_owner": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "mr_owner_config": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "rt_mr0": "85e0855a6384fa1c8a6ab36d0dcbfaa11a5753e5a070c08218ae5fe872fcb86967fd2449c29e22e59dc9fec998cb6547", - "rt_mr1": "9b43f9f34a64bc7191352585be0da1774a1499e698ba77cbf6184547d53d1770d6524c1cfa00b86352f273fc272a8cfe", - "rt_mr2": "7cc2dadd5849bad220ab122c4fbf25a74dc91cc12702447d3b5cac0f49b2b139994f5cd936b293e5f0f14dea4262d668", - "rt_mr3": "2c482b5b34f6902293bc203696f407241bfa319d2410a04c604d1021888d6028bf4bd280ff859ee270a0429aac5f0d82", - "report_data": "afab9790acb13c4c651c1933a22b5f0663ef22927120dd08cc8291d7e0912d8b1c36eb75cf661a64735042f8e81bbe42cb9ab310ca95bf8d36c44cb8835c901f" -} -``` + + Verify your attestation reports using Phala Cloud's API or manual methods + -You can check those information at the **CVM Dashboard→Attestation** page. + + Get started with Phala Cloud's attestation verification API + + - - - +## Next steps -Now, let’s dive into each field and learn what it represents. - -### Hardware Identity and Security Fields - -#### `tee_tcb_svn` - -The Trusted Computing Base Security Version Number. - -* **Meaning**: This represents the security patch level and version information for the TEE hardware components -* **Verification Use**: Crucial for ensuring the platform has the latest security patches against known vulnerabilities. - -#### `MRSEAM` (Measurement of TDX-Module) - -The cryptographic measurement of the SEAM (Secure Arbitration Mode) firmware. - -* **Meaning**: A hash representing the identity and integrity of the TDX module firmware. -* **Verification Use**: Verifies that the TDX firmware hasn't been tampered with and is a known, trusted version. - -#### `MRTD` (Measurement Register for Trust Domain) - -A cryptographic measurement of the initial TD memory contents and configuration. - -* **Meaning**: Captures the initial state of the TD (Trust Domain) when it was created. Measurement of TDVF. -* **Verification Use**: Ensures the TD was initialized with expected memory contents and configuration. - -### Runtime Measurement Fields - -#### `RTMR0`, `RTMR1`, `RTMR2` (Runtime Measurement Registers) - -Registers that contain hash chains of measurements of components loaded during boot. - -* **Meaning**: Each register measures a different aspect of the boot process: - * `RTMR0`: Measurement of virtual hardware environment - * `RTMR1`: Measurement of Linux kernel - * `RTMR2`: Measurement of kernel cmdline and initrd -* **Verification Use**: Verifies that the expected boot components were loaded, ensuring the integrity of the boot chain. - -#### `RTMR3` (Application-specific Measurement Register) - -In dstack's implementation, RTMR3 is dedicated to application-specific measurements. - -* **Meaning**: Measurements of application components including app-id, compose-hash, instance-id, and key-provider. -* **Verification Use**: Can be used to confirm the application running in the TEE has the expected code and configuration. - -### Additional TEE Configuration Fields - -#### `seamattributes` - -Attributes of the SEAM (Secure Arbitration Mode). - -* **Meaning**: Configuration flags for the SEAM firmware. -* **Verification Use**: Always zeros for TDX-module. - -#### `tdattributes` - -Attributes of the Trust Domain. - -* **Meaning**: Configuration flags for the TD (Trust Domain). -* **Verification Use**: Verifies the TD has the expected security settings. - -#### `xfam` (eXtended Feature Activation Mask) - -Controls which extended features are enabled in the TDX environment. - -* **Meaning**: Specifies which extended CPU features are accessible to the TD. -* **Verification Use**: Ensures the TD has access to the expected CPU features while maintaining security boundaries. - -#### Application-specific Fields - -#### `reportData` - -User-specified data that gets included in the quote. - -* **Meaning**: A 64-byte field that applications can fill with custom data (such as nonces, challenge responses, or application state hashes). -* **Verification Use**: Binds application-specific data to the hardware attestation, allowing for challenge-response protocols or linking to application state. - -#### `mrconfig`, `mrowner`, and `mrownerconfig` - -Configuration and ownership information. - -* **Example Values**: (Usually all zeros for dstack) -* **Meaning**: These fields can contain configuration data for more complex attestation scenarios. -* **Verification Use**: Generally not used in basic attestation but may be important in advanced scenarios. - -### RTMR3 Event Chain: How Application Components Are Measured - -In dstack's implementation, application components are measured and stored in RTMR3 through a hash chain mechanism: - -* **Component Measurement**: Each application component (compose-hash, instance-id, key-provider) is individually hashed. -* **Event Creation**: Measurement events are created with key-value pairs (e.g., "app-id": "your-app-123"). -* **Event Hashing**: Each event is hashed (e.g., Event0 → Hash(0x11111)). -* **RTMR3 Extension**: The hash chain is extended using the formula: - -``` -RTMR3_new = SHA384(RTMR3_old || SHA384(event)) -``` - -* **Verification**: The final RTMR3 value can be verified against a known-good value to ensure the application components haven't been modified. - -When you deployed your application on Phala Cloud, you can verify the RTMR3 with the data shown in dashboard attestation page. You can do it with a community tool called [rtmr3-calculator](https://rtmr3-calculator.vercel.app/). - - - - - -_The source code of the rtmr3-calculator:_ [_https://github.com/propeller-heads/rtmr3-calculator_](https://github.com/propeller-heads/rtmr3-calculator) - -## Verification Process - -When verifying an attestation report, follow these steps: - -1. **Verify Signature**: Ensure the attestation report is properly signed by a valid TEE certificate. -2. **Verify Certificate Chain**: Validate the entire certificate chain back to a trusted root. -3. **Check Hardware Identity**: Verify MRSEAM, and TCB values match known-good values. -4. **Verify System Measurements**: Ensure MRTD, RTMR0-2 values match your security policy. -5. **Verify Application Measurements**: Check that RTMR3 contains the expected hash of your application components. -6. **Verify ReportData**: If you used a challenge-response mechanism, verify the reportData contains the expected response. - -### Common Verification Targets - -In a typical attestation verification flow, you'll check: - - - -**Hardware Integrity**: Ensuring genuine, up-to-date, and properly configured TEE hardware. - -* Fields: `tee_tcb_svn` (or **tcbStatus**, **advisoryIds**), `MRSEAM` - - - -**System Integrity**: Verifying the System running in the TEE. - -* Fields: `MRTD`, `RTMR0`, `RTMR1`, `RTMR2` - - - -**Application Integrity**: Verifying the application running in the TEE is the expected one. - -* Fields: `RTMR3` - - - -**Identity Authentication**: Confirming the TEE has the expected identity for secure communication. - -* This often involves TLS certificates, blockchain wallet addresses, or other identity proofs embedded in `reportData` - - - -### dstack-Specific Verification - -When working with dstack TEE deployments, pay special attention to: - -1. **app-id Verification**: This field is relevant when the CVM is deployed with KMS, which generates application keys based on the app-id. -2. **compose-hash Verification**: The manifest hash of the currently executing application. This determines the application code executing within the TEE. -3. **key-provider Verification**: Indicates who distributed the keys for the App. The key is used to encrypt the root filesystem of the CVM. Therefore, it’s important to verify this field. -4. **reportData**: TLS certificates, blockchain wallet addresses, and social proofs like Twitter handles can be verified through the reportData field. - -Check more instructions [here](https://github.com/Dstack-TEE/dstack/blob/master/attestation.md) on how Dstack attestation work. - -## Next Steps - -Now that you understand attestation data, explore these practical guides: - -- **[Generate Attestation](/phala-cloud/attestation/get-attestation)** - Create quotes using dstack SDK -- **[API Quick Start](/phala-cloud/attestation/api-quickstart)** - Verify quotes with Phala Cloud API -- **[API Reference](/phala-cloud/phala-cloud-api/attestations)** - Complete endpoint documentation - -## External Resources - -- **Intel TDX Module Documentation** - Official Intel specifications -- **dstack Attestation Guide** - [https://github.com/dstack-TEE/dstack/blob/master/attestation.md](https://github.com/dstack-TEE/dstack/blob/master/attestation.md) -- **Verification Script Example** - [https://github.com/Dstack-TEE/dstack-examples/blob/main/attestation/rtmr3-based/verify.py](https://github.com/Dstack-TEE/dstack-examples/blob/main/attestation/rtmr3-based/verify.py) - -## Public PCCS Server - -We host a public PCCS server: `https://pccs.phala.network/sgx/certification/v4/`. - -When you want to run a local verifier like [`dcap-qvl`](https://github.com/Phala-Network/dcap-qvl), you can use this PCCS server to get the quote collaterals for verification. +Ready to get started? Begin with [Getting Attestation](/phala-cloud/attestation/get-attestation) to learn how to retrieve attestation reports from your CVM. diff --git a/phala-cloud/attestation/verifying-attestation.mdx b/phala-cloud/attestation/verifying-attestation.mdx index 57970aa..e9bcd15 100644 --- a/phala-cloud/attestation/verifying-attestation.mdx +++ b/phala-cloud/attestation/verifying-attestation.mdx @@ -1,225 +1,108 @@ --- -description: Security features and remote attestation capabilities of Phala Cloud - TEE. -title: Verifying +description: Learn how to verify remote attestation of CVM on Phala Cloud TEE. +title: Verifying Attestation --- +## Why verify attestation -## Introduction +Verifying attestation ensures your CVM runs in genuine TEE hardware with authentic software. This gives you cryptographic proof that: -Remote Attestation (RA) is a critical security mechanism in Trusted Execution Environments (TEEs) like Intel TDX. It allows a remote verifier to confirm that an application is running inside a genuine, secure TEE with the expected configuration and code. This guide explains the key fields in TEE attestation reports, with a specific focus on Intel TDX attestation as used by Phala Cloud. +- **TEE hardware stack is authentic** - Intel CPUs have TEE protections enabled +- **TEE software stack is untampered** - The entire software stack from OS to application code is verified +- **Environment is secure** - Your workloads run in a protected TEE environment -Let’s get into it! +## Verification methods -## Attestation Report Overview +### Method 1: Cloud API (Recommended) -An attestation report (or "quote") is a cryptographically signed document containing evidence about the TEE environment, including hardware measurements, runtime measurements, and application-specific data. The Attestation Key sealed by the manufactory in the Quoting Enclave will be used to sign the quote when received request from Challenger. When the remote Challenger receives this report, it can validate that the environment meets expected security properties before trusting it with sensitive data or operations. +The easiest way to verify attestation is using Phala Cloud's API: - - - - -Source: [https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html](https://www.intel.com/content/www/us/en/developer/tools/software-guard-extensions/attestation-services.html) - -### Key Fields in a TDX Attestation Report +```bash +curl -X POST "https://cloud-api.phala.network/api/v1/attestations/verify" \ + -H "Content-Type: application/json" \ + -d '{"hex": "0x040002000..."}' +``` -Here is an example report generated on Phala Cloud: +This returns a verification result and a shareable proof URL: -```bash +```json { - "tee_tcb_svn": "06010300000000000000000000000000", - "mr_seam": "5b38e33a6487958b72c3c12a938eaa5e3fd4510c51aeeab58c7d5ecee41d7c436489d6c8e4f92f160b7cad34207b00c1", - "mr_signer_seam": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "seam_attributes": "0000000000000000", - "td_attributes": "0000001000000000", - "xfam": "e702060000000000", - "mr_td": "c68518a0ebb42136c12b2275164f8c72f25fa9a34392228687ed6e9caeb9c0f1dbd895e9cf475121c029dc47e70e91fd", - "mr_config_id": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "mr_owner": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "mr_owner_config": "000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "rt_mr0": "85e0855a6384fa1c8a6ab36d0dcbfaa11a5753e5a070c08218ae5fe872fcb86967fd2449c29e22e59dc9fec998cb6547", - "rt_mr1": "9b43f9f34a64bc7191352585be0da1774a1499e698ba77cbf6184547d53d1770d6524c1cfa00b86352f273fc272a8cfe", - "rt_mr2": "7cc2dadd5849bad220ab122c4fbf25a74dc91cc12702447d3b5cac0f49b2b139994f5cd936b293e5f0f14dea4262d668", - "rt_mr3": "2c482b5b34f6902293bc203696f407241bfa319d2410a04c604d1021888d6028bf4bd280ff859ee270a0429aac5f0d82", - "report_data": "afab9790acb13c4c651c1933a22b5f0663ef22927120dd08cc8291d7e0912d8b1c36eb75cf661a64735042f8e81bbe42cb9ab310ca95bf8d36c44cb8835c901f" + "success": true, + "quote": { + "verified": true, + "header": { "tee_type": "TEE_TDX" } + }, + "checksum": "9aa049fb9049d4f582ca316206f7cf34ee185c2b5b63370a518921432385b81a" } ``` -You can check those information at the **CVM Dashboard→Attestation** page. - - - - - -Now, let’s dive into each field and learn what it represents. - -### Hardware Identity and Security Fields - -#### `tee_tcb_svn` - -The Trusted Computing Base Security Version Number. - -* **Meaning**: This represents the security patch level and version information for the TEE hardware components -* **Verification Use**: Crucial for ensuring the platform has the latest security patches against known vulnerabilities. - -#### `MRSEAM` (Measurement of TDX-Module) - -The cryptographic measurement of the SEAM (Secure Arbitration Mode) firmware. - -* **Meaning**: A hash representing the identity and integrity of the TDX module firmware. -* **Verification Use**: Verifies that the TDX firmware hasn't been tampered with and is a known, trusted version. - -#### `MRTD` (Measurement Register for Trust Domain) - -A cryptographic measurement of the initial TD memory contents and configuration. - -* **Meaning**: Captures the initial state of the TD (Trust Domain) when it was created. Measurement of TDVF. -* **Verification Use**: Ensures the TD was initialized with expected memory contents and configuration. - -### Runtime Measurement Fields - -#### `RTMR0`, `RTMR1`, `RTMR2` (Runtime Measurement Registers) - -Registers that contain hash chains of measurements of components loaded during boot. - -* **Meaning**: Each register measures a different aspect of the boot process: - * `RTMR0`: Measurement of virtual hardware environment - * `RTMR1`: Measurement of Linux kernel - * `RTMR2`: Measurement of kernel cmdline and initrd -* **Verification Use**: Verifies that the expected boot components were loaded, ensuring the integrity of the boot chain. - -#### `RTMR3` (Application-specific Measurement Register) - -In dstack's implementation, RTMR3 is dedicated to application-specific measurements. - -* **Meaning**: Measurements of application components including app-id, compose-hash, instance-id, and key-provider. -* **Verification Use**: Can be used to confirm the application running in the TEE has the expected code and configuration. - -### Additional TEE Configuration Fields - -#### `seamattributes` - -Attributes of the SEAM (Secure Arbitration Mode). - -* **Meaning**: Configuration flags for the SEAM firmware. -* **Verification Use**: Always zeros for TDX-module. - -#### `tdattributes` - -Attributes of the Trust Domain. - -* **Meaning**: Configuration flags for the TD (Trust Domain). -* **Verification Use**: Verifies the TD has the expected security settings. - -#### `xfam` (eXtended Feature Activation Mask) - -Controls which extended features are enabled in the TDX environment. - -* **Meaning**: Specifies which extended CPU features are accessible to the TD. -* **Verification Use**: Ensures the TD has access to the expected CPU features while maintaining security boundaries. - -#### Application-specific Fields - -#### `reportData` - -User-specified data that gets included in the quote. - -* **Meaning**: A 64-byte field that applications can fill with custom data (such as nonces, challenge responses, or application state hashes). -* **Verification Use**: Binds application-specific data to the hardware attestation, allowing for challenge-response protocols or linking to application state. - -#### `mrconfig`, `mrowner`, and `mrownerconfig` - -Configuration and ownership information. - -* **Example Values**: (Usually all zeros for dstack) -* **Meaning**: These fields can contain configuration data for more complex attestation scenarios. -* **Verification Use**: Generally not used in basic attestation but may be important in advanced scenarios. - -### RTMR3 Event Chain: How Application Components Are Measured - -In dstack's implementation, application components are measured and stored in RTMR3 through a hash chain mechanism: - -* **Component Measurement**: Each application component (compose-hash, instance-id, key-provider) is individually hashed. -* **Event Creation**: Measurement events are created with key-value pairs (e.g., "app-id": "your-app-123"). -* **Event Hashing**: Each event is hashed (e.g., Event0 → Hash(0x11111)). -* **RTMR3 Extension**: The hash chain is extended using the formula: - +**Share verification proof:** ``` -RTMR3_new = SHA384(RTMR3_old || SHA384(event)) +https://proof.t16z.com/reports/9aa049fb9049d4f582ca316206f7cf34ee185c2b5b63370a518921432385b81a ``` -* **Verification**: The final RTMR3 value can be verified against a known-good value to ensure the application components haven't been modified. - -When you deployed your application on Phala Cloud, you can verify the RTMR3 with the data shown in dashboard attestation page. You can do it with a community tool called [rtmr3-calculator](https://rtmr3-calculator.vercel.app/). +### Method 2: Manual verification - - - +For advanced users who want to verify attestation manually: -_The source code of the rtmr3-calculator:_ [_https://github.com/propeller-heads/rtmr3-calculator_](https://github.com/propeller-heads/rtmr3-calculator) +1. **Extract Intel TDX quote** from your attestation report +2. **Verify quote signature** using Intel's root certificates +3. **Check TCB status** to ensure no security vulnerabilities +4. **Validate measurements** against expected values -## Verification Process +```python +# Example using Intel DCAP libraries +from sgx_dcap_quote_verify import DCAPQuoteVerifier -When verifying an attestation report, follow these steps: +verifier = DCAPQuoteVerifier() +result = verifier.verify_quote(quote_data) -1. **Verify Signature**: Ensure the attestation report is properly signed by a valid TEE certificate. -2. **Verify Certificate Chain**: Validate the entire certificate chain back to a trusted root. -3. **Check Hardware Identity**: Verify MRSEAM, and TCB values match known-good values. -4. **Verify System Measurements**: Ensure MRTD, RTMR0-2 values match your security policy. -5. **Verify Application Measurements**: Check that RTMR3 contains the expected hash of your application components. -6. **Verify ReportData**: If you used a challenge-response mechanism, verify the reportData contains the expected response. - -### Common Verification Targets - -In a typical attestation verification flow, you'll check: - - - -**Hardware Integrity**: Ensuring genuine, up-to-date, and properly configured TEE hardware. +if result.is_valid: + print("Quote verified successfully") + print(f"TEE Type: {result.tee_type}") + print(f"TCB Status: {result.tcb_status}") +else: + print(f"Verification failed: {result.error_message}") +``` -* Fields: `tee_tcb_svn` (or **tcbStatus**, **advisoryIds**), `MRSEAM` - +## What gets verified - -**System Integrity**: Verifying the System running in the TEE. +When you verify attestation, these key components are checked: -* Fields: `MRTD`, `RTMR0`, `RTMR1`, `RTMR2` - +### TEE hardware stack verification +- **Intel TDX CPU** - Genuine Intel hardware with TEE enabled +- **Security features** - All TEE protections are active +- **Firmware integrity** - No tampering with system firmware - -**Application Integrity**: Verifying the application running in the TEE is the expected one. +### TEE software stack verification +- **Operating system** - Verified OS image with known measurements +- **Application code** - Hash of your deployed application +- **Runtime environment** - Secure boot chain and trusted execution -* Fields: `RTMR3` - +### Security verification +- **No vulnerabilities** - TCB status shows no known security issues +- **Freshness** - Quote was generated recently +- **Authenticity** - Cryptographic proof from Intel's root of trust - -**Identity Authentication**: Confirming the TEE has the expected identity for secure communication. +## Verification workflow -* This often involves TLS certificates, blockchain wallet addresses, or other identity proofs embedded in `reportData` - + + + Generate or retrieve an attestation quote from your CVM using the dashboard or dstack SDK. + + + Upload your quote to Phala Cloud's verification API or verify manually using Intel tools. + + + Check the verification status, TCB information, and get a shareable proof URL. + + + Use the verification proof URL to demonstrate your CVM's security to third parties. + -### dstack-Specific Verification - -When working with dstack TEE deployments, pay special attention to: - -1. **app-id Verification**: This field is relevant when the CVM is deployed with KMS, which generates application keys based on the app-id. -2. **compose-hash Verification**: The manifest hash of the currently executing application. This determines the application code executing within the TEE. -3. **key-provider Verification**: Indicates who distributed the keys for the App. The key is used to encrypt the root filesystem of the CVM. Therefore, it’s important to verify this field. -4. **reportData**: TLS certificates, blockchain wallet addresses, and social proofs like Twitter handles can be verified through the reportData field. - -Check more instructions [here](https://github.com/Dstack-TEE/dstack/blob/master/attestation.md) on how Dstack attestation work. - -## Conclusion - -Understanding attestation reports is crucial for developers working with TEE environments. By correctly interpreting these fields, you can verify that your application is running in a genuine, secure environment with the expected configuration and code. - -For more detailed information on Intel TDX attestation, refer to the Intel TDX Module documentation. For dstack-specific attestation flows, consult the dstack documentation and GitHub repository at [https://github.com/dstack-TEE/dstack](https://github.com/dstack-TEE/dstack). - -Full verification script: [https://github.com/Dstack-TEE/dstack-examples/blob/main/attestation/rtmr3-based/verify.py](https://github.com/Dstack-TEE/dstack-examples/blob/main/attestation/rtmr3-based/verify.py) - -## Public PCCS Server - -We host a public PCCS server: `https://pccs.phala.network/sgx/certification/v4/`. +## Next steps -When you want to run a local verifier like [`dcap-qvl`](https://github.com/Phala-Network/dcap-qvl), you can use this PCCS server to get the quote collaterals for verification. +- **[Get Attestation](/phala-cloud/attestation/get-attestation)** - Learn how to generate attestation quotes +- **[API Quickstart](/phala-cloud/attestation/api-quickstart)** - Use Phala Cloud's verification API +- **[API Reference](/phala-cloud/phala-cloud-api/attestations)** - Complete verification service documentation diff --git a/phala-cloud/confidential-ai/verify/verify-signature.mdx b/phala-cloud/confidential-ai/verify/verify-signature.mdx index a012f0e..43f232b 100644 --- a/phala-cloud/confidential-ai/verify/verify-signature.mdx +++ b/phala-cloud/confidential-ai/verify/verify-signature.mdx @@ -76,6 +76,4 @@ This gives you an independent third-party verification that the signature is val For a full implementation that verifies both attestation and signatures, see the [signature verifier example](https://github.com/Phala-Network/confidential-ai-verifier/blob/f606cf8675b6d920cdec49f46c5624cbcd7f2f16/examples/signature_verifier.py). -## What's next - You've now verified both the TEE environment (attestation) and individual AI responses (signatures). Your Confidential AI setup is fully verified and trustworthy.