Strumenti, riproducibilità e convalida

Quasi ogni traccia crypto viene prodotta con software, e gran parte di questo software è proprietario, cambia rapidamente e riflette opinioni specifiche. Il tribunale non deve fidarsi dello strumento, ma deve potersi fidare del risultato; questa fiducia deriva dal dimostrare che i fatti possono essere ricavati nuovamente dai dati grezzi della blockchain, che lo strumento è stato testato per il compito e che ogni impostazione e fonte delle etichette è stata registrata. Questa lezione illustra come mantenere gli strumenti al loro posto.

Il panorama degli strumenti

Gli strumenti si dividono in alcune categorie generali. Qui i nomi dei prodotti non sono importanti: conta ciò che ciascuna categoria aggiunge alle prove.

La maggior parte delle unità ne usa diversi contemporaneamente: una piattaforma per esplorare e generare piste, un nodo e query proprie per accertare i fatti e una relazione basata su entrambi.

Dati del nodo e output degli strumenti

Ogni output di uno strumento combina tre livelli. I fatti sono dati grezzi della blockchain: txid, output, importi, blocchi. Le trasformazioni deterministiche rendono i dati grezzi leggibili: conversione delle unità, decodifica degli eventi, tracce. Le interpretazioni aggiungono valutazioni: cluster, etichette, identificazione del resto, risultati delle allocazioni.

Uno strumento può sbagliare a ciascun livello. Può analizzare male i dati (i decimali di un token, un trasferimento interno omesso, una riorganizzazione gestita in modo scorretto), può avere una copertura incompleta (un token non indicizzato, una blockchain non supportata, dati non aggiornati alla punta della catena) e può applicare impostazioni predefinite che l'esaminatore non ha mai scelto (un'euristica per identificare il resto attivata, un metodo di allocazione preimpostato). La regola operativa è che ogni fatto contenuto in una relazione forense deve poter essere ricondotto a dati grezzi che una terza parte possa verificare sul proprio nodo, e ogni interpretazione deve indicare il metodo e le impostazioni utilizzati. Uno screenshot di una visualizzazione a grafo serve a illustrare; non costituisce una prova. Conservare le esportazioni sottostanti.

Ripetere una traccia a partire dai dati grezzi

Prima di riportare una traccia, ricavarla nuovamente al di fuori dello strumento che l'ha prodotta:

1. esportare il percorso dello strumento sotto forma di tabella dei passaggi: txid, riferimento all'output o al log, altezza del blocco, importo in unità base;
2. ricavare nuovamente gli stessi campi dal proprio nodo o da un data warehouse riconciliato con un nodo;
3. confrontarli campo per campo;
4. ricalcolare le allocazioni con uno script proprio secondo il metodo dichiarato;
5. registrare le differenze e come sono state risolte.

-- Confronta i passaggi esportati dallo strumento con i valori ricavati nuovamente dal nostro nodo
SELECT t.hop_id, t.txid, t.out_ref,
       t.amount_base  AS tool_amount,   n.amount_base  AS node_amount,
       t.block_height AS tool_height,   n.block_height AS node_height,
       CASE
         WHEN n.txid IS NULL THEN 'NOT FOUND ON NODE'
         WHEN t.amount_base <> n.amount_base
           OR t.block_height <> n.block_height THEN 'MISMATCH'
         ELSE 'OK'
       END AS check_result
FROM tool_hops t
LEFT JOIN node_hops n ON n.txid = t.txid AND n.out_ref = t.out_ref
ORDER BY t.hop_id;

La left join mantiene ogni passaggio riportato dallo strumento, quindi un passaggio assente nei dati del nodo appare come "NOT FOUND ON NODE" invece di scomparire. Gli importi vengono confrontati come numeri interi in unità base, perciò un errore nei decimali appare come una discrepanza di un fattore dieci. La query verifica soltanto i fatti; la corrispondenza dei risultati non dice nulla sulla correttezza delle etichette o dell'identificazione del resto dello strumento.

Convalida degli strumenti

Gli standard di laboratorio richiedono che i metodi, e gli strumenti che li implementano, siano dimostrati idonei allo scopo. La norma ISO/IEC 17025 richiede ai laboratori di convalidare i metodi non standard, quelli sviluppati dal laboratorio e i metodi standard utilizzati al di fuori dell'ambito previsto o modificati in altro modo (clausola 7.2.2). La norma ISO/IEC 27041 fornisce indicazioni per assicurare che i metodi investigativi siano idonei e adeguati. Il sistema di qualità relativo a questo aspetto è trattato nella lezione Gestione della qualità nell'unità forense; qui l'attenzione è rivolta agli strumenti.

Il documento Minimum Requirements for Testing Tools Used in Digital and Multimedia Forensics di SWGDE (documento 18-Q-001, versione 2.1, marzo 2024) descrive tre strategie di test, tutte applicabili agli strumenti blockchain:

• Test con dataset noti: fornire input con una risposta nota e verificare l'output.
• Test comparativi: eseguire almeno due strumenti e verificare che i risultati siano coerenti.
• Test empirici: verificare l'output rispetto ad altri dati.

Il documento richiede anche registrazioni dei test che indichino finalità e ambito, tester, data, procedura, dataset e risultati attesi, risultati con eventuali anomalie e limitazioni riscontrate. Raccomanda di ripetere i test sugli strumenti interni al primo utilizzo e dopo ogni revisione, e di ritestare gli strumenti di ricerca dopo gli aggiornamenti principali. Il programma Computer Forensics Tool Testing (CFTT) di NIST offre un modello per strutturare i test: è basato sulle funzionalità e prevede la stesura di una specifica dei requisiti, delle asserzioni e dei casi di test per ogni funzione dello strumento prima di eseguire i test.

Per uno strumento blockchain, un piano di test pratico elenca le sue funzioni e fornisce per ciascuna una risposta nota:

Le transazioni di test controllate sono particolarmente preziose perché l'unità conosce la verità riguardo alla titolarità e al resto. Tutto ciò che viene rilevato viene inserito in un registro delle limitazioni note, che gli esaminatori consultano prima di fare affidamento sullo strumento e che è disponibile per la divulgazione.

Registrazione delle versioni e delle fonti delle etichette

Ogni esecuzione analitica viene registrata e conservata nel fascicolo del caso:

{
  "run_id": "CF-2026-0142-R07",
  "started_utc": "2026-03-05T08:40:12Z",
  "tool": {"category": "investigation platform", "version": "8.4.1", "data_through_block": 939910},
  "node": {"client": "Bitcoin Core", "version": "29.0", "tip_height": 939962},
  "settings": {"allocation": "haircut", "hop_limit": 6, "change_heuristic": "on",
               "stop_at": "labeled custodial services"},
  "labels_used": [
    {"address": "bc1q…dx7e", "label": "Exchange K deposit", "source": "platform cluster 4471",
     "basis": "co-swept with known deposits", "retrieved_utc": "2026-03-05T08:52:40Z"}
  ],
  "exports": [{"file": "R07_hops.csv",
               "sha256": "3b1f…9e02"}],
  "examiner": "EX-07"
}

La registrazione fissa la versione dello strumento e l'altezza del blocco a cui arrivano i suoi dati, che potrebbe essere inferiore alla punta del nodo. Elenca tutte le impostazioni che modificano i risultati. Ogni etichetta viene registrata insieme alla relativa fonte, alla base dichiarata e all'ora in cui è stata recuperata, perché le etichette cambiano: lo stesso indirizzo potrebbe avere un'etichetta diversa il mese successivo. Ogni esportazione viene sottoposta a hash, così da poter confrontare con essa le copie successive. Nella registrazione effettiva va inserito il nome reale dello strumento; questo corso lo lascia generico. La conservazione di questi file è trattata nelle lezioni Conservazione delle prove on-chain e Hashing, registrazione e catena di custodia.

Quando gli strumenti sono in disaccordo

Il disaccordo tra gli strumenti è normale e utile: indica il punto in cui inizia l'interpretazione. Consideriamo il percorso della lezione Tracciamento secondo uno standard probatorio. Lo strumento A segnala che 0,90909091 BTC del riscatto sono arrivati a bc1q…dx7e e identifica l'indirizzo come deposito di Exchange K. Lo strumento B segnala 1,20000000 BTC e non assegna un'etichetta all'indirizzo.

Partire dal primo punto di divergenza e risalire ai dati grezzi:

Tra le cause comuni vi sono differenze nel clustering (uno strumento ha unito due cluster), diverse identificazioni del resto, fonti o date diverse per le etichette, impostazioni predefinite diverse per l'allocazione, trasferimenti interni o token mancanti e altezze di blocco limite diverse. Registrare il disaccordo, la causa e la risoluzione nel fascicolo del caso e non risolverlo mai scegliendo lo strumento che fornisce la risposta più conveniente. Gli esperti della difesa spesso mettono in discussione l'opacità degli strumenti e la provenienza delle etichette; vedere la lezione Divulgazione e scrutinio della difesa.

Focus sull'esame: le categorie di strumenti e ciò che ciascuna aggiunge alle prove; fatti, trasformazioni deterministiche e interpretazioni, e modalità con cui gli strumenti possono fallire a ciascun livello; perché i fatti riportati devono poter essere ricavati nuovamente dai dati grezzi e perché gli screenshot sono illustrazioni; ripetere una traccia e confrontare le esportazioni dello strumento con i dati del nodo; convalida dei metodi secondo ISO/IEC 17025 e ISO/IEC 27041; le tre strategie di test di SWGDE, le registrazioni dei test e i nuovi test; il modello CFTT di NIST basato sulle funzionalità; test con risposta nota, incluse le transazioni controllate; il registro delle limitazioni note; i campi di una registrazione di esecuzione (versione, altezza dei dati, impostazioni, fonte dell'etichetta e ora del recupero, hash delle esportazioni); diagnosi e documentazione dei disaccordi tra strumenti.