Hybride Kryptografie: Was passiert, wenn Ihr Lieferant den neuen Standard noch nicht unterstützt?

Ausgabe 14 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für Architekten von Verbindungen zwischen Unternehmen: Schnittstellen, Dateitransfer, Standortkopplungen.

Ihr Integrationsserver unterstützt seit dem letzten Update hybriden Schlüsselaustausch. Der Server Ihres slowenischen Lieferanten nicht. Was passiert? Nichts. Die Verbindung kommt zustande, wie immer, klassisch. Kein Fehler, keine Warnung, kein Eintrag im Monitoring. Genau das ist gewollt, und genau das ist das Problem: Sie wissen nicht, welche Ihrer Verbindungen schon hybrid laufen und welche nicht.

In diesem Beitrag: Was hybrid bedeutet · Beide Seiten müssen wollen · Bevorzugen oder verlangen · Was beim Einschalten schiefgehen kann · Beispiel · Wenn der Lieferant nicht kann · Ausfallszenarien · Wie lange hybrid · Die Frage an Ihren Lieferanten · Anhang: Matrix und Profilprüfung

Ein hybrides Verfahren kombiniert ein klassisches Verfahren mit einem Post-Quanten-Verfahren so, dass das Ergebnis sicher bleibt, solange eines der beiden ungebrochen ist. Im Schlüsselaustausch von TLS 1.3 heißt die verbreitete Kombination X25519MLKEM768: klassischer Austausch über elliptische Kurven plus ML-KEM-768 nach FIPS 203.

Warum nicht gleich nur das neue Verfahren? Weil Post-Quanten-Verfahren jung sind. Ihre Mathematik ist gut untersucht, ihre Implementierungen in Produkten sind es noch nicht so lange wie die der klassischen. Die Hybridlösung schützt gegen beide Risiken: gegen den künftigen Quantenrechner und gegen eine heute unentdeckte Schwäche im neuen Verfahren oder seiner Implementierung. Die EU-Roadmap vom Juni 2025 empfiehlt deshalb standardisierte und getestete hybride Lösungen, wo immer machbar; die Technische Richtlinie BSI TR-02102-1 empfiehlt Post-Quanten-Verfahren ebenfalls in Kombination mit klassischen.

Ein Schlüsselaustausch ist eine Verabredung. Der Client bietet an, was er kann, der Server wählt, was beide können. Daraus folgen drei Zustände für jede Verbindung:

Bei Verbindungen zu Lieferanten ist oft nicht einmal klar, wer Client und wer Server ist. Beim Dateitransfer holt mal Ihr System ab, mal liefert das des Lieferanten ein. Bei Schnittstellen ruft mal die eine, mal die andere Seite auf. Für jede Richtung gilt die Tabelle getrennt.

Wichtig: Die zweite und dritte Zeile sind kein Fehler. Sie sind das, wofür Protokolle wie TLS gebaut sind. Ein Fehler wäre nur, sie nicht zu bemerken.

Für jede Verbindung gibt es zwei mögliche Richtlinien:

• Bevorzugen: Hybrid wird angeboten und genutzt, wenn die Gegenseite es kann. Sonst klassisch. Keine Ausfälle, aber auch keine Garantie.
• Verlangen: Nur hybrid wird akzeptiert. Kann die Gegenseite es nicht, kommt keine Verbindung zustande.

In der Übergangszeit ist Bevorzugen fast immer richtig. Verlangen ist eine Entscheidung für einzelne Verbindungen mit hoher Schutzdauer, und nur, wenn feststeht, dass die Gegenseite bereit ist. Wer zu früh verlangt, produziert Ausfälle, und wer Ausfälle produziert, bekommt Druck, die Einstellung wieder zurückzunehmen.

Bevorzugen ohne Beobachtung ist allerdings keine Richtlinie, sondern Hoffnung. Dazu gehört, das tatsächlich ausgehandelte Verfahren je Verbindung zu protokollieren und regelmäßig auszuwerten.

Hybride Verfahren sind größer. Ein TLS-Verbindungsaufbau mit ML-KEM-Schlüsselanteil ist um rund ein Kilobyte länger. Bei der Einführung in verbreiteten Browsern im Jahr 2024 wurde sichtbar, dass manche Server und Netzwerkgeräte damit nicht zurechtkamen, wenn die erste Nachricht nicht mehr in ein einzelnes Netzwerkpaket passte. Solche Fehler zeigen sich als abgebrochene Verbindungen, nicht als verständliche Meldung.

Dazu kommen Versionsfragen. Frühe Implementierungen nutzten Vorabversionen des Verfahrens (Kyber), die mit dem endgültigen Standard ML-KEM nicht kompatibel sind. Zwei Systeme, die beide „Kyber“ oder „hybrid“ im Datenblatt stehen haben, verstehen sich deshalb nicht zwingend. Datenblätter sind geduldig.

Das heißt nicht, dass Sie warten sollten. Es heißt, dass Sie einschalten, beobachten und mit den wichtigsten Gegenstellen vorher testen sollten.

Nehmen Sie einen Hersteller von Medizintechnik in Hessen. Er aktiviert auf seinem Dateitransfer-Server und seinem API-Gateway hybriden Schlüsselaustausch mit der Richtlinie „bevorzugen“ und wertet nach vier Wochen die Protokolle aus:

Ein Abbruch, drei klassische Verbindungen, zwei hybride. Der Abbruch wird sofort behoben: Für diese eine Verbindung wird hybrid ausgeschaltet, bis der Lieferant sein Gerät aktualisiert. Die drei klassischen Verbindungen werden nicht als Fehler, sondern als offene Punkte mit Ansprechpartner und Termin erfasst.

Wenn eine Gegenseite noch keine hybriden Verfahren unterstützt, gibt es vier Wege, und alle sind legitim, wenn sie bewusst gewählt werden:

1. Abwarten mit Termin. Klassisch weiterbetreiben, mit dokumentiertem Risiko und vereinbartem Termin für die Umstellung.
2. Abschnitt verkürzen. Die Verbindung über einen Knoten führen, der hybrid kann, etwa ein VPN zwischen zwei Standorten, das den langen Weg über das Internet schützt. Dabei entsteht ein neuer Endpunkt mit eigener Verantwortung.
3. Daten zusätzlich schützen. Besonders schutzbedürftige Dateien vor dem Versand zusätzlich verschlüsseln. Das ist Schutz der Daten, nicht des Kanals, und braucht eine eigene Schlüsselverwaltung.
4. Verbindung ersetzen. Wenn ein Produkt keine Perspektive hat, kann der Austausch günstiger sein als jede Übergangslösung.

Welcher Weg passt, hängt von der Schutzdauer der Daten ab (Ausgabe 02), nicht davon, wie unangenehm das Gespräch mit dem Lieferanten ist.

Bevor Sie für eine Verbindung „verlangen“ einstellen, sollten drei Fragen beantwortet sein:

• Was passiert, wenn die Verbindung nicht zustande kommt? Welche Geschäftsprozesse stehen still, und wie schnell fällt es auf?
• Wer darf zurückschalten? Ein Zurückschalten auf „bevorzugen“ ist eine Sicherheitsentscheidung, keine reine Betriebsmaßnahme. Sie braucht eine Zuständigkeit und eine Dokumentation.
• Wie erfährt die Gegenseite davon? Ein Lieferant, dessen Lieferungen plötzlich abgewiesen werden, braucht eine verständliche Meldung und einen Ansprechpartner.

Hybrid ist eine Übergangsform, aber eine lange. Die EU-Roadmap empfiehlt, quantenverwundbare Public-Key-Verfahren für Anwendungsfälle mit hohem Risiko nach Ende 2030 nicht mehr allein einzusetzen, für mittleres Risiko nach Ende 2035. „Nicht allein“ heißt: in hybrider Kombination bleiben sie zulässig. Für die Planung mit Lieferanten bedeutet das:

• Kein Wettlauf um reine Post-Quanten-Verfahren. Wer heute auf hybrid umstellt, muss in absehbarer Zeit nicht ein zweites Mal umstellen, nur um den klassischen Teil zu entfernen.
• Klassisch allein hat ein Ablaufdatum. Verbindungen, die für Ihr Risiko „hoch“ eingestuft sind, sollten bis Ende 2030 nicht mehr klassisch allein ausgehandelt werden. Das ist der Termin, auf den Sie Gespräche mit Lieferanten ausrichten können.
• Die Einstufung machen Sie. Ob eine Lieferantenverbindung hohes Risiko trägt, entscheidet Ihre Risikoanalyse, nicht der Lieferant und nicht der Hersteller des Gateways.

„Welche Verfahren bietet Ihr System für unsere Verbindung heute an, in welcher Richtung ist Ihr System Client und in welcher Server, und können wir vor einer Umstellung gemeinsam einen Test vereinbaren?“

Die Frage berücksichtigt, dass beide Seiten den Ausgang bestimmen, und bietet einen gemeinsamen Test an, statt eine Umstellung anzukündigen.

Die slowenische Ausgabe richtet sich an Netzwerkfachleute und Entwickler beim Lieferanten: »ML-KEM ni čarobna zamenjava za RSA.« (auf Slowenisch). Vorherige Ausgabe: Kryptoagilität: Können Ihre Dienstleister Algorithmen austauschen, ohne Geschäftsprozesse umzubauen?

Seit dieser Ausgabe ist die hybride Schlüsseleinigung für TLS 1.3 als RFC 10024 erschienen (August 2026). Den gepflegten Stand der Fristen und Standards finden Sie unter BSI TR-02102 und Post-Quanten-Fristen.

Interoperabilitätsmatrix (je Verbindung und Richtung eine Zeile). In der slowenischen Ausgabe inhaltlich gleich.

Profilprüfung: Was ist für welches Protokoll zu prüfen? Stand August 2026; die Bezeichnungen können sich mit der Standardisierung ändern.

Alle erschienenen Ausgaben der Reihe: Übersicht „Post-Quanten-Sicherheit in der Lieferkette“

Nächste Ausgabe (7. 9. 2026): „Ihr Altsystem funktioniert. Aber ist es bis 2030 noch migrationsfähig?“

Quellen (Stand 3. 8. 2026): NIST FIPS 203 (August 2024); IETF Internet-Draft draft-ietf-tls-ecdhe-mlkem; RFC 9370 (Mai 2023); RFC 9881 (Oktober 2025); OpenSSH 10.0 Release Notes (April 2025); NIS Cooperation Group, „A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“, Version 1.1 (Juni 2025); BSI TR-02102-1 in der zum Stichtag gültigen Fassung.

Wenn Sie wissen wollen, welche Ihrer Lieferantenverbindungen schon hybrid laufen: Schreiben Sie uns.