La catena di custodia di una prova fotografica

«Catena di custodia» e' una di quelle espressioni che tutti usano e pochi definiscono. Non significa compilare un modulo. Significa una cosa sola: poter dimostrare che, tra il momento del fatto e il momento in cui la prova viene esaminata, nessuno ha potuto alterarla senza lasciare traccia.

Perche' e' il punto decisivo

Una prova digitale ha una caratteristica scomoda: e' perfettamente copiabile e perfettamente modificabile. Non esiste l'equivalente digitale della grana della carta o dell'inchiostro che sbiadisce. Un file alterato non «sembra» alterato.

Ne consegue che la fiducia non puo' poggiare sull'oggetto, ma sul percorso. Se il percorso e' documentato e sigillato, il file e' credibile; se il percorso ha buchi, ogni buco e' un appiglio per la controparte — e non serve dimostrare che una manomissione sia avvenuta, basta mostrare che sarebbe stata possibile.

La domanda non e' «questa foto e' stata alterata?». E' «qualcuno avrebbe potuto alterarla senza che si veda?». Se la risposta e' si', la discussione e' gia' persa.

Il riferimento: ISO/IEC 27037

La norma ISO/IEC 27037:2012 definisce le linee guida per identificazione, raccolta, acquisizione e conservazione delle evidenze digitali. E' il riferimento internazionale del settore, e le sue quattro fasi si mappano con precisione su cio' che accade in una cattura sigillata.

Il dettaglio che fa la differenza e' quanto tempo passa tra la raccolta e l'acquisizione. Nel flusso tradizionale — si fotografa, poi si scarica, poi si «certifica» — quella finestra puo' durare ore o giorni, ed e' esattamente la finestra su cui una contestazione fa leva. Sigillare alla cattura la riduce a frazioni di secondo, dentro un unico processo automatico.

Il pacchetto: BagIt RFC 8493

Una prova non e' solo il file: e' il file piu' tutto cio' che lo documenta. Serve quindi un contenitore, e ne esiste uno standard: BagIt, specificato nella RFC 8493 e nato alla Library of Congress per il trasferimento affidabile di archivi digitali.

La struttura e' semplice e leggibile a occhio: una cartella data/ con il contenuto vero e proprio, e accanto alcuni file di servizio che dichiarano cosa contiene il pacchetto e con quale impronta. Non e' un formato proprietario: chiunque puo' aprirlo, anche fra dieci anni, anche senza il software che l'ha creato.

I sigilli annidati

Il meccanismo funziona a strati, e ogni strato copre il precedente:

Il manifest elenca ogni file del contenuto con la sua impronta SHA-256. Verifica: nessun file e' stato modificato. C'e' anche il controllo inverso, meno ovvio e altrettanto importante: nessun file e' stato aggiunto di nascosto, perche' tutto cio' che sta in data/ deve essere dichiarato.

Il tagmanifest fa la stessa cosa sui file di servizio — compreso il manifest stesso e i metadati forensi. Copre insomma tutto quello che sta fuori dal contenuto. Su questo punto vale la pena essere precisi, perche' e' un errore che LOCUS ha effettivamente commesso e poi corretto: in una versione passata il sidecar dei metadati forensi restava fuori dal sigillo. Oggi il tagmanifest e' generato dinamicamente su ogni file presente, cosi' che non possa piu' sfuggire nulla. I bundle prodotti prima della correzione mantengono quel limite: non c'e' retrocompatibilita' possibile su un sigillo.

La firma Ed25519 lega il manifest a una chiave del dispositivo, registrata al primo utilizzo. Impedisce di ricombinare pezzi provenienti da acquisizioni diverse.

Le due marche temporali chiudono: una sul media, una sul tagmanifest. La seconda e' quella che fissa nel tempo l'intero pacchetto.

Un dettaglio di trasparenza sulla firma

La chiave privata usata per firmare risiede nell'area riservata dell'applicazione sul dispositivo. Non e' custodita in un vault hardware — Secure Enclave o equivalenti — e questo e' un limite reale, dichiarato: la migrazione a chiavi protette da hardware e' un obiettivo, non lo stato attuale. Chi valuta lo strumento deve saperlo, e vale la pena ripeterlo qui invece di lasciarlo scoprire.

Il punto attenuante e' che la firma non e' l'unica garanzia: anche ammettendo la compromissione della chiave, restano le marche temporali di autorita' esterne, che nessuno puo' retrodatare. Le garanzie sono volutamente ridondanti proprio perche' nessun singolo anello sia decisivo.

L'interoperabilita': CASE/UCO

Un pacchetto forense che nessuno riesce a leggere e' un problema rimandato. Per questo il bundle include un file di metadati in formato CASE/UCO (Cyber-investigation Analysis Standard Expression), lo standard adottato in ambito investigativo internazionale e supportato dai principali strumenti di analisi forense.

Significa che il fascicolo puo' essere importato negli strumenti che un consulente usa gia', senza conversioni manuali e senza dipendere da noi. E' anche una garanzia contro il lock-in: la prova resta tua, in un formato che sopravvive al fornitore.

La distinzione che evita figuracce

Qui serve una precisazione che spesso manca. Esiste una catena di custodia tecnica — impronte, sigilli, marche — e una catena di custodia procedurale: chi ha operato, con quale qualifica, con quale titolo, nel rispetto di quali norme processuali.

Un sigillo crittografico impeccabile non sostituisce la seconda. Se l'acquisizione e' avvenuta in violazione di norme procedurali, o da parte di chi non aveva titolo, la solidita' tecnica non la salva: il contesto in cui la documentazione nasce — un incarico peritale, un'attivita' di polizia giudiziaria, un accertamento disposto dal giudice, una raccolta autonoma — cambia le regole da rispettare, e quelle regole non le stabilisce lo strumento.

La catena tecnica fa una cosa sola, ma la fa bene: mette a disposizione un oggetto su cui si puo' fare una verifica, invece di lasciare che l'integrita' resti una questione di parola. Non decide l'ammissibilita' — quella la valuta il giudice caso per caso, e nessuno strumento puo' garantirla in anticipo.

Come si verifica

Il senso di tutto questo e' che chi controlla non debba fidarsi di chi ha prodotto la prova. Il bundle porta con se' gli strumenti per farlo, ed e' pensato per due destinatari diversi.

Il giudice puo' controllare da solo, senza installare nulla: apre nel browser il file di verifica interattivo che sta dentro il pacchetto, e vede se le impronte tornano.

Il consulente tecnico, se nominato, arriva molto piu' a fondo: ricostruisce il bundle, ricalcola le impronte di ogni file e le confronta con quelle firmate nel manifest, verifica la completezza del pacchetto, ripercorre i log della cattura e controlla marche temporali e firma con strumenti standard — shasum, openssl — che non abbiamo scritto noi.

In entrambi i casi l'esito e' binario: le impronte coincidono o non coincidono. E' la differenza tra una consulenza che si conclude con un accertamento e una che si conclude con «non e' possibile stabilirlo». Il percorso completo e' nella pagina come validare un bundle.

Continua con come si dimostra che una foto non e' stata ritoccata e la data di una foto.