Attestation Transparency Log

Remote attestation lets a machine prove what it is running: the boot chain measures each stage into hardware, and the node presents a signed statement of the resulting measurement. That proves the software was signed by the vendor. It does not prove it is the software everyone else gets. A vendor under legal compulsion, or an attacker with build-system access, can produce a validly signed image intended for one user, and attestation will confirm it happily.

An attestation transparency log closes that gap by making the set of acceptable measurements public and append-only, and by moving enforcement into the client: the device compares the node's attested measurement against the log and refuses to send the request if it is not there. A targeted build then has only two options, and both fail — publish it, where researchers can see it, or serve a measurement no client accepts.

Why it matters

Most privacy guarantees are claims about intent: a policy, an audit report, a signed binary. The person whose data is at stake cannot check any of them, and none of them survives an adversary who controls the operator. A published measurement log plus client-side refusal converts the claim into a mechanism whose failure is visible: either your device sent data to a node running published code, or it sent nothing.

It also changes what an insider can do. With the log in place, the smallest unit of misbehaviour is a public release, which is a very different risk calculus from a quiet one-node deployment.

Implementation patterns

• Measure the whole chain, from firmware through the OS image to the application, and attest the composite. A measurement that covers only the application leaves the layers beneath it unconstrained.
• Append-only with independent witnesses. The log's value comes from being unable to rewrite history, so it needs the mechanics transparency logs use: a Merkle tree, published signed tree heads, inclusion proofs, and third parties witnessing that the head only ever grows.
• Client-side fail-closed. If no node presents an attested, logged measurement, the correct behaviour is to refuse and tell the user, not to fall back. This is the decision that must be made before the first release, because a client that already accepts unattested nodes can never start refusing them.
• Very few node configurations. Each distinct image is a measurement to publish, verify and keep serviceable, so heterogeneity is expensive by design: a log listing 5 images is reviewable, and one listing images for 200 nodes is a list nobody reads.
• Publish the binaries, not only the hashes, so the measurement can be reproduced and reviewed. A hash nobody can map back to inspectable code is a commitment without a subject.

Industry example

Apple described exactly this pairing for Private Cloud Compute in June 2024: a PCC node attests the software image it is running, every production release's measurement is published to a public append-only transparency log, and the user's device will not send a request to a node whose attested measurement is not in that log. Apple also published the images for inspection and ran a security research programme against them.

The preconditions are visible in that example: Apple controls the silicon, the operating system, the server design and the client. The log is the half that makes the guarantee adversarial rather than reputational, and the client refusal is the half that makes it enforceable.

Failure scenarios

• Attestation without a log, which proves a signed build is running and permits a build made for one user.
• A log with no witnesses, where the operator can present different views to different clients and the append-only property is an assertion.
• A client that soft-fails when verification is unavailable, which turns the whole mechanism off exactly when an attacker wants it off.
• Configuration outside the measurement. If behaviour is driven by a runtime flag or a fetched policy file, the measured image is honest and the behaviour is not.
• An unusable rollback path. Rolling back is publishing again; teams that did not plan for this discover it during an incident.
• Measurement sprawl, where dozens of hardware revisions and images make the log so noisy that nobody reviews it, and the social half of the control stops working.

Trade-offs

The operational bill is concrete: you cannot attach a debugger to a production node, observability must be designed to emit only what is safe by construction, and node fleets must be homogeneous.

When not to use it

If your threat model does not include a compelled or compromised operator, this is a great deal of rigidity for very little safety. A product whose users already accept that the vendor processes their data gets far more per unit of effort from field-level encryption, tight access review and short-lived credentials. Two preconditions are usually absent as well: you must control the client, because an optional verifier is not a control, and you must own hardware with a measured boot chain you trust — renting general-purpose VMs gives you a hypervisor's claims about itself. The honest middle path for most teams is a confidential-computing enclave for the one workload that needs it, with no transparency log at all.

Interview question

Q: A regulator asks how you can prove that your inference nodes only ever ran code that was reviewed. You already sign your images and require attestation. What is still missing, and what would you have to change in the client?

What a strong answer covers: that signing and attestation together still permit a per-user build, so the missing property is publication in an append-only log with witnesses; that the client must fail closed and that this decision cannot be retrofitted; the operational costs — public images, rollback as a release, homogeneous nodes, no interactive debugging; and the honest scoping, that this is worth it only when the operator is inside the threat model.

Quick check

Quiz: What can an operator still do with attestation but no transparency log? Serve one user a specially built, validly signed image, which will attest correctly.

Flashcard: Which half of verifiable transparency does the work? — The client's refusal to talk to a node whose measurement is not in the public append-only log; attestation alone only proves the code was signed.