C.E.R.T.O.
C.E.R.T.O.
Beneath every acquisition lies the same architecture: first each module collects the content and its metadata read-only and computes its fingerprints, then everything is sealed into a BagIt bundle signed with Ed25519, anchored in time by a double RFC 3161 timestamp and described in CASE/UCO. Here we explain it step by step, with the diagrams and the reference standards.
From per-module collection to the cryptographic seal, down to a verification anyone can reproduce — even offline and without C.E.R.T.O.
All modules share the same forensic skeleton; only the way they access the source and the captured artefacts change.
MD5/SHA-1/SHA-256/SHA-512 fingerprints (FIPS 180-4). Only steps 03 and 04 — highlighted — change from module to module.| Module | How it accesses (03) | What it captures (04) | Module-specific standards & formats |
|---|---|---|---|
| Web pages | Instrumented forensic browser; navigation confined to the declared scope | Rendered HTML, DOM snapshot, WACZ archive, viewport/full-page screenshots, video, HAR traffic, DNS/WHOIS/traceroute, TLS certificates, cookies |
WACZ · WARC (ISO 28500) · HAR · RFC 8446 (TLS 1.3) |
| Files | Download of the exact byte-stream delivered by the server (HTTP/HTTPS) | Original file, HTTP headers, server IP, TLS certificates, EXIF/XMP/IPTC metadata and document properties | RFC 9110 (HTTP) · FIPS 180-4 · EXIF · XMP (ISO 16684) |
| Email / PEC | IMAP read-only: EXAMINE + BODY.PEEK (flags unchanged) |
Original EML (headers, body, attachments), DKIM/SPF/DMARC check; for PEC the envelope, daticert.xml and the provider S/MIME signature |
RFC 3501 (IMAP) · RFC 5322 · RFC 6376 (DKIM) · S/MIME · AgID PEC |
| WhatsApp Web: account linked via QR, instrumented web client | Messages, media and attachments, account/session metadata (cookies, localStorage, IndexedDB), video of the whole session |
RFC 6455 (WebSocket) · FIPS 180-4 | |
| Telegram | Telegram Web: linked account; private chats, groups, supergroups and channels | Messages (text, date, author), media, session metadata and video of the whole session | FIPS 180-4 · instrumented web client |
| Images | Image file supplied by the operator (no alteration of the file) | EXIF/IPTC/XMP and GPS metadata, perceptual hashes, histogram, ELA, Luminance Gradient, Level Sweep, JPEG quantization tables, C2PA provenance |
EXIF · XMP (ISO 16684) · C2PA · perceptual hashes |
| Screenshot | System-level screen capture: the operator does not interact with the image | Image (full screen or region, multi-monitor), PC and display state, cryptographic and perceptual hashes | FIPS 180-4 · perceptual hashes |
| FTP / SFTP | Read-only access to FTP/FTPS/SFTP; recursive copy of the remote filesystem | Copied files with folder structure, server tree map, connection and protocol info | RFC 959 (FTP) · RFC 4253 (SSH/SFTP) · TLS |
| Cloud | Authenticated OAuth access to Google Drive, Dropbox, OneDrive (no password stored) |
Files with provider-side hash reconciliation, sharing/exposure, revisions, trash, API log | RFC 6749 (OAuth 2.0) · provider content-hash · FIPS 180-4 |
| Deep Web (Tor) | Dedicated browser routed only over Tor: fresh memory-only session, proxy verified before every load, no fallback to the ordinary network | Pages, WACZ archive, reports and attachments; circuit taken node by node, checksum verification of the .onion address, register of omitted checks. The content stays only on the operator's computer: the server receives the fingerprints |
Tor onion service · WACZ · FIPS 180-4 |
The acquired artefacts become the payload of a BagIt 1.0 bundle (RFC 8493): a structure of files and manifests that fixes what the exhibit contains and guarantees its fixity.
bagit.txt declares the version and encoding; bag-info.txt carries the Payload-Oxum (byte sum and file count, a completeness check). The manifest-sha256.txt holds the SHA-256 hash of every file in data/: regenerating it reveals any addition, removal or change. The tagmanifest-sha256.txt extends the same guarantee to the control files.The exhibit manifest is signed with an Ed25519 key generated on the device and registered at first launch: it binds the acquisition to a verifiable identity.
Two independent timestamps anchor the exhibit in time: one inner on the payload and one outer on the whole bundle, each issued by a Time-Stamping Authority (TSA).
Beyond the files, the exhibit is described in a standard semantic graph (JSON-LD): what was acquired, with which tool, by whom, when and with what fingerprints.
metadata/evidence.case.jsonld file makes the exhibit interoperable: other tools can read, correlate and validate it unambiguously, linking file, hash, tool, operator, action and provenance into a single graph.The bundle verifies itself: the included verifiers redo the maths and declare whether the exhibit is intact — without C.E.R.T.O. and without the internet.
tsa-ca.pem (so even offline). If everything matches, they declare “VALID BUNDLE”; if even a single byte changed, verification fails and flags it. The same check can be reproduced by hand with openssl and standard BagIt tools: no lock-in.Two real web page acquisitions, to open and browse as a judge or an opposing expert would.
Text, an image with metadata, a PDF and a video: the bundle contains them all, with their fingerprints. Acquired page: /demo/en/
Download the ZIP · 11.9 MB
SHA-256 f93d3dd362101df7f8beccabf291e8a32986f795e19c3c78d8253547dfde4952
The public example page run by IANA: the simplest possible case. Acquired page: example.com/
Download the ZIP · 2.9 MB
SHA-256 ecb73368c1492ea13ccbfbdb70b6761e32ed607c2c006d3b94f6a086bac928a5
Worth knowing before you run the check. Before publishing them we removed the tax code of the person who acquired them. That is why the file fingerprints match but the signature and both timestamps, applied to the original files, fail: which is exactly what they must do when a bundle is modified. The LEGGIMI file in the ZIP lists the changed files with their fingerprints before and after. An unmodified bundle from C.E.R.T.O. passes every check.
No proprietary invention: every component of the bundle relies on a public, verifiable standard.
BagIt 1.0 — bundle structure and fixity manifests
Secure Hash Standard — SHA-1/256/512 (+ MD5, RFC 1321)
EdDSA Ed25519 signature and key identity
Time-Stamp Protocol — TSA timestamp
EU qualified timestamp (Reg. 910/2014) — InfoCert option
JSON-LD forensic ontologies for exhibit description
Guidelines for identification, collection and preservation of digital evidence
WARC and Web Archive (WACZ) for web page acquisition
IMAP (read-only) and DKIM for email/PEC acquisition
OAuth 2.0 for authenticated access to cloud accounts
Image and document metadata and provenance
Multi-source time synchronisation with documented offset
Register for free and apply the same forensic architecture to every acquisition, on Windows and macOS.