Sphinx: il formato dati anonimo alla base di Lightning e Nym

Una Mixnet funzionante, in grado di garantire una privacy a livello di rete più forte rispetto a Tor, è da tempo il sogno dei sostenitori della privacy, dei ricercatori e dei cypherpunk. Le Mixnet sono precedenti a Tor e la loro applicazione più efficace finora è stata [Mixminion]https://www.freehaven.net/anonbib/cache/minion-design.pdf, un remailer di “tipo 3” usato per inviare email in modo anonimo. Da quando lo sviluppo di Mixnet si è arenato — con due dei principali sviluppatori di Mixminion, Nick Mathewson e Roger Dingledine, che sono passati a lavorare su Tor — c’è stato poco lavoro open source dal 2003 e nessun commit dal 2011.

Grazie a un progetto iniziato con PANORAMIX e proseguito con Nym, le Mixnet sono tornate.

Come spiegato nel nostro [post precedente]https://medium.com/@nymtech/happy-birthday-bitcoin-hello-world-nym-mixnet-600cc7539190, la Mixnet di Nym è composta da mix-node che si scambiano i pacchetti tra loro. I nodi aggiungono ritardi di temporizzazione per offuscare i metadati temporali delle transazioni e generano traffico fittizio quando non c’è abbastanza traffico reale. Quindi la Mixnet di Nym offre una privacy superiore per il traffico basato sui messaggi rispetto a Tor o alle VPN (comprese le dVPN).

Il vero segreto delle Mixnet è il formato dei pacchetti Sphinx, usato sia da Nym che dalla [Lightning Network]https://lightning.network/. Sphinx è difficile da capire e non viene usato dalla Lightning Network in modo da garantire l’anonimato. Allora tuffiamoci a capofitto in Sphinx e risolviamo i suoi indovinelli!

Cos’è Sphinx?

[Sphinx]https://www.freehaven.net/anonbib/cache/DBLP:conf/sp/DanezisG09.pdf¹ instrada in modo anonimo un messaggio dal mittente al destinatario. Fornisce diverse proprietà necessarie per l’anonimato del mittente nei sistemi multi-hop:

1. Non collegabilità a livello di bit: nessun pacchetto in entrata in un mix può essere correlato a nessun pacchetto in uscita in base alla sua rappresentazione binaria da parte di un avversario che osserva la rete. In altre parole, i pacchetti sono anonimi.
2. Integrità: Resistenza agli attacchi attivi come il tagging e gli attacchi di replay, in cui l’avversario modifica e reimmette i messaggi per estrarre informazioni sulla loro destinazione o sul loro contenuto.
3. Nascondere le informazioni di instradamento: Nessun nodo di mix può dire quanti hop ha percorso finora un pacchetto, né la lunghezza del percorso di un messaggio. Per un dato nodo di mix, si conoscono solo i nodi di mix precedenti e successivi.

Con Sphinx, i pacchetti di risposta anonimi possono garantire l’anonimato del destinatario grazie ai Single-Use Reply Blocks (SURB), che sono indistinguibili dai messaggi Sphinx inoltrati nella rete.

Sphinx in breve

Un pacchetto Sphinx è composto da due parti indipendenti:

1. Un header che racchiude tutte le informazioni necessarie per instradare il messaggio dalla fonte alla destinazione; e
2. Un payload all’interno del quale è nascosto il contenuto effettivo del messaggio.

Immagina un mondo in cui Nakamoto voglia inviare in modo anonimo un messaggio a Hal Finney tramite una rete mix, dove i nodi sono rappresentati dai loro indirizzi IP e dalle chiavi pubbliche. Nakamoto deve distribuire le chiavi in modo che ogni nodo di mix nel percorso possa decodificare le informazioni di instradamento necessarie per inoltrare un pacchetto crittografato, mantenendo comunque nascosto il resto del percorso.

La struttura di Sphinx

Per prima cosa, Nakamoto sceglie un percorso, cercando la chiave pubblica di ogni nodo di mix e calcolando una chiave condivisa per ciascuno di essi. La chiave dell’intestazione Sphinx è un singolo elemento del gruppo ɑ che, quando combinato con le chiavi pubbliche dei nodi, permette di calcolare una chiave condivisa per ciascuno tramite lo scambio di chiavi Diffie-Hellman; in questo modo il primo nodo del percorso scelto dall’utente può inoltrare il pacchetto a quello successivo, e solo quel nodo di mixaggio può decrittografarlo.

Questa chiave condivisa effimera s permette a un nodo di elaborare il pacchetto ricavando le chiavi necessarie per assicurarsi che l’intestazione del pacchetto non sia stata modificata, controllando il tag di integrità ɣ nell’intestazione, e decrittografare le informazioni di instradamento crittografate β, che contengono una serie di istruzioni del mittente al nodo di mixaggio designato su cosa il nodo di mixaggio debba inoltrare e dove.

L’elemento del gruppo ɑ viene oscurato crittograficamente ad ogni fase di miscelazione per impedire la correlazione dei pacchetti per utente. Il fattore di oscuramento b viene estratto dalla chiave condivisa s, e quindi sia il mittente che il rispettivo mix possono eseguire tutte le operazioni necessarie per inoltrare i pacchetti. Il payload δ nel pacchetto Sphinx viene calcolato utilizzando un cifrario a blocchi ampi per garantire che, se un avversario modifica il payload in qualsiasi punto, il contenuto del messaggio vada irrimediabilmente perso. Il tag di integrità ɣ codificato nell’intestazione permette di verificare solo che l’intestazione del pacchetto non sia stata modificata. Tutti i pacchetti devono essere riempiti fino a raggiungere la stessa lunghezza ad ogni hop.

Garantire che l’intestazione mantenga una lunghezza costante è più complicato. Sphinx utilizza una sofisticata tecnica di padding per garantire che la dimensione costante dei pacchetti comporti un overhead minimo.

Creazione di un pacchetto Sphinx

Per instradare il messaggio m attraverso un percorso selezionato di mix M₀, M₁, M₂, Nakamoto genera un nuovo valore segreto x e precalcola tutti gli elementi del gruppo ɑ, le chiavi condivise s e i fattori di mascheramento b utilizzando x e le chiavi pubbliche dei nodi di mix. Inizia la codifica dell’intestazione incapsulando per livelli le informazioni di routing, come l’indirizzo IP, con il tag di integrità dell’intestazione per ogni nodo di mix nel percorso, dall’ultimo al primo.

Lo strato più interno è costituito da una concatenazione dell’indirizzo di Finney ∆*, di un identificatore I utilizzato per i SURB e di una sequenza di riempimento, che garantisce che la lunghezza del percorso non venga rivelata accidentalmente. Questi vengono poi crittografati tramite l’operazione XOR con l’output di un generatore di numeri pseudo-casuali inizializzato con la chiave condivisa _s_₂. Il risultato viene infine unito a una stringa di riempimento ɸ, la cui aggiunta garantisce che i pacchetti di intestazione mantengano una dimensione costante man mano che vengono aggiunti o rimossi livelli di crittografia. Una volta che l’informazione di instradamento crittografata finale β₂ è pronta, Nakamoto calcola il suo HMAC come tag di integrità ɣ₂ = HMAC(_s_₂, β₂) e crittografa questa informazione di instradamento β concatenata con il controllo di integrità ɣ. Il processo ricomincia con β₁, per poi passare al β successivo in modo ricorsivo, come mostrato qui sotto:

Creazione di un pacchetto Sphinx: più scuro è il grigio, maggiore è la crittografia!

Nakamoto poi riutilizza le chiavi condivise calcolate per crittografare a più livelli il payload. Proprio come nell’intestazione, l’incapsulamento del payload avviene in ordine inverso rispetto al percorso attraverso i nodi di mix. Il valore iniziale δ_₂_ viene creato utilizzando il cifrario a blocchi ampio, con la chiave s₂, dalla concatenazione del messaggio m, l’indirizzo di Finney ∆ e una sequenza di riempimento di byte zero, che permette di verificare che il corpo del messaggio non sia stato modificato durante il trasferimento — se un singolo bit viene modificato da un attaccante, la cifratura a blocchi ampi decifrerà il payload trasformandolo in bit casuali.

Finney deve comunque essere in grado di distinguere se si tratta di un messaggio valido o di un testo cifrato casuale utilizzando il riempimento aggiuntivo con sequenza nota di zero byte. Una volta che δ_₂_ è pronto, Nakamoto lo crittografa di nuovo usando s₁ e s₀, uno per uno.

Elaborazione di un pacchetto Sphinx

1. Quando riceve un pacchetto, il nodo di miscelazione estrae l’elemento del gruppo ɑ dall’intestazione e lo combina con la propria chiave segreta per ricavare la chiave condivisa s
2. Utilizzando s, il mix calcola l’hash con chiave delle informazioni di routing crittografate come HMAC(s, β) e lo confronta con il tag di integrità ɣ allegato nell’intestazione del pacchetto. Se il controllo di integrità fallisce perché l’intestazione è stata manomessa, il pacchetto viene scartato. Altrimenti, il nodo di mixaggio passa alla fase 3.
3. Il mix-node è ora pronto a decriptare il β allegato. Per estrarre le istruzioni di instradamento, il nodo di mixaggio aggiunge prima un riempimento di zero byte alla fine di β e decrittografa il blocco riempito di informazioni di instradamento B applicando l’operazione XOR con un flusso pseudo-casuale di byte generato utilizzando s. La quantità di riempimento con byte zero aggiunta a β è pari alla lunghezza delle istruzioni di instradamento che il nodo di miscelazione deve estrarre per preservare l’invarianza di lunghezza. Nota che, poiché il padding viene sottoposto a hash all’interno del tag di integrità ɣ, deve essere identico al padding pregenerato da Nakamoto.
4. Il mix-node analizza le istruzioni di instradamento provenienti da B per ottenere l’indirizzo del mix-node successivo (o, nel caso dell’ultimo hop, l’indirizzo di destinazione ∆ e l’identificatore I), oltre ai nuovi tag di integrità ɣ’ e β’, che devono essere inoltrati all’hop successivo.
5. Il nodo di mixaggio esegue anche la decrittografia a blocco ampio di δ, ottenendo δ’, che verrà inoltrato al nodo successivo.
6. Il nodo di miscelazione nasconde il valore ɑ ricevuto utilizzando un fattore di occultamento derivato dalla chiave condivisa s per ottenere un nuovo elemento del gruppo ɑ’.

Una volta che sia l’intestazione che il payload sono stati crittografati e l’elemento del gruppo è stato oscurato, il nodo di miscelazione può assemblare un nuovo pacchetto come ((ɑ’, β’, ɣ’), δ’) e inoltrarlo all’indirizzo successivo.

Illustrazione originale del formato dei pacchetti Sphinx, tratta da Danezis e Goldberg (2014)

Come Nym sventa gli attacchi a Sphinx

Uno degli aspetti migliori di Sphinx è che è dimostrabilmente sicuro — l’articolo originale offre una dimostrazione di sicurezza delle proprietà su cui si basa. In generale, vogliamo delle dimostrazioni di sicurezza, che i crittografi di solito fanno a mano per dimostrare che un sistema ha effettivamente una serie di proprietà che possono essere logicamente dimostrate a partire da una serie di presupposti matematici. È molto più difficile dimostrare le proprietà di privacy, che in genere richiedono la simulazione.

Quando i crittografi elaborano le dimostrazioni di sicurezza a mano, possono commettere errori o semplicemente trascurare alcuni aspetti di ciò che vogliono dimostrare. Il lavoro di Kuhn et al.,² dimostra che, poiché le proprietà formali definite da Camenisch e Lysyanskaya³ per i sistemi basati sull’onion routing sono insufficienti, nella dimostrazione di sicurezza presentata da Danezis e Goldberg non è stata individuata una grave falla nel progetto originale del pacchetto Sphinx. Se questo difetto non viene corretto, potrebbe compromettere in modo significativo la privacy degli utenti nei sistemi che utilizzano Sphinx.

Il progetto originale di Sphinx proponeva di usare un riempimento a zero byte, ma solo con una sequenza di zeri, poiché il riempimento permette all’ultimo nodo di miscelazione nel percorso di dedurre informazioni sulla lunghezza del percorso, compromettendo così una delle proprietà di sicurezza promesse da Sphinx e consentendo potenzialmente di ricavare informazioni significative sul percorso o addirittura sulla destinazione finale.

Come descritto in precedenza, l’ultimo nodo di mixaggio nel percorso riceve lo strato più interno delle informazioni di routing crittografate β, generato come crittografia dell’indirizzo del destinatario (∆), di un identificatore (I) e di un riempimento di zero byte, e combinato con la stringa di riempimento ɸ.

Seguendo la notazione usata nell’articolo su Sphinx, il β più interno viene creato come

dove |ɸ| = 2(v-1)κ, e κ, r sono rispettivamente un parametro di sicurezza e la lunghezza massima del percorso, mentre v è la lunghezza del percorso percorso dal pacchetto. L’elaborazione del β ricevuto da parte del mix-node viene eseguita come

Allora, come fa l’ultimo nodo di mixaggio a ricavare informazioni sulla lunghezza del percorso da questa matematica magica?

Per spiegare come funziona questo attacco, ti presentiamo un semplice esempio. Per prima cosa, ricorda che dato il valore x = a⊕b, sia x che a e b hanno la stessa lunghezza, e se poi esegui l’operazione XOR tra x e b ottieni x⊕b = a⊕b⊕b = a. Per il nostro esempio, supponiamo che l’output del PRNG con la chiave condivisa del nodo v-1 come input sia 10101010101010101010….

Consideriamo ora il seguente valore di β ricevuto dall’ultimo mix

Ora, seguendo il punto (2), eseguiamo le stesse operazioni che il mixnode di uscita eseguirebbe per decriptare e analizzare β

Per come è progettata, l’ultimo nodo di mix nel percorso conosce la lunghezza totale del β previsto (nel nostro esempio era di 9 bit) e sa che la concatenazione dell’indirizzo di destinazione (∆) e dell’identificatore (I) è seguita rispettivamente dal riempimento con zeri e dai bit pseudo-casuali della stringa di riempimento. Conoscendo le lunghezze esatte ∆ e I, l’ultimo nodo di mix onesto ma curioso cerca dove si trova il primo bit 1 dopo l’identificatore, poiché sa che la stringa di riempimento inizia lì o prima. L’osservazione del primo bit dopo l’identificatore permette all’ultimo mix di determinare un limite inferiore sulla lunghezza della stringa di riempimento. Poiché la lunghezza totale di ɸ è definita per impostazione predefinita come il doppio della lunghezza del percorso moltiplicata per il parametro di sicurezza κ, il limite inferiore della lunghezza della stringa di riempimento rivela informazioni sul limite inferiore della lunghezza del percorso utilizzato.

Perché conoscere la lunghezza del percorso è pericoloso

Come hanno dimostrato alcune ricerche,⁴ nelle reti che utilizzano topologie limitate o sparse (ad esempio Lightning), conoscere la lunghezza del percorso riduce l’insieme di anonimato dietro cui un mittente può nascondersi. L’esempio nella figura qui sotto mostra come la conoscenza del limite inferiore della lunghezza del percorso possa ridurre l’anonimato del mittente. Se D funge da nodo di mixaggio di uscita e inoltra un pacchetto a Timmy, senza conoscere la lunghezza del percorso, uno qualsiasi dei nodi A, B, C, E, G, F potrebbe essere il mittente. Tuttavia, se D riesce a dedurre che la lunghezza del percorso è almeno 3, allora osservando il grafico della rete si deduce che solo A o B possono essere il mittente, quindi l’insieme dei potenziali mittenti si riduce notevolmente.

È piuttosto semplice prevenire questo attacco. In (1), quando creiamo β invece di usare il riempimento con zeri, basta usare il riempimento con bit casuali. In realtà, l’implementazione in Python di George Danezis riconosce già questo [difetto]https://github.com/lightningnetwork/lightning-onion/issues/42.

Fig. 1

Ma questo attacco non ha alcun impatto su Nym

1. Nym utilizza una topologia stratificata per massimizzare l’anonimato, quindi tutti i percorsi hanno la stessa lunghezza e ogni nodo di mix conosce la propria posizione nel percorso. Con Lightning non è così. Utilizza percorsi di lunghezza variabile, quindi la sua implementazione originale di Sphinx era vulnerabile a questo attacco, anche se ora è stata [corretta]https://github.com/lightningnetwork/lightning-onion/issues/42.
2. L’ultimo livello di codifica Sphinx viene rimosso dall’applicazione stessa, non dal mix di uscita (come in Tor). Tuttavia, l’[implementazione di Sphinx in Rust](https://github.com/nymtech/sphinx di Nym è resistente a questo attacco (usa il padding randomizzato) e quindi può essere riutilizzata in tutta sicurezza da qualsiasi progetto basato su Sphinx.

Cosa riserva il futuro a Nym?

Il primo pacchetto Sphinx anonimo di Nym non sarà l’ultimo. La rete Nym si evolverà gradualmente in una Mixnet stabile e multiuso per qualsiasi applicazione Internet. La nostra testnet è già attiva e funzionante e dovrebbe entrare in produzione entro la fine del 2020.

Ma chi ha bisogno della privacy a livello di rete, in fondo? A quanto pare, quasi tutti.

Il Lightning Network usa già i pacchetti Sphinx, ma in un modo che compromette la sua capacità di garantire la privacy delle transazioni, come [ha dimostrato Claudia Diaz alla Lightning Conference]https://www.youtube.com/watch?v=g55kMhggIBY nel novembre 2019. Con alcune modifiche, Lightning potrebbe essere reso più rispettoso della privacy, dato che condivide già gran parte dell’infrastruttura, come Sphinx, con Nym. La combinazione di Nym e Lightning potrebbe essere la strada più praticabile per rendere Bitcoin privato.

(iframe src="https://www.youtube.com/embed/g55kMhggIBY?feature=oembed" width="700" height="393")(/iframe)

Claudia Diaz spiega perché Sphinx non aiuta la privacy di Lightning — e come si può risolvere il problema.

Anche le criptovalute con privacy potenziata e le sidechain di qualsiasi criptovaluta dovrebbero utilizzare l’anonimato a livello di rete, altrimenti gli attacchi potrebbero sfruttare i dati temporali per deanonimizzare i pacchetti e persino portare ad attacchi alle tecniche di privacy on-chain come gli zkSNARKS. Stiamo portando avanti attività di sensibilizzazione in diverse comunità e presto avremo altro da dire.

E non dimentichiamoci dell’interesse per le VPN decentralizzate da parte di Brave e altri. A che velocità possono viaggiare i pacchetti Sphinx? Sphinx utilizza molta crittografia asimmetrica e cifrari esotici a blocchi larghi per garantire l’impossibilità di tracciare collegamenti, ma forse potrebbe anche essere riprogettato per raggiungere le velocità che renderanno realtà questo tipo di casi d’uso.

Sphinx conferisce ai normali pacchetti Internet il potere dell’anonimato — ma da un grande potere derivano grandi responsabilità. Non vediamo l’ora di scoprire quali nuovi tipi di servizi e applicazioni si faranno carico di questa responsabilità e si svilupperanno sulla base di Nym!

Riferimenti

¹ George Danezis e Ian Goldberg. [Sphinx: un formato di mix compatto e dimostrabilmente sicuro]http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/sphinx-eprint.pdf. In IEEE Symposium on Security and Privacy, pp. 269–282. IEEE, 2009.

² Christiane Kuhn, Martin Beck e Thorsten Strufe. Come violare e (parzialmente) correggere l’onion routing dimostrabilmente sicuro. Preprint arXiv arXiv:1910.13772, 2019.

³ Jan Camenisch e Anna Lysyanskaya. [Un approccio formale all’onion routing]https://cs.brown.edu/people/alysyans/papers/cl05-full.pdf. In Annual International Cryptology Conference, pp. 169–187. Springer, 2005.

⁴ George Danezis. [Mix-networks con percorsi limitati]https://www.freehaven.net/anonbib/cache/danezis:pet2003.pdf. In International Workshop on Privacy Enhancing Technologies, pp. 1–17. Springer, 2003.