Don’t trust us.Verify.

How it works

Run the verifier

bf-verify works offline. Pin the instance key you read over a channel you trust, otherwise it can only check the bundle against the key the bundle carries.

# Build the verifier from the sources we provide (no server code involved)
make verifier

# An administrator exports a bundle: GET /api/evidence/bundle
# Read the instance key over a channel you trust: GET /api/evidence/keys
bf-verify evidence-bundle.json --public-key <hex>

# Exit status: 0 verified, 1 not verified (first problem named), 2 unreadable input

No installs? The same check runs in your browser, on your device, at the verifier page under Trust.

What it proves

Every entry links to the previous one and matches its own hash. The entries end exactly at the sealed head. The seal signature is valid for that head. When present, the time-stamp is for this very seal and signature, and states a time.

What it does not prove

Anything before the first entry of the bundle, that the instance was honest when it wrote an entry, or that the key in the bundle is the instance’s key (pin it). It does not check the authority’s own signature: do that with OpenSSL. Seals do not make the database write-once, and we make no claim of certification or legal evidential value.

bf-verify bundle.json --write-token seal.tsr    # prints the digest that was stamped
openssl ts -verify -in seal.tsr -digest <digest> -CAfile tsa-ca.pem

All guides