Verify a Walk‑Check record yourself

Every sealed walkaround carries its own proof. You do not need an account, our servers, or our word for it. This page gives you the tool and the key.

How it works

Each record is a hash chain: every entry links to the previous one and is signed with an ECDSA P-256 key held in AWS KMS, and the seal that closes the walkaround carries a timestamp from an RFC 3161 authority. The verifier below re-derives the whole chain from genesis and checks all three. It does not import our application code and it does not call our servers: it reads the public key once from a file and computes the rest locally. That is the point. If you do not trust us, you do not have to.

Steps

1. Get the protocol

   Open the share link you were given and download the PDF, or use the PDF you received by e-mail.

2. Extract the proof

   The machine-readable evidence is attached inside the PDF. pdfdetach is part of Poppler (the package poppler-utils or poppler). Take out only walkcheck-proof.json, never all attachments: a file planted in the PDF next to the tool could take its place.

   pdfdetach -savefile walkcheck-proof.json report.pdf

3. Get the tool

   Download the five .py files, the key walkcheck-audit-public-key.der and the anchor tsa-trust-freetsa.pem from the list below into one folder: verify_chain.py needs the other four next to it. You need Python 3.12 or newer and three libraries. Install them into an environment of their own, because many systems refuse pip install outside one.

   python3 -m venv venv
   . venv/bin/activate
   python3 -m pip install \
     "cryptography>=43" "pydantic>=2.9" "structlog>=24.4"

4. Run the verifier

   Run it with the key and the anchor from this page, never with a key that came together with the PDF.

   python3 verify_chain.py \
     --export walkcheck-proof.json \
     --public-key walkcheck-audit-public-key.der \
     --tsa-trust tsa-trust-freetsa.pem

5. Read the verdict

   VERIFIED

   chain intact, signatures and timestamp valid

   TAMPERED

   the record does not match what was sealed (with the key and the anchor from this page, that means a change after sealing); the line names the entry and the reason

   PENDING

   sealed, but the storage attestation does not cover it yet

   UNSEALED

   the walkaround was never sealed, so it is not evidence yet

   UNVERIFIED_DEV

   you ran it with --allow-unsigned, so signatures were not required. Not proof.

   The exit code follows the verdict: 1 for TAMPERED, and also for an export that can be read but is malformed; 0 for the others; 2 when the command is wrong or a file cannot be read, and nothing was checked. A run over a real record prints exactly this on standard output (log lines go to standard error):

   STORAGE: pilot mode, the record is NOT under an irreversible lock; it is kept for at least four years, then in a deep archive, and only Walk-Check can delete it, as an exception (this does not weaken the chain)
   VERIFIED (sealed=True, records=10), NOT CHECKED: global anchor (--require-anchor), WORM attestation (--require-attestation)
   SEALED HEAD (record_hash): b321eb4bf2b55b0a57eefaf01f059463f728cb6c1746dd48b8e0b677f0f07e34, WALKAROUND ID: 4b3bcb62-2ea9-4c05-ab88-164e80e3de32
   LOCATION (reported by device): none in chain (record predates device location)

   • STORAGE: appears only for a record stored in pilot mode, described at the bottom of this page. It does not weaken the chain.
   • Behind the verdict the tool names what it did not check in that run. That tail is the scope, not a failure: the global anchor and the storage attestation need data that the PDF does not carry.
   • The sealed head and the walkaround ID must match the PDF (fields SEALED HEAD and WALKAROUND ID). If they do not, do not rely on the document. The tool checks the attachment, not the printed pages: where the PDF and the attachment differ, the attachment is what was sealed.
   • LOCATION is the position the phone reported, if any. It is not a measurement of where anyone stood.

   Depending on the version of the cryptography library you may also see one warning about PKCS#7 certificates parsed as BER. It does not affect the verdict: the timestamp token of the pilot authority is BER encoded, which CMS allows, and this tool checks its signature over the exact bytes with its own decoder.

Files

Tool

Keys

The same thing written out, with every switch, the data it needs and what this does not prove: README.md, or README.sk.md in Slovak.

Two things we say out loud. The timestamp authority in the pilot is freetsa.org, which is a real RFC 3161 authority but not an eIDAS qualified one. And storage currently runs in pilot mode, without an irreversible lock: before the seal the user can delete a record, after the seal it is only hidden and archived, and only Walk‑Check can delete it permanently, as an exception. The sealed content never changes, and the verifier prints the storage mode itself rather than hiding it. Neither weakens the chain: if a record exists, you can prove it was not changed.