DCAP attestation: Add GCP provenence check to establish whether the associated PPID is endorsed by Google by ameba23 · Pull Request #54 · flashbots/attested-tls

ameba23 · 2026-06-12T07:12:01Z

When verifying an attestation which claims to be of type AttestationType::GcpTdx this PR adds an additional check as to whether the PPID from the PCK certificate included in the attestation is present in GCP's public bucket, which indicates that the PPID belongs to them. This is essentially a 'proof-of-cloud' check specially for GCP.

This is based on Google's own provenance checker tool written in Go: https://github.com/google/go-tdx-guest/blob/main/tools/gceprovenance/main.go

In order to match the Go implementation we:

Validate that PPIDs must be 16 bytes
Have a 30s timeout on the complete fetch
Check that the response has 200 status
Check that the response is valid JSON

Unlike the Go implementation we additionally:

To avoid unnecessary network calls on subsequent verifications, known GCP PPIDs are cached for up to one week. We might want to make this cache time shorter.
Validate that the response has fields zone and timestamp.
Cap the response size at 16kb.

Note: The Go implementation offers an additional instance-verification check as well as the provenance check. This checks the MR_OWNER value against instance metadata. This is outside of the scope of this PR and not implemented.

Note: No checks are made on the timestamp or zone details in the response, other than making sure those fields are present. This is because the Go implementation also does not check those values. Such checks could be added later in a follow-up.

See relevant documentation from Google:

TODO:

Validity window for cached PPIDs (store retrieval timestamp in cache)
Fix measurement policy to explicitly match GCP attestation type - otherwise this check is useless
Review against the Go implementation: https://github.com/google/go-tdx-guest/tree/main/tools/provenance
Tests - do we check PPID extraction with our existing DCAP test assets?

* main: Bump reqwest to 0.13.4 chore(deps): bump openssl from 0.10.79 to 0.10.80

ameba23 · 2026-07-06T10:02:18Z

    expected_input_data: [u8; 64],
    pccs: Option<Pccs>,
-) -> Result<MultiMeasurements, DcapVerificationError> {
+) -> Result<(MultiMeasurements, Quote), DcapVerificationError> {


To avoid parsing the quote a second time to extract the PPID after verification, the verifier function now returns the parsed quote.

ameba23 · 2026-08-17T07:36:26Z

@@ -0,0 +1,70 @@
+//! On GCP check MRTD values map to Google endorsed firmware


This file is mostly unchanged from main - i just refactored it into a separate file to avoid having both provenance and firmware stuff together in one file.

…k to be enforced

ameba23 · 2026-08-17T08:00:22Z

    /// OS image
    pub measurement_id: String,
+    /// The attestation type this record accepts
+    pub attestation_type: AttestationType,


To enforce the GCP provenance check, attestation policies need to explictly state the expected attestation type

MoeMahhouk · 2026-08-17T09:52:12Z

+const GCP_PROVENANCE_REGISTRY_URL: &str =
+    "https://storage.googleapis.com/confidential-host-registry";


should this be always fixed or should we also make it optionally set by an env var and if not provided it defaults to this URL instead?
This could also serve for future path in case PPID is deprecated or if the verifier would like to pull the registry from a different source.

Agree this would be nice to have configurable. I started adding this, and realised it would be nice to have this option on the builder API for attestation verifier, which is still an open PR awaiting review: #70 so will make an issue and add that once the builder API is merged.

Yes, I was recently thinking about this more and maybe for some of our workloads that soon going to migrate to bare-metal, we could also have something similar to the GCP provenance where we provide an endpoint as a registery URL for the TEE hardware inventory until a more standardized version comes out like Intel's PoE

MoeMahhouk · 2026-08-17T10:16:27Z

+    #[error("blocking task join: {0}")]
+    TaskJoin(String),


Nit: semantically doesn't seem to be a GcpProvenanceError type but rather a threading or async kind of error type, or did I misunderstand something here ?

No, semantically its not. This would happen if the task handling the provenance check panics. Which if this is implemented correctly should be highly unlikely to happen but we have to handle this case anyway. I would argue it make sense to categorize it as this because it is a possible bad outcome of running the provenance check.

MoeMahhouk · 2026-08-17T10:19:25Z

Small suggestion:
This provenance check is supposed to be a new addition for the verification path only, probably it would be good to gate it behind a flag instead of making it enforced for every gcp dcap attestation verification process. wdyt?
This way, it would leave it up to the verifier to choose if they want to check attestation & provenance or only attestation would suffice for their workload?

ameba23 · 2026-08-17T11:04:30Z

Small suggestion: This provenance check is supposed to be a new addition for the verification path only, probably it would be good to gate it behind a flag instead of making it enforced for every gcp dcap attestation verification process. wdyt? This way, it would leave it up to the verifier to choose if they want to check attestation & provenance or only attestation would suffice for their workload?

If i understand you right, you mean we should handle the case that the verifier doesn't care whether or not its a GCP attestation - any DCAP attestation will do. Currently you can get this by specifying 'DcapTdx' as the attestation type in the policy. However, if the server claims their attestation type is GcpTdx in the PlatformMetadata, we still do this check and bail if it fails, even though the verifier doesn't require it. So maybe we should only do the check if the verifier enforces attestation type to be GcpTdx.

I see the logic here, but i'd be wary of skipping the check in that case, because if the server indicates that they are running on GCP but is not, i don't think we should treat that as a valid attestation. In the happy path, the non-GCP server correctly submits platform metadata as DcapTdx and the provenance check never happens.

If your concern is more just that we are starting to bloat the whole process with GCP-specific logic, then yes i can see an argument for putting it behind a feature flag and not compiling it on builds where we don't care about GCP.

* main: Bump crates from attest repo following fix for counting disks attestation: keep deprecated azure feature as alias for azure-attester ci: check azure-verifier portability on macOS attestation: move azure generation into attester/, verification into verify.rs attestation: vendor portable vTPM quote verification, split the azure feature

…fyMode Second of two changes for flashbots#84, stacked on flashbots#85. Reporting the collateral a verification consumed is half of provenance. The other half is running the same verification again later, against that bundle, and getting the same answer. Nothing exposed that: the public entry points always fetched, and the only way to supply a bundle was through test-only variants that also took a bare timestamp. Verification now takes a VerifyMode. Live fetches collateral and reads the wall clock. Archived carries the bundle and the instant it was collected, so the two can never be supplied apart - a pinned bundle evaluated at the wrong instant is the mistake the old (Option<collateral>, now) pair permitted. Azure holds its AK certificate chain to the instant the DCAP leg reported, so both legs evaluate at one time in either mode. The Azure TCB override leaves the public DCAP entry points. Only the Azure verifier has a reason to relax TCB checks, so it reaches the override through a crate-private variant; verify_dcap_attestation always verifies at full strictness. The mock verifier likewise becomes its own function rather than a cfg switch inside the production one, so verify_dcap_attestation means Intel-rooted in every build and the fixture tests replay real captures against it. AttestationVerifier is the one place that picks between them. BREAKING CHANGE: verify_attestation and verify_attestation_sync take a VerifyMode; the DCAP and Azure entry points take mode before pccs and the DCAP ones drop override_azure_outdated_tcb; the *_with_given_timestamp variants are gone, replaced by VerifyMode::Archived. GCP checks and Archived mode ---------------------------- The GCP host provenance check from flashbots#54 stays live in either mode, as does the firmware fetch for the quote's MRTD. Neither rests on signed material a replay could re-verify: the provenance document is an unsigned JSON object whose trust is the TLS connection to Google's bucket, so archiving it would not make a replay stronger. The docs on VerifyMode::Archived and verify_attestation state the carve-out. Whether Archived should skip the provenance lookup instead is left open. Closes flashbots#84

ameba23 added 3 commits June 11, 2026 19:30

Basic GCP provenance check

5d3c8ea

Dont parse quote twice

7e12021

Cache known GCP PPIDs

a4ebbb2

ameba23 marked this pull request as draft June 12, 2026 07:15

ameba23 added 2 commits June 12, 2026 09:20

Measurement checks should check attestation type

9a4ea50

Fix azure tests, and avoid unneeded cloning

cfcce9b

ameba23 mentioned this pull request Jun 17, 2026

Requiring collateral to be in cache on verification causes problems #58

Open

ameba23 added 4 commits June 23, 2026 09:18

Merge main

8da4cc6

Add test for PPID extraction from current DCAP fixture

5abd134

Add expiry timestamp for cached PPIDs

f2f479f

Improve timestamp check

157bf2c

ameba23 marked this pull request as ready for review July 6, 2026 09:56

Merge branch 'main' into peg/gcp-provenance

37e5e29

* main: Bump reqwest to 0.13.4 chore(deps): bump openssl from 0.10.79 to 0.10.80

ameba23 commented Jul 6, 2026

View reviewed changes

ameba23 added 5 commits July 6, 2026 12:34

Minor code quality fixes

034c1f6

Revert changes from merge commit which are unrelated to this PR

355cc90

Improve code readability on cache check and tokio runtime check

18b5780

Fixes to match Go implementation

8817287

Merge main

6c65d17

ameba23 commented Aug 17, 2026

View reviewed changes

ameba23 added 2 commits August 17, 2026 09:46

Verifier should return quote to avoid parsing it twice

34346c6

MeasurementRecord must track attestation type for GCP provenance chec…

b4b0aa3

…k to be enforced

ameba23 commented Aug 17, 2026

View reviewed changes

ameba23 added 2 commits August 17, 2026 10:05

Restore GCP firmware test

7520e01

Rm comments changes to firmware checker

2edc2cf

ameba23 requested review from MoeMahhouk and alexhulbert August 17, 2026 08:14

Fmt

345c695

MoeMahhouk reviewed Aug 17, 2026

View reviewed changes

ameba23 added 5 commits August 17, 2026 13:33

Simplify mutex check for stale entries

59810e2

Dcap-tdx policy should allow GCP-TDX

5f96c7f

Fmt

2bc7dfb

Fixes for supporting differnt async runtime or no async runtime

f1e2051

ameba23 requested a review from MoeMahhouk August 25, 2026 06:16

MoeMahhouk approved these changes Aug 25, 2026

View reviewed changes

ameba23 merged commit 17afee1 into main Aug 25, 2026
4 checks passed

ameba23 deleted the peg/gcp-provenance branch August 25, 2026 08:32

samlaf mentioned this pull request Aug 25, 2026

feat(attestation)!: pin verification to archived collateral with VerifyMode SeismicSystems/attested-tls#3

Open

Navigation Menu

Uh oh!

DCAP attestation: Add GCP provenence check to establish whether the associated PPID is endorsed by Google - #54

DCAP attestation: Add GCP provenence check to establish whether the associated PPID is endorsed by Google#54
ameba23 merged 25 commits into
mainfrom
peg/gcp-provenance

ameba23 commented Jun 12, 2026 •

edited

Loading

Uh oh!

ameba23 Jul 6, 2026

Uh oh!

ameba23 Aug 17, 2026 •

edited

Loading

Uh oh!

ameba23 Aug 17, 2026

Uh oh!

MoeMahhouk Aug 17, 2026

Uh oh!

ameba23 Aug 19, 2026

Uh oh!

ameba23 Aug 19, 2026

Uh oh!

MoeMahhouk Aug 25, 2026 •

edited

Loading

Uh oh!

Uh oh!

MoeMahhouk Aug 17, 2026

Uh oh!

ameba23 Aug 17, 2026

Uh oh!

MoeMahhouk commented Aug 17, 2026

Uh oh!

ameba23 commented Aug 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		@@ -0,0 +1,70 @@
		//! On GCP check MRTD values map to Google endorsed firmware

		const GCP_PROVENANCE_REGISTRY_URL: &str =
		"https://storage.googleapis.com/confidential-host-registry";

Uh oh!

Conversation

ameba23 commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ameba23 Jul 6, 2026

Choose a reason for hiding this comment

Uh oh!

ameba23 Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ameba23 Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

MoeMahhouk Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

ameba23 Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

ameba23 Aug 19, 2026

Choose a reason for hiding this comment

Uh oh!

MoeMahhouk Aug 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MoeMahhouk Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

ameba23 Aug 17, 2026

Choose a reason for hiding this comment

Uh oh!

MoeMahhouk commented Aug 17, 2026

Uh oh!

ameba23 commented Aug 17, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ameba23 commented Jun 12, 2026 •

edited

Loading

ameba23 Aug 17, 2026 •

edited

Loading

MoeMahhouk Aug 25, 2026 •

edited

Loading