Skip to content

CONCEPT Cited by 1 source

Verifiable transparency log

Definition

A verifiable transparency log is a third-party-operated append-only ledger that publishes all acceptable artefacts (binary digests, certificates, keys, releases) a service is willing to serve, so that clients and external researchers can detect "the server is running X but X was never published" or "X was published but was never reviewed".

It is the audit-side companion to cryptographic attestations: attestation proves the server is running a specific binary; the transparency log proves that binary is one of the ones we said we'd run.

Canonical examples on the wiki:

  • Certificate Transparency — public append-only log of all TLS certificates issued by participating CAs.
  • Sigstore Rekor — public transparency log for Sigstore-signed artefacts.
  • Binary transparency for CVM images — the third-party log Meta names in Private Processing.

Load-bearing role in confidential computing

In a confidential-computing service, remote attestation returns a fresh proof "digest X is loaded in this TEE". Without a transparency log, the client has to trust the server's assertion that X is a legitimate image to accept. With a transparency log, the client can independently verify that X appears on the published list, and external researchers can independently detect divergences (e.g. a digest that never appeared on the log, or one that appeared but was flagged by review).

Meta names the mechanism verbatim:

"The attestation verification step cross-checks the measurements against a third-party ledger to ensure that the client only connects to code which satisfies our verifiable transparency guarantee."

and

"In order to provide verifiability, we will make available the CVM image binary powering Private Processing. We will make these components available to researchers to allow independent, external verification of our implementation."

Properties the log must provide

  • Append-only — entries cannot be rewritten or deleted.
  • Publicly inclusionable + auditable — anyone can fetch + verify inclusion proofs.
  • Hosted by a party distinct from the service operator — so a compromised operator cannot also rewrite the ledger.
  • Cryptographically committed — typically Merkle-tree-backed, with signed tree heads (STH) that consumers can cross-check.
  • Complete — every digest that could be attested must be on the log, so a forked / off-log binary is detectable by absence.

What transparency logs do NOT provide

  • Quality of the reviewed binary — the log says "this digest was published", not "this digest was correct". Pair with open-source + external audit.
  • Defence against signed-but-malicious releases — if the log operator colludes with the service operator, malicious releases appear legitimate. Mitigated by log operator being "a third party" with its own accountability / auditability.
  • Protection after a key compromise — if the service's signing key leaks, the attacker can publish valid-looking log entries until revocation. Forward-security + short key lifetimes help.

Sibling and parent concepts

Seen in

Last updated · 319 distilled / 1,201 read