The attestation record

Beyond storing encrypted snapshots, SafeGrd maintains a tamper-evident, append-only cryptographic record verifying when each snapshot was created, when it was tested, and its exact contents. Every verification step can be independently audited.

How the chain works

Each verification emits a certificate. Every certificate carries the hash of its predecessor, so the sequence is a chain: the first record's PrevHash is the literal string genesis, and every one after it links to the certificate before. Each is signed with Ed25519 by the control plane's attestation key.

This cryptographic linkage provides strict tamper evidence. Editing an older certificate invalidates subsequent hashes in the chain, removing a certificate breaks linkage, and backdating invalidates the signature. Historical compliance records cannot be quietly modified.

Verify it yourself

The command checks four things: that the first record says genesis, that every record links to the certificate hash of the one before it, that every Ed25519 signature is valid under the key the record names, and that no record was changed, removed or inserted.

When the signing key changes

Each record names the key that signed it (signing_key_id). When SafeGrd rotates its attestation key, the old key's public half stays published at /api/v1/attestations/public-key under retired, with the moment it stopped signing, so the records it signed keep verifying. safegrd history checks each record under its own key and prints which keys signed the chain and how many records each. It refuses a record under a retired key that is dated after the retirement, or that follows a record signed under the newer key.

Offline and air-gapped audit

Give an auditor the exported JSON and the public key, and the chain verifies on a machine with no network. --key takes the hex key inline; either way that one key is checked against every record. For a chain that spans a key rotation, save the published key set while online and pass it instead:

An offline check cannot see records the file leaves out. For a chain exported before a key rotation, compare it with safegrd history --node against the server, which walks every record the server holds.

Sample records

These files come from a demo organization. The daemon backed up a PostgreSQL database and a directory into a bucket under S3 Object Lock in compliance mode, then restored the database into an empty one and compared it with the backup.

Change any field in drill-chain.json and the same command reports the record whose signature no longer matches.

Public certificates

An owner or admin can publish one passed drill as a page anyone with the link can open. In the console, open the Fire Drills tab, choose History, then Certificate on the drill, and Publish certificate. The link has the form https://safegrd.dev/c/sgc_…, and the address is random, so nobody can find a certificate without being given it. Search engines are told not to list it. Withdraw turns the link off within a minute. Retiring the surface turns off every certificate published from it.

The page shows:

• the organization’s name
• the kind of surface (a PostgreSQL database, a file tree, a mailbox)
• how the drill ran: restored into a sandbox, restored in full, or decrypted and read in memory
• when the backup was taken and when the drill passed
• the certificate’s id and the key that signed it

By default it shows nothing else: no table or file names, row or file counts, sizes, restore times, surface names, host names, snapshot ids or storage. An owner or admin can add the surface’s name, the restore time and what was restored (tables and rows, files and directories, or emails and folders) with Change under Badge and public page on the Fire Drills tab. The choice covers every public certificate of the organization. Host names, snapshot ids and storage are never shown. The console shows the whole record to the organization’s members.

A surface’s page, for a README badge

A drill’s certificate names one point in time. For a link that stays current, publish the surface’s page from Badge and public page on the Fire Drills tab. Its address, https://safegrd.dev/c/sgs_…, shows the surface’s newest passed drill. Every drill that passes while the page is published is published with it, and the badge markdown the console gives you links there. If a newer drill did not pass, the page says so and shows no seal. Withdrawing the page withdraws the drill certificates it published. Drills you published one by one stay published.

The page checks the certificate’s Ed25519 signature in the browser before it shows the seal. To check it without the page, with OpenSSL 3:

The statement’s record field ties it to the full drill record without revealing it: it is the SHA-256 of a random salt, a |, and the record’s signed fields. The console shows the salt and the command that recomputes it, so the organization can show an auditor which record a certificate stands for.

When a report does not reach us

Backup execution and control plane reporting operate independently. If reporting encounters a network error, the CLI logs a warning to stderr while accurately reflecting the local backup status. The CLI avoids marking a run as attested if the control plane hasn't acknowledged the event, preventing discrepancies between local backups and central compliance logs.