La crittografia fallisce raramente perché un algoritmo viene violato. Fallisce nei dettagli attorno all’algoritmo: un nonce che si ripete, un generatore casuale inizializzato con l’ora, una firma verificata ma non legata al suo contesto, una chiave derivata correttamente e poi scritta in un log.
Questi errori sono silenziosi. Il sistema funziona, i test passano, e una chiave privata può essere ricostruita dalle firme che il sistema ha già pubblicato. Esaminiamo la progettazione per capire che cosa presuppone e l’implementazione per capire se quei presupposti reggono, e testiamo l’output dove la matematica consente un verdetto: firme, valori casuali e testi cifrati.
01Perimetro
Che cosa testiamo
Progettazione dei protocolli: autenticazione, scambio di chiavi, instaurazione della sessione
Schemi di firma: generazione dei nonce ECDSA ed EdDSA, malleabilità, replay
Generazione, derivazione, archiviazione, rotazione e distruzione delle chiavi
Generazione di numeri casuali e fonti di entropia
Modalità di cifratura, padding, autenticazione del testo cifrato
Wallet e custodia: gestione del seed, percorsi di derivazione, flussi di firma
Schemi a soglia e multi-party, configurazioni multi-firma
Integrazione con moduli di sicurezza hardware e servizi di gestione delle chiavi
Canali laterali nel software: tempi di esecuzione, comportamento in caso di errore, gestione della memoria
02Approccio
Come si svolge il lavoro
01
Revisione della progettazione
Leggiamo la specifica e indichiamo le proprietà di sicurezza che la progettazione dichiara e i presupposti da cui dipende.
02
Revisione dell’implementazione
Il codice viene confrontato con la progettazione. Esaminiamo come vengono usate le librerie e dove l’implementazione si discosta da ciò che la progettazione richiede.
03
Analisi degli output
Firme, nonce e valori casuali prodotti dal sistema vengono analizzati alla ricerca di distorsioni, riutilizzi e strutture, con metodi basati sui reticoli e metodi statistici.
04
Dimostrazione dell’attacco
Se una debolezza è sfruttabile, la dimostriamo su chiavi di test generate appositamente. Le chiavi che proteggono asset reali non sono mai l’obiettivo di una dimostrazione.
Usiamo una libreria nota. C’è qualcosa da esaminare?
Sì. La libreria è raramente il problema. Gli errori stanno nel modo in cui viene chiamata, nei parametri che riceve e in ciò che succede alle chiavi prima e dopo la chiamata.
Lavorerete con le nostre chiavi di produzione?
No. Lavoriamo con chiavi di test e con output pubblici come le firme. Se l’analisi dei dati pubblici mostra che una chiave di produzione è a rischio, ti informiamo subito e la chiave non viene ricostruita.
Potete esaminare un protocollo che esiste solo sulla carta?
Sì, ed è il momento in cui farlo costa meno. Un difetto di progettazione trovato prima dell’implementazione costa la modifica di un documento.
Audit riga per riga di smart contract e della logica del protocollo prima del deploy: revisione manuale, test delle invarianti e revisione delle correzioni.