TEE: TPM-Based Approach to Code and Location Verification

[executed]

Hello folks. It's a pleasure finding this community.

I'm a little late to the party, but given latest academic progress it's valid to bring the following topic to the surface again.
Please sorry if I make some hyperbolic/incorrect claims. I've researched "TEE confidentiality" for good amount of time, broke a lot of brain cells to understand what's going on before writing here.

Daniel Genkin and whole "Tee dot Fail" team deserve so much respect for their work. They've opened everybody's eyes on the fundamental problem.
Obviously however cool Proof Of Cloud going to be - the top-level Threat Model projects cannot use TEEs because of potential side-channel attacks that might be even approved under certain conditions if government is involved. Anyhow that's sadly out of scope of what can be done about it.

Another huge shout out goes to Andrew Miller and whole Flashbots team for paper "Proof of Cloud: Data Center Execution Assurance for Confidential VMs".
The latest version of the paper was published on March 3rd 2026, so it's a fairly new revision in case you previously were familiar with previous version from 14 Oct 2025.
It describes that idealistic version of Proof Of Cloud that speakers in the latest Phala video talk about closer to the end of the video. The paper clearly explains why at the moment user cannot have cryptographic guarantees about integrity of user data inside of TEE because TEE attestation can be forged and even Phala can be theoretically running everything in plain text while presenting both "valid" attestation and saying the server is in non-cryptographically-verifiable white list.

It's kind of sad that the revolution many of us envisioned where everybody having powerful compute at home could share the power to anybody else for money is not feasible in foreseeable future.
At least trust shifts to reputable major cloud providers which by itself significantly elevates the threat model of many of us.

Please excuse me for the following over-simplifications.

Per paper the trust can be shifted at least to level of reputable cloud providers ONLY in case user can:

• verify what code is running;
• verify in which cloud compute provider facility (AWS, GCP, Azure, etc.).

This knowledge can be derived from both TEE attestation and newly introduced TPM quote.

To validate WHAT code is running paper suggests user to:

• locally build and derive hash out of app code that is supposed to be deployed in enclave;
• cross-reference boot-stage OS/kernel/app code measurements computed by TPM chip with already existing TEE attestation that also contains code measurements;
• cross-reference locally derived app code with TPM & TEE attestation sourced hashes.

To validate WHERE code is running user needs to do following:

• get non-forgeable PPID value from TEE attestation (hardware ID hash);
• verify PPID against AWS/GCP/Azure public registry of devices they own;
• get AK_pub (Attestation Key) provided by TPM quote (now sent to user additionally to TEE attestation);
• check if AK_pub exactly matches the one injected by enclave inside TEE attestation's report_data field.
• get EKC value from TPM quote and check it against GCP/AWS/Azure Root CA.

Would be really nice to learn about Dstack/Phala plans to integrate the described concept from the paper.

Thank you very much for reading and even more so to everybody involved and specifically to Dstack team.

[executed]

Based on docs of Proof Of Cloud (https://github.com/proofofcloud/trust-server) repo it only extracts PPID from attestation and checks it against some whitelist of servers that user knows nothing about.

In recent Phala video (https://youtu.be/pkhoxYCMsqg?si=IPgYDF5AOZAECWhw) about "TEE dot fail" one of participants was actually surprised his garage hosted hardware is in that list even though he could have tampered it and be stealing user data without user knowing it. All because whoever created the whitelist thought that he was trusted long term compute provider. This further elaborates my point that "whitelist" is not a way to go.

Thanks to already mentioned TPM based provenance paper (https://arxiv.org/pdf/2510.12469) we know that PPID does not prove anything to user in terms of data confidentiality. PPID can be extracted from legitimate hardware and replayed from compromised systems.
In order to establish at least some trust about hardware being non-tampered we need to cross-check that PPID with reputable data center "lists" (e.g. GCP). It solves the problem of some "whitelist".
This by itself means our best bet is to shift trust to GCP, Azure, AWS, etc. and I don't see how Proof Of Cloud allows you to prove such provenance.

I've actually already raised issue (proofofcloud/trust-server#2) about this in POC repo a week ago, no response yet.

Does it make sense to not trust confidentiality claims of TEE providers until Proof Of Cloud incorporates TPM based provenance verification?
But then based on paper Dstack images would need to be changed to return TPM quote?

[executed]

Assuming possibly that ball is on Proof Of Cloud side, I've also created issue in their repo:
proofofcloud/trust-server#2

[executed]

@kvinwang @h4x3rotab @iKapitonau
Could you please join this discussion? Thank you!