Kryptographie und Post-Quanten-Übergang

Zusammenfassung. WKL TrustBridge setzt auf hybride Kryptographie: klassische Verfahren für die Verträglichkeit mit bestehenden Gegenstellen, ML-DSA (FIPS 204) als Post-Quanten-Signatur. Ein hybrides Zertifikat trägt beide Signaturen; klassische Prüfer lesen es unverändert, PQ-fähige Prüfer prüfen beide. Für die Verbindungen zwischen Partnern kommt ML-KEM (FIPS 203) zweimal zum Einsatz: in der hybriden Gruppe von TLS 1.3 und im unabhängigen Schlüsselaustausch der Schlüsselagenten. Kryptoagilität wird über CA-Generationen umgesetzt, nicht über Umschaltungen zur Laufzeit. Maßstab für alle Verfahren und Parametersätze ist BSI TR-02102 in der Fassung 2026-01.

• ML-KEM – Module-Lattice-Based Key-Encapsulation Mechanism (FIPS 203): Verfahren, mit dem zwei Parteien ein gemeinsames Geheimnis vereinbaren. FIPS 203 definiert ML-KEM-512, -768 und -1024; das BSI empfiehlt davon nur ML-KEM-768 und ML-KEM-1024 (Sicherheitskategorien 3 und 5).
• ML-DSA – Module-Lattice-Based Digital Signature Algorithm (FIPS 204). FIPS 204 definiert ML-DSA-44, -65 und -87; das BSI empfiehlt davon nur ML-DSA-65 und ML-DSA-87, jeweils in der Variante „hedged“ (Signatur mit zusätzlichem Zufall statt rein deterministisch).
• SLH-DSA – zustandsloses hashbasiertes Signaturverfahren (FIPS 205); konservative Annahmen, große Signaturen.
• Hybrid – Kombination eines klassischen und eines PQ-Verfahrens. Welche Sicherheit daraus folgt, hängt von der Konstruktion und davon ab, was die Gegenstelle prüft (siehe unten).
• Kryptoagilität – die Fähigkeit, Verfahren geplant und ohne Bruch zu wechseln.

Zwei Bedrohungen sind zu unterscheiden:

TrustBridge adressiert beide. Gegen die erste schützen die hybride TLS-Gruppe und das zusätzliche Geheimnis der Schlüsselagenten, siehe PQ-Schlüsselaustausch für TLS. Gegen die zweite schützen hybride Zertifikate. Ihr kritischer Pfad sind die Vertrauensanker: Eine Wurzel, die heute klassisch erzeugt wird und zwanzig Jahre gelten soll, wäre bei einem Quantencomputer vor ihrem Ablauf wertlos, und mit ihr jede Kette darunter.

Warum hybrid statt nur PQ. ML-DSA ist jung; seine Implementierungen haben weniger Betriebsjahre als RSA oder ECDSA hinter sich, und Fehler in Implementierungen wiegen erfahrungsgemäß schwerer als Schwächen der Mathematik. Eine Kombination beider Verfahren schützt gegen den Ausfall eines von ihnen – aber nur, wenn die Gegenstelle beide Signaturen prüft und eine fehlende als Fehler wertet. Das BSI empfiehlt PQ-Verfahren deshalb in Kombination mit klassischen. Zugleich bleibt ein hybrides Zertifikat für Gegenstellen ohne PQ-Unterstützung lesbar.

Maßstab ist BSI TR-02102-1 in der Fassung 2026-01. Sie empfiehlt für die Schlüsseleinigung nur ML-KEM-768 und ML-KEM-1024 (Abschnitt 2.4.3, Tabelle 2.7) und für Signaturen nur ML-DSA-65 und ML-DSA-87 in der Variante „hedged“ (Abschnitt 5.3.4.2, Tabelle 5.7), Post-Quanten-Verfahren jeweils in Kombination mit einem klassischen Verfahren. TrustBridge bietet deshalb nur diese Parametersätze an, und nur hybrid.

ML-DSA-44 und ML-KEM-512 erfüllen diese Empfehlung nicht. In Profilen, Zertifikaten, Anträgen und Beziehungen sind sie nicht zulässig; ein CSR mit einem solchen Schlüssel wird abgelehnt.

Der Bezeichner einer PQ-Signatur folgt den standardisierten Kennungen aus RFC 9881.

graph LR
  %% LR: Die Felder des Zertifikats stehen so untereinander, von oben nach unten wird das Diagramm mehr als doppelt so breit.
  CA[CA mit klassischem<br/>und ML-DSA-Schlüssel<br/>im Sicherheitsmodul]
  subgraph CERT [Zertifikat]
    subgraph TBS [Signierter Teil]
      SUB[Subjekt, Seriennummer, Laufzeit]
      SPK[Klassischer öffentlicher Schlüssel]
      ALTK[subjectAltPublicKeyInfo 2.5.29.72<br/>ML-DSA-Schlüssel]
      ALTA[altSignatureAlgorithm 2.5.29.73]
      ALTV[altSignatureValue 2.5.29.74<br/>ML-DSA-Signatur der CA]
      EXT[übrige Erweiterungen]
    end
    SIG[Klassische Signatur der CA<br/>über den gesamten signierten Teil]
  end
  CA ==>|1. ML-DSA über den signierten Teil<br/>ohne altSignatureValue| ALTV
  CA ==>|2. klassisch über alles| SIG
  classDef pq fill:#dff6dd,stroke:#107c10,color:#201f1e
  classDef kl fill:#deecf9,stroke:#0078d4,color:#201f1e
  classDef neu fill:#f3f2f1,stroke:#605e5c,color:#201f1e
  classDef tcb fill:#fde7e9,stroke:#a4262c,color:#201f1e
  class ALTK,ALTA,ALTV pq
  class SPK,SIG kl
  class SUB,EXT neu
  class CA tcb
  style CERT fill:#ffffff,stroke:#8a8886,color:#201f1e
  style TBS fill:#ffffff,stroke:#8a8886,color:#201f1e

Zwei Ebenen der Aussage.

Im Unterschied dazu binden Composite-Signaturen (IETF-Entwurf) beide Signaturen untrennbar unter einem neuen Algorithmus; klassische Prüfer lehnen solche Zertifikate ab. TrustBridge stellt hybride Zertifikate mit Alternativsignatur aus, damit bestehende Gegenstellen sie weiter lesen können, und gleicht die Trennbarkeit mit der PQ-Pflicht je Beziehung aus.

Grenze. Die Alternativsignatur ist trennbar. Wer künftig die klassische Signatur fälschen kann, kann ein Zertifikat ohne PQ-Erweiterungen herstellen, das ein Prüfer ohne PQ-Pflicht annimmt. Der PQ-Schutz wirkt also erst, wenn Gegenstellen ihn verlangen. Der TLS-Adapter verlangt ihn, sobald die Beziehungsrichtlinie es vorsieht. Ein Antrag für ein hybrides Zertifikat muss den Besitz beider privaten Schlüssel nachweisen.

Kryptoagilität heißt hier nicht, Verfahren zur Laufzeit umzuschalten, sondern den Wechsel geplant zu haben:

1. Neue Generation statt Umschlüsselung. Ein neues Verfahren bedeutet eine neue CA mit neuem Schlüssel und neuem Zertifikat. Ein bestehender Schlüssel wird nicht neu zertifiziert.
2. Überlappung. Gegenstellen erhalten den neuen Anker, bevor die erste Ausstellung unter der neuen Generation erfolgt.
3. Auslaufen. Die alte Generation stellt nicht mehr aus, sobald ihre Restlaufzeit die längste Profillaufzeit unterschreitet, und signiert danach nur noch Sperrlisten.

gantt
  title Ablösung einer klassischen durch eine hybride Generation (schematisch)
  dateFormat YYYY-MM-DD
  axisFormat %Y
  section Klassische Generation
  stellt aus             :a1, 2027-01-01, 2028-06-30
  nur Sperrlisten        :a2, after a1, 365d
  section Hybride Generation
  Anker verteilt         :b0, 2027-07-01, 180d
  stellt aus             :b1, 2028-01-01, 2031-12-31

Migration bestehender klassischer Anker einer Organisation: Bestandsaufnahme der Gegenstellen und ihrer PQ-Fähigkeit; Verteilung des hybriden Ankers zusätzlich zum alten; Ausstellung neuer Zertifikate nur noch hybrid; Vereinbarung von PQ-Pflicht je Beziehung, sobald beide Seiten prüfen können; Rückzug des alten Ankers nach Ablauf aller Zertifikate darunter.

Abhängigkeit vom Sicherheitsmodul. Hybride CAs setzen ein Sicherheitsmodul voraus, das ML-DSA nicht exportierbar erzeugt und verwendet. Einen Software-Schlüssel für eine CA gibt es auch nicht als Übergang.

Heterogene Implementierungen. Die Zertifizierungsstelle bleibt bei einer einzigen Grundlage, weil jede zusätzliche Bibliothek in der Vertrauensbasis den Prüfaufwand vervielfacht. Die Endpunktkomponenten verwenden bewusst eine andere TLS-Implementierung: Das zusätzliche Geheimnis ist damit auch in der Implementierung unabhängig von der Kryptographie der Zertifizierungsstelle.

Prüfung gegen Normvektoren. Jede Fassung prüft ML-DSA und ML-KEM gegen die veröffentlichten Prüffälle aus FIPS 203 und FIPS 204, einschließlich fehlerhafter Schlüssel und veränderter Kontextzeichenketten. Der Parametersatz eines Schlüssels wird aus seiner Objektkennung gelesen, nicht aus seiner Länge erschlossen.

Jedes Modul, das diese Abnahme besteht, ist für TrustBridge zulässig. Ein Software-Modul ist für CA-Schlüssel ausgeschlossen und nur für Test- und Schulungsumgebungen vorgesehen.

• Kein bestimmtes Sicherheitsmodul. Die Anforderungen und die Abnahmeprüfung stehen oben.
• Keine Composite-Signaturen. TrustBridge verwendet die trennbare Alternativsignatur, damit klassische Gegenstellen Zertifikate weiter lesen können.
• Keine Verfahren außerhalb der Empfehlung von BSI TR-02102, auch nicht auf Wunsch einzelner Partner.

• FIPS 203 – ML-KEM.
• FIPS 204 – ML-DSA.
• RFC 9881 – Kennungen für ML-DSA in X.509.
• RFC 10024 – hybride Schlüsseleinigung aus ECDHE und ML-KEM für TLS 1.3.
• BSI TR-02102 – TR-02102-1 und TR-02102-2, Fassung 2026-01.
• PKCS #11 Version 3.2 – Mechanismen für ML-DSA und ML-KEM.