Account presso exchange e account cloud come prove

La maggior parte delle indagini che iniziano on-chain termina presso un servizio: un exchange che sa chi ha prelevato i fondi, un account cloud che contiene il backup, una casella di posta elettronica piena di conferme di deposito. I dati di questi fornitori spesso rivelano l'identità e l'intento che la blockchain non può mostrare. Tuttavia, un foglio di calcolo proveniente da un exchange non costituisce di per sé una prova: l'esaminatore deve sapere da dove proviene, se è completo, che cosa significa ciascuna colonna e se concorda con la blockchain. Questa lezione illustra che cosa contengono i dati dei fornitori, come autenticarli, come gestire l'accesso agli account attivi e come riconciliare i dati dei fornitori con i dati on-chain.

Contenuto dei dati degli exchange e dei servizi di custodia

Le modalità di richiesta dei dati sono trattate nella lezione Collaborare con i fornitori di servizi; questa lezione inizia al momento della ricezione della risposta. Una tipica documentazione fornita da un exchange o da un custode contiene:

I dati possono pervenire in tre modi, con diverso valore probatorio. Le produzioni documentali del fornitore rispondono a richieste formulate nell'ambito di un procedimento legale e sono accompagnate da informazioni sulla provenienza fornite dal fornitore. Le esportazioni dell'utente, come estratti conto scaricati da un sospettato o forniti da una vittima, vengono rinvenute sui dispositivi o consegnate e devono essere verificate presso il fornitore. Le acquisizioni in tempo reale sono dati che un investigatore raccoglie accedendo all'account sulla base di un'autorizzazione o del consenso. Un riscontro deve indicare su quale tipologia si fonda.

Autenticazione dei dati del fornitore

Autenticare significa dimostrare che un documento è ciò che dichiara di essere e non è stato modificato da quando è stato prodotto.

1. Provenienza. Documentare chi ha richiesto i dati, in base a quale autorizzazione, attraverso quale canale (un portale per le forze dell'ordine, un trasferimento sicuro, supporti fisici), chi li ha ricevuti e quando.
2. Integrità alla ricezione. Calcolare immediatamente l'hash di ogni file consegnato, conservare l'originale senza modificarlo e lavorare su copie. Se il fornitore fornisce i propri hash, confrontarli.
3. Attestazione. Molti fornitori possono fornire una dichiarazione del responsabile della conservazione dei documenti che descrive come i dati vengono creati e conservati nel normale svolgimento dell'attività. La necessità di tale dichiarazione e la forma richiesta dipendono dalla giurisdizione; richiederla comporta un impegno minimo.
4. Significato. Ottenere un dizionario dei dati: quale fuso orario utilizzano i timestamp, se gli importi sono al lordo o al netto delle commissioni, che cosa significa ciascun codice di stato, come vengono rappresentati i trasferimenti interni.
5. Completezza. Verificare che siano stati consegnati tutti i dati richiesti relativi al periodo, agli account, agli asset e alle tipologie di dati, e che il saldo iniziale più i movimenti corrisponda al saldo finale.

I software per fogli di calcolo causano errori evitabili. Gli identificativi numerici lunghi possono essere convertiti in notazione scientifica, gli zeri iniziali eliminati, gli importi arrotondati e le date reinterpretate nei formati locali. Importare i file del fornitore in uno strumento di analisi o in un database come testo, effettuare le conversioni in modo consapevole e conservare i passaggi di conversione.

Accesso agli account attivi e dati API

Talvolta gli investigatori accedono direttamente a un account: con il consenso di una vittima, con credenziali rinvenute durante una perquisizione legittima o tramite l'API di un exchange. I dati raggiunti in questo modo possono essere conservati all'estero. La Convenzione di Budapest, articolo 32, consente a una parte di accedere ai dati conservati nel territorio di un'altra parte con il consenso legittimo e volontario della persona che ha l'autorità legale di divulgarli, nonché di accedere a dati pubblicamente disponibili; al di fuori di questi casi, si applicano le procedure descritte nella lezione Autorizzazione legale e cooperazione internazionale. Quando è disponibile un ordine di esibizione, questo offre generalmente garanzie di provenienza più solide rispetto a un accesso all'account.

Se si ricorre all'accesso a un account attivo, documentarlo come un'attività in tempo reale: registrazione dello schermo durante la sessione, ora, account, ogni esportazione scaricata con il relativo hash e, per le chiamate API, endpoint, parametri e risposta grezza salvata senza modifiche. Prestare attenzione a non modificare l'account: nessuna operazione di scambio, nessuna modifica delle impostazioni, nessuna reimpostazione della password che avvisi il titolare e nessuna azione che violi gli accordi di non divulgazione del fornitore.

Riconciliazione dei dati del fornitore con i dati on-chain

I dati di un fornitore e la blockchain sono due fonti indipendenti relative agli stessi eventi. La loro riconciliazione permette di verificarle entrambe, e un dato riconciliato è molto più difficile da contestare rispetto a ciascuna fonte considerata singolarmente. La verifica principale dei prelievi unisce le righe del fornitore ai dati della blockchain propri dell'unità:

-- Riconciliare i prelievi del fornitore con gli output on-chain (tabelle di tipo UTXO)
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount_sat,  -- importo dell'estratto conto, convertito in satoshi all'importazione
       o.value AS value_sat, t.block_timestamp,
       CASE
         WHEN w.txid IS NULL THEN 'NO_TXID'
         WHEN t.hash IS NULL THEN 'TXID_NOT_ON_CHAIN'
         WHEN o.transaction_hash IS NULL THEN 'ADDRESS_NOT_IN_TX'
         WHEN o.value <> w.amount_sat THEN 'AMOUNT_DIFFERS'
         ELSE 'MATCHED'
       END AS status
FROM provider_withdrawals w
LEFT JOIN transactions t ON t.hash = w.txid
LEFT JOIN outputs o ON o.transaction_hash = t.hash AND o.address = w.to_address
ORDER BY w.requested_utc;

Ogni riga relativa a un prelievo viene associata prima alla transazione tramite il txid, poi all'output che paga l'indirizzo indicato e infine all'orario confermato del relativo blocco. Le left join mantengono le righe del fornitore prive di corrispondenza, e l'espressione CASE le suddivide in categorie spiegabili anziché eliminarle. L'output contiene l'importo al netto della commissione di prelievo del fornitore, mentre la query confronta l'importo così come riportato nell'estratto conto; stabilire se tale cifra sia lorda o netta richiede di consultare il dizionario dei dati, e uno scostamento pari alla commissione è una differenza spiegata, non una mancata corrispondenza (W-102 qui sotto). Nelle blockchain basate sul modello ad account, la join sugli output diventa una join sui trasferimenti o sui log di trasferimento dei token, con un indice del log al posto dell'output.

Un esempio svolto di riconciliazione di cinque prelievi da un account:

Ogni riga risulta infine corrispondente oppure spiegata. W-103 è un caso tipico: i trasferimenti interni tra clienti dello stesso servizio sono scritture nel registro contabile del fornitore, quindi i dati del fornitore ne costituiscono l'unica prova (si veda la lezione Tracciamento attraverso exchange e servizi di custodia). W-104 mostra perché una transazione cumulativa non debba essere attribuita interamente a un solo cliente. I depositi vengono riconciliati nello stesso modo, ricordando che i fornitori successivamente consolidano i depositi in hot wallet. Le differenze temporali devono essere spiegate attraverso il fuso orario del fornitore e l'intervallo tra richiesta, trasmissione e conferma.

Account cloud come prove

I servizi cloud conservano ciò che gli utenti vogliono mantenere al sicuro o sincronizzato: foto di frasi seed, backup di wallet, fogli di calcolo di indirizzi, archivi di gestori di password, note ed email con notifiche degli exchange relative a depositi, prelievi, accessi e passaggi KYC. Questi dati vengono ottenuti e autenticati come quelli degli exchange: preservati tempestivamente, prodotti sulla base di un'autorizzazione, sottoposti al calcolo dell'hash alla ricezione e verificati quanto alla completezza.

L'attacco a Bitfinex del 2016 mostra il valore della loro combinazione con i dati della blockchain. Sulla base di un mandato di perquisizione, gli investigatori ottennero un file da un account di archiviazione cloud e lo decifrarono. Il file elencava circa 2.000 indirizzi di valuta virtuale con le relative chiavi private. L'analisi della blockchain collegò quasi tutti questi indirizzi al furto e, il 31 gennaio e il 1° febbraio 2022, le autorità sequestrarono da essi circa 94.636 BTC. Il file cloud fornì la prova del controllo e un collegamento al suo titolare; la blockchain confermò che gli indirizzi corrispondevano ai fondi rubati. Nessuna delle due fonti, da sola, avrebbe avuto lo stesso peso.

Focus sull'esame: contenuto dei dati degli exchange (KYC, registro contabile, depositi, prelievi, operazioni di scambio, log di accesso, canali in valuta fiat) e uso forense di ciascuna tipologia; produzioni documentali del fornitore, esportazioni dell'utente e acquisizioni in tempo reale a confronto; le cinque fasi di autenticazione (provenienza, integrità alla ricezione, attestazione, significato, completezza) e le insidie dei fogli di calcolo; documentazione dell'accesso agli account attivi e tramite API e procedura basata sul consenso prevista dall'articolo 32 della Convenzione di Budapest; riconciliazione dei prelievi tramite txid, indirizzo, importo netto e ora; spiegazione di trasferimenti interni, commissioni, transazioni cumulative e richieste annullate; account cloud come fonti di chiavi, backup e notifiche; il caso Bitfinex come esempio di combinazione di prove provenienti dal cloud e dalla blockchain.