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 RFC 3161 timestamps — including, from version 3.3.3, a qualified eIDAS InfoCert seal — 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 on their own, 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 |
| Screen recording | System-level capture of a whole screen or the window of a single application, with system audio and microphone; the control bar is excluded from the capture | Original WebM video written in one-second blocks chained with SHA-256, three audio tracks (combined, system, microphone), derived MP4 copy with measured sync, a snapshot of every screen, the workstation's network and processes, identity of the recorded application. The content stays only on the operator's computer: the server receives fingerprints and metadata |
WebM (VP9 · Opus) · MP4 (H.264 · AAC) · 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.
From version 3.3.3 every bundle is closed by a qualified eIDAS InfoCert timestamp, included in the price. The other two, internal stamps are still issued by public TSAs.
tagmanifest-sha256.txt, which holds, in a chain, the fingerprints of every other file: anchoring that file anchors the whole bundle. From version 3.3.3 the seal is issued by InfoCert, a qualified trust service provider: it is a qualified eIDAS timestamp (EU Reg. 910/2014, ETSI EN 319 422).For a qualified timestamp the eIDAS regulation (art. 41(2)) sets a presumption: that the date and time are accurate and that the stamped data are intact. Here the stamped data are the tagmanifest, and through its fingerprints every file of the bundle.
eIDAS qualifies the timestamp, not the acquisition: the presumption covers “when” and “it has not changed”, not the weight of what the bundle contains. That is for the court to assess, together with the rest of the bundle.
The qualified seal costs no extra slots, in any module that produces a bundle. Prices apply from C.E.R.T.O. 3.3.3; earlier versions apply the previous price list: update the program.
If InfoCert does not respond, the seal is applied by a public TSA and the bundle declares it in bag-info.txt (External-Seal-TSA). You read it in the bundle; you do not find out later.
OSINT checks do not produce a bundle, and stay as before: 1 slot, 3 with the InfoCert timestamp. All rates are on the pricing page.
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.
openssl and standard BagIt tools: no lock-in. On Mac and Linux run the verifiers from the Terminal with sh verify.sh, on Windows double-click verify.bat; the signature and timestamps need OpenSSL 3, which on a Mac the script downloads by itself if it is missing.Real web page acquisitions, to open and browse as a judge or an opposing expert would.
The most complete one, and intact: the acquisition of this site's home page of 12 October 2026, explained file by file, with video, screenshots, email and reports. Signature and timestamps verify: web page acquisition example.
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 bundle seal, from 3.3.3
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
Original screen recording video and derived viewing copy
Multi-source time synchronisation with documented offset
Register for free and apply the same forensic architecture to every acquisition, on Windows and macOS.