Derivazione hardened vs non hardened

L'hardening è un confine nel tuo percorso di derivazione, non un'impostazione che attivi e disattivi. BIP-32 è stato assegnato l'11 febbraio 2012 con la sola derivazione non hardened; la derivazione privata per gli indici pari o superiori a 0x80000000 è stata aggiunta il 16 aprile 2013, e quelle chiavi sono state rinominate hardened il 15 gennaio 2014. Il punto in cui cade quel confine decide quanto del tuo wallet consegna una chiave pubblica estesa condivisa.

Come funziona

La derivazione non hardened ha una proprietà che la derivazione hardened deliberatamente non ha, e BIP-32 registra la differenza come un'identità algebrica. Indica con N() la neutering, il passaggio che scarta la metà privata di una chiave estesa e conserva il chain code di 32 byte. Lungo i livelli non hardened, N(m/a/b/c) è uguale a N(m)/a/b/c, quindi applicare la neutering prima di derivare e applicarla dopo la derivazione porta alla stessa chiave. A un livello hardened la riscrittura non vale: N(m/a') non può diventare N(m)/a', perché la derivazione pubblica è definita solo per le chiavi figlie non hardened e restituisce un errore per qualsiasi altra.

Dal punto di vista meccanico le due modalità differiscono per un solo campo. Entrambe usano il chain code della chiave genitore come chiave di un HMAC-SHA512 e aggiungono l'indice di 4 byte. La modalità non hardened fornisce la chiave pubblica compressa della chiave genitore; la modalità hardened fornisce il segreto della chiave genitore, riempito con un byte zero iniziale fino alla stessa larghezza di 33 byte. Nulla che possieda solo una xpub dispone di quel secondo input, quindi la derivazione si ferma al confine.

BIP-32 è insolitamente esplicito su ciò che le chiavi non hardened non riescono a proteggere. La sua sezione sulla sicurezza elenca due proprietà come assenti e non come presenti: data una chiave pubblica estesa genitore e una chiave pubblica figlia, trovare l'indice non è difficile, e data quella stessa chiave pubblica estesa genitore più una qualsiasi chiave privata figlia non hardened, recuperare la chiave privata estesa genitore non è difficile neppure questo. La prima ti costa la privacy. La seconda ti costa il ramo.

Dove lo vedi

I livelli non hardened sono ciò che rende utile esportare una chiave pubblica estesa, e BIP-32 dedica una sezione agli accordi di condivisione costruiti su di essi. Un revisore a cui vengono consegnate le chiavi pubbliche estese dei conti vede ogni pagamento in entrata e in uscita da ogni conto e nessuna chiave segreta. Due aziende che fanno trading spesso possono condividere la catena esterna di un singolo conto come indirizzo fisso su cui pagare, così nessuna delle due deve chiedere un indirizzo nuovo per ogni trasferimento. Un negozio online può consegnare lo stesso tipo di chiave al proprio server web, che poi genera indirizzi di ricezione dai quali non ha alcun potere di spesa.

La struttura che pone il confine a livello di conto è un consiglio, non una regola. BIP-32 definisce la propria struttura master, account, chain e subchain solo orientativa e dice alle implementazioni che possono discostarsene per esigenze specifiche, ed è per questo che un wallet conforme può applicare l'hardening a più livelli del wallet conforme che gli sta accanto.

Vale la pena conoscere una trappola di interoperabilità, perché la specifica è stata corretta due volte per questa ragione. I vettori di test per la derivazione hardened con zeri iniziali sono stati aggiunti il 24 febbraio 2017 e di nuovo il 4 novembre 2020. L'input hardened è fissato a 33 byte, un byte zero seguito dal segreto di 32 byte, quindi un software che taglia uno zero iniziale invece di mantenere quella larghezza calcola l'hash di dati diversi, produce un ramo diverso e trova un wallet vuoto quando qualcuno ripristina quel seed in un altro programma. La derivazione non hardened non incontra mai questo difetto, perché una chiave pubblica compressa inizia sempre con 0x02 o 0x03 e quindi non ha alcuno zero iniziale da perdere.