Post-Quantum-Sicherheit: Was heute mitgeschnitten wird, liest morgen jemand

Die üblichen Schlagzeilen zum Thema Quantencomputer sind entweder Panikmache oder Beschwichtigung. Beides hilft nicht weiter. Nüchtern betrachtet ist die Lage überschaubar: Ein Teil der heute eingesetzten Verschlüsselung hat ein Ablaufdatum, ein anderer Teil nicht, und der Unterschied lässt sich in einem Satz erklären. Danach wird es allerdings praktisch — und dort liegen die eigentlichen Probleme.

Das Problem heisst «Harvest now, decrypt later»

Wer heute verschlüsselten Datenverkehr mitschneidet, kann ihn speichern. Nicht um ihn jetzt zu lesen, sondern um ihn zu lesen, sobald die Mittel dazu existieren. Ein hinreichend grosser Quantenrechner bricht mit dem Shor-Algorithmus genau jene Verfahren, die heute den Schlüsselaustausch absichern: RSA, Diffie-Hellman und die elliptischen Kurven.

Der Angriff findet also in der Zukunft statt, das Sammeln der Daten aber jetzt. Für die Risikobewertung heisst das: Nicht das Datum des ersten Quantenrechners zählt, sondern die Frage, wie lange die Daten schützenswert bleiben, die heute über die Leitung gehen. Ein Krankenversicherungsvertrag, eine Konstruktionszeichnung oder ein Anwaltsmandat sind in zehn Jahren nicht weniger vertraulich als heute.

Die klassische Formulierung dafür ist Moscas Ungleichung: Wenn die Zeit, die Ihre Daten geheim bleiben müssen, plus die Zeit, die Ihre Umstellung dauert, grösser ist als die Zeit bis zum ersten fähigen Quantenrechner — dann sind Sie zu spät dran. Man muss das Datum des Quantenrechners dafür nicht kennen. Es genügt zu wissen, dass die eigene Umstellung Jahre dauert.

Was betroffen ist — und was nicht

Hier lohnt sich die Genauigkeit, weil sie Aufwand spart.

Aus diesen drei Zeilen folgt die ganze Priorisierung: Der Schlüsselaustausch ist die Baustelle, alles andere hat Zeit.

Die Lösung ist da — und sie ist hybrid

Die Algorithmen sind seit August 2024 standardisiert. Das NIST hat mit FIPS 203 ML-KEM veröffentlicht, ein gitterbasiertes Schlüsselaustauschverfahren, das nach heutigem Stand auch gegen Quantenrechner hält.

Entscheidend ist, wie man es einsetzt: hybrid. Das klassische Verfahren bleibt drin, das neue kommt obendrauf, und der Sitzungsschlüssel entsteht aus beiden. Fällt eines der beiden Verfahren, schützt das andere weiter. Das ist kein Zögern, sondern begründete Vorsicht — die neuen Verfahren sind deutlich jünger und weniger lange öffentlich angegriffen worden als RSA oder X25519. Das deutsche BSI empfiehlt aus genau diesem Grund den ausschliesslich hybriden Einsatz. Man handelt sich mit der Umstellung also kein neues Risiko ein, sondern legt eine zweite Schicht darüber.

In der Praxis heissen die Verfahren so — beides ist verfügbar, beides ist erprobt:

Wo es in der Praxis scheitert

Wenn Algorithmen und Standards fertig sind — warum ist die Umstellung dann Arbeit? Aus fünf Gründen, die alle nichts mit Kryptographie zu tun haben.

1. Niemand weiss, wo überall Krypto steckt. Nicht der Webserver ist das Problem, sondern das Backup, das nachts irgendwohin repliziert, der Monitoring-Agent, die Datenbankverbindung zwischen zwei Rechenzentren, das Gerät in der Fertigung mit dem Webinterface von 2014. Der schwierigste Teil einer PQ-Migration ist eine vollständige Inventarliste — nicht die Auswahl des Algorithmus.
2. Die Softwareversion entscheidet, nicht der Wille. ML-KEM gibt es in OpenSSH erst ab Version 9.9. Ubuntu 24.04 liefert 9.6 aus, Debian 13 hingegen OpenSSH 10. Wer den neuen Algorithmus fest in die Konfiguration schreibt, bringt damit jeden Server zu Fall, der ihn nicht kennt: Der Dienst verweigert den Start wegen eines unbekannten Namens in der Konfiguration. Bei einem SSH-Server ist das im ungünstigsten Fall der Verlust des Zugangs.
3. Alte Systeme können es nie. In fast jeder gewachsenen Umgebung steht ein System, dessen Software niemals eine PQ-fähige Version bekommen wird — weil die Anwendung darauf nicht migrierbar ist, weil der Hersteller nicht mehr existiert oder weil ein Zertifizierungsprozess daran hängt. Solche Systeme verschwinden nicht dadurch, dass man eine Richtlinie schreibt. Sie brauchen eine Einordnung: Was läuft darüber, wie lange noch, und welche Schutzschicht liegt in der Zwischenzeit davor?
4. Erzwingen bricht Dinge, die niemand auf dem Schirm hat. Wer die klassischen Verfahren abschaltet, sperrt nicht nur Angreifer aus, sondern auch jeden Client, der zu alt ist — den Backup-Agenten, den CI-Runner, das Monitoring. Diese Verbindungen fallen selten sofort auf. Sie fallen auf, wenn man das Backup braucht.
5. Die trügerischste Falle: PQ ist konfiguriert, wird aber nie benutzt. Client und Server einigen sich auf den ersten gemeinsamen Eintrag ihrer Algorithmenliste. Steht das PQ-Verfahren an dritter Stelle und ein klassisches davor, wird das klassische verwendet — jedes Mal. Die Konfiguration sieht korrekt aus, ein Prüfbericht meldet «vorhanden», und tatsächlich ist der Eintrag totes Gewicht. Nicht das Vorhandensein zählt, sondern die Reihenfolge.

Wie wir das lösen

Unsere eigene Infrastruktur läuft über automatisierte Härtungs-Baselines: Ein Skript setzt den Sicherheitsstand eines Servers, ein zweites misst ihn unabhängig davon nach. Der Leitsatz dahinter ist älter als das Quantenthema:

Härtung ohne Verifikation ist Hoffnung.

Wir haben einmal erlebt, dass eine vorbildlich aussehende Konfigurationsdatei überhaupt keine Wirkung hatte, weil eine andere Datei sie überstimmte. Seitdem prüfen wir nie, ob eine Einstellung irgendwo steht, sondern immer, was der Dienst tatsächlich tut.

Auf dieser Grundlage sieht unsere Umstellung so aus:

Die Algorithmenliste wird zur Laufzeit gebaut

Das Skript fragt den Server, welche Verfahren seine SSH-Version überhaupt kennt, und nimmt die beste verfügbare Kombination — ML-KEM, wo vorhanden, sonst das ältere hybride Verfahren. Ein Server mit Debian 13 bekommt damit automatisch ML-KEM, einer mit Ubuntu 24.04 läuft unverändert weiter, und beim nächsten Distributions-Upgrade zieht die Konfiguration von selbst nach. Ein Skript für alle Systeme, ohne Versionsabfragen, die jemand pflegen müsste. Lehnt der Dienst die neue Konfiguration trotzdem ab, wird sie automatisch zurückgerollt — bei einer SSH-Konfiguration ist das der Unterschied zwischen einem Warnhinweis und einem Serverausfall.

Geprüft wird die Reihenfolge, nicht die Anwesenheit

Der Prüflauf beanstandet es, wenn ein klassisches Verfahren vor dem PQ-Verfahren steht — genau die Falle aus Punkt 5.

Gegengeprüft wird, was wirklich passiert

Der Prüflauf baut eine echte Verbindung zum Dienst auf, die ausschliesslich das PQ-Verfahren zulässt, und wertet aus, worauf sich die beiden Seiten geeinigt haben. Nicht «keine Fehlermeldung» — das wäre wertlos, denn auch ein abgestürzter Dienst meldet keinen Fehler. Sondern die protokollierte Bestätigung, dass der Austausch tatsächlich post-quantum stattgefunden hat.

Der harte Schnitt ist ein Schalter, kein Standard

Die klassischen Verfahren ganz abzuschalten ist möglich, aber es ist eine bewusste Entscheidung pro System und nicht die Voreinstellung. Die richtige Reihenfolge ist: erst überall hybrid, dann messen, dann die verbleibenden alten Clients erheben — und erst danach abschalten.

Der grösste Hebel liegt nicht bei SSH

SSH-Verkehr läuft bei uns ausschliesslich in internen Netzen und über VPN. Wer ihn mitschneiden will, steht schon im Netz. Der Verkehr, der wirklich grossflächig eingesammelt werden kann, ist der öffentliche HTTPS-Verkehr am Rand des Netzes. Dort hängt die PQ-Fähigkeit an der Version der TLS-Bibliothek — bei den heute üblichen Container-Images liegt genau dazwischen die Grenze: Die eine Version kann es, die vorherige nicht. Der Weg dorthin führt also über einen Image-Aktualisierung und eine Zeile Konfiguration, nicht über ein Projekt.

Manches ist bereits sicher, ohne dass man es merkt

Unser Administrations-VPN nutzt WireGuard mit klassischem Schlüsselaustausch — aber mit einem individuellen Pre-Shared Key pro Gerät. Dieser Schlüssel geht nie über die Leitung, und er macht den Tunnel damit quantenresistent. Ein Detail aus dem Einrichtungsverfahren, das ursprünglich aus einem anderen Grund gesetzt wurde und heute zufällig genau richtig ist. Solche Punkte findet man nur, wenn man den Bestand systematisch durchgeht — was uns zurück zu Punkt 1 bringt.

Was wir empfehlen

Post-Quantum ist kein Projekt, das man startet und beendet, sondern eine Eigenschaft, die man in den Standard einbaut, mit dem Systeme aufgesetzt und überprüft werden. Wer heute anfängt, sollte in dieser Reihenfolge vorgehen:

1. Inventar aufnehmen. Welche Verbindungen tragen Daten, die in zehn Jahren noch schützenswert sind? Das ist die einzige Frage, die die Priorität bestimmt.
2. Aussenkanten zuerst. Alles, was über das offene Internet läuft, vor allem Internes.
3. Hybrid umstellen, nicht ersetzen. Der Schutz von heute bleibt erhalten.
4. Wirkung messen, nicht Konfiguration lesen. Die Reihenfolge der Algorithmen entscheidet, ob die Umstellung tatsächlich etwas bewirkt.
5. Alt-Systeme benennen. Was nie PQ-fähig wird, gehört auf eine Liste mit Ablaufdatum — und in der Zwischenzeit hinter zusätzliche Schutzschichten.
6. Erst am Ende erzwingen. Und dann mit einem Rückweg.

Der Aufwand für die ersten vier Punkte ist überschaubar, wenn die Umgebung automatisiert verwaltet wird. Bei uns waren es Ergänzungen an bestehenden Skripten, keine neue Infrastruktur.

Wir beraten und begleiten Unternehmen bei genau dieser Bestandsaufnahme und Umstellung — von der Inventarisierung über die Härtung der Systeme bis zur laufenden, automatisierten Überprüfung. Sprechen Sie uns an, wenn Sie wissen möchten, wie es um Ihre Verbindungen steht.