Allow verification at an explicit timestamp, and report which collateral was used
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- azure, rust
- 领域
- cryptography, security
调研方向
从 crates/attestation/src/dcap.rs 和带时间戳的 DCAP 验证测试开始,然后跟踪 verify_azure_attestation_with_given_timestamp 和 AttestationVerifier::verify_attestation。验证能够接受可选的 collateral 和显式时间戳,同时保留基于挂钟的默认值,并且其结果报告实际使用的 collateral 时,此更改即完成。
由索引模型根据 Issue 内容生成。
描述
Hello :) Dropping this Claude-authored issue. Think it's clear/clean enough as is, but happy to chat about it if it needs clarification.
The problem: archived attestations stop being verifiable
We use the attestation crate as a relying party for a one-time event rather than a live
handshake. When a Seismic network is founded, each founding node produces Azure TDX +
vTPM evidence bound to its freshly generated keys; we verify it against a measurement
policy, and we archive the evidence as permanent provenance. Those founding keys enter the
genesis validator set, so "this key came from a real TEE running this image" is a claim
later readers need to check for themselves, years afterwards.
Today they can't. Re-verification goes through AttestationVerifier::verify_attestation,
which verifies at SystemTime::now() against collateral fetched now. TCB Info, QE Identity
and both CRLs carry nextUpdate on a roughly 30-day cadence, and the Azure AK chain has an
ordinary notAfter. So about a month after founding, re-verification of perfectly good
archived evidence starts failing, and the property degrades into "the operator says it
verified once".
What we want is the validity-at-creation-time property archived evidence is supposed to
have: evaluate the chains and TCB status as of when the evidence was collected, against the
collateral that was current then.
The crate is already almost there
All the machinery exists — a single now already gates every freshness check (root CA CRL,
TCB Info window and chain, QE Identity window and chain, PCK chain validity, and the Azure
AK chain via verify_ak_cert_with_azure_roots), and Option<QuoteCollateralV3> already
means "use this, don't fetch". verify_dcap_attestation_with_given_timestamp and
verify_dcap_attestation_with_timestamp_sync are public and take both.
Your own tests rely on exactly this, for exactly our reason:
// crates/attestation/src/dcap.rs
// To avoid this test stopping working when the certificate is no longer
// valid we pass in a timestamp
let now = 1769509141;
The gap is only that the parameterization doesn't reach the two places we have to go
through:
- The Azure path.
verify_azure_attestation_with_given_timestampand its_sync
sibling takenowandOption<QuoteCollateralV3>, but are module-private; the two
public entry points bindnowtounix_time_now_secs(). AttestationVerifier. We need the measurement-policy check, so we can't call the
DCAP function directly — andverify_attestationhas no way to pass either input.
And one thing genuinely missing: nothing reports which collateral bundle a verification
used, so there's no way to archive it.
What we'd need
Two additions, no wire or payload change:
- An optional
(collateral, now)input pair on theAttestationVerifierverify call —
Some(collateral)meaning "no network fetch",Nonefornowmeaning "wall clock", so
existing behaviour is the default. - The collateral the verification actually used, in the verify result.
The second one matters more than it looks. The obvious workaround — fetch a second copy
alongside verification and archive that — is subtly wrong: a PCCS cache refresh between the
two fetches makes the archived bundle a bundle rather than the bundle the verification
consumed. For provenance that distinction is the whole point.
Nothing else is needed for our case. QuoteCollateralV3 already derives serde, and every
other time-sensitive Azure input (AK leaf, AK intermediates, vTPM quote, HCL report, TD
quote) already rides in the evidence message, with the Microsoft/Azure roots compiled in.
DCAP collateral is the only input a verifier fetches, so these two changes close the gap
completely.
How this relates to work in flight
- #58 / #63 / #65 are about where collateral comes from, to avoid a fetch during a
handshake. This is about which instant verification is evaluated at and what the
verifier reports — orthogonal. If #65 ever lands, archived evidence would carry its
collateral for free, which suits us, but we'd still need the explicitnow, since
bundling collateral doesn't stop it expiring. - #70 (verifier builder) composes cleanly:
nowandcollateralare per-verification
inputs, not per-verifier configuration, so they belong on the call rather than the
builder. - #79 (return
ExpectedMeasurements) touches the surface our second ask needs. Since
the return type is already changing there, a small outcome struct carrying both the
matched measurements and the collateral used would fold in naturally. I'd rather propose
against the direction you're taking than cut across it — hence this issue before a PR.
Nothing here adds to the evidence payload, so it's also neutral with respect to the rustls
64 kb cap in #75.
Happy to implement whichever shape you prefer, and to wait for #70/#79 if they're close.
- 主要语言
- Rust
- 星标
- 6
- 派生
- 3
- 平均合并
- 1 天 2 小时
- 30 天内合并 PR
- 3
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
flashbots/attested-tls 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 72/100
flashbots/attested-tls#100 ·
-
难度 5/5 一周以上 新手友好度 35/100
flashbots/attested-tls#97 ·
-
难度 5/5 一周以上 新手友好度 45/100
flashbots/attested-tls#92 · 4 条评论 ·
-
难度 3/5 1-2 天 新手友好度 68/100
flashbots/attested-tls#87 · 1 条评论 ·
-
难度 3/5 1-2 天 新手友好度 58/100
flashbots/attested-tls#82 · 1 条评论 ·
查看 flashbots/attested-tls 的全部 Issue
相似的 Issue
-
`mise doctor` Shows Not Installed Lazy Tools as Problems可能已有人在做 @jdx 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 67/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
nn::linear: weight initialization depends on `bias` because the bias is created before the weight可能已有人在做 @monfortema 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 72/100
LaurentMazare/tch-rs#1067 ·
-
难度 2/5 1-3 小时 新手友好度 64/100
astral-sh/astral-codec#234 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100