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 piena di conferme di deposito. I registri di questi provider spesso riportano l'identità e l'intento che la blockchain non può mostrare. Ma un foglio di calcolo di un exchange non si prova da sé: l'esaminatore deve sapere da dove proviene, se è completo, che cosa significa ciascuna colonna e se concorda con la blockchain. Questa lezione illustra quali dati contengono i registri dei provider, come autenticarli, come gestire l'accesso agli account attivi e come riconciliare i dati dei provider con quelli on-chain.

Contenuto dei registri degli exchange e dei custodi

La lezione Collaborare con i provider di servizi spiega come richiedere i registri; questa lezione inizia quando arriva la risposta. Una produzione tipica di un exchange o di un custode contiene:

I registri possono arrivare in tre modi, con diverso peso probatorio. Le produzioni del provider rispondono a un procedimento legale e sono accompagnate dalla provenienza attestata dal provider. Le esportazioni dell'utente, come gli estratti conto scaricati da un sospettato o forniti da una vittima, si trovano sui dispositivi o vengono consegnate e devono essere verificate con il provider. Le acquisizioni in tempo reale sono registri raccolti da un investigatore accedendo con autorizzazione o consenso. Ogni conclusione dovrebbe indicare su quale tipo di acquisizione si basa.

Autenticazione dei registri dei provider

Autenticare significa dimostrare che un registro è ciò che dichiara di essere e che non è stato modificato dalla sua produzione.

1. Provenienza. Registrare chi ha richiesto i dati, in base a quale autorità, attraverso quale canale (un portale per le forze dell'ordine, un trasferimento sicuro, un supporto fisico), chi li ha ricevuti e quando.
2. Integrità al momento della ricezione. Calcolare immediatamente l'hash di ogni file consegnato, conservare l'originale senza modificarlo e lavorare su copie. Se il provider fornisce i propri hash, confrontarli.
3. Attestazione. Molti provider possono fornire una dichiarazione del custode dei registri che descrive come i registri vengono creati e conservati nell'ambito della normale attività aziendale. La necessità di tale dichiarazione e la forma richiesta dipendono dalla giurisdizione; richiederla costa poco.
4. Significato. Ottenere un dizionario dei dati: quale fuso orario usano i timestamp, se gli importi sono lordi o al netto delle commissioni, che cosa significa ciascun codice di stato e come vengono mostrati i trasferimenti interni.
5. Completezza. Verificare che siano stati consegnati tutti i periodi, gli account, gli asset e i tipi di registri richiesti, e che il saldo iniziale più i movimenti corrisponda al saldo finale.

I fogli di calcolo causano errori evitabili. Gli identificativi numerici lunghi possono essere convertiti in notazione scientifica, gli zeri iniziali possono essere eliminati, gli importi arrotondati e le date reinterpretate secondo i formati locali. Importare i file dei provider in uno strumento di analisi o in un database come testo, convertire intenzionalmente i dati e conservare i passaggi di conversione.

Accesso agli account attivi e registri API

A volte gli investigatori accedono direttamente a un account: con il consenso di una vittima, usando credenziali trovate durante una perquisizione legale o tramite l'API di un exchange. I dati raggiunti in questo modo potrebbero essere conservati all'estero. L'articolo 32 della Convenzione di Budapest consente a una parte di accedere ai dati archiviati e situati in un'altra parte con il consenso lecito e volontario della persona che ha l'autorità legittima di divulgarli, e di accedere ai dati pubblicamente disponibili; per gli altri casi si applicano le procedure descritte nella lezione Autorità legale e cooperazione internazionale. Quando è disponibile un ordine di produzione, di solito offre una provenienza più solida rispetto a un accesso tramite login.

Se si ricorre all'accesso in tempo reale, documentarlo come un'azione svolta in tempo reale: registrazione dello schermo della sessione, orario, account, ogni esportazione scaricata con il relativo hash e, per le chiamate API, endpoint, parametri e risposta grezza salvata senza modifiche. Fare attenzione a non modificare l'account: niente operazioni, modifiche alle impostazioni o reimpostazioni della password che avvisino il titolare, e niente azioni che violino gli accordi di non divulgazione del provider.

Riconciliazione dei registri dei provider con i dati on-chain

Un registro del provider e la blockchain sono due fonti indipendenti relative agli stessi eventi. Riconciliarle permette di verificare entrambe, e un registro riconciliato è molto più difficile da contestare rispetto a ciascuna fonte presa singolarmente. La verifica di base dei prelievi collega le righe del provider ai dati on-chain dell'unità:

-- Riconcilia i prelievi del provider con gli output on-chain (tabelle di tipo UTXO)
SELECT w.withdrawal_id, w.txid, w.to_address, w.net_amount_btc,
       o.value_btc, b.block_time_utc,
       CASE
         WHEN w.txid IS NULL THEN 'NO_TXID'
         WHEN t.txid IS NULL THEN 'TXID_NOT_ON_CHAIN'
         WHEN o.txid IS NULL THEN 'ADDRESS_NOT_IN_TX'
         WHEN o.value_btc <> w.net_amount_btc THEN 'AMOUNT_DIFFERS'
         ELSE 'MATCHED'
       END AS status
FROM provider_withdrawals w
LEFT JOIN transactions t ON t.txid = w.txid
LEFT JOIN outputs o ON o.txid = t.txid AND o.address = w.to_address
LEFT JOIN blocks b ON b.block_height = t.block_height
ORDER BY w.requested_utc;

Ogni riga di prelievo viene abbinata prima alla transazione tramite txid, poi all'output che paga l'indirizzo indicato e infine al blocco, per determinare l'orario di conferma. I join sinistri mantengono le righe del provider che non trovano corrispondenza e l'espressione CASE le suddivide in categorie spiegabili invece di eliminarle. Gli importi vengono confrontati al netto della commissione di prelievo del provider, motivo per cui il dizionario dei dati è importante. Nelle blockchain basate su account, il join con gli output diventa un join con i trasferimenti o con i log dei trasferimenti di token, usando un indice di log al posto dell'output.

Esempio di riconciliazione di cinque prelievi da un account:

Ogni riga risulta abbinata oppure spiegata. W-103 è un caso tipico: i trasferimenti interni tra clienti dello stesso servizio sono registrazioni nel libro mastro del provider, quindi i registri del provider ne costituiscono l'unica prova (vedere la lezione Tracciare i fondi attraverso i servizi di custodia). W-104 mostra perché una transazione batch non deve essere attribuita per intero a un solo cliente. I depositi si riconciliano allo stesso modo, tenendo presente che in seguito i provider trasferiscono i depositi nei propri hot wallet. Le differenze temporali dovrebbero essere spiegate in base al fuso orario del provider e all'intervallo tra richiesta, trasmissione e conferma.

Gli account cloud come prove

I servizi cloud conservano ciò che gli utenti vogliono mettere al sicuro o sincronizzare: foto di frasi seed, backup di wallet, fogli di calcolo con indirizzi, archivi di gestori di password, note ed email con notifiche degli exchange relative a depositi, prelievi, accessi e procedure KYC. Questi registri si ottengono e si autenticano come i registri degli exchange: si preservano tempestivamente, si producono sulla base di un'autorità, se ne calcola l'hash alla ricezione e se ne verifica la completezza.

L'hack di Bitfinex del 2016 mostra il valore della combinazione di queste prove con i dati on-chain. Con un mandato di perquisizione, gli investigatori hanno ottenuto un file da un account di archiviazione cloud e lo hanno decifrato. Il file elencava circa 2.000 indirizzi di valuta virtuale con le relative chiavi private. L'analisi della blockchain ha collegato quasi tutti quegli indirizzi al furto e, il 31 gennaio e il 1° febbraio 2022, le autorità hanno sequestrato circa 94.636 BTC da quegli indirizzi. Il file cloud ha fornito la prova del controllo e un collegamento al suo titolare; la blockchain ha confermato che gli indirizzi corrispondevano ai fondi rubati. Nessuna delle due fonti, da sola, avrebbe avuto lo stesso peso.

Focus sull'esame: contenuto dei registri degli exchange (KYC, libro mastro, depositi, prelievi, operazioni, registri di accesso, canali fiat) e uso forense di ciascuno; produzioni del provider vs esportazioni dell'utente vs acquisizioni in tempo reale; le cinque fasi di autenticazione (provenienza, integrità al momento della ricezione, attestazione, significato, completezza) e i rischi dei fogli di calcolo; documentazione dell'accesso in tempo reale e tramite API e percorso del consenso previsto dall'articolo 32 della Convenzione di Budapest; riconciliazione dei prelievi tramite txid, indirizzo, importo netto e orario; spiegazione di trasferimenti interni, commissioni, batch e richieste annullate; account cloud come fonti di chiavi, backup e notifiche; il caso Bitfinex come esempio di combinazione di prove cloud e on-chain.