Der Schlüssel ist die Route: Warum Verimesh auf WireGuard laeuft

Viele von uns haben mehr Stunden damit verbracht, als uns lieb ist, dabei zuzuschauen, wie Menschen versuchen, einen IPsec-Tunnel zwischen zwei Firewalls verschiedener Hersteller aufzubauen. Wer die VPN-Kriege der 2000er Jahre miterlebt hat, kennt das Gefühl: eine Konfigurationsdatei mit vierzig Parametern, von denen die Haelfte genau auf der anderen Seite übereinstimmen muss, und ein Debug-Log, das dir nichts verrät, wenn sie es nicht tun.

Dann reichte 2018 ein einzelner Entwickler, Jason Donenfeld, WireGuard zur Aufnahme in den Linux-Kernel ein, und Linus Torvalds, jemand, der dafuer bekannt ist, kein Blatt vor den Mund zu nehmen, schrieb, dass er nur hoffen koennte, dass es bald gemergt wuerde, und nannte es “ein Kunstwerk” neben den “Horrors, die OpenVPN und IPSec sind”. Das ist hohes Lob. Es landete 2020 im Mainline.

Also, wenn Palo Alto Networks, das schwere Sicherheitsappliances verkauft, die WireGuard stillschweigend überbucht aussehen laesst, einen Cyberpedia-Erklärer veroeffentlicht, der seine kleine Codebasis, feste moderne Kryptographie und Geschwindigkeit lobt, ist das einen Moment wert.

Das verschlüsselte Mesh unter Verimesh laeuft auf WireGuard, und wir machen eine Sache darauf, die, soweit ich weiss, sonst niemand macht: Der Tunnel-Schlüssel leitet sich von der gleichen Wurzel ab wie die Anwendungsidentitaet.

Was Palo Alto empfaehlt

WireGuard antwortet nicht auf Pakete, die es nicht authentifizieren kann. Sende eine Probe von einem unbekannten Schlüssel und du bekommst nichts zurück: kein Banner, keine Antwort, nicht einmal einen lauschenden Socket zum Fingerabdrucken. Bei einem Port-Scan ist das Mesh einfach nicht vorhanden, und du kannst eine Oberflaeche nicht angreifen, die du nicht finden kannst.

Dann ist da die Groesse davon. WireGuard hat ungefaehr 4.000 Zeilen Code. OpenVPN sind etwa 100.000. IPsec, wenn man seinen Wildwuchs von Standards und Implementierungen zaehlt, ist naeher an 400.000. Eine Codebasis, die man an einem Nachmittag lesen kann, ist eine, die ein Mensch tatsaechlich audieren kann. Und Audierbarkeit in diesem Massstab ist selbst eine Sicherheitseigenschaft, die du nicht nachtraeglich auf etwas anbringen kannst, das zwei Groessenordnungen groesser ist.

Die Kryptographie ist festgelegt. Keine konfigurierbaren Cipher-Suites, keine Algorithmus-Verhandlung, kein “lass uns auf das downgraden, was wir beide unterstuetzen”-Schritt. Nur Curve25519 fuer den Schlüsselaustausch, ChaCha20-Poly1305 fuer die Daten, BLAKE2s zum Hashing, Noise_IKpsk2 haelt es zusammen. Die ganze Familie von Downgrade-Angriffen existiert hier nicht, weil es nichts zu verhandeln gibt.

Und WireGuard routet nach Schlüssel. Seine Cryptokey-Routing-Tabelle bindet den oeffentlichen Schlüssel jedes Peers an die IP-Bereiche, die dieser Peer verwenden darf. Ausgehend waehlt die Zieladresse den Schlüssel des Peers aus, der die Sitzung auswählt; eingehend wird ein entschlüsseltes Paket nur akzeptiert, wenn seine Quelle in den autorisierten Bereich dieses Peers faellt. Es gibt keine separaten “wer bist du”-Check neben einem “was darfst du senden”-Check. Der oeffentliche Schlüssel ist die Route. Identitaet und Erreichbarkeit stellen sich als die gleiche Tatsache heraus.

Eine Wurzel, nicht zwei

Bei fast jeder WireGuard-Bereitstellung, die ich gesehen habe, fuehren die Schlüssel ein Eigenleben. Jemand laeuft wg genkey, gibt die oeffentliche Haelfte ab, speichert die private Haelfte irgendwo, und landet mit einem Netzwerk-Schlüssel, der nichts mit der Identitaet zu tun hat, der die Anwendung darüber vertraut. Zwei Vertrauenswurzeln, abgestimmt von einem Tabellenkalkulationsprogramm und guten Absichten.

In Verimesh gibt es eine Wurzel. Die Curve25519-Tunnel-Schlüssel jeder Organisation sind in ihrem eigenen Dezentralisierten Schlüsselverwaltungs- (DKMS) Material verankert. Die gleiche Identitaetsinfrastruktur, auf der die Anwendungsschicht bereits laeuft. Niemand gibt sie aus. Es gibt keine Zertifizierungsstelle im Pfad, die entscheidet, welche Tunnel zulässig sind, und es gibt keine Luecke zwischen wer du auf der Netzwerk-Schicht bist und wer du darueber bist.

Da die Schlüssel auf das Key-Material der Organisation zurückgehen, kann jeder Tunnel gegen das Schlüssel-Event-Log überprüft werden: du kannst fragen, welche Identitaet welchen Tunnel wann aufgebracht hat, und die Antwort kryptographisch verifizieren, anstatt auf die eigene Aussage eines Servers zu vertrauen. Wenn Schlüssel rotieren, rotieren sie im Schritt mit DKMS-Prä-Rotation (aufgebaut auf KERI), sodass die Tunnel-Identitaet den Schlüssel-Lebenszyklus übersteht, anstatt zu brechen, wenn ein Schlüssel sich aendert. Und da das Ganze selbst gehostet wird, sitzt kein Vermittler in der Mitte und besitzt den Datenfluss.

Also warum nicht einfach mTLS verwenden, das bereits Identitaet in den Transport-Handshake bindet?

Weil die Schichten zu trennen der Punkt ist. WireGuard bewegt authentifizierte, verschlüsselte Pakete zwischen Peers, die den richtigen Schlüssel halten, und dann hoert es auf. Es weiss nicht, was eine Zustimmungsruecknahme ist, welche Autorisierung eine Nachricht traegt, oder ob eine Berechtigung widerrufen wurde. Diese Logik gehoert oben am Draht, in DKMS. mTLS neigt dazu, die Autorisierung in den Transport-Handshake zu ziehen, bis du die beiden nicht mehr separat audieren kannst. Wir halten sie mit Absicht auseinander und bauen sie auf die gleiche Wurzel.

Souveraen bis zum Draht

Der Stack ist von oben bis unten Open Source. WireGuard ist im Kernel; die DKMS-Schicht darueber ist unser, veroeffentlicht unter der AGPLv3. Kein SaaS-Control-Plane sitzt im Pfad. Kein Dritter, der fuer die Schlüssel vorgeladen werden kann, niemand protokolliert stillschweigend, wer mit wem sprach. Fuer Schweizer Gesundheitswesen, wo die Daten das Land nicht verlassen duerfen und das Vertrauen die Institution nicht verlassen darf, muss das bis zum Transport gelten. Souveraenitaet, die auf der Anwendungsschicht stoppt und ihre Netzwerk-Rohre von jemandem mietet, ist keine echte Souveraenitaet.

Worauf wir verzichten

Keine Architektur ist kostenlos, und die Leute, die diese Systeme ausfuehren, koennen es riechen, wenn du so tust, als waere es anders. WireGuard verlangt drei Kompromisse, ueber die wir transparent sind:

Erstens ist es ein Layer-3-Tunnel. Er traegt IP-Pakete, keine Straeme, also bekommst du nicht das native Stream-Multiplexing, das ein TLS- oder QUIC-basierter Transport kostenlos anbietet. Alles, das Multiplexing braucht, baut es oben auf dem Tunnel auf. Fuer ein Mesh, das authentifizierten Austausch zwischen Institutionen traegt, ist das wohl der richtige Platz, aber es ist eine echte Einschraenkung, nicht ein Non-Issue.

Zweitens waechst die Peer-Konfigurationsflaeche mit dem Mesh. WireGuard hat keine Control Plane, die Peers zentral aushaendigt und widerruft; jeder Knoten kennt die Peers, mit denen er spricht. In einem kleinen, verwalteten Mesh von Hubs und Knoten ist das eine Funktion. Nichts Zentrales zu kompromittieren. Im Grosseinsatz wird es echte Arbeit, und die Verwaltung der Schlüssel via DKMS ist das, was es davor bewahrt, in den Albtraum der Tabellenkalkulation von fruher zu kollabieren.

Drittens ist es jünger als IPsec. Palo Alto setzt das auf die Nachteile-Liste und das macht Sinn. Aber das, was WireGuard jung macht, ist das gleiche, das es audierbar macht: Donenfeld warf drei Jahrzehnte angesammelte Optionalitaet weg und fing von vorne an. Das ist die Art von Kompromiss, den wir gerne machen.

Die Quanten-Frage

WireGuard hat eine optionale Pre-Shared-Key-Schicht, die ein symmetrisches Geheimnis in den Handshake mischt. Das kauft eine Sache: Verkehr, der heute erfasst wird, wird spaeter nicht lesbar, auch wenn der Elliptic-Curve-Austausch schliesslich unterbrochen wird. Der Store-Now-Decrypt-Later-Angriff hoert auf zu funktionieren. Das ist nicht das gleiche wie Post-Quantum-Sicherheit im NIST-Sinne, und wir sind uns dessen 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 ausfuehrt. Es ist ein Integrationspfad fuer das Mesh, nicht etwas, das Verimesh heute ausliefert.

Was unser ist, ist das, was als naechstes kommt. Weil die Tunnel-Schlüssel von DKMS stammen, ist die Annahme von Post-Quantum-Algorithmen eine routinemässige Schlüssel-Rotation auf dem bestehenden Schlüssel-Event-Log. Nicht eine erzwungene, Alles-auf-Einmal-Zertifikats-Neuausstellung über einen ganzen Bestand hinweg. Von der Zertifizierungsstelle ausgegebener Transport kann das nicht sagen.

Eine Wurzel, vom Draht aufwaerts

Ein Mesh, bei dem der Netzwerk-Schlüssel und die Anwendungsidentitaet aus dem gleichen DKMS-Material waechsen, schliesst die Naht, wo die meisten interessanten Angriffe und fast alle langweiligen Audit-Fehler leben: die Luecke zwischen wer das Netz denkt, dass du bist, und wer die Anwendung denkt, dass du bist. WireGuard gibt uns einen Transport, der einfach genug ist, um darauf zu vertrauen; DKMS gibt ihm die gleiche Identitaet, der alles andere in Verimesh bereits vertraut.

Das ist der Transport unter dem Verimesh-Rollout mit HIN, unter allem in der Trust Architecture, wo der vollstaendige Pfad von Schlüssel zu Tunnel zu audierter Nachricht end-to-end ausgelegt ist. Was oben laeuft, ist Verimesh selbst.

Gute Rohre sind die Art, über die du nie nachdenken musst. Das ist die ganze Idee.