Developers often ask questions such as:

1. How can I generate an attestation report?

2. How can I prove to my users that my application is in a TEE?

3. What must I implement so that my users can verify it?

This blog post aims to address these questions with a practical explanation for leveraging Intel DCAP attestation—showing you how to customize the attestation report’s report_data field to prove that your application is running in a Trusted Execution Environment (TEE).

In our previous blog post, Understanding TDX Attestation Reports: A Developer’s Guide, we detailed the fields of an Attestation Report and explained how TEE hardware and user applications are measured. Here, we’ll walk through specific code examples and demonstrate how you can prove your application is running inside a TEE.

What Attestation Report Verification Offers

Similar to a Zero-Knowledge Proof, an Attestation Report in a TEE allows anyone to verify that the TEE is genuine. Moreover, it guarantees that data in the quote (the measurement of the TEE) can be considered trustworthy. Our focus here is slightly different: once we verify that the TEE is authentic, how do we prove a specific application is indeed running inside it?

Below is a typical Intel DCAP quote produced by Phala Cloud. Notice the report_data field:

{
  "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"
}

When the Attestation Report verifies successfully, it proves two things:

1. The TEE is genuine.

2. The fields in the quote—particularly report_data—are trusted and authentic.

To prove that your application is the one running in the TEE, you must demonstrate that your application alone sets the report_data in the quote. For instance, you could store a public key (unique to your application) in the report_data, then have your application sign messages with the corresponding private key. Anyone verifying both the signature and the attestation report can be confident the application in the TEE is yours.

Proving Application Identity in TEE

While the default attestation validates environmental integrity, proving specific application execution requires strategic use of the 64-byte report_data field. This user-controlled space enables application-level attestation through two complementary approaches:

1. Code Transparency

• Open-source your application code and make sure the build is reproducible

• Publish audited binary hashes generally are your docker image and docker compose file

• Make sure anyone can verify RTMR3 event-chain with tools like rtmr3-calculator with your instance’s attestation report

2. Cryptographic Proof of Control

• Generate asymmetric key pairs within TEE

• Embed public key in report_data

• Sign external data with private key

• Enable third-party verification through:
• Attestation report validation (public key integrity)
• Signature verification (private key possession)

This dual verification establishes a cryptographic link between the TEE environment and application identity.

Note: As a verifier, the mr_seam, mr_td, and rtmr[0-3] also should be used to check the integrity of the hardware environment and TDX base image with the exact values the provider claimed.

Generating a Custom Attestation Report

Phala Cloud automatically generates a default Attestation Report after you deploy an application; you can view it under the “Attestation” tab on the Phala Cloud dashboard.

You can also generate a customized Attestation Report (with your own report_data) by making two key configurations:

1. Configure the Docker Compose file to allow access to the TAPPD socket:

services:
  your_app:
    volumes:
      - /var/run/tappd.sock:/var/run/tappd.sock

Add the above volumes configuration to the service that will request the Attestation Report. This lets your application communicate with the TEE environment.

1. Generate the Attestation Report.

Phala provides an official library@phala/dstack-sdkfor convenience, but the following Python snippet (run via a Jupyter Notebook deployed on Phala Cloud) illustrates the basic workflow. The SDK internally sends a request over the Unix socket to obtain the quote (more details of socket API can be found here):

Here, report_data is set to 0x309ecc489c12d6eb4cc40f50c902f2b4d0ed77ee511a7c7a9bcd3ca86d4cd86f989dd35bc5ff499670da34255b45b0cfd830e81f605dcf7dc5542e93ae9cd76f , which is the sha512 output of “hello world”.

import http.client, json, socket

# Set application-specific evidence
custom_evidence = {
    "report_data": "0x309ecc489c12d6eb4cc40f50c902f2b4d0ed77ee511a7c7a9bcd3ca86d4cd86f989dd35bc5ff499670da34255b45b0cfd830e81f605dcf7dc5542e93ae9cd76f",  # 64-byte field
    "hash_algorithm": "raw"
}

sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.connect("/var/run/tappd.sock")

conn = http.client.HTTPConnection("localhost")
conn.sock = sock
conn.request("POST", "/prpc/Tappd.TdxQuote?json", 
             body=json.dumps(custom_evidence), 
             headers={"Content-Type": "application/json"})

response = conn.getresponse()
print(json.dumps(json.loads(response.read()), indent=2))

You can customize this to anything you’d like. After running the code, the notebook will display the generated quote in the console.

Verifying the Attestation Report

After obtaining the attestation quote from Phala Cloud, use any DCAP-compatible verifier to validate it. For example, https://proof.t16z.com/ relies on dcap-qvl. Other verifiers exist, including on-chain solutions like Automata’s Solidity implementation.

To verify the quote you generated, copy the quote’s hexadecimal data from your console and paste it into https://proof.t16z.com/. After verification, you can scroll through the report contents to confirm that report_data matches the value you defined.

Prove Your App by Customizing report_data

The key step in proving that it’s your application inside the TEE is customizing the report_data. In code, you can do it like this:

// Get a TDX quote for the given custom data and hash algorithm.
const quoteResult = await client.tdxQuote('user-data', 'raw');

The document is guide you generate attestation report through @phala/dstack-sdk, make sure you set hash algorithm to ‘raw’.

However, you shouldn’t store arbitrary data here. Instead, store something only your application can produce or control. A secure option is to generate a key pair inside your application and embed the public key in report_data. Because this key pair is unique to your application (and ideally derived from your application’s root key through Phala’s Key Management Service), only your application can produce valid signatures with the corresponding private key.

Anyone verifying the custom Attestation Report (and the signature produced by your application) can be confident that what they see in report_data tightly couples the quote to your specific software running inside a genuine TEE.

Conclusion

By customizing your Attestation Report with application-specific data in the report_data field, you demonstrate that only your software, running within a genuine TEE, can produce particular, verifiable information. This approach assures users that your application is not only securely isolated but also provably tied to a trusted environment. Integrating public key infrastructure, for example, further reinforces application authenticity. By verifying the Attestation Report and validating these unique identifiers or signatures, anyone can confirm that the correct software is operating securely inside the TEE.

Try Phala Cloud

• Get started by deploying CVM in TEE, enjoy $400 credit on us!

• Join the Telegram chat for any questions on how to run your CVM.

• View Phala Cloud Blog for insights on the technical stack.

• Last but not the least explore our documentation for a quick overview on how to get started.