---
title: "Wallet cold: firma offline, ripristino e controlli operativi"
description: "Impara a progettare e verificare la custodia di cold wallet attraverso generazione delle chiavi, identità del wallet, backup, revisione delle transazioni, firma offline, multisig, recupero e risposta agli incidenti."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Wallet cold: firma offline, ripristino e controlli operativi

> Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

<a id="answer"></a>

## Risposta diretta

Un cold wallet è un sistema di custodia che mantiene il materiale di firma segreto e il passo di approvazione decisivo al di fuori dell'esposizione normale del software connesso a Internet. Gli asset rimangono sulla blockchain; il sistema controlla le chiavi o altra autorità che può autorizzare i cambiamenti di stato. "Cold wallet" è un'etichetta operativa, non una classe di dispositivi definita da protocollo, e la freddezza è una proprietà del flusso di lavoro completo piuttosto che di un marchio o tipo di connessione.

Un firmatario hardware può supportare lo storage a freddo mentre è collegato tramite USB perché la chiave privata può rimanere isolata, tuttavia il flusso di lavoro non è sicuro se l'utente firma una destinazione non verificata o una chiamata a contratto opaca. Al contrario, un computer disconnesso dalla rete non è sicuro solo perché manca di un'interfaccia di rete: entropia compromessa, supporti di installazione, parser di transazioni, supporti rimovibili, backup o schermi possono ancora violare il confine. Lo storage a freddo riduce l'esposizione all'estrazione remota delle chiavi; non dimostra l'intento della transazione, la correttezza del software, il recupero, la privacy o la finalità.

La copia di recupero non è "solo un backup." Un mnemonico, seme grezzo, chiave privata estesa o una quota di recupero equivalente può ricreare l'autorità di spesa e quindi necessita di una protezione comparabile a quella di un firmatario. Una passphrase, un percorso di derivazione, rete, tipo di script, descrittore del portafoglio, ordine delle chiavi e politica di soglia possono anche essere necessari per recuperare gli indirizzi previsti. Un portafoglio pubblico solo di osservazione normalmente non può firmare, ma un `xpub` o un descrittore possono rivelare relazioni tra indirizzi e la cronologia delle transazioni, e BIP-32 conferisce alle chiavi pubbliche estese implicazioni di sicurezza più forti rispetto alle chiavi pubbliche ordinarie.

<a id="mechanism"></a>

## Come progettare e verificare un deposito frigorifero

### 1. Definire autorità e modello di minaccia

Registra la rete, l’asset, l’account o la policy di output esatta, i proprietari, i beneficiari, l’autorità di recupero, la frequenza prevista delle transazioni e l’esposizione operativa massima. Identifica malware remoto, applicazioni dannose, compromissione della catena di fornitura, collusione interna, furto fisico, coercizione, incendio, alluvione, perdita, incapacità e successione come minacce separate. Decidi cosa deve rimanere freddo: una singola chiave privata, tutte le chiavi in una soglia, un quorum di firmatari, una chiave di autorizzazione EIP-712, o un amministratore capace di modificare il codice del portafoglio.

### 2. Inizializzare entropia e software attendibili

Ottieni dispositivi e software tramite canali autenticati, controlla lo stato di inizializzazione, verifica le versioni dove supportato e rifiuta qualsiasi mnemonico o segreto pre-generato fornito nella confezione o da un assistente. Genera entropia in un ambiente controllato e registra quale standard e implementazione l'hanno creata. BIP-39 codifica `128` in `256` bit di entropia come mnemonico e deriva un seme `512-bit` dal mnemonico più una eventuale passphrase; non è uno standard per trasformare una frase memorabile in un portafoglio sicuro.

### 3. Fissare l'identità riproducibile del wallet

Prima di un finanziamento sostanziale, registra la rete, l'impronta digitale principale, lo standard di derivazione e il percorso completo, l'indice del conto, il tipo di indirizzo o script, e i primi indirizzi di ricezione verificati. Per le politiche Bitcoin, conserva il descrittore di output, il checksum, le origini delle chiavi, la soglia, il conteggio dei firmatari, l'ordine delle chiavi e i rami di cambio. Per ciascun firmatario, conferma indipendentemente che la sua chiave e la politica visualizzata siano quelle previste. Tratta uno `xpub` come metadati sensibili: può derivare discendenti pubblici non protetti, compromettere la privacy e, insieme a una corrispondente chiave privata figlia non protetta, esporre la chiave privata estesa principale sotto BIP-32.

### 4. Eseguire il backup e testare il ripristino

Proteggi ogni input di recupero richiesto, incluso il mnemonico o le condivisioni, la passphrase opzionale, il descrittore o la configurazione dell'account intelligente, il percorso di derivazione e le istruzioni di recupero. Non inventare uno schema suddividendo le parole mnemoniche in frammenti ad hoc; utilizza una soglia specificata o un design multisig quando nessuna singola copia dovrebbe essere sufficiente. Colloca le copie in domini di guasto realmente indipendenti e monitora l'accesso senza esporne i contenuti. Su un dispositivo di riserva affidabile o un firmatario reimpostato, esercitati nel ripristino e confronta l'impronta digitale, la politica e l'indirizzo di ricezione previsti prima di cancellare l'ambiente di test.

### 5. Costruire e verificare l'intento completo

Un coordinatore online può ottenere lo stato della catena e costruire una richiesta non firmata, ma non è affidabile. Per un Bitcoin `PSBT`, verifica la rete, ogni input e l'importo UTXO, l'output del destinatario, l'importo, la tassa, il tasso di commissione, il locktime, la policy sighash e se ogni altro output è un cambiamento autenticato. Per una transazione EVM, verifica `chainId`, `nonce`, `to`, `value`, il limite del gas, i limiti delle tasse e `data` decodificato; per EIP-712, verifica il dominio, `chainId`, `verifyingContract`, i campi del messaggio, il nonce e la scadenza, se applicabile. Il EIP-712 struttura i dati e separa i domini, ma lo standard esplicitamente non fornisce protezione contro il replay di per sé.

### 6. Firmare attraverso un confine di trasferimento controllato

Sposta solo il payload non firmato o parzialmente firmato richiesto attraverso il QR, la carta, il cavo o qualsiasi altro canale approvato. I gap d'aria e i codici QR non rendono affidabili i parser o i media: il firmatario deve analizzare il payload, autenticare la policy e le modifiche, mostrare le conseguenze materiali e rifiutare i campi non supportati. In multisig, mantieni firmatari, operatori, sedi, fornitori e percorsi di recupero sufficientemente indipendenti da corrispondere al modello di minaccia; tratta il coordinatore come sostituibile e incapace di modificare la policy inosservato. Confronta la transazione o operazione firmata con l'intento approvato prima della trasmissione.

### 7. Riconciliare, mantenere e preparare la migrazione

Dopo la trasmissione, confrontare l'identificatore della transazione, la transazione inclusa, le uscite o i log, la commissione effettiva, il resto, il nonce del conto, le autorizzazioni e i saldi risultanti con l'intento firmato, quindi attendere la finalità appropriata alla catena e al caso d'uso. Mantenere software compatibile, percorsi firmware verificati, backup leggibili, descrittori documentati ed esercizi periodici di recupero senza inserire segreti di produzione in un dispositivo online. Se un qualsiasi segreto di firma o di recupero può essere esposto, un conto con una singola chiave semplice non può revocare quella chiave: stabilire una nuova autorità, migrare risorse e ruoli, invalidare le autorizzazioni rimanenti laddove il protocollo lo consente, e preservare un registro dell'incidente.

<a id="example"></a>

## Esempi svolti

### Allocazione e finanziamento a fasi

Un piano di custodia limita il portafoglio di interazioni online a `5%` di `100,000 units` del valore dell'asset: `100,000 × 5% = 5,000 units` hot e `95,000 units` cold. La destinazione cold riceve prima un test di `100-unit`, e il trasferimento rimanente è `95,000 - 100 = 94,900 units`. Dopo entrambi i trasferimenti, il saldo target cold è `100 + 94,900 = 95,000 units`; il piccolo test limita un errore di configurazione ma non convalida le firme future o il recupero del backup.

### Bitcoin PSBT tasse e modifica

Un `PSBT` spende input di `0.80 BTC` e `0.35 BTC`, per un totale di `1.15 BTC`. Paga `1.00 BTC` al destinatario e stima `250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC`. La modifica autenticata deve quindi essere `1.15 - 1.00 - 0.000020 = 0.149980 BTC`. Se il firmatario non riesce a identificare quell'output di modifica dal proprio registro di policy, non dovrebbe firmare neanche quando il bilancio aritmetico totale è corretto.

### Budget massimo EVM rispetto alla tariffa effettiva

Un account EVM inizia con `5 ETH` e approva un trasferimento di `1.2 ETH`. Un limite `30,000 gas` e una commissione massima `50 gwei` implicano un budget per le commissioni di `30,000 × 50 gwei = 0.001500 ETH`. Se la transazione utilizza `21,000 gas` a un prezzo effettivo di `25 gwei`, la commissione effettiva è `21,000 × 25 gwei = 0.000525 ETH`, lasciando `5 - 1.2 - 0.000525 = 3.799475 ETH`. Il firmatario deve rivedere i limiti delle commissioni e `data`, non assumere che verrà addebitato il budget massimo o che un'interfaccia dall'aspetto vuoto dimostri un trasferimento ordinario.

### Resilienza dei firmatari due su tre

Una politica `2-of-3` con firmatari `A`, `B` e `C` ha `3` coppie di firma valide: `AB`, `AC` e `BC`. Se un firmatario non è disponibile, rimane esattamente `1` coppia; se un firmatario è compromesso, quel firmatario da solo controlla `0` coppie valide; se due firmatari sono compromessi, controllano `1` coppia valida e possono spendere. Il design quindi tollera una perdita o una compromissione isolata, non due, e il recupero richiede comunque il descrittore corretto, i dati di derivazione e l'ordine delle chiavi.

<a id="risks"></a>

## Rischi e fallimenti della revisione

- **Rete o policy errata:** ripristinare una chiave valida con chain, tipo di indirizzo, script, account o policy di smart account sbagliati può produrre indirizzi diversi o inutilizzabili.
- **Entropia insufficiente:** casualità prevedibile, un brainwallet o un generatore compromesso possono rendere indovinabile anche una chiave offline.
- **Segreto fornito da terzi:** una frase mnemonica prestampata, importata, fotografata o consegnata da un assistente può essere già sotto controllo dell'attaccante.
- **Backup esposto:** carta, metallo, copie cloud, stampanti, fotocamere, spedizioni o documenti ereditari possono rivelare l'intera autorità di spesa.
- **Errore della passphrase:** perdere o digitare male la passphrase BIP-39 può derivare un altro wallet senza mostrare errori.
- **Parametri di derivazione incoerenti:** percorsi, coin type, indici account o convenzioni mancanti possono nascondere asset recuperabili.
- **Perdita della configurazione:** chiavi multisig prive di descrittore, soglia, tipo di script, origine e ordine delle chiavi potrebbero non ricostruire il wallet finanziato.
- **Fuga di metadati pubblici:** un `xpub`, un descrittore, l'elenco degli indirizzi o il database del coordinatore possono esporre saldi, relazioni e indirizzi futuri.
- **Supply chain compromessa:** hardware, firmware, software, confezione o canali di aggiornamento alterati possono sostituire entropia, indirizzi o firme.
- **Sostituzione da parte dell'host:** il coordinatore online può cambiare destinatario, importo, commissione, resto, calldata, messaggio tipizzato o payload non firmato.
- **Display insufficiente:** troncamento, blind signing, script non supportati o decodifica incompleta possono nascondere autorizzazioni importanti.
- **Attacco all'indirizzo di resto:** se il firmatario non autentica il resto rispetto alla policy, una transazione Bitcoin può inviarlo a un attaccante.
- **Errore di commissione o nonce:** commissioni eccessive, nonce EVM vecchi, locktime errati o modalità sighash inattese possono ritardare, sostituire o alterare l'esecuzione.
- **Autorità contrattuale persistente:** approvazioni token, permit, moduli, deleghe e chiamate amministrative possono restare valide oltre la transazione visibile.
- **Attacco al canale di trasferimento:** QR, USB, schede, cavi e formati parser possono trasportare payload dannosi o far fuoriuscire metadati.
- **Soglia correlata:** firmatari nello stesso luogo, seed condivisi o dipendenza da un unico fornitore, operatore o sito di recupero riducono l'indipendenza della soglia.
- **Attacco fisico:** furto, coercizione, sorveglianza, manomissione e scoperta dei segreti restano possibili senza rete.
- **Danno ambientale:** incendio, alluvione, corrosione, degrado dei supporti, casseforti inaccessibili, morte o incapacità possono rendere indisponibile un segreto corretto.
- **Compatibilità in degrado:** firmware vecchio, derivazioni o script non supportati e migrazioni non documentate possono impedire recuperi o firme future.
- **Risposta all'incidente incompleta:** controllare il saldo senza migrare chiavi, ruoli, approvazioni e autorità di recupero può lasciare attiva la compromissione originaria.

<a id="misconceptions"></a>

## Comuni idee sbagliate

### Un portafoglio freddo deve rimanere fisicamente disconnesso per sempre?

No. La proprietà di sicurezza è che l'autorità segreta rimane isolata e la firma avviene attraverso un confine controllato e verificabile. Un firmatore hardware collegato via cavo può mantenere quella proprietà; un computer isolato dalla rete con configurazione compromessa o revisione del payload può non farlo.

### Le monete sono conservate all'interno del dispositivo hardware?

No. Lo stato della blockchain registra le risorse. Il dispositivo protegge o utilizza l'autorità che può firmare le transazioni, e il materiale di recupero compatibile può riprodurre quell'autorità su un'altra implementazione.

### Un backup mnemonico è meno sensibile del dispositivo di firma?

No. Una mnemonica completa e la passphrase richiesta possono ricreare il portafoglio. Un backup è normalmente inattivo, ma il suo compromesso può essere decisivo quanto l'estrazione della chiave di firma attiva.

### Il multisig elimina la necessità di backup e registri di configurazione?

No. Le soglie riducono singoli punti di guasto selezionati, ma ogni chiave necessita di un piano di recupero e la politica del portafoglio o il descrittore devono essere riproducibili. Troppo poche chiavi sopravvissute o una configurazione persa possono comunque bloccare i fondi.

### Un test di trasferimento riuscito dimostra che il sistema di conservazione a freddo è sicuro?

No. Conferma un percorso limitato in un momento. Non dimostra la qualità dell'entropia, la segretezza del backup, il ripristino, la decodifica di transazioni future, l'indipendenza del quorum, gli aggiornamenti software, la sicurezza del contratto o il recupero in caso di incidente.

<a id="related"></a>

## Argomenti correlati

- [Portafoglio hardware](/it/crypto/hardware-wallet/)
- [Frase seme](/it/crypto/seed-phrase/)
- [Chiavi pubbliche e private](/it/crypto/public-private-key/)
- [Portafoglio multisig](/it/crypto/multisig-wallet/)
- [Simulazione della transazione](/it/crypto/transaction-simulation/)

<a id="sources"></a>

## Fonti

- [Panoramica sulla tecnologia blockchain](https://doi.org/10.6028/NIST.IR.8202) - NIST (accesso: 2026-08-19)
- [BIP 32: Portafogli Deterministici Gerarchici](https://bips.dev/32/) - Proposte di miglioramento Bitcoin (accesso: 2026-08-19)
- [BIP 39: Codice mnemonico per generare chiavi deterministiche](https://bips.dev/39/) - Proposte di Miglioramento Bitcoin (accesso: 2026-08-19)
- [BIP 44: Gerarchia multi-account per portafogli deterministici](https://bips.dev/44/) - Proposte di miglioramento Bitcoin (accesso: 2026-08-19)
- [BIP 174: Formato di Transazione Bitcoin Parzialmente Firmata](https://bips.dev/174/) - Proposte di miglioramento Bitcoin (accesso: 2026-08-19)
- [BIP 380: Operazione Generale dei Descrittori di Script di Uscita](https://bips.dev/380/) - Proposte di miglioramento Bitcoin (accesso: 2026-08-19)
- [BIP 129: Impostazione Multisig Sicura Bitcoin](https://bips.dev/129/) - Proposte di miglioramento Bitcoin (accesso: 2026-08-19)
- [EIP-712: Hashing e Firma dei Dati Strutturati Digitati](https://eips.ethereum.org/EIPS/eip-712) - Proposte di Miglioramento Ethereum (accesso: 2026-08-19)

Source: https://wiki.fcontext.com/it/crypto/cold-wallet/index.mdx