An archive that cannot keep quiet about a change

The audit chain

Every action on the archive becomes an entry in a journal: every message taken in, every search, every export and printout, every tag and note, every change to the retention policy, every hold, every erasure, every verification and every collection run. Each entry carries the digest of the one before it. Change, reorder or remove an entry, and every entry after it stops verifying.

When several are at work on the same archive at once – the window, the command line, a scheduled run – each appends its entry where the chain ends at that moment. None writes over another's.

The journal lives outside the database and survives its loss. The database is only an index and can be rebuilt from the pack files at any time.

Seals with Ed25519

At regular intervals – after a set number of entries, and at least daily – a seal is taken: an Ed25519 signature over the head of the chain and the number of entries at that moment. A seal proves the chain had exactly that content then. The public key travels with every seal and can be handed to an auditor separately.

Time from outside

Anyone with administrator rights can set a computer's clock back. A seal that only knows that clock says: “we say it was like this then”.

So every seal also carries an RFC 3161 time-stamp. The time then comes from a time-stamping authority, not from the Mac, and our own statement becomes one a third party attests. The default is SwissSign; if it cannot be reached, MailVault asks DigiCert and then FreeTSA. Only a hash value is sent, never a message.

Each archive can name a different authority, and a machine that is deliberately offline can switch time-stamping off. The control report names the authority, and the compliance report shows any seal without a time-stamp as outstanding.

mailvault policy "Archive.mailvault" --timestamp-authority https://tsa.example.com

For records kept on rewritable media, Switzerland's GeBüV asks for exactly this: that the time of storage can be proven in a way that cannot be falsified, for example by time-stamps (Art. 9(1)(b)(2) GeBüV).

Verify and verify deeply

A verification re-reads the chain and the seals and recomputes them. A deep verification also reads every message back out of the pack files, reassembles it and compares it with the digest taken when it came in. That is the check that finds a damaged disk before anybody else does.

mailvault verify "Archive.mailvault" --deep

Verify where nothing can be written

An archive kept where nothing can be written – on a locked disk, in a disk image opened read-only, on write-once media, or in a folder without write permission – is opened read-only. It can be read, searched, verified, printed and exported. A backup, or a copy handed to an auditor, can be verified deeply without anybody being able to change it, not even by accident.

Nothing done with such a copy is recorded in its audit journal, because nothing can be written there either. MailVault says so beside the archive's name and with every export, rather than passing over it.

An archive written by a newer version of MailVault also opens read-only. An older version can read it; writing to it could lose what the newer version records.

The control report

Switzerland's GeBüV requires information media to be checked regularly for integrity and readability (Art. 10(1)). A check nobody looks at does not do that. So MailVault runs the deep verification as a control that a person starts, and sets a PDF report from it:

• which archive, with its identifier, location, message and attachment counts and the regimes it is configured for,
• which checks passed, which failed and which are outstanding,
• which requirements are organisational and therefore rest with you,
• the evidence: chain head, latest seal, signature and, where present, the time-stamp and the authority that issued it,
• who carried out the control, when and where, and a line for the signature.

The report comes in English, German, French, Italian or Spanish. A signed report naming a different chain head from the archive is a report about a different archive.

What the chain does not prove

It does not prove that a message is what a mail server delivered. That is a separate claim, and it holds only for messages the archive received as messages. Mail rebuilt from an Outlook file is a faithful rendering of the fields Outlook kept, and its digest is the digest of that rendering. The compliance report separates the two under “Message provenance”, in the report an auditor reads.

Recompute it without MailVault

The format is documented, and the documentation ships inside the app. The chain and the seals can be recomputed with sha256sum and any Ed25519 implementation, without our software. A proof only the vendor can check would be no proof.