Der verschlüsselte Kanal allein macht Ihre Lieferantenanbindung nicht quantensicher

Ausgabe 11 der Reihe „Post-Quanten-Sicherheit in der deutsch-slowenischen Lieferkette“. Für Netzwerk- und Integrationsarchitekten sowie alle, die Anforderungen an Lieferantenanbindungen formulieren.

Der Dienstleister meldet Vollzug: „Ihr Lieferantenportal unterstützt jetzt hybriden Schlüsselaustausch mit ML-KEM.“ Die Verbindung vom Browser des slowenischen Lieferanten bis zum Content-Delivery-Netz ist damit auf dem Stand der Technik. Vom Content-Delivery-Netz zum Rechenzentrum läuft sie über eine zweite TLS-Verbindung, klassisch. Von dort zum Integrationsserver über eine dritte. Die Bestellung, die der Lieferant hochlädt, liegt außerdem eine Nacht lang unverschlüsselt im Eingangsordner.

In diesem Beitrag: Ein Kanal besteht aus Abschnitten · Wo Verschlüsselung endet · Was heute schon hybrid möglich ist · Was ein Kanal nicht schützt · Beispiel · Anforderungen je Abschnitt · Messen statt annehmen · Typische Fehlannahmen · Die Frage an Ihren Lieferanten · Anhang: Abschnitte

Auf dem Architekturbild ist die Lieferantenanbindung ein Pfeil: links der Lieferant, rechts Ihr ERP-System, darüber ein Schloss. Technisch ist dieser Pfeil eine Kette. Jede Komponente, die eine verschlüsselte Verbindung annimmt, entschlüsselt sie und baut, wenn nötig, eine neue auf.

Für die Post-Quanten-Planung folgt daraus eine einfache Regel: Jeder Abschnitt hat seinen eigenen Schlüsselaustausch. Ein Angreifer, der heute mitschneidet, um später zu entschlüsseln, sucht sich den Abschnitt aus, der noch klassisch verhandelt. Dass ein anderer Abschnitt hybrid geschützt ist, hilft ihm nicht und Ihnen nicht.

Die Frage ist also nicht „Ist die Verbindung quantensicher?“, sondern: „Welche Abschnitte gibt es, wer betreibt sie, und was wird auf jedem verhandelt?“

Typische Punkte, an denen eine Verbindung endet und eine neue beginnt:

• Content-Delivery-Netze und Web Application Firewalls vor dem Portal. Oft von einem Dienstleister betrieben, mit eigener Konfiguration.
• Lastverteiler und Reverse Proxies am Rand des Rechenzentrums.
• API-Gateways, die Anfragen prüfen, umschreiben und weiterleiten.
• Managed-File-Transfer-Server in der DMZ, die Dateien per SFTP oder HTTPS annehmen und intern weiterreichen.
• VPN-Konzentratoren für Standortverbindungen und Servicezugänge.
• Proxies mit TLS-Inspektion, die ausgehenden Verkehr aufbrechen, um ihn zu prüfen.
• Nachrichtenbroker und Integrationsplattformen zwischen DMZ und Kernsystemen.

An jedem dieser Punkte liegen die Daten im Klartext im Speicher der Komponente. Jeder dieser Punkte ist eine Vertrauensgrenze: Wer die Komponente betreibt, kann die Daten sehen, und wer sie konfiguriert, bestimmt den Schlüsselaustausch des nächsten Abschnitts.

Für den Schlüsselaustausch gibt es in den wichtigsten Protokollen hybride Verfahren, die ein klassisches mit einem Post-Quanten-Verfahren kombinieren:

• TLS 1.3: Die Gruppe X25519MLKEM768 ist in der IETF als Entwurf spezifiziert (draft-ietf-tls-ecdhe-mlkem). Aktuelle Browser verhandeln sie, OpenSSL unterstützt sie seit Version 3.5 (April 2025). TLS 1.2 kennt keinen solchen Mechanismus.
• SSH: OpenSSH verwendet seit Version 10.0 (April 2025) standardmäßig einen hybriden Schlüsselaustausch mit ML-KEM, sofern beide Seiten ihn kennen.
• IPsec/IKEv2: RFC 9370 (Mai 2023) erlaubt mehrere aufeinanderfolgende Schlüsselaustausche; die Unterstützung hängt stark vom Hersteller und der Firmware ab.

Entscheidend ist der letzte Halbsatz jedes Punktes: Verhandelt wird, was beide Seiten können. Ein moderner Client an einem Gateway mit älterer Software verhandelt klassisch, ohne Fehlermeldung.

Ein Post-Quanten-geschützter Kanal ist wertvoll, aber er schützt genau eines: die Daten während der Übertragung über diesen Abschnitt. Nicht geschützt sind:

• Daten an den Endpunkten der Abschnitte: Eingangsordner des Dateitransfers, Warteschlangen, Zwischenspeicher, Protokolldateien mit Nutzdaten.
• Gespeicherte Daten in Datenbanken, Archiven und Sicherungen. Deren Schutz ist ein eigenes Thema.
• Die Identität der Gegenseite. Wer mit wem spricht, entscheidet die Authentisierung mit Zertifikaten oder Schlüsseln, nicht der Schlüsselaustausch.

Wer „Kanal geschützt“ mit „Daten geschützt“ gleichsetzt, übersieht genau die Stellen, an denen Daten am längsten liegen. Ein Eingangsordner, in dem Konstruktionsdaten eine Nacht verbringen, ist für einen späteren Angreifer interessanter als jede Sekunde der Übertragung: Er muss dort nichts mitschneiden, er muss nur einmal Zugriff bekommen.

Zum Beispiel ein Maschinenbauer in Baden-Württemberg: Er bindet einen slowenischen Zulieferer über drei Wege an:

Der Dienstleister hatte recht: Das Portal ist am äußeren Abschnitt hybrid. Für die Konstruktionsdaten, die über den Dateitransfer laufen und zehn Jahre vertraulich bleiben müssen, hat das keine Wirkung. Der wichtigste Abschnitt ist der, an den niemand gedacht hat: der SFTP-Server in der DMZ, betrieben vom eigenen Team, seit Jahren nicht aktualisiert. Er lief ja zuverlässig.

Eine Anforderung an einen Lieferanten oder Dienstleister lautet oft: „Die Verbindung muss quantensicher verschlüsselt sein.“ Sie ist nicht erfüllbar, weil niemand für „die Verbindung“ zuständig ist. Zuständig ist man für Abschnitte.

Eine brauchbare Anforderung benennt deshalb:

• den Abschnitt mit beiden Endpunkten;
• den Betreiber jedes Endpunkts;
• das Ziel (zum Beispiel hybrider Schlüsselaustausch für TLS 1.3) und den Termin;
• den Nachweis (zum Beispiel ein Mitschnitt oder Protokolleintrag des verhandelten Verfahrens);
• was mit Daten an den Endpunkten geschieht (Verweildauer, Verschlüsselung, Löschung).

Für Abschnitte, deren beide Endpunkte bei Ihnen liegen, brauchen Sie keine Anforderung an den Lieferanten. Sie brauchen einen eigenen Plan. Im Schema im Anhang liegen zwei von vier Abschnitten ganz bei Ihnen.

Eine Formulierung, die ein Lieferant prüfen und erfüllen kann, könnte so aussehen: „Für den Dateitransfer (Abschnitt B: SFTP-Client des Lieferanten zu MFT-Server des Auftraggebers) unterstützt der SFTP-Client des Lieferanten bis 31. 12. 2027 den hybriden Schlüsselaustausch mlkem768x25519-sha256. Der Auftraggeber stellt die Unterstützung auf seinem Server bis 30. 9. 2027 bereit. Der Nachweis erfolgt durch einen Protokolleintrag des Servers.“ Die Formulierung ist ein Beispiel, keine Vertragsklausel; Termine und Verfahren legen Sie selbst fest.

Eine Zusage „unterstützt ML-KEM“ sagt nichts darüber, was im Betrieb verhandelt wird. Messen Sie deshalb jeden Abschnitt dort, wo der Produktivverkehr läuft:

• TLS: Ab OpenSSL 3.5 zeigt openssl s_client die verhandelte Gruppe. Viele Gateways und Lastverteiler können sie protokollieren, wenn man es einschaltet.
• SSH: ssh -v gibt das verhandelte Schlüsselaustauschverfahren aus; der Server protokolliert es auf entsprechender Protokollstufe.
• IPsec: Status der Sicherheitsverbindungen am VPN-Gerät.

Eine Messung vom Arbeitsplatz des Architekten aus misst einen anderen Abschnitt als den, über den die Daten laufen. Und eine einmalige Messung veraltet mit dem nächsten Update eines Gateways. Wo möglich, gehört das verhandelte Verfahren in die laufende Protokollierung.

• „Wir haben TLS, also ist es verschlüsselt.“ Ja, auf diesem Abschnitt. Welche anderen gibt es?
• „Der Browser zeigt ML-KEM, also ist alles hybrid.“ Der Browser sieht nur den ersten Abschnitt.
• „Das VPN schützt alles dahinter.“ Es schützt den Tunnel. Was am Ende des Tunnels geschieht, ist eine andere Frage.
• „Der Lieferant muss das umstellen.“ Häufig liegen beide Enden des kritischen Abschnitts bei Ihnen.

„Über welche Abschnitte laufen Ihre Daten bis zu unserem Endpunkt, welche Endpunkte betreiben Sie selbst, und welche Verfahren verhandeln Ihre Systeme dort heute?“

Die Frage verlagert das Gespräch vom Pfeil auf die Kette. Sie zeigt dem Lieferanten, dass Sie die eigenen Abschnitte kennen, und fragt nur nach seinen.

Die slowenische Ausgabe richtet sich an Netzwerk- und Systemverantwortliche beim Lieferanten: »TLS, VPN, API Gateway: kje se vaša kriptografska zaščita dejansko konča?« (auf Slowenisch). Vorherige Ausgabe: Ihre Zertifikate laufen ab. Ihre Vertrauensarchitektur bleibt.

Schema einer Lieferantenanbindung (vereinfacht, für den Dateitransfer). Jede senkrechte Linie ist eine Vertrauensgrenze; jeder Abschnitt dazwischen hat einen eigenen Schlüsselaustausch. In der slowenischen Ausgabe inhaltlich gleich.

 LIEFERANT                 |  INTERNET  |        AUFTRAGGEBER
                           |            |
 [ERP] --A--> [MFT-Client] ===== B =====> [MFT-Server DMZ] --C--> [Integration] --D--> [ERP]
                           |            |        |
                           |            |   (Eingangsordner:
                           |            |    Daten im Ruhezustand)

Tabelle der Abschnitte zum Ausfüllen:

Zu jedem Endpunkt ergänzen: Verweildauer der Daten, Verschlüsselung im Ruhezustand, Zugriff durch Dritte (Dienstleister, Cloud-Betreiber), Protokollierung von Nutzdaten.

Lesart: Abschnitt B ist der einzige, über den Sie mit dem Lieferanten verhandeln müssen. A liegt bei ihm, C und D bei Ihnen.

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

Nächste Ausgabe (1. 6. 2026): „PQC-Migration: Welche Systeme zuerst – und wer bezahlt?“

Quellen (Stand 4. 5. 2026): IETF Internet-Draft draft-ietf-tls-ecdhe-mlkem, Revision 04 (Februar 2026); OpenSSL 3.5 Release Notes (April 2025); OpenSSH 10.0 Release Notes (April 2025); RFC 9370 „Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)“ (Mai 2023); NIST FIPS 203 (August 2024).

Wenn Ihr Architekturbild einen Pfeil zeigt, wo eine Kette ist: Schreiben Sie uns.