Tecnologie di gestione delle chiavi

Ogni modello di custodia si riduce a una domanda: come viene prodotta una firma valida e chi può produrla? Quattro famiglie di tecnologie dominano la gestione istituzionale delle chiavi e la maggior parte dei custodi ne combina più di una. Ognuna comporta compromessi diversi in termini di trasparenza, flessibilità, supporto delle blockchain e dipendenza da un fornitore; un professionista dovrebbe saper illustrare questi compromessi a un comitato rischi.

Moduli di sicurezza hardware

Un modulo di sicurezza hardware (HSM) è un dispositivo antimanomissione che genera, archivia e usa chiavi, in modo che il materiale della chiave privata non ne esca mai in testo in chiaro. Le applicazioni inviano all'HSM un messaggio da firmare e ricevono una firma. Le banche usano gli HSM da decenni per le carte di pagamento e la PKI, e la maggior parte dei custodi istituzionali di criptovalute li utilizza in qualche punto della propria infrastruttura.

Gli HSM sono convalidati secondo lo standard FIPS 140-3, lo standard statunitense e canadese per i moduli crittografici, gestito dal Cryptographic Module Validation Program (CMVP) del NIST. FIPS 140-3 è entrato in vigore il 22 settembre 2019 ed è allineato con ISO/IEC 19790:2012 (requisiti) e ISO/IEC 24759 (metodi di prova). Definisce quattro livelli di sicurezza:

La custodia istituzionale punta solitamente al Livello 3. Il precedente standard, FIPS 140-2, ha smesso di accettare nuove richieste di test nel settembre 2021. Il 21 settembre 2026 tutti i certificati FIPS 140-2 ancora validi sono stati trasferiti nell'Historical List del CMVP. Le agenzie federali statunitensi non dovrebbero acquistare moduli presenti in tale elenco per nuovi sistemi, e la maggior parte degli acquirenti istituzionali applica la stessa regola. Un nuovo acquisto di HSM dovrebbe quindi essere accompagnato da un certificato FIPS 140-3 in corso di validità.

Un certificato riguarda un singolo modulo, con una specifica versione del firmware e in una specifica modalità. Non certifica l'intero sistema di custodia. Quando si valuta un HSM, occorre verificare il numero del certificato, il livello, la versione del firmware e il supporto degli algoritmi necessari all'attività: secp256k1 per Bitcoin ed Ethereum, Ed25519 per blockchain come Solana. Anche un HSM standard che custodisce una sola chiave costituisce un singolo punto di controllo. Chiunque possa accedere all'HSM e inviargli messaggi può ottenere firme: perciò le procedure che lo regolano sono importanti quanto l'hardware.

Wallet multisignature

Un wallet multisignature (multisig) richiede le firme di m chiavi su n indipendenti, per esempio 3 su 5. La regola è applicata direttamente dalla blockchain:

• Su Bitcoin, tramite script nativi (P2WSH o script Taproot dall'aggiornamento del 2021).
• Su Ethereum e altre blockchain EVM, tramite uno smart contract. Il più usato è Safe (in precedenza Gnosis Safe).

Il multisig presenta vantaggi evidenti. La policy è visibile on-chain, quindi un revisore può confermare che sono richieste 3 firme su 5. Le chiavi possono trovarsi su dispositivi e presso fornitori diversi, in paesi differenti, così che nessuna singola compromissione sia sufficiente. Anche i punti deboli sono concreti. Ogni blockchain richiede la propria implementazione e alcune blockchain non supportano affatto il multisig. Le transazioni sono più grandi e le commissioni più elevate. Su Bitcoin, cambiare un firmatario significa trasferire i fondi a un nuovo indirizzo. Sulle blockchain EVM, il contratto del wallet e la sua interfaccia utente diventano parte della superficie di attacco. Il furto ai danni di Bybit, avvenuto nel febbraio 2025, ha colpito un multisig Safe tramite la sua interfaccia, non la sua crittografia (vedi la lezione Minacce e controlli di sicurezza operativa).

MPC e firme a soglia

Uno schema di firma a soglia (TSS) usa il calcolo multipartitico (MPC) per suddividere il potere di firma tra più parti. Durante la generazione distribuita delle chiavi (DKG), ogni parte crea la propria quota di chiave e la chiave privata completa non esiste mai in alcun luogo, nemmeno per un istante. Per firmare, t parti su n eseguono un protocollo che produce un'unica firma ordinaria. On-chain, la transazione appare esattamente come una transazione con una sola chiave.

Tra i protocolli più comuni figurano GG18, GG20 e CGGMP per ECDSA (lo schema di firma di Bitcoin ed Ethereum) e FROST per le firme Schnorr ed EdDSA. FROST è stato pubblicato dall'IETF come RFC 9591 nel giugno 2024.

L'MPC offre vantaggi concreti:

• Indipendente dalla blockchain: funziona su qualsiasi blockchain che utilizzi una curva supportata, senza richiedere il supporto multisig da parte della blockchain stessa.
• Commissioni più basse e maggiore privacy: la transazione presenta un'unica firma.
• Aggiornamento delle quote: le quote possono essere ruotate, o il quorum modificato, senza trasferire i fondi né cambiare indirizzo.

Comporta anche svantaggi concreti. Il quorum è invisibile on-chain, quindi i revisori devono fare affidamento sulla documentazione del fornitore e sui rapporti di assurance. La crittografia è complessa e le implementazioni hanno presentato vulnerabilità. Nell'agosto 2023, i ricercatori di Fireblocks hanno divulgato le vulnerabilità «BitForge» nelle implementazioni di GG18 e GG20 presso diversi fornitori di wallet (una è stata registrata come CVE-2023-33241); in alcuni casi, un aggressore avrebbe potuto estrarre la chiave completa. La maggior parte delle soluzioni è proprietaria, il che crea dipendenza dal fornitore. Un custode deve disporre di una procedura verificata per recuperare gli asset nel caso in cui il fornitore scompaia.

Non confondere l'MPC con la condivisione segreta di Shamir (SSS). La SSS suddivide una chiave già creata in parti per il backup, ma per firmare la chiave deve essere ricostruita in un unico luogo. L'MPC non la ricostruisce mai. Un concetto correlato su Bitcoin, MuSig2 (BIP 327), consente a n firmatari di combinare le proprie chiavi, così che una spesa Taproot n-su-n appaia come una singola firma.

Wallet basati su smart contract e astrazione degli account

Su Ethereum, un account basato su smart contract è un wallet le cui regole sono definite dal codice. Può applicare limiti di spesa, autorizzazioni per ruolo, chiavi di sessione con diritti limitati, procedure di recupero sociali o istituzionali e il pagamento del gas da parte di terzi. Sono rilevanti due standard:

• ERC-4337, attivo sulla mainnet di Ethereum dal 2023, offre l'astrazione degli account senza modificare il protocollo. Gli utenti inviano «operazioni utente», che i bundler inseriscono in transazioni tramite un contratto EntryPoint condiviso. I paymaster facoltativi possono pagare il gas.
• EIP-7702, attivato con l'aggiornamento Pectra il 7 maggio 2025, consente a un normale account posseduto esternamente (EOA) di puntare a codice di un contratto. L'account acquisisce le funzionalità di uno smart account e mantiene il proprio indirizzo.

Il compromesso è il rischio legato ai contratti. Un bug nel codice del wallet o una funzione di aggiornamento controllata male può causare la perdita di tutto. Con EIP-7702, una singola firma di autorizzazione malevola può cedere il controllo di un account al codice di un aggressore, e le campagne di phishing hanno già preso di mira questa possibilità. Le questioni relative alla possibilità di aggiornamento e alle chiavi di amministrazione sono trattate nella lezione Valutare il rischio DeFi.

Generazione delle chiavi e cerimonie delle chiavi

L'affidabilità di una chiave dipende dal metodo con cui è stata creata. I custodi istituzionali generano le chiavi di alto valore nel corso di una cerimonia delle chiavi: una procedura documentata, presenziata e registrata.

Per l'MPC, la cerimonia DKG dovrebbe generare ogni quota su infrastrutture separate, controllate da persone diverse, affinché nessun singolo team detenga mai un numero di quote sufficiente a raggiungere la soglia.

Scelta e combinazione delle tecnologie

I grandi custodi raramente si affidano a una sola tecnologia. Un modello comune prevede l'MPC per i wallet caldi e tiepidi, dove sono importanti la velocità e il supporto delle blockchain. La conservazione a freddo avviene con chiavi protette da HSM o con un multisig dotato di firmatari distribuiti geograficamente. Le regole degli smart contract aggiungono limiti on-chain laddove la blockchain li supporta. Quando si valuta un fornitore, occorre porre quattro domande:

1. La chiave privata completa esiste mai e, in tal caso, dove e per quanto tempo?
2. Un soggetto esterno può verificare la policy di firma oppure può solo leggere la descrizione fornita dal fornitore?
3. Cosa succede se il fornitore della tecnologia fallisce, e il recupero senza il suo intervento è stato verificato?
4. Quali certificazioni coprono quali componenti (un certificato FIPS 140-3 per l'HSM, un rapporto di assurance per il sistema nel suo complesso)?

Focus sull'esame: cosa fa un HSM e quali sono i quattro livelli di sicurezza FIPS 140-3 (il Livello 3 è tipico per la custodia); perché un nuovo HSM dovrebbe avere un certificato FIPS 140-3 ora che i certificati FIPS 140-2 figurano nell'Historical List; come il multisig applica on-chain la regola m-su-n e quali sono i compromessi (policy visibile, specifica per blockchain, commissioni più elevate); come funzionano MPC/TSS (DKG, la chiave non esiste mai, una normale firma singola on-chain) e quali sono i compromessi (policy invisibile, rischio di implementazione come BitForge, dipendenza dal fornitore); la differenza tra MPC e condivisione segreta di Shamir; ERC-4337 ed EIP-7702 (Pectra, maggio 2025) e il rischio legato ai contratti; le fasi e le prove documentali di una cerimonia delle chiavi.