Dispositivi e recupero dei wallet · Lezione 4 di 5
Recupero dei wallet in presenza di un legittimo titolo autorizzativo
10 min di lettura
Trovare una frase seed o un file wallet non equivale a sapere che cosa controlla. Il recupero è la fase che trasforma il materiale crittografico in un elenco documentato di indirizzi, saldi e cronologia e, ove il titolo autorizzativo lo consenta, in fondi messi in sicurezza dall'autorità procedente. È anche la fase in cui un esaminatore poco attento può perdere fondi, allertare un sospettato o produrre un risultato non ripetibile. Questa lezione tratta il recupero come una procedura forense svolta in presenza di un legittimo titolo autorizzativo: gli standard coinvolti, l'ambiente, i limiti e la documentazione che rende il risultato difendibile.
Il recupero come procedura forense
Il recupero dovrebbe iniziare solo quando sono stati definiti quattro elementi. Il titolo autorizzativo copre l'esame del materiale crittografico e, se previsto, il trasferimento dei fondi. Il piano indica chi esegue il recupero, chi vi assiste come testimone nell'ambito del doppio controllo e dove saranno destinati i fondi messi in sicurezza (si veda la lezione Messa in sicurezza delle cripto-attività sequestrate). L'ambiente è un dispositivo isolato dell'esaminatore, predisposto appositamente. Infine, il registro viene aperto prima della prima operazione, affinché ogni derivazione, scansione e decisione sia registrata nel momento in cui avviene.
L'obiettivo è duplice: accertare, a fini probatori, che cosa controlla il materiale crittografico ed eliminare il rischio che qualcun altro, in possesso di una copia delle stesse chiavi, trasferisca i fondi per primo.
Dalla frase mnemonica agli indirizzi
La maggior parte dei wallet moderni segue tre Bitcoin Improvement Proposals, riutilizzate anche da molte altre blockchain.
BIP-39 trasforma l'entropia in parole. A un'entropia compresa tra 128 e 256 bit, con incrementi di 32, viene aggiunta una somma di controllo di un bit ogni 32 bit di entropia, ricavata dal relativo hash SHA-256. I bit combinati vengono suddivisi in gruppi di 11 bit, ciascuno dei quali individua una parola in un elenco di 2.048 parole, ottenendo così 12, 15, 18, 21 o 24 parole. La frase, normalizzata secondo Unicode NFKD, viene quindi elaborata per ottenere un seed di 512 bit tramite PBKDF2 con HMAC-SHA512 e 2.048 iterazioni; il salt è la stringa "mnemonic" seguita dalla passphrase facoltativa.
BIP-32 deriva un albero di chiavi da quel seed. La chiave principale si ottiene da HMAC-SHA512 usando "Bitcoin seed" come chiave. Le chiavi figlie sono normali oppure hardened (indice pari o superiore a 2^31, indicato con un apostrofo o con h). Una chiave pubblica estesa consente a chiunque di derivare le chiavi pubbliche figlie normali, rendendo possibili i wallet di sola osservazione; BIP-32 avverte inoltre che una chiave pubblica estesa, combinata con una qualsiasi chiave privata figlia non hardened, rivela la chiave privata genitrice, motivo per cui gli esaminatori trattano le xpub come dati sensibili.
BIP-44 definisce la struttura dell'albero: m / purpose' / coin_type' / account' / change / address_index. I primi tre livelli sono hardened. Il valore di change è 0 per la catena esterna (ricezione) e 1 per la catena interna (resto). I tipi di moneta sono registrati in SLIP-0044, ad esempio 0 per Bitcoin, 1 per tutte le testnet, 2 per Litecoin, 60 per Ether e 195 per Tron. Le proposte successive riutilizzano questa struttura con un numero di purpose diverso per ciascun tipo di script:
| Standard | Primo percorso di ricezione | Tipo di script | Prefisso dell'indirizzo | Chiave estesa |
|---|---|---|---|---|
| BIP-44 | m/44'/0'/0'/0/0 | P2PKH | 1… | xpub |
| BIP-49 | m/49'/0'/0'/0/0 | P2WPKH annidato in P2SH | 3… | ypub per convenzione |
| BIP-84 | m/84'/0'/0'/0/0 | P2WPKH (SegWit nativo) | bc1q… | zpub |
| BIP-86 | m/86'/0'/0'/0/0 | P2TR (Taproot a chiave singola) | bc1p… | xpub (nessun nuovo byte di versione) |
| BIP-44, tipo di moneta 60 | m/44'/60'/0'/0/0 | Account Ethereum | 0x… | — |
La conseguenza sul piano forense è che una sola frase può controllare fondi associati contemporaneamente a più purpose, più account e più blockchain. Anche i wallet Ethereum differiscono: alcuni incrementano l'indice dell'indirizzo (m/44'/60'/0'/0/n), altri l'account (m/44'/60'/n'/0/0). Un recupero che verifichi un solo percorso può segnalare come "vuoto" un wallet che non lo è.
Il problema della passphrase
La passphrase BIP-39 costituisce il limite più importante a qualsiasi affermazione. Ogni passphrase, compresa quella vuota, produce un seed valido e un wallet valido; BIP-39 presenta questa caratteristica come negabilità plausibile. Una passphrase errata non genera alcun messaggio di errore, ma soltanto un wallet diverso, solitamente vuoto. Un utente può quindi mantenere un piccolo saldo esca senza passphrase e le disponibilità effettive sotto una passphrase segreta.
L'esaminatore non può dimostrare che non esista una passphrase. Il risultato deve essere formulato con precisione: "con una passphrase vuota, i wallet derivati non hanno mostrato attività sui percorsi e sulle blockchain elencati", non "il wallet è vuoto". La ricerca, nel materiale del caso, di una passphrase conservata separatamente dalle parole e le domande al riguardo nel rispetto delle regole discusse nella lezione Perquisizione e sequestro di cripto-attività sul posto fanno parte del piano di recupero.
Ripristino su un dispositivo isolato dell'esaminatore
La sequenza generale è la stessa, indipendentemente dal software utilizzato:
- Preparare un dispositivo dedicato dell'esaminatore, appena configurato, che non abbia mai contenuto chiavi di altri casi, con le funzionalità di rete disabilitate. Utilizzare un software open source per wallet o per la derivazione, la cui versione rilasciata sia verificata rispetto all'hash pubblicato, e registrarne nome, versione e hash.
- Verificare la frase. La somma di controllo BIP-39 rileva la maggior parte degli errori di trascrizione; una frase non valida viene riesaminata confrontandola con l'originale in regime di doppio controllo. Per una frase di 12 parole, circa una sequenza casuale di parole su 16 supera la verifica della somma di controllo; una somma di controllo valida avvalora quindi la correttezza della trascrizione, ma non la dimostra.
- Derivare offline le chiavi pubbliche estese e gli indirizzi per ogni purpose, account e blockchain plausibile, esportando esclusivamente materiale pubblico.
- Verificare l'attività in sola osservazione, preferibilmente utilizzando i nodi dell'unità. Interrogare server di terzi rivela gli indirizzi e l'identità di rete dell'unità, il che può compromettere la riservatezza e, tramite il gestore del server, allertare altri soggetti. Eseguire la scansione almeno fino al limite di gap BIP-44 di 20 indirizzi inutilizzati, e oltre quando è noto che il software del wallet utilizza intervalli più ampi.
- Mettere in sicurezza i fondi secondo il piano, trasferendoli al wallet controllato dall'autorità procedente con doppio controllo e una transazione di prova. Non trasferire mai fondi utilizzando il dispositivo o il software del sospettato.
Non tutte le frasi sono BIP-39. I seed Electrum codificano un numero di versione in un hash della frase anziché in una somma di controllo BIP-39; i wallet Monero legacy utilizzano 25 parole; le quote Shamir SLIP-39 richiedono un numero minimo di quote pari alla soglia. Identificare prima lo standard, quindi scegliere un software che lo implementi.
Il registro di recupero documenta ogni esecuzione:
{
"case": "CASE-0417",
"recovery_id": "REC-002",
"source_item": "CASE-0417-I-012 (piastra metallica, sigillo TE-88213 aperto il 2026-03-16T10:05Z)",
"operator": "Esaminatore 2", "witness": "Esaminatore 4",
"environment": "Dispositivo dell'esaminatore EX-07, offline, riconfigurato il 2026-03-15",
"software": "strumento di derivazione open source v4.2.1, SHA-256 della versione rilasciata 9d0c…41ee",
"phrase_standard": "BIP-39, 24 parole, somma di controllo valida",
"passphrase": "vuota (nessuna passphrase rinvenuta nel materiale del caso)",
"paths_scanned": ["m/44'/0'/0'", "m/49'/0'/0'", "m/84'/0'/0'..m/84'/0'/2'", "m/86'/0'/0'", "m/44'/60'/0'/0/0..19"],
"gap_limit_used": 50,
"activity_found": "m/84'/0'/0': 31 indirizzi utilizzati, saldo di 4,21907 BTC al blocco 940.912",
"public_material_exported": "elenco xpub, SHA-256 b77a…0c3e",
"funds_action": "Trasferiti ai sensi del provvedimento OR-2026-118; si veda il registro di trasferimento TR-004"
}
Il registro collega l'esecuzione al reperto sorgente sigillato e all'ora di apertura del sigillo, indica operatore e testimone, identifica l'ambiente e il software verificato, specifica lo standard, l'ipotesi relativa alla passphrase e ogni percorso sottoposto a scansione, e riporta il risultato con un'altezza di blocco, affinché chiunque possa ricontrollare il saldo in seguito.
File wallet cifrati e recupero delle password
I file wallet su computer e telefoni cifrano solitamente il materiale crittografico con una chiave derivata da una password dell'utente. Se la password non è nota, il recupero dipende dal suo ritrovamento o dal suo recupero. In termini generali, il recupero delle password nei laboratori forensi utilizza password candidate costruite a partire dalle informazioni investigative del caso: password trovate altrove sui dispositivi sequestrati, nei gestori di password o negli appunti, fornite durante i colloqui oppure basate su schemi noti dell'utente. Strumenti validati verificano le candidate su una copia del file wallet, mai sull'originale. Le impostazioni di derivazione della chiave del wallet determinano il costo di ogni tentativo, quindi il successo non è mai garantito e l'impegno, i dati di ingresso e i risultati vengono registrati come qualsiasi altra fase dell'esame. Il titolo autorizzativo per questa attività dovrebbe essere esplicito.
I wallet hardware costituiscono un caso diverso. La protezione tramite PIN e i meccanismi di cancellazione in caso di tentativi falliti fanno sì che il recupero avvenga normalmente tramite la copia di sicurezza del seed, non tramite il dispositivo. Gli attacchi fisici all'hardware del dispositivo sono un'attività specialistica, specifica del modello, che esula dall'ambito di questo corso.
Multisig, MPC e casi in cui il recupero non è possibile
Un wallet multisig richiede M chiavi su N per spendere, ma per recuperarlo occorrono anche la chiave pubblica estesa di ogni cofirmatario e l'esatta configurazione dello script, solitamente registrata come descrittore di output (la famiglia BIP-380). Un solo seed di un wallet 2 su 3 non rende disponibile alcun fondo spendibile da solo; l'esaminatore deve cercare il file di configurazione o di backup del wallet e gli altri cofirmatari. Un wallet MPC, o a soglia, non forma mai una chiave completa: le quote risiedono sul dispositivo dell'utente e presso un fornitore o un'altra parte, pertanto una sola quota non è sufficiente e il recupero avviene solitamente attraverso la procedura di recupero del fornitore stesso o una procedura legale rivolta a quest'ultimo (si veda la lezione IDFE-DA Tecnologie di gestione delle chiavi).
| Situazione | Esito tipico | Passo successivo |
|---|---|---|
| Seed perduto, dispositivo cancellato | Nessun controllo | Monitoraggio in sola osservazione; richieste di congelamento quando i fondi raggiungono servizi |
| Passphrase sconosciuta | È visibile solo il wallet con passphrase vuota | Cercare la passphrase; dichiarare il limite nella relazione |
| Password robusta sul file wallet | Il recupero può richiedere troppo tempo o fallire | Registrare l'impegno profuso; monitorare gli indirizzi ricavati da qualsiasi materiale pubblico |
| Multisig al di sotto della soglia | Nessun controllo; cronologia completa degli indirizzi se vengono trovate tutte le xpub | Individuare gli altri cofirmatari o la configurazione |
| Una sola quota MPC | Nessun controllo | Richiedere la collaborazione del fornitore tramite una procedura legale |
Quando il recupero fallisce, il lavoro non è sprecato. Il materiale pubblico consente comunque di attribuire indirizzi, supporta il tracciamento e permette di presentare una richiesta di congelamento nel momento in cui i fondi raggiungono un servizio (si veda la lezione Opzioni di congelamento e sequestro).
Focus sull'esame: i quattro prerequisiti del recupero (titolo autorizzativo, piano, ambiente isolato, registro); i parametri BIP-39 (da 128 a 256 bit, somma di controllo di ENT/32 bit, 2.048 parole, PBKDF2-HMAC-SHA512 con 2.048 iterazioni e salt "mnemonic" più passphrase, seed di 512 bit); le chiavi hardened BIP-32, le xpub di sola osservazione e il rischio legato alla combinazione di xpub e chiave privata figlia; i livelli del percorso BIP-44, i valori di change, i tipi di moneta SLIP-0044, il limite di gap di 20 e i purpose 44, 49, 84 e 86 con i relativi tipi di indirizzo; perché una passphrase errata produce un wallet vuoto valido e come formulare tale limite; derivazione offline, verifiche in sola osservazione tramite i propri nodi e formati non BIP-39; recupero delle password in termini generali e recupero dei wallet hardware tramite il seed; requisiti multisig e MPC e passi successivi quando il recupero fallisce.