Introduzione
Il settore blockchain si è dato come obiettivo principale quello di trovare i punti deboli nel codice degli smart contract. I team di sviluppo investono in audit, gare di bug bounty, strumenti di fuzzing e tecniche di verifica formale, convinti che trovare tutti i bug nel codice finale garantirà la sicurezza.
Questo metodo è importante, ma non tiene conto di uno dei fatti più spaventosi che sono venuti alla luce nel 2024. Il modo più devastante in cui si può attaccare i protocolli delle criptovalute al momento non è una serie complicata di exploit o vulnerabilità nascoste nel codice. È invece una minaccia molto più profonda e meno discussa che ha dominato il panorama delle minacce negli ultimi anni.
La compromissione delle chiavi private domina il panorama delle minacce
Uno studio del 2024 mostra dei dati preoccupanti che ci faranno ripensare come ci occupiamo della sicurezza delle blockchain. La percentuale di tutti i fondi in criptovaluta rubati durante l'anno che sono stati compromessi tramite una chiave privata è del 43,8%, rendendo questo tipo di attacco di gran lunga il più efficace.
Le debolezze nell'architettura del controllo degli accessi non vengono spesso segnalate dalle tradizionali società di revisione blockchain come risultati formali, e le piattaforme di revisione competitive scoraggiano chiaramente le segnalazioni che si concentrano su questi problemi sistemici.
Questo modo di pensare è molto diverso dalle buone pratiche degli audit di sicurezza in altri settori, dove l'escalation dei privilegi e la progettazione del controllo degli accessi sono questioni fondamentali che devono essere prese in considerazione nelle prime fasi del ciclo di sviluppo, quando spesso è troppo tardi per cambiare la natura complessiva dei problemi di controllo degli accessi del sistema.
Per capire come le scelte di progettazione influiscono sulla vulnerabilità agli attacchi contro le chiavi private, pensa a questo protocollo teorico di prestito sovracollateralizzato. Però, per fare alcune operazioni importanti, serve un accesso speciale a questi sistemi:
- •Inserimento e rimozione delle risorse supportate
- •Configurare i parametri di rischio e i tassi di interesse
- •Riscossione delle commissioni di protocollo
- •Pause di emergenza e aggiornamenti sviluppo di contratti intelligenti
Questi elementi definiscono la resilienza complessiva di un protocollo di questo tipo alla compromissione della chiave privata.
Livello 1: Esposizione completa con controllo a punto singolo
Il livello più basso è quello in cui lo sviluppatore ha un unico account controllato esternamente con pieni diritti amministrativi su tutte le funzioni del protocollo. Questa architettura è la configurazione più vulnerabile, in cui la violazione di una chiave privata fornirà agli aggressori un accesso immediato e completo al sistema, possibilmente sotto forma di portafogli software collegati direttamente a Internet.
La minaccia di tradimento è enorme e l'effetto è devastante e diretto.
Livello 2: Gestione semplice dei rischi tramite chiavi distribuite
Il livello successivo è trasferire i poteri amministrativi al portafoglio multi-firma, che richiederà la garanzia di più detentori di chiavi per eseguire l'aggiornamento. Questo può solo ridurre le possibilità di compromissione e non limitare la portata del danno al protocollo, ma è comunque un miglioramento.
Questo è molto meglio di avere un controllo a chiave singola in termini di sicurezza, perché per prendere il controllo del protocollo non basta più avere accesso a una chiave di firma. Comunque, ci sono ancora rischi alti anche con questo miglioramento:
- •La rapidità di esecuzione è importante perché potrebbero esserci azioni dannose prima che si riesca a reagire in modo sicuro.
- •Anche se i punti di errore sono sparsi tra le chiavi, la struttura di controllo rimane centralizzata
- •Anche i sistemi multi-firma ben protetti possono essere violati tramite tecniche avanzate di ingegneria sociale
Livello 3: Protezione migliorata grazie alla separazione di tempi e ruoli
I notevoli miglioramenti in termini di maturità richiedono l'applicazione di due meccanismi di controllo fondamentali: i timelock e il principio del privilegio minimo.
I timelock mettono un po' di tempo tra l'approvazione e l'esecuzione di una transazione, così c'è tempo per controllare bene la transazione e reagire se succede qualcosa. Il principio del privilegio minimo vuol dire separare i ruoli e le responsabilità in modo che ogni ruolo abbia solo i permessi minimi necessari per fare il proprio lavoro.
Questo livello affronta i difetti fondamentali dei metodi più semplici:
- •Non puoi fare cose tipo eseguire subito qualcosa.
- •Condivisione del controllo tra più specializzazioni
- •Dai tempo ai team di sicurezza di controllare le transazioni che sembrano strane
- •Permette di intervenire in modo proattivo invece di limitarsi a gestire i danni
Livello 4: Massima sicurezza
Il massimo livello di maturità si basa sulla rimozione totale delle azioni amministrative ed è la forma più radicale di impegno verso l'idea di decentralizzazione e minimizzazione della fiducia. Una strategia del genere esclude categoricamente il controllo degli accessi come parte del modello di minaccia del protocollo.
Per raggiungere questo livello, servono approcci completamente diversi da tutti gli altri livelli:
- •L'aggiornabilità dei contratti deve essere eliminata - gli smart contract diventano completamente immutabili
- •L'elenco delle risorse diventa senza autorizzazione - i mercati autonomi vengono implementati in modo indipendente
- •I parametri di rischio sono fissati per sempre - non puoi cambiarli
- •Non si può fare un intervento di emergenza - i sistemi non si possono cambiare dopo che sono stati messi in funzione
Nel caso dei sistemi di prestito sovracollateralizzati, bisogna considerare diversi elementi importanti:
- •Nuove funzionalità implementate in distribuzioni completamente diverse con migrazione manuale degli utenti
- •Mercati creati come istanze di protocollo indipendenti per particolari asset
- •I parametri di rischio seguono le linee guida algoritmiche o le impostazioni di implementazione permanenti
Questo numero è cinque volte più grande di qualsiasi altro tipo di attacco confermato, ma l'ecosistema di sicurezza blockchain non è ancora pronto per affrontare una minaccia del genere.
Proteggi il tuo protocollo oggi stesso
Non aspettare che ci sia un problema. Metti subito in atto dei controlli di accesso adeguati.
Struttura di separazione dei ruoli
| Tipo di ruolo | Responsabilità | Requisiti di sicurezza | Durata del blocco temporale |
|---|---|---|---|
| Sistema centrale | Aggiornamenti del contratto | Soglie multisig elevate | Grandi ritardi |
| Operazioni | Configurazione del protocollo quotidiano | Moderate le esigenze di sicurezza | Ritardi medi |
| Pausa Guardian | Sospensione del protocollo di emergenza | Capacità di agire subito | Nessun ritardo |
| Annulla Guardian | Togli le approvazioni che non vanno bene. | Autorità di risposta rapida | Nessun ritardo |
I team di sicurezza ora possono intervenire in modo positivo nei casi, invece di limitarsi a rispondere al danno una volta che è stato causato, ma questo comporta nuovi rischi, come possibili bug nei sistemi di gestione dei ruoli.
Anche se questo paradigma di progettazione non ha rischi di controllo degli accessi, ha dei grossi svantaggi, come l'impossibilità di fare interventi di emergenza e costi di verifica iniziali molto alti.
Costruire sistemi resilienti fin dal primo giorno
La vulnerabilità delle chiavi private, responsabile di quasi la metà dei furti di criptovalute nel 2024, è un problema che non si può ignorare a causa delle scelte architetturali di controllo degli accessi fatte all'inizio del processo di progettazione. Anche se l'identificazione convenzionale delle vulnerabilità è ancora necessaria, le decisioni fondamentali di progettazione dovranno essere prese molto prima nel ciclo di sviluppo.
Ecco alcune cose che puoi fare nella vita di tutti i giorni per migliorare la sicurezza:
- •Analisi onesta di quanto è maturo il protocollo adesso
- •Implementazione di contratti con blocco temporale sulle funzioni amministrative
- •Sistemi di monitoraggio adeguati per le modalità amministrative ad alto rischio
- •Mappa le funzioni privilegiate e dividile in ruoli logici
- •Usa il principio del privilegio minimo
- •Individua gli elementi di design che vanno bene per i modelli immutabili
Gli sviluppatori possono creare protocolli innovativi e robusti solo se capiscono bene i framework di maturità e scelgono con attenzione modelli di progettazione che non dipendono dalla fiducia o che non permettono la diffusione di compromessi.
Questo richiede un investimento nella resilienza operativa nelle prime fasi di sviluppo, assicurandosi che i protocolli siano resistenti non solo alle intrusioni tecniche, ma anche ai fattori umani che rendono la compromissione delle chiavi private una fonte di minaccia così efficace.
