In questo post esploreremo come un algoritmo di curva ellittica, nello specifico l'algoritmo di firma digitale a curva ellittica (ECDSA), venga utilizzato sul web e come possa migliorare le prestazioni generali e la sicurezza.
UN PO' DI STORIA
Quando visitiamo un sito che inizia con https:// anziché http://, il nostro browser si connette a quel sito tramite una connessione crittografata.
Il browser verifica che il sito web sia esattamente chi che afferma di essere utilizzando la crittografia a chiave pubblica insieme ad un certificato digitale.
Nella crittografia a chiave pubblica, ogni utente ha una coppia di chiavi: una chiave pubblica e una privata. Di solito si tratta di numeri scelti in modo tale da avere una relazione matematica specifica.
In RSA (crittografia a chiave simmetrica), la chiave pubblica è il risultato del prodotto di due numeri primi, a cui si somma un numero più piccolo. La chiave privata è un numero correlato.
In ECC (Crittografia a curva ellittica) la chiave pubblica corrisponde ad un'equazione per una curva ellittica ed un punto che si trova su quella curva.
La chiave privata associata alla chiave pubblica può essere utilizzata per creare una firma digitale per qualsiasi tipo di dati utilizzando un algoritmo di firma digitale. Questo processo solitamente implica il prelievo di un hash crittografico dei dati e l'esecuzione di una operazione matematica su di esso utilizzando la chiave privata. Chiunque abbia la chiave pubblica può verificare che questa firma sia stata creata utilizzando sia la chiave privata, sia l'algoritmo di convalida della firma appropriato.
La firma digitale risulta oggi uno strumento efficace in quanto consente di attestare pubblicamente qualsiasi messaggio.
Un certificato per sito web di solito contiene due elementi:
1) Informazioni riguardanti l'identità: di solito, chi possiede il certificato e per quali domini il certificato è valido.
2) Una chiave pubblica: fornita la chiave pubblica di una coppia di chiavi, il proprietario del sito controlla e mantiene segreta la chiave privata associata a quella pubblica.
Il certificato è successivamente firmato digitalmente da un'autorità di certificazione affidabile che convalida l'identità del proprietario del sito.
Dall'introduzione di SSL da parte di Netscape nel 1994, i certificati per i siti web hanno di solito utilizzato una coppia di chiavi pubbliche/private basata sull'algoritmo RSA. Man mano che il protocollo SSL si e' evoluto in TLS, ad esso è stato aggiunto il supporto per diversi altri tipi algoritmi di chiave pubblica.
SCELTE ED UTILIZZI
Sebbene ECDSA non abbia preso piede tra le applicazioni web, l'algoritmo è diventato lo schema di firma digitale scelto per tutta una serie di nuove applicazioni crittografiche non web.
Bitcoin è un buon esempio di sistema che si affida a ECDSA per la sicurezza.
Ogni indirizzo Bitcoin è costituito da un hash crittografico di una chiave pubblica ECDSA.
La proprietà del conto Bitcoin è determinata da chi controlla la chiave privata ECDSA. Per trasferire una quantità di Bitcoin a un'altra persona, il mittente esegue una transazione, firma quella transazione con la sua chiave privata e lo invii alla blockchain Bitcoin per la sua validazione.
In questo caso, il perno della sicurezza e della coerenza del sistema Bitcoin risiede proprio nella sicurezza delle chiavi private ECDSA.
Le curve ellittiche e, in particolare, le curve ECDSA sono utilizzate per garantire la sicurezza delle applicazioni di messaggistica. Nel recente whitepaper di Apple sulla sicurezza di iOS, gli sviluppatori di Cupertino hanno riferito come utilizzino ampiamente ECDSA nell'ecosistema Apple. Due rapidi esempi: le conversazioni tramite iMessage sono firmate con ECDSA e la sincronizzazione del portachiavi iCloud si basa anch'essa su ECDSA. Sempre più tecnologie utilizzano ECDSA per la sicurezza, incluse le app di messaggistica a end-to-end criptate TextSecure e CryptoCat.
La grande battaglia: ECDSA vs RSA
Perché ECDSA è l'algoritmo scelto per i nuovi protocolli quando RSA è disponibile ed è stato il gold standard per la crittografia asimmetrica dal 1977? Il motivo è che noi umani siamo più bravi a violare RSA che a violare ECC.
Nello specifico, la sicurezza di una chiave dipende dalla sua dimensione e dal suo algoritmo. Alcuni algoritmi sono più facili da decifrare di altri e richiedono chiavi più grandi per lo stesso livello di sicurezza. Per decifrare una chiave RSA è necessario fattorizzare un numero grande. Purtroppo o per fortuna, nel corso degli anni, siamo diventati abbastanza bravi a fattorizzare numeri grandi e miglioriamo continuamente.
Per decifrare una chiave ECDSA invece, diventa necessario risolvere un particolare problema, quello del logaritmo discreto della curva ellittica (ECDLP). La comunità matematica non ha fatto grandi progressi nel migliorare gli algoritmi per risolvere questo problema da quando è stato introdotto in modo indipendente dai matematici *Koblitz * e **Miller **nel 1985.
Ciò significa che con ECDSA è possibile ottenere lo stesso livello di sicurezza di RSA, ma con chiavi più piccole: e le chiavi più piccole sono migliori di quelle più grandi per diversi motivi:
1) Le chiavi più piccole sono caratterizzate da algoritmi più veloci per la generazione delle firme, perché i calcoli riguardano ovviamente numeri più piccoli.
2) Chiavi pubbliche più piccole significano certificati più piccoli e meno dati da trasmettere per stabilire una connessione TLS. Ciò significa connessioni più veloci e tempi di caricamento più rapidi sui siti web.
Secondo le raccomandazioni di ECRYPT II sulla lunghezza delle chiavi, una chiave a curva ellittica a 256 bit fornisce la stessa protezione di una chiave asimmetrica a 3.248 bit.
Ora effettuiamo un piccolo test.
Sappiamo che e chiavi RSA tipiche dei certificati dei siti web sono a 2048 bit.
Se confrontiamo la parte dell'handshake TLS che avviene sul server per le chiavi ECDSA a 256 bit con le chiavi RSA a 2048 bit, crittograficamente molto più deboli, otteniamo quanto segue:
sign/s
256 bit ecdsa (nistp256) 9516.8
rsa 2048 bits 1001.8
(openssl 1.0.2 beta on x86_64 with enable-ec_nistp_64_gcc_128)
La sezione qui sopra mostra il numero di firme ECDSA e RSA possibili al secondo (sign/s).
Come visionabile dal test effettuato, l'uso di un certificato ECDSA riduce il costo dell'operazione di chiave privata di di circa 9,5 volte, risparmiando in modo consistente sui cicli della CPU.
ESISTE UNA DANGER ZONE?
Possiamo essere relativamente fiduciosi sulla sicurezza matematica connessa alle ECDSA.
La storia della crittografia ci mostra che la buona crittografia è stata ripetutamente sconfitta non a causa di una cattiva matematica, ma a causa di cattive implementazioni della buona matematica.
Una particolarità interessante dell'algoritmo ECDSA è che ogni firma richiede come input alcuni dati casuali o imprevedibili. Se la fonte di casualità è prevedibile per un attaccante, questi può scoprire la chiave privata. E storicamente, hacker black-hat hanno sfruttato questa vulnerabilità in diversi casi di alto profilo.
Nel 2010 ad esempio, una falla nel modo in cui venivano utilizzati i numeri casuali in ECDSA su Playstation 3 di Sony ha portato alla fuga di una chiave privata. Più di recente, si è scoperto che alcuni dispositivi Android generavano in modo errato valori casuali, che ha causato un massiccio furto di Bitcoin da dispositivi che eseguivano il software BTC sulla macchina.
Esistono altri attacchi più esoterici contro specifiche implementazioni di ECDSA.
In un paper pubblicato da un gruppo di ricercatori australiani e britannici, si descrive un attacco all'implementazione di ECDSA di OpenSSL per la curva secp256k1 (la specifica curva utilizzata dal protocollo Bitcoin). Fortunatamente, questo attacco non rappresenta attualmente una minaccia per i server remoti occupati.
Esiste inoltre un pericolo legato alla perdita di chiavi tramite dati casuali di scarsa qualità o attacchi side channel, ma rimane una casistica gestibile con una preparazione adeguata e con una attenta attivita' di prevenzione.
La chiave di volta sta nell'assicurare che il generatore di numeri casuali (PRNG - pseudorandom number generator) del sistema abbia un'entropia sufficiente.
Tale crittografia è difficile da implementare correttamente, soprattutto nel contesto di un protocollo complesso come TLS, come dimostrato da alcune famose correzioni di bug recenti. Detto questo, i vantaggi sembrano superare i rischi in questo caso.
Top comments (0)