PP pki type

Ogni protocollo che firma qualcosa deve nominare l'algoritmo, e nominarlo in un campo che il mittente controlla è il modo in cui iniziano gli attacchi di declassamento. BIP70 offriva tre valori, uno dei quali era considerato debole da anni prima che la specifica fosse scritta. I browser hanno completato l'espulsione dei certificati SHA-1 a gennaio 2017, e il protocollo di pagamento non ha mai pubblicato un aggiornamento.

Come funziona

Stato: storico. PP pki type era il campo 2 di PaymentRequest, con valore predefinito la stringa "none", ed è assente da Bitcoin Core dalla versione 0.20.0 del 3 giugno 2020.

Sono stati definiti tre valori e non ne è mai stato registrato un quarto, sebbene la specifica lasciasse spazio per uno.

"none" indicava una richiesta non firmata. Il campo del certificato restava vuoto, il campo della firma restava vuoto, e un wallet poteva mostrare l'importo e la destinazione ma nessuna identità. La maggior parte delle richieste in circolazione era esattamente questo.

"x509+sha256" significava che il commerciante serializzava l'intero messaggio con il campo della firma svuotato, calcolava l'hash del risultato con SHA-256 e firmava quell'hash con la chiave privata del primo certificato della catena allegata.

"x509+sha1" significava la stessa procedura con SHA-1 al posto di SHA-256.

Offrire l'opzione debole è la parte interessante. Un verificatore che rispetta qualunque algoritmo il mittente nomini è forte solo quanto il peggior algoritmo che accetta ancora, ed è per questo che i progetti successivi fissano l'insieme accettabile dal lato del verificatore invece di leggerlo dal messaggio. SHA-1 era un candidato scadente già nel 2013. Un attacco di collisione più rapido della forza bruta è stato pubblicato nel 2005, e il NIST ha vietato l'uso di SHA-1 per generare nuove firme digitali dopo il 2013. Le autorità di certificazione hanno smesso di emettere certificati SHA-1 alla fine del 2015, Chrome 56 ha smesso di considerarne affidabili a gennaio 2017, e una collisione pubblica completa è arrivata un mese dopo.

Dove lo vedi

Bitcoin stesso fornisce il controesempio a un algoritmo di firma nominato dal mittente, e vale la pena tenerlo a mente.

Una transazione bitcoin non negozia mai il proprio algoritmo di firma con chi la convalida. L'output speso risolve la questione: un output precedente a Taproot viene verificato con ECDSA su secp256k1, e un output che paga una chiave Taproot viene verificato con Schnorr secondo BIP340, una regola attivata al blocco 709.632 a novembre 2021. Chi spende non può proporre qualcosa di più economico da rompere, perché la scelta era fissata quando i bitcoin sono stati ricevuti.

Questa differenza spiega perché uno strato basato sui certificati si adattasse così male sopra bitcoin. Le regole di consenso si applicano allo stesso modo a tutti e cambiano solo con un aggiornamento coordinato, mentre un campo che nomina un algoritmo è una negoziazione, e le negoziazioni vengono declassate.

Se stai scegliendo dove comprare invece di scrivere software, la versione utile è ristretta ma reale. Una piattaforma che tiene viva un'opzione crittografica obsoleta "per compatibilità" ti sta dicendo come pesa la comodità rispetto alla sicurezza, e quel giudizio vale anche per le parti del sistema che non puoi ispezionare.

PP pki type vs firma SSL

PP pki type nominava uno schema; la firma SSL era il risultato della sua esecuzione. Trattare le due cose come una sola rende confusa la vecchia documentazione BIP70, perché una richiesta poteva nominare un tipo e non portare alcuna firma, che è precisamente ciò che significava "none". Il TLS moderno mantiene la stessa accoppiata, con un identificatore di algoritmo registrato accanto ai byte della firma, ma un client non accetta più ogni identificatore che un tempo era valido.