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