Elliptic Curve Digital Signature Algorithm: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Ilmiomantra (discussione | contributi)
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti.
 
(7 versioni intermedie di 6 utenti non mostrate)
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|sitourlarchivio=https://web.archive.org/web/20130405070453/http://www.di.unisa.it|accesso=17 gennaio 2017/~ads/corso-security/www/CORSO-0001/ECC/index.htm}}</ref>.
 
== Dimensioni della chiave e della firma in confronto al DSA ==
Come in generale nella crittografia delle curve ellittiche, la dimensione in bit della [[chiave pubblica]] necessaria all'ECDSA è circa il doppio della dimensione del livello di sicurezza in bit. Per esempio, con un livello di sicurezza di 80 bit (un massimo di <math>2^{80}</math> operazioni necessarie ad un aggressore informatico per trovare la chiave privata) la dimensione di una chiave pubblica ECDSA sarebbe di 160 bit, laddove la [[dimensione della chiave]] pubblica DSA è di almeno 1024 bit. La dimensione della firma è la stessa per ECDSA e DSA: <math>4 t</math> bit, dove <math>t</math> è il livello di sicurezza misurato in bit; nell'esempio precedente (con <math>t</math> = 80 bit), la dimensione della firma è di 320 bit.
 
== Algoritmo di generazione della firma ==
Si supponga che [[Alice e Bob|Alice]] voglia mandare a [[Alice e Bob|Bob]] un messaggio protetto da [[firma digitale]]. Inizialmente devono accordarsi sui parametri della curva <math>(\textrm{CURVE}, G, n)</math>. Oltre al campo e all'equazione della curva, è necessario <math>G</math>, un punto base di ordine primo sulla curva; <math>n</math> è l'ordine moltiplicativo del punto <math>G</math>.
{| class="wikitable" style="margin-bottom: 10px;"
! Parametro
Riga 21:
|}
 
Alice genera una coppia di chiavi consistente in una chiave privata <math>d_A</math>, scelta casualmente nell'intervallo <math>[1, n-1]</math> ed una chiave pubblica <math>Q_A = d_A \times G</math>. Si usa <math>\times</math> per indicare la moltiplicazione di uno scalare per un punto della [[curva ellittica]].
 
Al fine di generare una firma per il messaggio <math>m</math>, Alice segue questi passi:
Riga 31:
# Calcola <math>s = k^{-1}(z + r d_A)\,\bmod\,n</math>. Se <math>s = 0</math>, ritorna al passo 3.
# La firma è la coppia <math>(r, s)</math>.
Computando <math>s</math>, la stringa <math>z</math> risultante da <math>\textrm{HASH}(m)</math> deve essere convertita ad intero. Si noti che <math>z</math> può essere ''più grande'' di <math>n</math> ma non ''più lunga''.<ref>[{{cita testo|url=http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf |titolo=NIST FIPS 186-4, July 2013, pp. 19 and 26]}}</ref>
 
Come stabiliscono gli standard, è cruciale che vengano selezionati <math>k</math> diversi 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>[{{cita testo|url=https://events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf |titolo=Console Hacking 2010 - PS3 Epic Fail] {{Webarchive|urlurlarchivio=https://web.archive.org/web/20141215140847/http://events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf |datapp=15 dicembre 2014 123-128}}, 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>{{Cita web|url=https://bitcoin.org/en/alert/2013-08-11-android|titolo=Android Security Vulnerability|accesso=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 name=":0">{{Cita web|url=https://tools.ietf.org/html/rfc6979|titolo=RFC 6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)|accesso=24 febbraio 2015}}</ref>
 
== Algoritmo di verifica della firma ==
Riga 81:
<math>C = k \times G</math>
 
Dalla definizione di <math>r</math>, questo è il passo 6 dell'[[algoritmo]] di verifica.
 
Questo però mostra solo che un messaggio firmato correttamente supererà la verifica; sono necessarie molte altre proprietà per un algoritmo di firma sicuro.
Riga 88:
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>{{Cita news|cognome=Bendel|nome=Mike|titolo=Hackers Describe PS3 Security As Epic Fail, Gain Unrestricted Access|editore=Exophase.com|data=29 dicembre 2010|url=http://exophase.com/20540/hackers-describe-ps3-security-as-epic-fail-gain-unrestricted-access/|accesso=5 gennaio 2011}}</ref>
 
Il 29 marzo del 2011, due ricercatori pubblicarono un documento IACR<ref>{{Cita web|url=https://eprint.iacr.org/2011/232|titolo=Cryptology ePrint Archive: Report 2011/232|accesso=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>[{{cita testo|url=https://www.kb.cert.org/vuls/id/536044 |titolo=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>{{Cita webtesto|url=//www.openssl.org/news/changelog.html|titolo=ChangeLog|editore=OpenSSL Project|accesso=22 aprile 2014}}</ref>
 
Nell'agosto 2013, è stato reso pubblico che alcune implementazioni della classe [[Java (linguaggio di programmazione)|Java]] [{{cita testo|url=https://docs.oracle.com/javase/7/docs/api/java/security/SecureRandom.html |titolo=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=https://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=17 gennaio 2017}}</ref>
 
Questo problema può essere risolto da una generazione deterministica di <math>k</math>, come descritto da <nowiki>RFC 6979</nowiki><ref name=":0" />.
 
== Note ==
Riga 98:
 
== Bibliografia ==
* Accredited Standards Committee [{{cita testo|url=http://www.x9.org |titolo=X9]|postscript=nessuno}}, ''American National Standard X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)'', November 16, 2005.
* Certicom Research, [{{cita testo|url=http://www.secg.org/download/aid-780/sec1-v2.pdf |titolo=''Standards for efficient cryptography, SEC 1: Elliptic Curve Cryptography'']|postscript=nessuno}}, Version 2.0, May 21, 2009.
* López, J. and Dahab, R. [{{cita testo|url=http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.2771 |titolo=''An Overview of Elliptic Curve Cryptography'']|postscript=nessuno}}, Technical Report IC-00-10, State University of Campinas, 2000.
* {{cita libro|autore=[[Daniel J. Bernstein]], [|url=https://cr.yp.to/papers/pippenger.pdf |titolo=Pippenger's exponentiation algorithm], |anno=2002.}}
* Daniel R. L. Brown, ''Generic Groups, Collision Resistance, and ECDSA'', Designs, Codes and Cryptography, '''35''', 119–152, 2005. [{{cita testo|url=https://eprint.iacr.org/2002/026 |titolo=ePrint version]}}
* Ian F. Blake, Gadiel Seroussi, and Nigel Smart, editors, ''Advances in Elliptic Curve Cryptography'', London Mathematical Society Lecture Note Series 317, Cambridge University Press, 2005.
* {{Cita libro|titolo=Guide to elliptic curve cryptography |ISBN=0-387-95273-X|DOIdoi=10.1007/b97644}}
 
== Voci correlate ==
Riga 110:
 
== Collegamenti esterni ==
* [{{cita testo|url=http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf |titolo=Digital Signature Standard; include informazioni su ECDSA]}}
* [{{cita testo|url=http://www.di.unisa.it/~ads/corso-security/www/CORSO-0001/ECC/index.htm |titolo=Crittosistemi basati su Curve Ellittiche UNISA]}}
 
{{Portale|crittografia}}
 
[[Categoria:Crittosistemi di firma digitale]]