Skip to content

PATTERN Cited by 1 source

Publish binary digest ledger

Pattern

For any service whose trust depends on "this specific server binary is running" — TEE-based inference, signed releases, supply-chain-critical binaries — publish every acceptable binary's digest on an append-only, third-party-operated transparency log. Pair it with an open release of the binary image itself so external researchers can disassemble and audit what each digest corresponds to.

The ledger is the public policy source that attestation-gating consumes. Attestation alone proves "digest X is running"; without the ledger, the client still has to trust the operator's assertion that X is OK. The ledger turns that into "digest X is one of a publicly-enumerated set", which anyone can independently inspect, review, and monitor.

Components

  1. Append-only log. Typically Merkle-tree-backed with signed tree heads; entries cannot be rewritten or silently removed.
  2. Third-party operator. The log is run by a party independent of the service operator. If the service operator could also silently update the ledger, the pattern collapses.
  3. Published binary image. Not just the digest — the actual binary, so external researchers can reverse it, reproduce the build, and match digests.
  4. Signed inclusion proofs. Clients (and auditors) can verify a specific digest's presence without downloading the whole log.
  5. Cross-checking in the attestation verifier. The client's handshake verifier looks up the attested digest in the ledger before proceeding.

Why the "third-party" operator is load-bearing

A ledger operated by the same party as the service loses its auditability property: a compromised operator can silently append post-hoc digests, or rewrite history, to match whatever binary it wants to run. Separating the operator — ideally with a published multi-witness / multi-signer model, as in Sigstore's Rekor — means compromising the pattern requires compromising both the service operator and the ledger operator independently.

Canonical wiki instance: WhatsApp Private Processing

The 2025-04-30 Meta post describes the realisation:

"Transparency of the CVM environment, which we'll provide through publishing a third-party log of CVM binary digests and CVM binary images, will allow external researchers to analyze, replicate, and report instances where they believe logs could leak user data."

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."

and

"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."

Three artefacts together: the ledger, the binary image, and a published security design paper — plus expanded Bug Bounty for researchers to report findings against — form the full transparency posture.

Sibling wiki instances

  • concepts/release-attestation / Sigstore / Rekor — same pattern at the software-release layer. Digest + signer identity + timestamp, published on a Merkle-tree log. Sibling instance for CI/CD artefacts.
  • Certificate Transparency — same pattern at the X.509-certificate layer. Publicly-auditable append-only log of every issued certificate; browsers require inclusion before accepting.
  • concepts/coordinated-disclosure — transparency norm at the vulnerability-disclosure layer. Not an append-only crypto log, but the same design stance: "make the claim publicly auditable on a timeline, so abuse is detectable".

Failure modes

  • Ledger operator colludes with service operator. Defence: multi-witness model (Sigstore-style), published governance, separate legal jurisdiction.
  • Stale / cached ledger on the client. An attacker who can delay updates can slip in an old-good-now-revoked digest. Defence: fresh nonces + signed tree heads + strict-mode clients.
  • Ledger downtime. Clients can't verify; they must fail closed to preserve the guarantee.
  • Binary-image-review capacity is small. External researchers are finite; a high publish-rate of new binaries dilutes review. Defence: slow release cadence, detailed change descriptions, Bug Bounty incentives.
  • Digest-reproducibility gap. Published binary must be bit-identical to the one attested, so external researchers can match. Defence: reproducible builds, documented build environment.

Seen in

Last updated · 319 distilled / 1,201 read