Audit di Sicurezza (di Jean Philippe Aumasson)

Siamo lieti di annunciare che Ergo ha superato con successo l'audit di sicurezza di alcune (le più critiche) parti del codice. Questa volta l'audit è stato effettuato da Jean-Philippe Aumasson (alias veorq, https://aumasson.jp/ ).

Il rapporto dettagliato è riportato di seguito. Non è stato trovato nulla di critico. Commenti sui problemi riscontrati:

1. Per quanto riguarda la password del wallet, forniremo una raccomandazione nelle prossime versioni del client del protocollo. Non siamo certi che ci sarà un'applicazione rigorosa della password, ma faremo ulteriori consultazioni su questo.
2. Cambiare i parametri "n" e "k" ha senso solo quando si lancia una nuova rete. Cambiare questi parametri in un nodo di mining renderà i blocchi prodotti non validi per altri nodi. Cambiare questi parametri nel client del protocollo significa andare su un'altra fork (i blocchi provenienti dai partecipanti onesti del protocollo verranno rifiutati). Quindi, forse non è necessario effettuare controlli aggiuntivi, poiché le persone che lanciano nuove reti imposteranno "n" e "k" correttamente.
3. Attualmente il nodo Ergo (così come altri client di protocollo blockchain e wallet di cui siamo a conoscenza, così come le librerie crittografiche che stiamo utilizzando) non forniscono protezione contro attacchi side-channel eseguiti localmente (ad es. attacchi di temporizzazione o ispezione della memoria da parte di malware o virus). Quindi, per favore, proteggi le macchine su cui stai eseguendo i wallet!

==========================================================================================================

% Valutazione della sicurezza di Ergo % Jean-Philippe Aumasson % 07/Dic/19

Riepilogo

Siamo stati sollecitati da Ergo per eseguire una valutazione della sicurezza di diversi componenti della loro Piattaforma Ergo:

• Creazione e verifica delle prove del protocollo Sigma
• Sicura memorizzazione dei segreti nel wallet
• Validazione del Proof-of-Work

Questo breve rapporto riassume la nostra valutazione e descrive le nostre scoperte e raccomandazioni di mitigazione.

Prove del protocollo Sigma

Il protocollo Ergo si basa su ErgoScript, un linguaggio di scripting che supporta le dichiarazioni sigma, che possono essere provate e verificate attraverso prove di conoscenza non interattive.

Queste prove sono dichiarazioni descritte come un albero di condizioni AND, OR e di soglia, le cui foglie sono prove di conoscenza di un problema di logaritmo discreto.

La prova della dichiarazione sigma è quindi resa non interattiva grazie alla trasformazione di Fiat-Shamir.

Questa logica è specificata nel documento ErgoScript, e le specifiche
routine di prova e verifica sono descritte nell'Appendice A.

Le sfide di implementazione sono quindi:

• Definire la codifica delle prove che siano sicure ed efficienti, e implementare la serializzazione e deserializzazione che riesca sempre a elaborare input validi, e che fallisca sempre in modo elegante nell'elaborare input non validi.
• Implementare correttamente le funzionalità di prova e verifica, in conformità con la specifica, e soprattutto in modo tale che nessuna dichiarazione non valida possa superare con successo la verifica.

Abbiamo esaminato questi due aspetti, basandoci sul codice nel repository sigmastate-interpreter, e sul documento ErgoScript, confrontando attentamente il comportamento previsto (nell'Appendice A) con il comportamento effettivo come implementato.

Abbiamo esaminato in particolare il codice dei tratti e oggetti SigSerializer, Interpreter, e ProverInterpreter.

Ci siamo principalmente concentrati su bug delle seguenti classi:

• Elaborazione non sicura di input malformati
• Elaborazione non sicura di input insolitamente lunghi o corti
• Comportamento quando la profondità dell'albero è grande o il livello di ricorsione
• Uso non sicuro di tipi e strutture Scala
• Tipi di variabili inappropriati
• Overflow interi
• Condizioni di gara
• Bug logici

Nonostante un'ampia revisione, non abbiamo identificato alcun problema di sicurezza.

La logica e gli interni del protocollo sono comunque relativamente complessi, e riteniamo che il rischio più alto sia nella parsing e verifica delle prove. Per sfruttare tali problemi, tuttavia, un attaccante dovrebbe creare uno script semanticamente corretto che in qualche modo gli avvantaggi, ma che superi la verifica quando non dovrebbe farlo.

Per quanto riguarda la sicurezza del software, Scala elimina alcune classi di bug, ma il codice Scala può comunque soffrire di bug a causa del comportamento specifico di Scala o di errori non gestiti.

Wallet

La funzionalità del wallet di Ergo consente ai suoi utenti di memorizzare un segreto su disco e recuperarlo, inizializzando il wallet con un nuovo seed quando viene utilizzato per la prima volta.

Questa logica è principalmente definita in ErgoWalletActor, e un componente chiave riguardante la memorizzazione dei segreti è JsonSecretStorage.

La prima volta che viene creato un wallet, il comando InitWallet esegue le seguenti operazioni:

• Genera settings.walletSettings.seedStrengthBits bit casuali, come entropia iniziale. Per impostazione predefinita, vengono generati 160 bit.
• Genera un BIP39 dai bit casuali generati, che può essere visto come una codifica dei bit di entropia. Viene utilizzata la logica standard BIP39, con password opzionale.
• Deriva un seed dalla mnemonica utilizzando la logica di derivazione basata su PBKDF2 di BIP39.
• Cripta questo seed su disco con AES-GCM, utilizzando un nonce casuale, e una chiave derivata dalla password utilizzando PBKDF2-HMAC-SHA256 con 128000 iterazioni, utilizzando un sale casuale.

Per sbloccare un wallet già creato, un utente fornisce la password e il wallet tenta di decrittare i dati memorizzati.

Per ripristinare un account esistente da una passphrase BIP39, viene eseguito un processo simile a quello di inizializzazione, tranne che il wallet deriverà il seed dalla mnemonica invece di scegliere una mnemonica casuale.

I due rischi che abbiamo identificato qui sono:

• L'assenza di controlli sulla lunghezza della password: poiché la password è sufficiente per accedere al seed dato il segreto memorizzato su disco del wallet, la password dovrebbe teoricamente avere almeno tanta entropia quanto la mnemonica, e in pratica dovrebbe essere praticamente difficile da decifrare. Raccomandiamo quindi di imporre una lunghezza minima della password, ad esempio di 16 caratteri.
• Le copie dei valori segreti (password, seed e chiavi private derivate) potrebbero rimanere in memoria dopo l'esecuzione del software del wallet, il che è una limitazione intrinseca dei linguaggi garbage-collected come Scala.

Un altro processo o utente che condivide lo stesso spazio di indirizzi di memoria potrebbe potenzialmente recuperare i segreti, e potrebbero anche apparire nei dump di crash. Per quanto ne sappiamo, non esiste una mitigazione efficace in puro Scala.

Validazione PoW

Dopo aver precedentemente esaminato la sicurezza dell'Autolykos PoW, abbiamo eseguito un altro giro di revisione concentrandoci sulla sua logica di verifica più recente, e in particolare le modifiche nel commit eb0f85a.

Il file principale rilevante è AutolykosPowScheme, e altre operazioni importanti sono ad esempio implementate in
HeadersProcessor e ModifierValidator.

Abbiamo verificato che la logica di verifica implementata sia coerente con quella specificata nelle specifiche di Autolykos, e che sia correttamente integrata nella logica di validazione dell'intestazione del blocco.

Riteniamo che i seguenti punti debbano essere affrontati:

• Validazione più rigorosa di k e n: sebbene la classe imponga k<=32 (numero di elementi nella soluzione) e n<31 (log2 del numero totale di elementi), potrebbero comunque essere creati weak dai parametri autorizzati. La funzione validate() potrebbe quindi avere una validazione aggiuntiva che n e k siano uguali ai valori previsti.
• Assicurarsi che k e n siano valori positivi, poiché attualmente quelli negativi (come Ints) supererebbero le dichiarazioni assert.