liberlume-content-v3
lang: it
title: Il numero usato una volta sola
summary: Ogni firma digitale consuma, oltre alla chiave, un secondo numero segreto generato per l'occasione e buono una volta sola: il nonce. Se si ripete, da due firme si ricava la chiave privata con una sottrazione: è successo alla PlayStation 3 e ai portafogli Bitcoin su Android nel 2013. Come funziona il recupero in ECDSA e in Schnorr, mostrato sui byte di firme reali; perché un nonce anche solo prevedibile tradisce; e il punto che riguarda Bitcoin: un nodo valida allo stesso modo una firma nata da un nonce disastroso, il consenso non può accorgersene.
btc-anchor: 960990,0000000000000000000007c6cbdc6958d83fbfe12368e96f373a23a84ed45276
prev: genesis
--- body ---
Firmare non usa soltanto la chiave. Ogni volta che un portafoglio produce una
firma consuma anche un secondo numero segreto, generato per quell'occasione e
buono per quella sola: il **nonce**. La chiave si custodisce per anni, il nonce
vive il tempo di una firma e poi non serve più. Eppure è lui il pezzo fragile.
Se due firme della stessa chiave nascono dallo stesso nonce, chiunque legga
quelle due firme ricava la chiave privata. Non la indebolisce: la ricava.
Quel che segue riguarda le firme in sé, non un sistema in particolare. Bitcoin
è il posto dove la cosa si vede meglio, perché le firme finiscono su un registro
pubblico che chiunque può rileggere anni dopo, ma il caso più famoso di riuso
del nonce non è di Bitcoin.
## Il segreto che si usa una volta sola
La prima ambiguità da chiarire è quella sull'uso del termine. Nel gergo di
Bitcoin «nonce» indica anche il numero che i miner fanno variare per cercare un
blocco valido: quello è pubblico, sta nell'intestazione del blocco, e trovarlo a
tentativi è esattamente il mestiere. Il nonce di firma non ha niente a che
vedere. È segreto, non va cercato da nessuno, e va usato una volta soltanto.
Non è nemmeno una seconda chiave. Una chiave privata è un segreto permanente che
dice chi può spendere; il nonce vale per una firma sola e poi si butta. E non è
una complicazione di cui si farebbe volentieri a meno: senza, ogni firma
consegnerebbe la chiave a chi la legge.
Il motivo è un conteggio. Una firma pubblicata è, in sostanza, un'equazione, e
lega tre cose: il messaggio, la chiave privata e il nonce. Il messaggio è
pubblico, e pubblica è la firma stessa; le incognite sono due, la chiave e il
nonce. Se il nonce mancasse, o fosse un valore che chi guarda conosce,
l'incognita resterebbe una sola e l'equazione si risolverebbe: il vantaggio che
il nonce toglie a un attaccante è esattamente questo, ricavare la chiave privata
da una firma qualunque, letta sul registro. E ogni firma nuova si porta dietro
il proprio nonce, cioè una nuova incognita insieme alla nuova equazione: mille
firme sono mille equazioni con milleuno incognite, sempre una di troppo perché
il sistema si chiuda.
Ripetere il nonce toglie di mezzo quel margine. Due firme fatte con la stessa
chiave e lo stesso nonce sono due equazioni con due incognite soltanto: il conto
si pareggia e il sistema si risolve. Non serve attaccare la crittografia, basta
sottrarre l'una dall'altra.
## Dov'è, dentro una firma
Una firma ECDSA è una coppia di numeri, `r` e `s`. Il secondo mescola chiave,
messaggio e nonce. Il primo viene dal nonce e basta: è la coordinata di un punto
ottenuto moltiplicando il nonce per il punto generatore della curva.
Questo è il fatto centrale del pezzo, e va detto piano. **Metà di ciò che finisce
scritto sul registro viene dal solo nonce.** Non il nonce, che resta
segreto, ma un valore che dipende soltanto da lui. Due firme con lo stesso nonce
hanno quindi la stessa `r`, e la coincidenza è visibile a chiunque, senza
calcoli, leggendo i byte.
Quel passaggio è a senso unico, ed è lo stesso che trasforma una chiave privata
in una chiave pubblica: un numero segreto moltiplicato per il punto generatore.
Da `r` non si torna al nonce, come da una chiave pubblica non si torna alla
privata. La ripetizione di `r` non è quindi una via d'ingresso: è un segnale, e
dice soltanto dove guardare.
Una firma ECDSA vera, byte per byte: quella con cui fu speso il primo pagamento della storia, blocco 170. Dentro l'involucro DER stanno due numeri: r, che dipende soltanto dal nonce di quella firma, e s, che mescola chiave, messaggio e nonce. L'ultimo byte, fuori dall'involucro, dice quale parte della transazione la firma copre. Caselle: blu = i byte che annunciano che cosa viene, e in coda quello che dice cosa la firma copre; grigio = quanti byte occupa il pezzo che segue; giallo = i due numeri. I byte che annunciano sono codici fissi del formato, gli stessi in ogni firma; i numeri sopra le caselle sono i loro byte. Verificabile con getrawtransaction f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16.
Nel formato usato da Bitcoin quei due numeri stanno dentro un involucro DER, che
scrive ogni pezzo sempre nello stesso modo: un byte dice che cosa viene, il byte
dopo dice quanti byte occupa, e poi vengono i byte veri. Così il primo byte
annuncia una sequenza e il secondo dice quanto è lunga; dentro, ciascuno dei due
numeri si presenta allo stesso modo, prima che cosa è, poi quanto è lungo, poi
il numero. In coda, fuori dall'involucro, un byte dice quale parte della
transazione la firma copre.
I byte che annunciano sono codici fissi del formato, non contenuto: `30` vuol
dire «qui viene una sequenza» e `02` «qui viene un numero intero», e sono gli
stessi identici in ogni firma mai scritta. Di una firma all'altra cambiano solo
le lunghezze e i due numeri: è utile saperlo per leggere le figure che seguono,
dove le caselle uguali non dicono nulla e quelle diverse dicono tutto.
DER sta per *Distinguished Encoding Rules*, ed è una convenzione di scrittura
nata fuori da Bitcoin, la stessa dei certificati che un browser controlla a ogni
sito. È la versione severa di uno standard più permissivo, che lo stesso valore
lo lascerebbe scrivere in più modi: qui invece, per un dato valore, la scrittura
ammessa è una sola. La regola è servita, perché una firma non copre sé stessa:
finché i nodi accettavano involucri scritti in modo
lasco, si poteva riscrivere la firma di un altro in una forma diversa e
altrettanto valida, cambiando così l'identificativo della transazione senza
invalidarla; dal 2015 la forma stretta è regola di consenso (BIP 66). Dentro
l'involucro, infine, gli interi si scrivono con segno, quindi un numero che
comincia con un byte alto si porta davanti uno zero: è per questo che le firme
di queste figure occupano 71, 72 o 73 byte.
## Quando si ripete
Prima dei conti, una cosa da chiarire: una firma non è un'impronta. L'impronta
c'è, ed è il messaggio ridotto a numero, ma è pubblica e chiunque la rifà; la
firma vera e propria sono due numeri ottenuti con addizioni, moltiplicazioni e
inversi, operazioni che si fanno e si disfano. E deve essere così, altrimenti la
firma non sarebbe verificabile: chi controlla non conosce né la chiave né il
nonce, quindi l'unica cosa che può fare è verificare che fra i valori pubblici
valga una relazione, e una relazione si controlla solo se è aritmetica. La
stessa aritmetica che rende una firma verificabile permette di combinarne due
fra loro.
Le regole della firma stanno in due righe. `d` è la chiave privata, `z` il
messaggio ridotto a numero (la sua impronta), `G` il punto generatore, `n`
l'ordine del gruppo, e tutti i conti si fanno modulo `n`:
```
r = x(k · G) la coordinata del punto ottenuto dal nonce
s = k⁻¹ · (z + r · d) dove k è il nonce
```
Si firmi ora due volte con la stessa chiave e lo stesso nonce, su due messaggi
diversi `z₁` e `z₂`. La `r` è la stessa, perché dipende solo dal nonce:
```
s₁ = k⁻¹ · (z₁ + r · d)
s₂ = k⁻¹ · (z₂ + r · d)
```
Sottraendo, il termine con la chiave sparisce, perché è identico nelle due
righe:
```
s₁ - s₂ = k⁻¹ · (z₁ - z₂)
k = (z₁ - z₂) / (s₁ - s₂)
```
`r` non viene mai invertita: il nonce esce dalla differenza delle due `s`, e `r`
serve solo alla fine, come numero noto, per ricavare la chiave.
Recuperato il nonce, la chiave viene dalla prima equazione, riscritta:
```
d = (s₁ · k - z₁) / r
```
Due sottrazioni e due divisioni, modulo un numero primo. È aritmetica che un
telefono svolge in un istante. Nessuna forza bruta, nessuna curva ellittica
violata, nessun difetto della matematica: la matematica ha fatto esattamente ciò
che prometteva, ed è stata usata due volte con lo stesso ingrediente segreto.
Due firme della stessa chiave prodotte con lo stesso nonce. La r evidenziata è identica nelle due strisce, perché dipende solo dal nonce, e la coincidenza si vede leggendo i byte, senza calcoli. La s invece cambia, perché cambia il messaggio: è proprio quella differenza che, sottratta, restituisce prima il nonce e poi la chiave privata. Le due firme sono costruite con una chiave creata per questa figura, che non ha mai posseduto nulla; lo script che le genera ricava la chiave dalle due firme e si ferma se non ritrova quella di partenza.
Una precisazione che rende il quadro esatto. Serve che sia la **stessa chiave** a
firmare due volte con lo stesso nonce. Se due chiavi diverse usano per caso lo
stesso nonce, le equazioni restano due e le incognite diventano tre, e non si
ricava nulla. Il pericolo quindi non viene da collisioni fra estranei: viene da
un portafoglio che ripete sé stesso.
## Non è mai stato teorico
Nel 2010 si scoprì che le firme con cui la PlayStation 3 autenticava il proprio
codice usavano un nonce **costante**. Non ripetuto per sfortuna: sempre lo stesso,
scritto una volta per tutte. La chiave di firma della console ne uscì per
sottrazione, con il conto visto sopra.
Nell'agosto del 2013 si scoprì che il componente di Android incaricato di
produrre numeri casuali sicuri era difettoso. L'avviso pubblicato allora dichiarò
vulnerabili **tutti** i portafogli generati fino a quel momento su quel sistema e
impose di spostare i fondi su chiavi nuove. Il difetto colpiva in due punti
distinti: nel momento della nascita delle chiavi, che nascevano meno
imprevedibili di quanto si credesse, e nel momento della firma, dove il nonce
poteva ripetersi. Del secondo caso restano le tracce sul registro, perché le
firme con la stessa `r` si contano leggendo. Chi le trovò non ruppe nulla: lesse
due firme e fece una divisione.
Vale la pena notare che un solo componente difettoso è bastato a minacciare due
cose che sembrano lontane, la chiave al momento in cui viene creata e la firma al
momento in cui viene prodotta. È lo stesso pezzo di software, ed è il punto in
cui quasi tutti i disastri di questa famiglia hanno avuto origine.
## La cura non è più caso, è meno caso
La reazione istintiva sarebbe pretendere generatori casuali migliori. La
soluzione adottata va nella direzione opposta: **togliere il caso di mezzo**. Il
nonce non si sorteggia, si deriva dalla chiave privata e dal messaggio, con una
funzione che li mescola in modo irreversibile. È la ricetta di RFC 6979 per
ECDSA, ed è la stessa idea che BIP-340 scrive nella propria specifica per le
firme Schnorr, con in più la possibilità di aggiungere casualità ausiliaria a
chi ce l'ha buona. La scelta non è di Bitcoin soltanto: EdDSA, un'altra
famiglia di firme d'uso comune, deriva il nonce per costruzione e il sorteggio
non lo prevede affatto.
Il vantaggio è strutturale, non statistico: due messaggi diversi non possono
produrre lo stesso nonce per sbaglio, perché il nonce è funzione del messaggio.
E firmare due volte lo stesso identico messaggio produce due firme identiche,
il che non rivela niente che non fosse già pubblico.
Qui sta il punto che di solito fa inciampare: derivare il nonce sembra renderlo
prevedibile. Non è così, perché nella derivazione entra la chiave privata. Chi
ha la chiave può ricalcolare il nonce, ma chi ha la chiave ha già tutto. Chi non
ce l'ha resta davanti a un valore che non ha modo di indovinare. Determinato non
vuol dire prevedibile.
La stessa firma in due forme. Sopra ECDSA, con l'involucro DER che annuncia una sequenza e la lunghezza di ciascun numero; sotto Schnorr di BIP-340, sessantaquattro byte piatti senza involucro. Cambia l'imballaggio, non la sostanza: anche qui la prima metà dipende dal solo nonce e la seconda mescola chiave, messaggio e nonce, e anche qui due firme con lo stesso nonce consegnano la chiave, con un conto perfino più corto.
Vale la pena vedere che il cambio di forma non cambia il problema. Una firma
Schnorr è più semplice, sessantaquattro byte piatti senza involucro, e la sua
regola è lineare:
```
s = k + e · d dove e dipende da R, dalla chiave pubblica e dal messaggio
```
Con lo stesso nonce su due messaggi diversi il conto è persino più corto:
```
s₁ - s₂ = (e₁ - e₂) · d
d = (s₁ - s₂) / (e₁ - e₂)
```
Una sottrazione e una divisione, senza passare dal nonce. La forma è cambiata,
il guasto no. Per questo BIP-340 non si limita a consigliare una derivazione del
nonce: la scrive nella specifica.
## Quello che il consenso non vede
Un nodo che riceve una transazione esegue la
[serratura](/it/serrature-bitcoin/) delle monete spese e controlla che la firma
verifichi. Non controlla come è nato il nonce, e non è una svista: non può. Il nonce non è nella
firma, e nella firma non c'è nulla che dica da dove viene. Una firma prodotta con
un nonce disastroso è una firma valida, indistinguibile da una fatta bene, e
viene accettata, propagata e confermata come qualsiasi altra.
Non è una regola mancante che qualcuno potrebbe aggiungere. È informazione che
al verificatore non arriva. Nessuna modifica del protocollo può far controllare a
un nodo un dato che non possiede.
Resta una consolazione parziale, ed è bene chiamarla per nome: la ripetizione
diventa visibile a posteriori, perché chiunque può scorrere il registro e cercare
due firme con la stessa `r`. Ma quando la si vede la chiave è già uscita. È
un'osservazione da autopsia, non una difesa.
Ne segue la cosa che questo pezzo voleva dire. La verifica accerta che una firma
sia valida, non che sia stata prodotta in modo sicuro. Sono due domande diverse,
e il registro risponde solo alla prima. La seconda sta tutta dalla parte di chi
firma, dentro un programma che nessun altro esegue e che nessun altro può
controllare.
## Le coppie che si confondono
Sei distinzioni che, tenute ferme, sciolgono quasi tutto:
- **nonce di firma ≠ nonce del blocco**: la stessa parola in due posti che non
c'entrano niente fra loro; quello del mining è pubblico e si cerca a tentativi,
questo è segreto e non va cercato affatto;
- **nonce ≠ chiave privata**: la chiave dura per anni, il nonce vale per una
firma sola;
- **nonce ripetuto ≠ chiave debole**: la chiave può essere perfetta, è la firma
ad averla consegnata;
- **casuale ≠ imprevedibile**: un generatore può produrre numeri che sembrano
casuali e che qualcun altro riesce a rifare;
- **deterministico ≠ prevedibile**: il nonce derivato è ricalcolabile solo da chi
ha già la chiave, quindi determinato e non indovinabile;
- **firma valida ≠ firma sicura**: il consenso controlla la prima e non ha modo
di controllare la seconda.
## In breve
Ogni firma consuma, oltre alla chiave, un numero segreto che vale per quella
firma sola. Metà di ciò che resta scritto sul registro viene da quel numero
soltanto, quindi la sua ripetizione è visibile a chiunque; e due firme della
stessa chiave con lo stesso nonce si sottraggono l'una dall'altra fino a
restituire la chiave privata, con qualche divisione. È successo davvero, sempre
per generatori difettosi, mai per un cedimento della crittografia. La difesa non
è più casualità ma meno: il nonce si deriva dalla chiave e dal messaggio, così
che due messaggi diversi non possano collidere. E nessun nodo può farla
rispettare, perché quel dato non gli arriva: una firma valida resta valida anche
quando è nata malissimo.
## Riferimenti
- RFC 6979, *Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)*: [datatracker.ietf.org/doc/html/rfc6979](https://datatracker.ietf.org/doc/html/rfc6979)
- BIP 340, *Schnorr Signatures for secp256k1*: [github.com/bitcoin/bips/blob/master/bip-0340.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)
- RFC 8032, *Edwards-Curve Digital Signature Algorithm (EdDSA)*: [datatracker.ietf.org/doc/html/rfc8032](https://datatracker.ietf.org/doc/html/rfc8032)
- BIP 66, *Strict DER signatures* (la forma stretta dell'involucro come regola di consenso, 2015): [github.com/bitcoin/bips/blob/master/bip-0066.mediawiki](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki)
- Bitcoin.org, avviso di sicurezza sui portafogli Android (agosto 2013): [bitcoin.org/en/alert/2013-08-11-android](https://bitcoin.org/en/alert/2013-08-11-android)
- fail0verflow, *Console Hacking 2010 (PS3 Epic Fail)*, 27C3 (la chiave di firma della PlayStation 3): [media.ccc.de/v/27c3-4087-en-console_hacking_2010](https://media.ccc.de/v/27c3-4087-en-console_hacking_2010)
- La libreria che Bitcoin Core usa per le firme, [`libsecp256k1`](https://github.com/bitcoin-core/secp256k1)