Planned: attested key release

This page describes something that is not built. It does not run on the hosted instance, no route serves it, and nothing below is a commitment to build it. It is here because the gap it describes is the honest answer to a question teams ask early, and a plan nobody writes down reads as a plan somebody is hiding.

The design, in three sentences

Release an object’s key only to an attested program — a measured enclave image, identified by its measurement rather than by a hostname, a network position or a credential — and only under a grant that names the object, names the program, and expires.

Verify three things on every release, not once at setup: the attestation document, the grant, and a fresh nonce that makes the attestation belong to this request rather than to a recording of an earlier one.

Re-wrap the key to the enclave’s own key, so it never exists outside the measured image in a form the host can use, and write the attestation’s hash onto the release event, so every access leaves a receipt.

What it would make possible

A server-side program could use material it cannot read outside the enclave — index it, search it, serve an answer derived from it — with the plaintext existing only inside an image whose identity is a measurement a reader can check against the one the grant named.

And every use would be on the record. The question behind most requests for this is “prove nobody read my bytes”, which a log kept by the party being asked cannot answer. An attestation hash per release event can.

What exists today instead

Two things, and both are plain about their trust model.

The custody surface serves plaintext to the credential holder. Each object has its own key, this instance holds it, and the decryption boundary sits on the server — which is what makes server-side behaviour possible at all, and which means this instance can read the object while its key lives. → Hold, serve, incinerate

A team that wants more than that encrypts before upload. Permafrost then stores bytes it cannot read; the receipt still records the fingerprint, the owner and the lineage; the key never comes near us. What the team gives up is every server-side feature that needs plaintext. → Encryption at rest

The distance between those two and the design above is the entire content of this page. If attested key release is ever built, it will arrive as a guide with a run record behind it, and this page will say so instead.

No dates appear here, because there are none.