La Chiave È la Rotta: Perché Verimesh Utilizza WireGuard

Molti di noi hanno passato più ore di quanto ammetterebbero a guardare persone cercare di stabilire un tunnel IPsec tra due firewall di fornitori diversi. Chi ha vissuto le guerre VPN degli anni 2000 ricorda la sensazione: un file di configurazione con quaranta parametri, metà dei quali dovevano corrispondere esattamente all’altro lato, e un log di debug che non diceva nulla quando non coincidevano.

Poi nel 2018 un singolo sviluppatore, Jason Donenfeld, ha sottoposto WireGuard per l’inclusione nel kernel Linux, e Linus Torvalds, una persona che notoriamente non ha peli sulla lingua, ha scritto che poteva «solo sperare» che venisse integrato presto, definendolo «un’opera d’arte» rispetto agli «orrori che sono OpenVPN e IPSec». Questo è un grande complimento. È finito nel mainline nel 2020.

Quindi quando Palo Alto Networks, che vende gli appliance di sicurezza pesanti che WireGuard tranquillamente fa sembrare sovradimensionati, pubblica un esplicativo su Cyberpedia che ne elogia il piccolo codebase, la crittografia moderna fissa e la velocità, vale la pena fermarsi un momento.

La mesh crittografata sottostante Verimesh utilizza WireGuard, e facciamo una cosa su di essa che, per quanto ne so, nessun altro fa: la chiave del tunnel deriva dalla stessa radice dell’identità dell’applicazione.

Quello che Palo Alto sta approvando

WireGuard non risponde a pacchetti che non può autenticare. Invia una sonda da una chiave sconosciuta e non ricevi nulla in risposta: nessun banner, nessuna risposta, nemmeno un socket in ascolto da fingerprint. Per una scansione delle porte la mesh semplicemente non esiste, e non puoi attaccare una superficie che non riesci a trovare.

Poi c’è la dimensione. WireGuard è circa 4.000 linee di codice. OpenVPN è circa 100.000. IPsec, contando la sua diffusione di standard e implementazioni, è più vicino a 400.000. Una codebase che puoi leggere in un pomeriggio è una che un essere umano può effettivamente controllare. E l’auditabilità a quella scala è di per sé una proprietà di sicurezza, una che non puoi retrofittare su qualcosa di due ordini di grandezza più grande.

La crittografia è fissa. Nessun cipher suite configurabile, nessuna negoziazione dell’algoritmo, nessun «facciamo il downgrade a quello che entrambi supportiamo». Solo Curve25519 per lo scambio di chiavi, ChaCha20-Poly1305 per i dati, BLAKE2s per l’hashing, Noise_IKpsk2 a tenere tutto insieme. L’intera famiglia di attacchi di downgrade non esiste qui, perché non c’è nulla da negoziare.

E WireGuard indirizza per chiave. La sua tabella di routing delle chiavi crittografiche associa la chiave pubblica di ogni peer agli intervalli IP che quel peer può utilizzare. In uscita, l’indirizzo di destinazione seleziona la chiave del peer, che seleziona la chiave di sessione; in entrata, un pacchetto decifrato è accettato solo se la sua origine rientra nell’intervallo autorizzato di quel peer. Non c’è un controllo «chi sei tu» separato aggiunto accanto a un controllo «cosa puoi inviare». La chiave pubblica è la rotta. L’identità e la raggiungibilità si rivelano essere lo stesso fatto.

Una sola radice, non due

In quasi ogni distribuzione di WireGuard che ho visto, le chiavi vivono una vita a parte. Qualcuno esegue wg genkey, distribuisce la metà pubblica, archivia la metà privata da qualche parte, e finisce con una chiave di rete che non ha nulla a che fare con l’identità che l’applicazione sopra di essa si fida. Due radici di fiducia riconciliate da un foglio di calcolo e dalle buone intenzioni.

In Verimesh c’è una sola radice, e tutto deriva da essa. Ogni organizzazione ha la sua identità, costruita su Decentralized Key Management (DKMS) — la stessa infrastruttura di identità su cui il livello applicativo già funziona. Sotto quella identità organizzativa, ogni connessione viene stabilita da un Iris Agent che possiede la sua identità di agente: un asset verificabile, radicato nel materiale DKMS dell’organizzazione, che rappresenta un nodo sulla mesh piuttosto che l’istituzione nel suo insieme. Le chiavi del tunnel Curve25519 derivano da quella identità di agente — non da una stringa che qualcuno ha generato una volta con wg genkey e incollato in una configurazione. Non c’è un’autorità di certificazione di terze parti nel percorso che decide quali tunnel sono consentiti; l’organizzazione emette le proprie identità di agente, secondo la propria radice. Nessun divario tra chi sei al livello di rete e chi sei sopra di esso.

Quel livello intermedio non è una cerimonia. È quello che rende la mesh pratica. Un’organizzazione può configurare più di un nodo — siti separati, data center separati, le due estremità di un gruppo di cliniche — ognuno con la sua identità di agente sotto la stessa radice organizzativa, ognuno verificabilmente della stessa istituzione. E la rete può procedere con il suo orologio: quando una chiave del tunnel ha bisogno di cambiare, ruoti l’identità di agente da cui deriva, senza toccare l’identità organizzativa o le chiavi dell’applicazione sopra di essa. Il filo può agitarsi sottostante mentre l’identità dell’istituzione rimane esattamente dov’è.

Poiché ogni identità di agente risale al materiale chiave dell’organizzazione, ogni tunnel può essere verificato rispetto al registro degli eventi chiave: puoi chiedere quale identità ha stabilito quale tunnel e quando, e verificare la risposta crittograficamente piuttosto che fidarti del conto dell’organizzazione su se stessa. Quando le chiavi ruotano, ruotano in sintonia con la pre-rotazione DKMS (costruita su KERI), quindi l’identità del tunnel sopravvive al ciclo di vita della chiave invece di rompersi quando una chiave cambia. E poiché l’intera cosa è self-hosted, nessun intermediario si siede nel mezzo possedendo il flusso di dati.

Allora perché non usare mTLS, che già lega l’identità nell’handshake del trasporto?

Perché tenere i livelli separati è il punto. WireGuard sposta pacchetti autenticati e crittografati tra peer che detengono la chiave giusta, e poi si ferma. Non sa cosa è un ritiro del consenso, quale autorizzazione porta un messaggio, o se una credenziale è stata revocata. Quella logica appartiene al di sopra del filo, in DKMS. mTLS tende a tirare l’autorizzazione nell’handshake del trasporto fino a quando non puoi più controllare i due separatamente. Li teniamo separati di proposito, e li costruiamo sulla stessa radice.

Sovrano fino al filo

Lo stack è Open Source da cima a fondo. WireGuard è nel kernel; il livello DKMS sopra di esso è nostro, pubblicato sotto la AGPLv3. Nessun control plane SaaS si siede nel percorso. Nessuna terza parte che possa essere citata in giudizio per le chiavi, nessuno che registri tranquillamente chi ha parlato con chi. Per l’assistenza sanitaria svizzera, dove i dati potrebbero non lasciare il paese e la fiducia potrebbe non lasciare l’istituzione, questo deve valere fino al trasporto. La sovranità che si ferma al livello dell’applicazione e affitta l’impianto idraulico della rete a qualcun altro non è davvero sovranità.

Quello che stiamo scambiando

Nessuna architettura è gratuita, e le persone che gestiscono questi sistemi possono sentirlo quando fingi il contrario. WireGuard chiede tre scambi, riguardo ai quali siamo trasparenti:

Innanzitutto, è un tunnel di livello 3. Trasporta pacchetti IP, non flussi, quindi non ottieni il multiplexing nativo dei flussi che un trasporto basato su TLS o QUIC ti fornisce gratuitamente. Tutto ciò che necessita di multiplexing lo costruisce sopra il tunnel. Per una mesh che trasporta scambi autenticati tra istituzioni è probabilmente il posto giusto, ma è un vincolo reale, non una non-questione.

Secondo, la superficie di configurazione dei peer cresce con la mesh. WireGuard non spedisce un control plane che distribuisca e revochi peer centralmente; ogni nodo conosce i peer con cui parla. In una mesh piccola e governata di hub e nodi è una funzione. Nulla di centrale da compromettere. Su larga scala diventa vero lavoro, e amministrare le chiavi tramite DKMS è quello che lo impedisce di crollare nell’incubo dei fogli di calcolo da prima.

Terzo, è più giovane di IPsec. Palo Alto mette questo nella lista dei contro e ha senso. Ma la cosa che rende WireGuard giovane è la stessa cosa che lo rende controllabile: Donenfeld ha buttato via tre decenni di opzionalità accumulata e ricominciato da capo. Questo è il tipo di scambio che facciamo volentieri.

La questione quantistica

WireGuard ha un livello opzionale di chiave pre-condivisa che mescola un segreto simmetrico nell’handshake. Questo compra una cosa: il traffico catturato oggi non diventa leggibile in seguito anche se lo scambio della curva ellittica è infine rotto. L’attacco di store-now-decrypt-later smette di funzionare. Questo non è la stessa cosa della sicurezza post-quantistica nel senso NIST, e ne siamo consapevoli. È una copertura efficace.

La rotta oltre la copertura ha un nome: Rosenpass, un progetto Open Source che esegue uno scambio di chiavi genuinamente post-quantistico davanti a quello slot di chiave pre-condivisa. È un percorso di integrazione per la mesh, non qualcosa che Verimesh spedisce oggi.

Quello che è nostro è quello che succede dopo. Poiché le chiavi del tunnel derivano da un’identità DKMS, l’adozione di algoritmi post-quantistici è una routine di rotazione di quella identità sul registro degli eventi chiave esistente — il livello di rete che si muove sul suo orologio di nuovo, questa volta verso un algoritmo più forte. Non una riemissione forzata di certificati all’interno di un’intera proprietà. Il trasporto emesso da CA non riesce a dire questo.

Una sola radice, dal filo verso l’alto

Una mesh dove la chiave di rete e l’identità dell’applicazione crescono dallo stesso materiale DKMS chiude la giunzione dove vivono la maggior parte degli attacchi interessanti e quasi tutti i noiosi errori di audit: il divario tra chi pensa la rete che sei e chi l’applicazione pensa che sei. WireGuard ci fornisce un trasporto sufficientemente semplice da fidarsi; DKMS gli dà la stessa identità di cui tutto il resto in Verimesh già si fida.

Questo è il trasporto sotto il rollout Verimesh con HIN, sotto tutto in Trust Architecture, dove l’intero percorso da chiave a tunnel a messaggio controllato è disposto end to end. Quello che corre sopra è Verimesh stesso.

I buoni impianti idraulici sono quelli di cui non devi mai pensare. Questo è l’intero concetto.