La chiave è il percorso: perché Verimesh funziona su WireGuard

Molti di noi hanno passato più ore di quanto vorremmo ammettere a guardare persone che cercano di portare in funzione un tunnel IPsec tra due firewall di fornitori diversi. Chiunque abbia vissuto le VPN wars dei 2000 ricorda quella sensazione: un file di configurazione con quaranta parametri, metà dei quali dovevano corrispondere esattamente all’altro lato, e un debug log che non vi diceva nulla quando non lo facevano.

Poi nel 2018 un singolo sviluppatore, Jason Donenfeld, ha sottoposto WireGuard per l’inclusione nel kernel Linux, e Linus Torvalds, qualcuno che notoriamente non è solito usare mezzi termini, ha scritto di poter “solo sperare” che venisse integrato presto, chiamandolo “un’opera d’arte” rispetto agli “orrori che sono OpenVPN e IPSec”. Questo è un grande elogio. È entrato nel mainline nel 2020.

Dunque quando Palo Alto Networks, che vende i pesanti dispositivi di sicurezza che WireGuard silenziosamente rende sovradimensionati, pubblica un explainer Cyberpedia che elogia la sua base di codice ridotta, la crittografia fissa e moderna e la velocità, merita un momento di attenzione.

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

Cosa sta endorsando Palo Alto

WireGuard non risponde ai pacchetti che non può autenticare. Inviate una sonda da una chiave sconosciuta e non otterrete nulla: nessun banner, nessuna risposta, nemmeno un socket in ascolto da riconoscere. A una scansione delle porte la mesh semplicemente non c’è, e non potete attaccare una superficie che non riuscite a trovare.

Poi c’è la dimensione. WireGuard è approssimativamente 4.000 righe di codice. OpenVPN è intorno a 100.000. IPsec, contando il suo insieme di standard e implementazioni, è più vicino a 400.000. Una base di codice che potete leggere in un pomeriggio è una che un essere umano può effettivamente auditare. E l’auditabilità a quella scala è di per sé una proprietà di sicurezza, una che non potete aggiungere a posteriori a qualcosa due ordini di grandezza più grande.

La crittografia è fissa. Nessun suite di cifrari configurabile, nessuna negoziazione di algoritmi, nessun “facciamo un downgrade a quello che entrambi supportiamo” passo. Solo Curve25519 per lo scambio di chiavi, ChaCha20-Poly1305 per i dati, BLAKE2s per hashing, Noise_IKpsk2 che tiene il tutto insieme. L’intera famiglia di attacchi di downgrade non esiste qui, perché non c’è nulla da negoziare.

E WireGuard esegue il routing per chiave. La sua tabella di routing a chiave crittografica lega la chiave pubblica di ogni peer agli intervalli IP che quel peer può usare. In uscita, l’indirizzo di destinazione seleziona la chiave del peer, che seleziona la chiave di sessione; in ingresso, un pacchetto decriptato è accettato solo se la sua sorgente ricade nell’intervallo autorizzato di quel peer. Non c’è un controllo separato “chi sei” bullonato accanto a un controllo “cosa puoi inviare”. La chiave pubblica è il percorso. L’identità e la raggiungibilità risultano essere lo stesso fatto.

Una radice, non due

In quasi ogni deployment di WireGuard che ho visto, le chiavi vivono una loro vita. 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 considera affidabile. Due radici di fiducia riconciliate da un foglio di calcolo e buone intenzioni.

In Verimesh c’è una radice, e tutto dipende 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 quell’identità organizzativa, ogni connessione è portata in funzione da un Iris Agent che detiene la sua stessa identità agentica: un asset verificabile, radicato nel materiale DKMS dell’organizzazione, che sta per un nodo della mesh piuttosto che per l’istituzione nel suo insieme. Le chiavi del tunnel Curve25519 derivano da quella identità agentica, 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 permessi; l’organizzazione emette le sue stesse identità agentiche, sotto la sua stessa radice. Nessun divario tra chi siete a livello di rete e chi siete sopra.

Quello strato intermedio non è una cerimonia. È quello che rende la mesh pratica. Un’organizzazione può far funzionare più di un nodo, siti separati, data center separati, i due capi di un gruppo clinico, ognuno con la sua identità agentica sotto la stessa radice organizzativa, ognuno verificabilmente della stessa istituzione. E la rete può muoversi secondo il suo proprio orologio: quando una chiave del tunnel ha bisogno di cambiare, ruotate l’identità agentica da cui deriva, senza toccare l’identità organizzativa o le chiavi dell’applicazione sopra. Il wire può agitarsi di sotto mentre l’identità dell’istituzione rimane esattamente dove si trova.

Poiché ogni identità agentica risale al materiale chiave dell’organizzazione, ogni tunnel può essere controllato rispetto al log degli eventi chiave: potete chiedere quale identità ha portato in funzione quale tunnel e quando, e verificare la risposta crittograficamente piuttosto che fidarvi del resoconto di un server su se stesso. Quando le chiavi ruotano, ruotano in passo con la pre-rotazione DKMS (costruita su KERI), così l’identità del tunnel sopravvive al ciclo di vita della chiave invece di rompersi quando una chiave cambia. E poiché l’intera cosa è auto-ospitata, nessun intermediario siede in mezzo possedendo il flusso dati.

Allora perché non usare semplicemente mTLS, che già lega l’identità nel 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 sia un ritiro del consenso, quale autorizzazione porti un messaggio, o se una credenziale sia stata revocata. Quella logica appartiene sopra il wire, in DKMS. mTLS tende a trascinare l’autorizzazione verso il basso nell’handshake del trasporto finché non potete più auditare i due separatamente. Li teniamo separati deliberatamente, e li costruiamo sulla stessa radice.

Sovrano fino al wire

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

Cosa stiamo rinunciando

Nessuna architettura è gratuita, e le persone che gestiscono questi sistemi riescono a fiutarla quando fingete il contrario. WireGuard chiede tre compromessi, sui quali siamo trasparenti:

In primo luogo, è un tunnel layer-3. Trasporta pacchetti IP, non stream, così non ottenete il multiplexing stream nativo che un trasporto basato su TLS o QUIC vi regala gratuitamente. Tutto quello che ha bisogno di multiplexing lo costruisce sopra il tunnel. Per una mesh che trasporta scambi autenticati tra istituzioni è discutibilmente il luogo giusto, ma è un vero vincolo, non una non-questione.

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

In terzo luogo, è più giovane di IPsec. Palo Alto mette questo nella lista dei contro ed ha senso. Ma la cosa che rende WireGuard giovane è la stessa cosa che lo rende auditabile: Donenfeld ha buttato via tre decenni di optionality accumulata e ricominciato da capo. Questo è il tipo di compromesso che accettiamo volentieri.

La questione quantistica

WireGuard ha uno strato opzionale pre-shared-key che mescola un segreto simmetrico nell’handshake. Questo compra una cosa: il traffico catturato oggi non diventa leggibile dopo anche se lo scambio ellittico-curvato viene eventualmente rotto. L’attacco store-now-decrypt-later smette di funzionare. Questo non è lo stesso della sicurezza post-quantistica nel senso NIST, e siamo consapevoli di ciò. È una copertura efficace.

Il percorso oltre la copertura ha un nome: Rosenpass, un progetto Open Source che esegue uno scambio di chiavi genuino post-quantico davanti a quello slot pre-shared-key. È un percorso di integrazione per la mesh, non qualcosa che Verimesh spedisce oggi.

Quello che è nostro è quello che accade dopo. Poiché le chiavi del tunnel derivano da un’identità DKMS, adottare algoritmi post-quantici è una routine rotazione di quella identità sul log degli eventi chiave esistente, il livello di rete che si muove di nuovo secondo il suo orologio, questa volta verso un algoritmo più forte. Non una reissuance di certificato forzata e all’una con tutto all’interno di un intero patrimonio. Il trasporto emesso da CA non arriva a dire questo.

Una radice, dal wire in su

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

Questo è il trasporto sotto il rollout di Verimesh con HIN, sotto tutto nella Trust Architecture, dove l’intero percorso dalla chiave al tunnel al messaggio auditato è disposto end to end. Quello che funziona sopra è Verimesh stesso.

La buona infrastruttura è quella di cui non dovete mai pensare. Questa è l’idea intera.