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 una doppia marca RFC 3161 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, anche offline e 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 |
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.
Due marche indipendenti ancorano il reperto nel tempo: una interna sul payload e una esterna sull'intero fascicolo, ciascuna emessa da un'Autorità di Marcatura Temporale (TSA).
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. e senza Internet.
tsa-ca.pem inclusa (quindi anche offline). Se tutto torna, dichiarano «BUNDLE VALIDO»; se anche un solo byte è cambiato, la verifica fallisce e lo segnala. Lo stesso controllo è eseguibile a mano con openssl e gli strumenti BagIt standard: nessun lock-in.Due acquisizioni reali di pagine web, da aprire e sfogliare come farebbe un giudice o un consulente di parte.
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) — opzione InfoCert
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
Sincronizzazione temporale multi-sorgente con offset documentato
Registrati gratis e applica la stessa architettura forense a ogni acquisizione, su Windows e macOS.