Der Schlüssel ist die Route: Warum Verimesh auf WireGuard läuft
Viele von uns haben mehr Stunden damit verbracht, als wir gerne zugeben würden, zuzusehen, wie Menschen versuchen, einen IPsec-Tunnel zwischen zwei Firewalls verschiedener Hersteller aufzubauen. Wer die VPN-Kriege der 2000er Jahre erlebt hat, kennt das Gefühl: eine Konfigurationsdatei mit vierzig Parametern, von denen die Hälfte genau auf der anderen Seite passen musste, und ein Debug-Log, das dir nichts sagte, wenn sie es nicht taten.
Dann reichte 2018 ein einzelner Entwickler, Jason Donenfeld, WireGuard zur Aufnahme in den Linux-Kernel ein, und Linus Torvalds, jemand, der dafür bekannt ist, kein Blatt vor den Mund zu nehmen, schrieb, dass er nur “hoffen” könne, dass es bald gemergt würde, und nannte es “ein Kunstwerk” neben den “Horrors, die OpenVPN und IPSec sind”. Das ist hohes Lob. Es landete 2020 im Hauptzweig.
Als dann Palo Alto Networks, das die massiven Sicherheits-Appliances verkauft, die WireGuard im Stillen überbuilt wirken lässt, einen Cyberpedia-Erläuterungsbeitrag veröffentlicht, der seine kleine Codebasis, festgelegte moderne Kryptographie und Geschwindigkeit lobt, ist das bemerkenswert.
Das verschlüsselte Mesh unter Verimesh läuft auf WireGuard, und wir tun eine Sache darauf, die meines Wissens niemand anders macht: der Tunnel-Schlüssel leitet sich von derselben Wurzel ab wie die Anwendungsidentität.
Was Palo Alto unterstützt
WireGuard antwortet nicht auf Pakete, die es nicht authentifizieren kann. Sende einen Scan von einem unbekannten Schlüssel aus und du bekommst nichts zurück: kein Banner, keine Antwort, nicht mal einen lauschenden Socket zum Fingerabdruck. Für einen Port-Scan ist das Mesh einfach nicht da, und du kannst eine Oberfläche nicht angreifen, die du nicht finden kannst.
Dann ist da die Grösse. WireGuard umfasst grob 4.000 Zeilen Code. OpenVPN sind etwa 100.000. IPsec, wenn man seine Ausbreitung von Standards und Implementierungen zählt, liegt näher bei 400.000. Eine Codebasis, die du an einem Nachmittag lesen kannst, ist eine, die ein Mensch tatsächlich überprüfen kann. Und Überprüfbarkeit in diesem Ausmass ist selbst eine Sicherheitseigenschaft, eine, die du nicht nachträglich auf etwas zwei Grössenordnungen Grösseres aufpfropfen kannst.
Die Kryptographie ist festgelegt. Keine konfigurierbaren Cipher-Suiten, keine Algorithmus-Verhandlung, kein “lass uns auf das herunterfahren, das wir beide unterstützen”-Schritt. Nur Curve25519 für den Schlüsselaustausch, ChaCha20-Poly1305 für die Daten, BLAKE2s zum Hashing, Noise_IKpsk2 als Bindeglied. Die ganze Familie der Downgrade-Angriffe existiert hier nicht, weil es nichts zu verhandeln gibt.
Und WireGuard routet nach Schlüssel. Seine Cryptokey-Routingtabelle bindet den öffentlichen Schlüssel jedes Peers an die IP-Bereiche, die dieser Peer verwenden darf. Ausgehend wählt die Zieladresse den Schlüssel des Peers, der die Sitzungsschlüssel auswählt; eingehend wird ein entschlüsseltes Paket nur akzeptiert, wenn seine Quelle innerhalb des autorisierten Bereichs dieses Peers liegt. Es gibt keine separate “Wer bist du”-Überprüfung, die neben einer “Was darfst du senden”-Überprüfung angebracht ist. Der öffentliche Schlüssel ist die Route. Identität und Erreichbarkeit stellen sich als derselbe Fakt heraus.
Eine Wurzel, nicht zwei
In fast jeder WireGuard-Bereitstellung, die ich gesehen habe, führen die Schlüssel ein Eigenleben. Jemand führt wg genkey aus, gibt die öffentliche Hälfte aus, speichert die private Hälfte irgendwo, und endet mit einem Netzwerk-Schlüssel, der nichts mit der Identität zu tun hat, der die Anwendung darüber vertraut. Zwei Vertrauenswurzeln, die durch eine Tabellenkalkulation und gute Absichten in Einklang gebracht werden.
In Verimesh gibt es eine Wurzel, und alles hängt davon ab. Jede Organisation hat ihre eigene Identität, aufgebaut auf Decentralized Key Management (DKMS), der gleichen Identitätsinfrastruktur, auf der die Anwendungsschicht bereits läuft. Unter dieser Organisationsidentität wird jede Verbindung von einem Iris Agent aufgebaut, der seine eigene agentenhafte Identität hält: eine überprüfbare Ressource, in der Organisation’s eigenem DKMS-Material verwurzelt, die für einen Knoten im Mesh steht, anstatt für die Institution als Ganze. Die Curve25519-Tunnel-Schlüssel leiten sich von dieser agentenhaften Identität ab, nicht von einer Zeichenkette, die jemand einmal mit wg genkey generiert und in eine Konfiguration eingefügt hat. Es gibt keine Zertifizierungsstelle Dritter im Weg, die entscheidet, welche Tunnel zulässig sind; die Organisation stellt ihre eigenen agentenhaften Identitäten unter ihrer eigenen Wurzel aus. Keine Lücke zwischen dem, wer du auf der Netzwerkschicht bist, und wer du darüber bist.
Diese Zwischenschicht ist keine Zeremonie. Das ist es, was das Mesh praktisch macht. Eine Organisation kann mehr als einen Knoten aufstellen – separate Standorte, separate Rechenzentren, die beiden Enden einer Klinikgruppe – jeder mit seiner eigenen agentenhaften Identität unter der gleichen Organisationswurzel, jeder einzelne überprüfbar die gleiche Institution. Und das Netzwerk kann auf seiner eigenen Uhr laufen: wenn ein Tunnel-Schlüssel sich ändern muss, rotierst du die agentenhafte Identität, von der er abgeleitet ist, ohne die Organisationsidentität oder die Anwendungsschlüssel darüber zu berühren. Die Leitung kann unter sich wühlen, während die Identität der Institution genau dort bleibt, wo sie ist.
Weil jede agentenhafte Identität bis zum Schlüsselmaterial der Organisation zurückverfolgt werden kann, kann jeder Tunnel gegen das Schlüsselereignisprotokoll überprüft werden: du kannst fragen, welche Identität welchen Tunnel und wann aufgebaut hat, und die Antwort kryptographisch überprüfen, statt dem eigenen Bericht des Servers zu vertrauen. Wenn Schlüssel rotieren, rotieren sie im Einklang mit DKMS-Vor-Rotation (aufgebaut auf KERI), sodass die Tunnel-Identität den Schlüssel-Lebenszyklus überlebt, anstatt zu reissen, wenn sich ein Schlüssel ändert. Und da das Ganze selbstgehostet ist, sitzt kein Vermittler in der Mitte und besitzt den Datenfluss.
Also warum nicht einfach mTLS verwenden, das Identität bereits in den Transport-Handshake bindet?
Weil die Schichten auseinander zu halten der Sinn ist. WireGuard bewegt authentifizierte, verschlüsselte Pakete zwischen Peers, die den richtigen Schlüssel halten, und dann hört es auf. Es weiss nicht, was ein Zustimmungsentzug ist, welche Autorisierung eine Nachricht trägt, oder ob eine Berechtigung widerrufen wurde. Diese Logik gehört über die Leitung, in DKMS. mTLS neigt dazu, die Autorisierung in den Transport-Handshake zu ziehen, bis du die beiden nicht mehr separat überprüfen kannst. Wir halten sie absichtlich auseinander und bauen sie auf der gleichen Wurzel auf.
Souverän bis zur Leitung
Der Stack ist von oben bis unten Open Source. WireGuard ist im Kernel; die DKMS-Schicht darüber ist unsere, veröffentlicht unter der AGPLv3. Kein SaaS-Kontrollflugzeug sitzt im Weg. Keine Partei, die vorgeladen werden könnte, um die Schlüssel zu sichern, niemand der im Stillen protokolliert, wer mit wem sprach. Für Schweizer Gesundheitswesen, wo die Daten das Land nicht verlassen dürfen und das Vertrauen die Institution nicht verlassen darf, muss das bis zum Transport halten. Souveränität, die auf der Anwendungsschicht stoppt und ihre Netzwerk-Rohre von jemand anderem mietet, ist nicht wirklich Souveränität.
Was wir aufgeben
Keine Architektur ist kostenlos, und die Menschen, die diese Systeme betreiben, können es riechen, wenn du so tust, als wäre es anders. WireGuard fragt nach drei Kompromissen, zu denen wir transparent sind:
Erstens ist es ein Layer-3-Tunnel. Es trägt IP-Pakete, keine Streams, also du bekommst nicht das native Stream-Multiplexing, das dir ein TLS- oder QUIC-basierter Transport kostenlos gibt. Alles, das Multiplexing braucht, baut es über dem Tunnel. Für ein Mesh, das authentifizierten Austausch zwischen Institutionen trägt, ist das möglicherweise der richtige Ort dafür, aber es ist eine echte Einschränkung, nicht ein Nicht-Problem.
Zweitens wächst die Peer-Konfigurationsoberfläche mit dem Mesh. WireGuard liefert keine Kontrollflugzeug, das Peers zentral ausgibt und widerruft; jeder Knoten kennt die Peers, mit denen er spricht. In einem kleinen, verwalteten Mesh von Hubs und Knoten ist das ein Feature. Nichts Zentrales zu kompromittieren. Im grossen Massstab wird es echte Arbeit, und die Verwaltung der Schlüssel über DKMS ist das, was sie davon abhält, in den Tabellenkalkulationsnachtmahr von früher zu kollabieren.
Drittens ist es jünger als IPsec. Palo Alto setzt das auf die Contra-Liste und das macht Sinn. Aber das, das WireGuard jung macht, ist die gleiche Sache, die es überprüfbar macht: Donenfeld warf drei Jahrzehnte angesammelte Wahlfreiheit weg und fing von vorne an. Das ist die Art von Kompromiss, den wir gerne machen.
Die Quantum-Frage
WireGuard hat eine optionale Pre-Shared-Key-Schicht, die ein symmetrisches Geheimnis in den Handshake mischt. Das kauft eine Sache: Der Verkehr, der heute erfasst wird, wird nicht später lesbar, auch wenn der elliptische Kurvenaustausch schliesslich gebrochen wird. Der Store-Now-Decrypt-Later-Angriff funktioniert nicht mehr. Das ist nicht das gleiche wie Post-Quantum-Sicherheit im NIST-Sinne, und wir sind uns das bewusst. Es ist eine effektive Absicherung.
Die Route vorbei an der Absicherung hat einen Namen: Rosenpass, ein Open-Source-Projekt, das einen echten Post-Quantum-Schlüsselaustausch vor diesem Pre-Shared-Key-Slot durchführt. Es ist ein Integrationspfad für das Mesh, nicht etwas, das Verimesh heute liefert.
Das Unsere ist, was als Nächstes kommt. Weil die Tunnel-Schlüssel sich von einer DKMS-Identität ableiten, ist die Annahme von Post-Quantum-Algorithmen eine routinemässige Rotation dieser Identität auf dem vorhandenen Schlüsselereignisprotokoll – die Netzwerkschicht läuft wieder auf ihrer eigenen Uhr, dieses Mal zu einem stärkeren Algorithmus. Nicht eine erzwungene, all-auf-einmal-Zertifikateneuausgabe über einen ganzen Bestand hinweg. Von einer CA ausgestellte Transporte bekommen das nicht zu sagen.
Eine Wurzel, von der Leitung auf
Ein Mesh, bei dem der Netzwerk-Schlüssel und die Anwendungsidentität aus demselben DKMS-Material wachsen, schliesst die Naht, wo die meisten interessanten Angriffe und nahezu alle langweiligen Audit-Fehler leben: die Lücke zwischen dem, wer das Netzwerk denkt, du bist, und wem die Anwendung denkt, du bist. WireGuard gibt uns einen Transport, der einfach genug ist, um zu vertrauen; DKMS gibt ihm die gleiche Identität, der alles andere in Verimesh bereits vertraut.
Das ist der Transport unter der Verimesh-Einführung mit HIN, unter allem in der Trust Architecture, wo der vollständige Pfad von Schlüssel zu Tunnel zu überprüfter Nachricht von Ende zu Ende gelegt ist. Das, das oben läuft, ist Verimesh selbst.
Gute Rohre sind die Art, über die du nie nachdenken musst. Das ist die ganze Idee.
