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 |
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 proves 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.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.