C.E.R.T.O.
C.E.R.T.O.
Sotto ogni acquisizione c'è la stessa architettura: prima ogni modulo raccoglie il contenuto e i suoi metadati in sola lettura calcolandone le impronte, poi tutto viene sigillato in un fascicolo BagIt firmato Ed25519, ancorato nel tempo da marche RFC 3161 — fra cui, dalla versione 3.3.3, un sigillo qualificato eIDAS InfoCert — e descritto in CASE/UCO. Qui la spieghiamo passo per passo, con gli schemi e gli standard di riferimento.
Dalla raccolta per-modulo al sigillo crittografico, fino alla verifica che chiunque può rifare da sé, senza C.E.R.T.O.
Tutti i moduli condividono lo stesso scheletro forense; cambiano solo il modo di accedere alla sorgente e gli artefatti catturati.
MD5/SHA-1/SHA-256/SHA-512 (FIPS 180-4). Solo i passi 03 e 04 — evidenziati — cambiano da modulo a modulo.| Modulo | Come accede (03) | Cosa cattura (04) | Standard e formati specifici |
|---|---|---|---|
| Pagine web | Browser forense controllato dal software; navigazione confinata allo scope dichiarato | HTML reso, snapshot DOM, archivio WACZ, screenshot viewport/full-page, video, traffico HAR, DNS/WHOIS/traceroute, certificati TLS, cookie |
WACZ · WARC (ISO 28500) · HAR · RFC 8446 (TLS 1.3) |
| File | Download del byte-stream esatto consegnato dal server (HTTP/HTTPS) | File originale, header HTTP, IP server, certificati TLS, metadati EXIF/XMP/IPTC e proprietà del documento | RFC 9110 (HTTP) · FIPS 180-4 · EXIF · XMP (ISO 16684) |
| Email / PEC | IMAP in sola lettura: EXAMINE + BODY.PEEK (i flag non cambiano) |
EML originale (header, corpo, allegati), verifica DKIM/SPF/DMARC; per PEC busta, daticert.xml e firma S/MIME del gestore |
RFC 3501 (IMAP) · RFC 5322 · RFC 6376 (DKIM) · S/MIME · AgID PEC |
| WhatsApp Web: account collegato via QR, client web controllato dal software | Messaggi, media e allegati, metadati di account/sessione (cookie, localStorage, IndexedDB), video dell'intera sessione |
RFC 6455 (WebSocket) · FIPS 180-4 | |
| Telegram | Telegram Web: account collegato; chat private, gruppi, supergruppi e canali | Messaggi (testo, data, autore), media, metadati di sessione e video dell'intera sessione | FIPS 180-4 · client web controllato dal software |
| Immagini | File immagine fornito dall'operatore (nessuna alterazione del file) | Metadati EXIF/IPTC/XMP e GPS, hash percettivi, istogramma, ELA, Luminance Gradient, Level Sweep, tabelle di quantizzazione JPEG, provenienza C2PA |
EXIF · XMP (ISO 16684) · C2PA · hash percettivi |
| Screenshot | Cattura dello schermo dal sistema: l'operatore non interagisce con l'immagine | Immagine (schermo intero o regione, multi-monitor), stato del PC e dei display, hash crittografici e percettivi | FIPS 180-4 · hash percettivi |
| FTP / SFTP | Accesso in sola lettura a FTP/FTPS/SFTP; copia ricorsiva del filesystem remoto | File copiati con struttura delle cartelle, mappa ad albero del server, info di connessione e protocollo | RFC 959 (FTP) · RFC 4253 (SSH/SFTP) · TLS |
| Cloud | Accesso autenticato OAuth a Google Drive, Dropbox, OneDrive (nessuna password memorizzata) |
File con riconciliazione dell'hash lato provider, condivisione/esposizione, revisioni, cestino, log delle API | RFC 6749 (OAuth 2.0) · content-hash provider · FIPS 180-4 |
| Deep Web (Tor) | Browser dedicato instradato solo via Tor: sessione nuova in memoria, proxy verificato prima di ogni caricamento, nessun ripiego sulla rete ordinaria | Pagine, archivio WACZ, rapporti e allegati; circuito seguito nodo per nodo, verifica del codice di controllo dell'indirizzo .onion, registro delle indagini omesse. Il contenuto resta solo sul computer dell'operatore: al server arrivano le impronte |
Tor onion service · WACZ · FIPS 180-4 |
| Registrazione schermo | Cattura dal sistema di uno schermo intero o della finestra di una sola applicazione, con audio di sistema e microfono; la barra di controllo è esclusa dalla cattura | Video originale WebM scritto a blocchi di un secondo concatenati con SHA-256, tre tracce audio (combinata, sistema, microfono), copia MP4 derivata con la sincronia misurata, fotografia di tutti gli schermi, rete e processi della postazione, identità dell'applicazione registrata. Il contenuto resta solo sul computer dell'operatore: al server arrivano impronte e metadati |
WebM (VP9 · Opus) · MP4 (H.264 · AAC) · FIPS 180-4 |
Gli artefatti acquisiti diventano il payload di un fascicolo BagIt 1.0 (RFC 8493): una struttura di file e manifesti che fissa cosa contiene il reperto e ne garantisce la fixity.
bagit.txt dichiara versione e codifica; bag-info.txt riporta il Payload-Oxum (somma di byte e conteggio file, un controllo di completezza). Il manifest-sha256.txt contiene l'hash SHA-256 di ogni file in data/: basta rigenerarlo per scoprire qualsiasi aggiunta, rimozione o modifica. Il tagmanifest-sha256.txt estende la stessa garanzia ai file di controllo.Il manifesto del reperto è firmato con una chiave Ed25519 generata sul dispositivo e registrata al primo avvio: lega l'acquisizione a un'identità verificabile.
Dalla versione 3.3.3 ogni fascicolo è chiuso da una marca temporale qualificata eIDAS InfoCert, inclusa nel prezzo. Le altre due marche, interne, restano emesse da TSA pubbliche.
tagmanifest-sha256.txt, che contiene in catena le impronte di tutti gli altri file: ancorare quel file significa ancorare l'intero fascicolo. Dalla versione 3.3.3 il sigillo è emesso da InfoCert, prestatore qualificato: è una marca qualificata eIDAS (Reg. UE 910/2014, ETSI EN 319 422).Per una marca temporale qualificata il regolamento eIDAS (art. 41, par. 2) stabilisce una presunzione: che data e ora siano esatte e che i dati marcati siano integri. Qui i dati marcati sono il tagmanifest, e attraverso le sue impronte ogni file del fascicolo.
eIDAS qualifica la marca, non l'acquisizione: la presunzione riguarda il «quando» e il «non è cambiato», non il valore di ciò che il fascicolo contiene. Quello lo valuta il giudice, insieme al resto del fascicolo.
Il sigillo qualificato non costa slot in più, in nessun modulo che produce un fascicolo. I prezzi valgono da C.E.R.T.O. 3.3.3; le versioni precedenti applicano il listino precedente: aggiorna il programma.
Se InfoCert non risponde, il sigillo lo appone una TSA pubblica e il fascicolo lo dichiara in bag-info.txt (External-Seal-TSA). Lo si legge nel fascicolo, non lo si scopre dopo.
Le verifiche OSINT non producono un fascicolo, e restano come prima: 1 slot, 3 con la marca InfoCert. Tutte le tariffe nella pagina dei prezzi.
Oltre ai file, il reperto è descritto in un grafo semantico standard (JSON-LD): cosa è stato acquisito, con quale strumento, da chi, quando e con quali impronte.
metadata/evidence.case.jsonld rende il reperto interoperabile: altri strumenti possono leggerlo, correlarlo e validarlo senza ambiguità, collegando file, hash, strumento, operatore, azione e provenienza in un unico grafo.Il fascicolo si valida da solo: i verificatori inclusi rifanno i conti e dichiarano se il reperto è integro — senza C.E.R.T.O.
openssl e gli strumenti BagIt standard: nessun lock-in. Su Mac e Linux i verificatori si avviano dal Terminale con sh verify.sh, su Windows con un doppio clic su verify.bat; per firma e marche serve OpenSSL 3, che su Mac lo script scarica da sé se manca.Acquisizioni reali di pagine web, da aprire e sfogliare come farebbe un giudice o un consulente di parte.
Il più completo, e integro: l'acquisizione della home di questo sito del 12 ottobre 2026, spiegata file per file, con video, schermate, email e rapporti. Firma e marche si verificano: esempio di acquisizione di una pagina web.
Testo, un'immagine con metadati, un PDF e un video: il fascicolo li contiene tutti, con le rispettive impronte. Pagina acquisita: /demo/
Scarica lo ZIP · 11,9 MB
SHA-256 f93d3dd362101df7f8beccabf291e8a32986f795e19c3c78d8253547dfde4952
La pagina d'esempio pubblica gestita da IANA: il caso più semplice possibile. Pagina acquisita: example.com/
Scarica lo ZIP · 2,9 MB
SHA-256 ecb73368c1492ea13ccbfbdb70b6761e32ed607c2c006d3b94f6a086bac928a5
Da sapere prima di lanciare la verifica. Prima di pubblicarli abbiamo tolto dai due fascicoli il codice fiscale di chi ha acquisito. Per questo le impronte dei file tornano, ma la firma e le due marche temporali, apposte sui file originali, falliscono: è esattamente ciò che devono fare quando un fascicolo viene modificato. Il file LEGGIMI nello ZIP elenca i file cambiati con le impronte prima e dopo. Un fascicolo che esce da C.E.R.T.O. senza modifiche supera tutti i controlli.
Nessuna invenzione proprietaria: ogni componente del fascicolo si appoggia a uno standard pubblico e verificabile.
BagIt 1.0 — struttura del fascicolo e manifesti di fixity
Secure Hash Standard — SHA-1/256/512 (+ MD5, RFC 1321)
Firma EdDSA Ed25519 e identità di chiave
Time-Stamp Protocol — marca temporale della TSA
Marca qualificata UE (Reg. 910/2014) — sigillo InfoCert del fascicolo, dalla 3.3.3
Ontologie forensi JSON-LD per la descrizione del reperto
Linee guida per identificazione, raccolta e conservazione della prova digitale
WARC e Web Archive (WACZ) per l'acquisizione di pagine web
IMAP (sola lettura) e DKIM per l'acquisizione email/PEC
OAuth 2.0 per l'accesso autenticato agli account cloud
Metadati e provenienza di immagini e documenti
Video originale della registrazione dello schermo e copia derivata per la visione
Sincronizzazione temporale multi-sorgente con offset documentato
Registrati gratis e applica la stessa architettura forense a ogni acquisizione, su Windows e macOS.