Elliptic Curve Digital Signature Algorithm: differenze tra le versioni

Versione delle 10:02, 20 gen 2017

Versione delle 09:54, 22 gen 2017

Riga 1:

In [[crittografia]], l''''Elliptic Curve Digital Signature Algorithm '''('''ECDSA''') offre una variante del [[Digital Signature Algorithm]] (DSA) usando la [[crittografia ellittica]]. 

Fu proposto la prima volta nel 1992 da Scott Vanstone. Nel 1998 è diventato uno standard [[ISO]] (ISO 14888), nel 1999 è stato accettato come standard [[ANSI]] (ANSI X9.62) mentre nel 2000 è diventato uno standard [[IEEE]] (IEEE P1363 2)<ref>{{Cita web|url=http://www.di.unisa.it/~ads/corso-security/www/CORSO-0001/ECC/index.htm|titolo=Crittosistemi basati su curve ellittiche|sito=www.di.unisa.it|accesso=2017-01-17 gennaio 2017}}</ref>.

== Dimensioni della chiave e della firma in confronto al DSA ==

Riga 35:

Come stabiliscono gli standard, è cruciale che vengano selezionati <math>k</math> per firme diverse, altrimenti l'equazione al passo 6 può essere risolta per <math>d_A</math>, la chiave privata: date due firme <math>(r, s)</math> e <math>(r, s')</math>, l'impiegare la stessa <math>k</math> per due messaggi differenti <math>m</math> e <math>m'</math> apre ad una vulnerabilità ad attacchi. Un aggressore può calcolare <math>z</math> e <math>z'</math>, e poiché <math>s - s' = k^{-1}(z - z')</math> (tutte le operazioni di questo paragrafo sono svolte in modulo <math>n</math>) l'aggressore può trovare <math>k = \frac{z - z'}{s - s'}</math>. Dato che <math>s = k^{-1}(z + r d_A)</math>, l'aggressore può ora calcolare la chiave privata <math>d_A = \frac{s k - z}{r}</math>. Questa implementazione errata è stata sfruttata, per esempio, per estrarre la firma digitale usata nella console [[PlayStation 3]].<ref>[https://events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf Console Hacking 2010 - PS3 Epic Fail], page 123–128</ref>

Un'altra situazione in cui la firma ECDSA può lasciare trapelare le chiavi private si ha quando <math>k</math> è generato da un ''[[Generatore di numeri pseudocasuali crittograficamente sicuro|random number generator]]'' difettoso.  Una falla simile causò la perdita dei fondi di alcuni portafogli di [[bitcoin]] su piattaforma [[Android]] nell'agosto 2013.<ref>{{citeCita web|url=https://bitcoin.org/en/alert/2013-08-11-android|titletitolo=Android Security Vulnerability|publisheraccesso=|accessdate=February24 24,febbraio 2015}}</ref> Per assicurare che <math>k</math> sia unico per ogni messaggio si può bypassare completamente la generazione casuale e ottenere una firma in modo deterministico computando <math>k</math> dal messaggio e dalla chiave privata.<ref>{{citeCita web|url=http://tools.ietf.org/html/rfc6979|titletitolo=RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)|publisheraccesso=|accessdate=February24 24,febbraio 2015}}</ref>

== Algoritmo di verifica della firma ==

Riga 50:

# Calcola il punto della curva<math>(x_1, y_1) = u_1 \times G + u_2 \times Q_A</math>.

# La firma è valida se <math>r \equiv x_1 \pmod{n}</math>, altrimenti non è accettata.

Si noti che usando lo ''Shamir's trick'', una somma di due moltiplicazioni scalari <math>u_1 \times G + u_2 \times Q_A</math> può essere calcolata in tempo inferiore a quello necessario allo svolgimento indipendente delle due moltiplicazioni scalari.<ref>{{citeCita web|url=http://www.lirmm.fr/~imbert/talks/laurent_Asilomar_08.pdf|titletitolo=The Double-Base Number System in Elliptic Curve Cryptography|accessdateaccesso=22 Aprilaprile 2014}}</ref>

== Correttezza dell'algoritmo ==

Riga 86:

== Sicurezza ==

Nel dicembre 2010, un gruppo che si fa chiamare ''fail0verflow'' annunciò di aver scoperto la chiave privata ECDSA usata da Sony per firmare i software della console [[PlayStation 3|Playstation 3]]. Tuttavia, questo attacco funzionò perché Sony non implementò correttamente l'algoritmo, <math>k</math> era statico invece che casuale. Come è sottolineato nella precedente sezione ''Algoritmo di generazione della firma'', ciò rende risolvibile <math>d_A</math> ed inutile l'intero algoritmo.<ref>{{CiteCita news|lastcognome=Bendel|firstnome=Mike|titletitolo=Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access|publishereditore=Exophase.com|datedata=2010-12-29 dicembre 2010|url=http://exophase.com/20540/hackers-describe-ps3-security-as-epic-fail-gain-unrestricted-access/|accessdateaccesso=5 gennaio 2011-01-05}}</ref>

Il 29 marzo del 2011, due ricercatori pubblicarono un documento IACR <ref>{{citeCita web|url=http://eprint.iacr.org/2011/232|titletitolo=Cryptology ePrint Archive: Report 2011/232|publisheraccesso=|accessdate=February24 24,febbraio 2015}}</ref> dimostrando che è possibile recuperare una chiave privata TLS di un server usando [[OpenSSL]] il quale esegue un'autenticazione ECDSA su un campo binario attraverso un'' timing attack''.<ref>[https://www.kb.cert.org/vuls/id/536044 Vulnerability Note VU#536044 - OpenSSL leaks ECDSA private key through a remote timing attack]</ref> La vulnerabilità ha ricevuto un ''fix'' nella release OpenSSL 1.0.0e.<ref>{{citeCita web|url=//www.openssl.org/news/changelog.html|titletitolo=ChangeLog|publishereditore=OpenSSL Project|accessdateaccesso=22 Aprilaprile 2014}}</ref>

Nell'agosto 2013, è stato reso pubblico che alcune implementazioni della classe [[Java]] [http://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html SecureRandom] talvolta generavano collisioni nel valore <math>k</math>. Come discusso sopra, questo ha permesso la risoluzione delle chiavi private, di conseguenza ciò ha aperto alla possibilità di rubare [[bitcoin]] dalle app Wallet Android, le quali erano basate su ECDSA per l'autenticazione delle transazioni.<ref>{{Cita web|url=http://www.theregister.co.uk/2013/08/12/android_bug_batters_bitcoin_wallets/|titolo=Android bug batters Bitcoin wallets|autore=12 Aug 2013 at 00:43, Richard Chirgwin tweet_btn()|accesso=2017-01-17 gennaio 2017}}</ref>

Questo problema può essere risolto da una generazione deterministica di <math>k</math>, come descritto da <nowiki>RFC 6979</nowiki>.