Check a run's receipts on another machine¶
This page is for the person checking someone else's evidence: an auditor, a customer or a regulator, on a clean machine, with no EKKA account and no network.
The person who ran the agent exports one run into a file. You check that file against a key you got from EKKA yourself. Nothing on your side contacts EKKA, the Enclave that ran the agent, or anyone else.
What it proves, exactly¶
When all four checks pass, you can say this, and only this:
Anyone can verify, offline, with no EKKA service, that these receipts are unaltered, signed by the Enclave EKKA has on record, and complete up to the point EKKA witnessed at the time the check prints.
What it does not prove:
- Anything written after that time. No offline check can prove a record that came later is present or absent. The check prints the time, and the claim stops there. Never say "complete" without it.
- That a gate's own signature is valid. Each gate's signature was checked by the Enclave when it recorded the receipt. The file carries those receipts and links them, and the check confirms the links and the receipts the Enclave signed itself.
Step 1. The operator exports the run¶
On the machine that ran the agent:
It writes ekka-receipts-<run-id>.json. That file holds every record from the
run's first record to the point EKKA last confirmed, the chain's first record,
the Enclave's key, and EKKA's signed witness of how far the record reached.
Exporting asks EKKA once; checking never does.
Right after a run, the export may refuse and name a time to try again. The records hold the short-lived access EKKA gave the run, which still works until it expires. The export waits so the file never carries access that works.
What the file shows the person you send it to: every record in that span,
including other runs' records written in between. Each record carries the hash
of the one before it, so the run's records cannot be proven complete without
them. Before you send it, read what those runs recorded with
ekka receipts show <run-id> for each one.
If the run is newer than the point EKKA last confirmed, export says so. The
Enclave sends its next confirmed point with its heartbeat; export again a minute
later.
Step 2. You get EKKA's witness key yourself¶
Never use a trust file from the person who sent you the export: it would let them vouch for themselves. On your own machine, once, with the network on:
It writes ekka-trust.json and prints the address it read from and the key's
fingerprint. Compare that fingerprint with the one below before you trust it.
The file is only as trustworthy as the address it came from.
EKKA's witness key fingerprint¶
Published here when EKKA issues witnesses.
Step 3. You check it, offline¶
Networking off, if you like:
It prints four verdicts, each on its own line, and never folds them into one:
| Verdict | Passes when |
|---|---|
| Signatures valid | Every record links to the one before it, and every receipt the Enclave signed checks out against the Enclave's key. |
| Signer authorized | That key is the one EKKA has on record for this Enclave, as EKKA's witness says. |
| Complete | The records reach the point EKKA witnessed, and the record there is exactly the one EKKA witnessed. |
| Not revoked | EKKA had not revoked the Enclave's key at the time it witnessed. |
The command exits 0 only when all four pass, 3 when any check finds a problem, and 2 when something could not be established.
When the export has no EKKA witness¶
An export can lack EKKA's witness, for example from an EKKA that does not issue witnesses yet. Then the last three verdicts read "not established", never "pass", and the most it supports is exactly this sentence:
Signatures and links verified offline against the Enclave's key; completeness is the Enclave's own signed claim, not EKKA-witnessed.
Say that sentence exactly, or say nothing.