Verifying a Cerenaid evidence pack

1. What you are holding

A Cerenaid evidence pack is a ZIP file produced by the assessed organization for a date range. It contains the sealed record of every key ceremony completed or aborted in that period, the key inventory and component custody register as they stood when the pack was built, the members and their roles, and the organization's audit chain for the period together with a full recomputation of that chain from its first event.

Every file in the pack is listed in manifest.json with its SHA-256 hash. The pack hash is the SHA-256 of manifest.json itself. It is printed on cover.pdf, in README.txt, and on the organization's Evidence page. Checking any of this needs a SHA-256 tool, which every operating system already ships (see section 3), and nothing from Cerenaid: no account, no login, no network.

The pack contains no key material and no key components. Cerenaid never stores them; the KCV field accepts at most six hex characters, and every free-text field is screened for anything that looks like a key.

2. What is in the pack

3. Verify the pack

Unzip the pack into a folder and open a terminal there. You do not need to install anything: macOS has shasum, Linux has sha256sum, and Windows has certutil and PowerShell's Get-FileHash. If you prefer not to use a terminal, 7-Zip on Windows adds a right-click CRC SHA → SHA-256 menu to any file, and QuickHash GUI is a free, open-source hash tool for Windows, macOS and Linux. Any of these produces the same 64-character value.

Step 1. The pack hash

Compute the SHA-256 of manifest.json and compare it with the pack hash on the cover page and the one the organization shows you on its Evidence page. They should be identical.

# macOS
shasum -a 256 manifest.json
# Linux
sha256sum manifest.json
# Windows (Command Prompt)
certutil -hashfile manifest.json SHA256
# Windows (PowerShell)
Get-FileHash manifest.json -Algorithm SHA256

Step 2. Every file

Compare each file's SHA-256 with the value in manifest.json. Any of the tools above will do, one file at a time. This checks all of them at once on macOS or Linux with jq installed:

jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json | shasum -a 256 -c -
# on Linux use: sha256sum -c -

Every line should end in OK. A file that fails was changed after the pack was built.

Step 3. The seals

Cerenaid records the chain head every day and, when the organization has set a security officer address, emails it there. Ask for those emails and compare their heads with audit/seals.csv. A seal that exists outside the system is what makes the chain independent of it.

4. Verify the audit chain

Every change to the organization's records is an audit event. Each event stores a hash of its own content joined to the hash of the event before it, so changing or removing any past event changes every hash after it. Cerenaid recomputes the full chain when a pack is built and reports the result in audit/verification.txt. You can recompute it yourself from audit/events.jsonl.

The method, exactly as the verification file states it:

hash = hex( SHA-256( canonicalJSON({orgId, seq, at, actorUid, actorRole, action, target, data}) || prevHash ) )

• canonicalJSON is JSON with object keys sorted recursively and no whitespace.
• at is the event time in milliseconds since the Unix epoch.
• prevHash is the hex hash of the previous event. For event 1 it is the genesis value: a string of sixty-four ASCII "0" characters, text rather than null bytes.
• || is plain string concatenation: the canonical JSON followed immediately by the 64 hex characters.

To spot-check one event: take any line in events.jsonl, build the payload from those eight fields, canonicalize it, append the line's prevHash, hash it, and compare with the line's hash. Then confirm that the next line's prevHash equals this line's hash. The events file covers the pack's period only; the verification file covers the chain from its first event.

Each line is already canonical JSON: keys sorted, timestamp as a number. Drop the id, prevHash and hash fields, keep the other eight, and hash what remains followed by the line's prevHash.

5. Read a ceremony record

Each PDF in ceremonies/ is the record of one ceremony: what template and version was used, who was present, every step in order, and every signature. The things worth checking:

• Template hash. The hash of the exact procedure the ceremony followed. Two ceremonies with the same hash followed the same script, word for word.
• Performed by, confirmed by. A step marked dual control shows two different names with two times. The system refuses to let the person who submitted a step also confirm it, so a record with the same name in both places cannot exist. Rejected attempts stay on the record with their reason.
• Captures. What the step recorded: device serial numbers, KCVs, bag serial numbers, counts. A KCV is at most six hex characters. If you see anything longer anywhere in the pack, that is a finding against Cerenaid, and we want to hear about it.
• Attestations. Each participant re-authenticated within the previous five minutes with their password and, where the organization requires it, an authenticator code, then typed their name. The record shows MFA or no MFA against each attestation, and members.csv shows when each person enrolled an authenticator. Each attestation hashes the step chain head and template hash at that moment, so it is tied to exact content.
• Names. Names on a record are the names at the time of signing. If a member later changes their name, members.csv shows the new one and the audit chain carries a rename event with both names; the sealed record is not rewritten.
• Step chain head and record hash. Steps form their own hash chain inside the ceremony. The record hash covers the template hash, the step chain head, the participant list and every attestation hash. It is computed once, when the lead completes the ceremony, and appears in the audit event that sealed it.

Aborted ceremonies are kept and included, with the reason and the steps committed before the abort.

6. What this does and does not prove

• It proves that the records you hold are the records Cerenaid held when the pack was built, that nothing in the chain was altered after the fact, that dual-control steps were confirmed by a second person who was authenticated, checked in as an authorized participant of that ceremony, and acting on a separate device, and that each participant signed the record with a fresh authentication.
• It does not prove that the values people typed match what was on the HSM screen. That is what the second pair of eyes at each dual-control step, the attestations and your interview are for. Cerenaid makes those controls enforceable and their evidence tamper-evident; it does not replace them.
• Independence. A hash chain held only by the system that writes it is only as good as that system. The daily seal emailed to the organization is the copy outside the system. Ask for it.

Questions about the format, or something in a pack that does not check out: support@cerenaid.com.