Die TLS-Infrastruktur und X.509-Zertifikate treten in ein neues Zeitalter ein – das postquantische Zeitalter. NIST-Algorithmen (ML-KEM und ML-DSA) und hybride Zertifikate verändern die Art und Weise, wie wir Schlüssel generieren, CSR erstellen und TLS-Handshakes durchführen. Der bisher einfache CSR wird heute zu einem kritischen Element: Er muss konform mit den neuen Anforderungen des CA/B Forum sein, moderne Algorithmen unterstützen und eine korrekte ASN.1-, SPKI-, Erweiterungs- und Composite-Struktur-Kodierung sicherstellen.

In der Praxis bedeutet dies, dass hybride Zertifikate einen klassischen Schlüssel (ECDSA/RSA) mit einem postquantischen Schlüssel kombinieren und der TLS-Handshake zwei unabhängige kryptografische Geheimnisse generiert, die zu einem gemeinsamen Sitzungsschlüssel zusammengeführt werden. Dies bietet Widerstandsfähigkeit gegen zukünftige Quantenangriffe und vollständige Kompatibilität mit heutigen Clients. Es erzwingt jedoch ein Update der Bibliotheken auf OpenSSL 3.x, die Vorbereitung von DevOps/ACME-Umgebungen und die Überprüfung, ob die Infrastruktur mit größeren DER- und SPKI-Strukturen zurechtkommt.

In den kommenden Jahren werden PQC-ready-Zertifikate zum globalen Standard werden. Unternehmen, die sich jetzt darauf vorbereiten – indem sie hybride Zertifikate testen, TLS-Bibliotheken modernisieren und Automatisierungsprozesse aktualisieren – vermeiden das Risiko, dass ihre Umgebung nicht mehr konform mit den neuen Anforderungen des Internets ist.

Grundlagen von X.509 und die Entstehung der Vertrauensinfrastruktur.

Als in den neunziger Jahren das TLS-Protokoll entstand, ahnten nur wenige voraus, dass es zur Grundlage der gesamten digitalen Wirtschaft werden würde. Zu dieser Zeit wuchs das Internet dynamisch, hatte aber eine völlig andere Struktur als heute: wenige dynamische Anwendungen, keine massenhafte Virtualisierung, keine Cloud, und die meisten Websites waren statisch, ohne Notwendigkeit für Verschlüsselung. Die ersten Versionen von SSL entstanden unter der Annahme, dass ihre Hauptrolle darin bestehen würde, Vertraulichkeit in der Kommunikation zwischen Browser und Webserver zu gewährleisten. Die Struktur des X.509-Zertifikats, die aus früheren Systemen übernommen wurde, war konservativ und hierarchisch: ein öffentlicher Schlüssel, eine Signatur und Vertrauen, das durch eine Zertifikatskette aufgebaut wurde, deren oberstes Element der Root CA war. Dennoch erwiesen sich die damals geschaffenen Grundlagen als überraschend langlebig. X.509 hat in praktisch unveränderter Form über drei Jahrzehnte überdauert – bis ins Jahr 2025.

Der Kern dieser Langlebigkeit lag in der strukturellen Einfachheit. Ein X.509-Zertifikat war ein ASN.1-Objekt, in dem das Feld subjectPublicKeyInfo genau einen Algorithmus und den von ihm bereitgestellten öffentlichen Schlüssel beschrieb. Dieses Feld, gekennzeichnet als Sequenz, enthielt eine Algorithmus-Kennung in Form einer OID und den rohen öffentlichen Schlüssel, kodiert als BIT STRING. In den neunziger Jahren bezog sich die Algorithmus-Kennung ausschließlich auf RSA, da es keine wirkliche Notwendigkeit gab, etwas anderes zu unterstützen. RSA dominierte, weil es eine natürliche Kombination aus Sicherheit und Implementierungsleichtigkeit darstellte: relativ einfache Mathematik, ein klarer Sicherheitsgrad resultierend aus der Schwierigkeit der Faktorisierung und breite Adoption in Bibliotheksimplementierungen. Infolgedessen wurde das X.509-Zertifikat nicht aufgrund einer bewussten architektonischen Entscheidung, sondern weil niemand die Notwendigkeit erwartete, mehr als einen Schlüssel darin unterzubringen, zu einem Einzelalgorithmus-Format.

Das nächste Jahrzehnt brachte eine dynamische Entwicklung des Internets, änderte aber nicht die grundlegende Architektur von TLS. Die Verbreitung von E-Commerce, Online-Banking und SaaS-Diensten machte SSL-Zertifikate unerlässlich, doch das Zertifikatsformat selbst blieb statisch. Selbst die Einführung elliptischer Kurven änderte nicht seine grundlegende Struktur: Im SPKI-Feld wurde nach wie vor ein einzelner öffentlicher Schlüssel gespeichert. Der Algorithmuswechsel bestand im Wesentlichen im Austausch der OID und einem anderen Inhalt des BIT STRING, aber die Dokumentstruktur blieb unverändert. Das Ökosystem entwickelte sich weiter, aber seine Grundlagen waren untrennbar mit den Annahmen aus der Zeit vor Cloud, IoT oder mobilem Internet verbunden.

Das Problem, das über die Jahre wuchs, war, dass X.509 – obwohl solide – nicht mit Blick auf Widerstandsfähigkeit gegen eine völlig neue Klasse von Bedrohungen entworfen wurde. Quantencomputer existierten einst nur als theoretische Konstrukte. Dass sie eines Tages RSA und ECDSA brechen könnten, war Mathematikern und Kryptografen bekannt, aber es hatte keine praktische Bedeutung. Erst nach der Veröffentlichung konkreter Ergebnisse zur Implementierung von Shors Algorithmus auf immer größeren Registern begann man zu verstehen, dass die Bedrohung real ist. Und wenn sie real ist, dann könnte jedes heute ausgestellte Zertifikat in der Zukunft nutzlos werden. Schlimmer noch, selbst wenn ein Quantencomputer noch nicht in der Lage ist, RSA zu brechen, könnte er heute TLS-Datenverkehr abfangen und speichern, um ihn in der Zukunft zu entschlüsseln. Dies änderte alles. Die Vertrauensinfrastruktur hörte auf, resistent gegen „Harvest-now, decrypt-later“-Angriffe zu sein.

An der Wende von 2018-2021 begannen große Organisationen – von Google bis Cloudflare – immer deutlicher über die Notwendigkeit des Übergangs zu postquantischen Algorithmen zu sprechen. Das Problem dabei war, dass die Migration der gesamten X.509-Struktur auf neue Algorithmen praktisch unmöglich war. Die Unterstützung für PQC in Browsern, Mobilgeräten, IoT-Sets und Kryptografie-Bibliotheken war und ist immer noch sehr begrenzt. Wenn Browser plötzlich PQC-Zertifikate erfordern oder CAs sie standardmäßig ausstellen würden, würde ein enormer Teil des Internets aufhören zu funktionieren. Es musste eine Lösung gefunden werden, die gleichzeitig Widerstandsfähigkeit gegen Quantencomputer bietet, aber nicht die Kompatibilität mit dem Ökosystem zerstört, das sich über drei Jahrzehnte entwickelt hatte.

So entstand die Idee hybrider Zertifikate – Konstruktionen, die RSA oder ECDSA nicht ersetzen, sondern ihnen einen zweiten, postquantischen öffentlichen Schlüssel hinzufügen. Diese beiden Werte bilden eine SPKI-Struktur, die zwei Welten der Kryptografie repräsentiert. Ein hybrides Zertifikat ist noch kein vollständig postquantisches Zertifikat. Es ist ein Übergangszertifikat, eine Brücke zwischen den Epochen. Es gewährleistet Kompatibilität mit Geräten, die nur klassische Algorithmen verstehen, ermöglicht aber gleichzeitig PQC-fähigen Clients, Sitzungen sicher aufzubauen, die resistent gegen zukünftige Quantenangriffe sind. Um zu verstehen, warum hybride Zertifikate so fundamental sind, muss man zur eigentlichen Architektur von X.509 zurückkehren. Das gesamte Vertrauenssystem in TLS basiert auf einer Zertifikatskette. Jedes Zertifikat ist mit einem übergeordneten Schlüssel signiert, und die Kette endet mit einem Zertifikat vom Typ Root, das im vertrauenswürdigen Speicher des Browsers oder Betriebssystems verankert ist. Dieses Modell gewährleistet trotz seiner Einfachheit hohe Flexibilität: Es ermöglicht klassische EV-, DV-, OV-Ketten, Cross-Signed-Zertifikate, Intermediate-Zertifikate in der Cloud und viele andere Konstruktionen. Das hybride Zertifikat muss im selben Ökosystem funktionieren wie das klassische Zertifikat. Root CAs können nicht ausgetauscht werden – zumindest nicht kurzfristig – weil das Ökosystem Milliarden von Geräten und Millionen von Anwendungen umfasst. Daher basiert das Hybrid-Design darauf, die klassische X.509-Struktur beizubehalten und zu erweitern, anstatt sie zu ersetzen.

Die größte Herausforderung aus Sicht der Zertifikatskonstruktion ist, dass X.509 nicht als Multi-Algorithmus-Container entworfen wurde. Als 1999 RFC 2459 entstand, haben die Entwickler nicht vorhergesehen, dass das SPKI-Feld jemals mehr als einen Schlüssel speichern müsste. Die Struktur war ausreichend für RSA, später ECDSA und sogar EdDSA. Aber die Notwendigkeit, mehrere Algorithmen gleichzeitig zu kodieren, wurde nicht vorhergesehen. Daher ist Composite-SPKI eine so bedeutende Revolution: In einem BIT STRING müssen zwei unabhängige öffentliche Schlüssel platziert werden, und die OID muss anzeigen, dass diese Struktur eine zusammengesetzte Konstruktion ist. Dies stellt den fundamentalen Ausgangspunkt für die weiteren Teile des Artikels dar. Damit hybride Zertifikate existieren können, musste eine völlig neue Architektur für public_key, eine neue Architektur für Signaturen, eine neue Architektur für CSR, eine neue Art der TLS-Handshake-Durchführung und ein neues Validierungsmodell bei CAs entstehen. Dies ist keine Evolution – es ist eine Rekonstruktion. Und doch gelang es, sie abwärtskompatibel durchzuführen, was die größte Errungenschaft der angewandten Kryptografie der letzten Jahre ist.

Das Ende der RSA/ECDSA-Ära: Die Krise der klassischen Kryptografie und der Grund für die Geburt von Hybrid

Die asymmetrische Kryptografie, die über drei Jahrzehnte die Säule der Internetsicherheit bildete, befindet sich an einem Wendepunkt, dessen Ausmaß in der Geschichte der Sicherheitstechnik beispiellos ist. Die Algorithmen RSA und ECDSA, die seit den 90er Jahren definierten, wie TLS funktioniert, erwiesen sich als fundamental nicht resistent gegen die Entwicklung von Quantencomputern. Es handelt sich hier nicht um eine marginale Schwächung; es handelt sich um eine mathematische Gewissheit – diese Algorithmen werden dem Shor-Algorithmus zum Opfer fallen, sobald Quantencomputer die Schwelle von einigen hundert logischen Qubits überschreiten.

Dies führte zu einem Begriff, der derzeit die Richtung der gesamten Sicherheitswelt definiert: „harvest now, decrypt later“. Angreifer benötigen heute keine Quantencomputer, um eine zukünftige Bedrohung zu schaffen. Es reicht aus, verschlüsselten TLS-Datenverkehr abzufangen und zu archivieren. Wenn die TLS-Sitzung auf RSA oder ECDSA basiert, wird ihr Inhalt zum Zeitpunkt des Aufkommens von Quantencomputern offengelegt. Das Problem ist somit keine abstrakte Bedrohung am Horizont, sondern eine reale Notwendigkeit, heutige Sitzungen vor zukünftiger Entschlüsselung zu schützen. Zu verstehen, warum RSA und ECDSA besonders anfällig für Quantenangriffe sind, erfordert eine kurze Einführung in die Struktur dieser Algorithmen. RSA basiert auf der Schwierigkeit, große Zahlen zu faktorisieren – eine Aufgabe, die für klassische Computer bei 2048-Bit-Schlüsseln rechnerisch undurchführbar bleibt. Der Shor-Algorithmus reduziert jedoch das Faktorisierungsproblem auf eine Suche im Zustandsraum mit Hilfe von Quantenregistern und verkürzt die Berechnungszeit drastisch auf polynomiale Zeit. ECDSA hingegen basiert auf dem Problem des diskreten Logarithmus auf elliptischen Kurven, das ebenfalls für klassische Computer schwierig ist, sich aber als ebenso anfällig für den Shor-Algorithmus erweist. Mit anderen Worten, die gesamte TLS-Architektur basierte auf Annahmen, die in dem Moment nicht mehr gelten, in dem eine bestimmte Größenordnung von Quantencomputern erreicht wird.

Zusätzlich stellt sich die Frage der Schlüssellänge. Viele Administratoren leben in dem Glauben, dass eine Erhöhung der RSA-Schlüssellänge das Sicherheitsproblem lösen wird. In der Praxis ist dies eine Illusion. RSA 4096 bietet eine größere Widerstandsfähigkeit gegen klassische Angriffe, erhöht aber die Widerstandsfähigkeit gegen den Shor-Algorithmus nicht einmal um eine Millisekunde – RSA 4096 fällt genauso wie RSA 2048. Daher ist die Einführung hybrider Zertifikate keine Alternative zu RSA 4096; es ist der einzige reale Weg, um vor zukünftiger Entschlüsselung zu schützen. In diesem Kontext entstand die Post-Quanten-Kryptografie (PQC). Basierend hauptsächlich auf Gitter-basierter Kryptografie (lattice-based cryptography) scheint sie die vielversprechendste Algorithmus-Familie zu sein, da sie nicht für uns bekannte Quantenangriffe anfällig ist. Die wichtigsten davon sind ML-KEM (ehemals Kyber) und ML-DSA (ehemals Dilithium), die von NIST als PQC-Standards ausgewählt wurden. Diese Algorithmen bringen jedoch ernsthafte Komplikationen mit sich. PQC-Schlüssel und -Signaturen sind um ein Vielfaches größer als ihre klassischen Gegenstücke, und ihre Verwendung erfordert neue Formate und Anpassungen der Kommunikationsprotokolle.

Und hier taucht ein fundamentales Problem auf – PQC kann nicht einfach in die bestehende Zertifikatsstruktur „geworfen“ werden. X.509 sah die Möglichkeit der Einbettung mehrerer Schlüssel gleichzeitig nicht vor. SPKI war eine eindeutige Struktur, die nur einen Satz Algorithmus + Schlüssel enthielt. Daher zwang das Aufkommen von PQC eine Neudefinition des Zertifikatsmodells. Nebenbei bemerkt, ist dies das erste Mal seit den 90er Jahren, dass die SPKI-Konstruktion radikal umgebaut werden musste. Bevor wir zu Composite-SPKI kommen, muss jedoch ein weiterer Aspekt der Krise der klassischen Kryptografie diskutiert werden: der Anstieg der Rechenleistung und die Miniaturisierung. Über Jahrzehnte reichte es aus, die Schlüssellänge zu erhöhen oder neue elliptische Kurven einzuführen. Aber der Anstieg der Rechenleistung, die Entwicklung hardwarebasierter Koprozessoren und Forschungen zu Quantum Annealing zeigten, dass die Aufrechterhaltung der Sicherheit durch das Erhöhen der Parameter klassischer Algorithmien ineffizient wird. Es musste eine strukturelle, nicht nur eine parametrische Lösung gefunden werden.

Ein weiterer wichtiger Aspekt ist, dass PQC-Algorithmen deutlich höhere Speicher- und Leistungsanforderungen haben – nicht im Hinblick auf die Rechenkomplexität als solche, sondern im Hinblick auf das Datengewicht. Der öffentliche Schlüssel ML-KEM-768 ist über 1 KB groß, und eine ML-DSA-Signatur kann 2-3 KB groß sein. Aus Sicht eines Zertifikats, in dem ein klassischer ECDSA-Schlüssel 64 Byte belegt, ist dies ein gigantischer Sprung. Die Einbettung von PQC allein in ein Zertifikat würde dazu führen, dass das Zertifikat größer wäre als viele während des TLS-Handshakes verwendete Pakete. Daher wären einige Geräte, insbesondere im IoT-Bereich, nicht in der Lage, solche Zertifikate zu verarbeiten. Hybride lösen dieses Problem, indem sie Kompatibilität mit Geräten bieten, die PQC nicht unterstützen, aber bereit sind, ein größeres Zertifikat als bisher zu verarbeiten. Es ist auch erwähnenswert, dass die Migration zu PQC nicht in einem einmaligen Schritt erfolgen kann. CAs können nicht plötzlich aufhören, klassische Zertifikate auszustellen, da die meisten Geräte sie nicht unterstützen würden. Browser können PQC nicht plötzlich erzwingen, da sie die Abwärtskompatibilität brechen würden. Aus diesem Grund sind hybride Zertifikate die einzige praktikable Lösung, die eine schrittweise Migration ermöglicht. Sie ermöglichen die Bereitstellung von PQC in Handshake-Protokollen, ohne PQC-Unterstützung von CAs, Browsern und Geräten zu erzwingen, die noch nicht bereit sind.

Hybride Zertifikate entstanden daher nicht als Experiment – sie entstanden als notwendige Konstruktion. Die Beibehaltung des aktuellen X.509-Modells mit einem Algorithmus war unmöglich. Der Übergang zu reinem PQC war ebenfalls unmöglich. Ein Composite-Modell war erforderlich. Im nächsten Teil kommen wir zu dem Punkt, an dem die wahre Hybrid-Ingenieurarbeit beginnt – dem Design von Composite SPKI. Dort taucht die Mechanik der Kodierung zweier Schlüssel in einem ASN.1-Objekt auf, die Frage der Algorithmus-Identifikatoren, die Kompatibilität mit der bestehenden Zertifikatsstruktur und praktische Probleme wie Größe und Auswirkung auf Transportprotokolle.

Design und Architektur von Composite SPKI: Die neue Form des öffentlichen Schlüssels in X.509

Die Revolution, die durch hybride Zertifikate eingeführt wurde, hat ihr Zentrum nicht in TLS, nicht in PQC, sondern in einem der fundamentalsten Elemente des gesamten X.509-Standards – dem Feld SubjectPublicKeyInfo (SPKI). Genau diese Struktur, die über mehr als drei Jahrzehnte nahezu unberührt blieb, musste radikal neu gestaltet werden, um die Einbettung eines klassischen und eines postquantischen Schlüssels in einem Zertifikat zu ermöglichen. SPKI wurde nicht als Multi-Algorithmus-Container konstruiert. Im gesamten RFC 5280 wurde klar angenommen, dass ein Zertifikat genau einen öffentlichen Schlüssel beschreibt. Das hybride Zertifikat erzwingt die Brechung dieser Annahme – muss dies aber auf eine Weise tun, die die Kompatibilität mit der bestehenden Infrastruktur, Bibliotheken, ASN.1-Parsern, Browsern, CAs und Mechanismen der Zertifikatspfadvalidierung nicht verletzt.

Um zu verstehen, wie Composite SPKI entstand, muss man zunächst verstehen, wie klassisches SPKI aufgebaut ist. Seine ASN.1-Definition besteht aus zwei Elementen: algorithm und subjectPublicKey. Der erste enthält eine OID, die den Algorithmus beschreibt, sowie potenzielle Parameter, der zweite enthält den rohen öffentlichen Schlüssel, kodiert als BIT STRING. Im Fall von RSA ist der öffentliche Schlüssel eine Struktur, die Modul und Exponenten enthält, bei ECDSA ein Punkt der elliptischen Kurve, kodiert im unkomprimierten oder komprimierten Format. SPKI repräsentiert immer ein einziges Wertepaar – und praktisch alle ASN.1-Parser weltweit nehmen diese Eindeutigkeit an. Beim hybriden Zertifikat konnte der PQC-Schlüssel nicht in Form einer X.509-Erweiterung „angeklebt“ werden, da die meisten Zertifikatsinterpreter nicht-kritische Erweiterungen im Validierungsprozess ignorieren. Wenn PQC in einer Erweiterung wäre, könnten PQC-fähige Clients ihn nutzen, aber klassische Implementierungen würden das Zertifikat weiterhin als klassisches Zertifikat interpretieren – das heißt, der TLS-Handshake bliebe anfällig für Quantenangriffe. Die Lösung musste eine Konstruktion sein, die den Kern des Zertifikats selbst modifiziert, so dass der PQC-Schlüssel Teil des SPKI wird. Dadurch sieht jeder Client, selbst einer, der PQC nicht kennt, diese Struktur als eine registrierte Form von SPKI – und ein moderner Client versteht sie als Komposit aus zwei Schlüsseln.

Zu diesem Zweck wurde compositeSubjectPublicKeyInfo entworfen, eine Struktur, die immer noch in das SPKI-Feld passt, deren Inhalt jedoch anzeigt, dass sie zwei Schlüssel gleichzeitig repräsentiert. Es handelt sich um eine mehrschichtige Konstruktion. Die erste Schicht ist die Änderung der Algorithmus-Kennung – die OID zeigt nicht mehr den RSA-, ECDSA- oder ML-KEM-Algorithmus an, sondern einen Composite-Algorithmus. In IETF-Entwürfen erscheinen normalerweise OIDs wie id-alg-composite oder id-alg-hybrid, die ein Signal für Implementierungen darstellen, dass SPKI keinen einzelnen Schlüssel enthält. Dies ist das grundlegende Element der Kompatibilität: Eine Bibliothek, die die Composite-OID nicht versteht, behandelt sie als unbekannten Algorithmus, aber auf eine Weise, die mit RFC 5280 konform ist – sie bricht die Zertifikatsvalidierung selbst nicht ab, solange der Signaturalgorithmus des Zertifikats klassisch und erkennbar ist. Dies ermöglicht die Beibehaltung der Kompatibilität mit aktuellen Browsern.

Die zweite Schicht von Composite-SPKI ist die Art und Weise, wie die beiden Schlüssel kodiert werden. ASN.1 erfordert, dass der BIT STRING genau eine bitweise Repräsentation des public_key enthält. Composite-SPKI muss daher zwei Schlüssel in eine Sequenz verpacken. Die typische Darstellung sieht folgendermaßen aus: BIT STRING { SEQUENCE { publicKey1 BIT STRING, publicKey2 BIT STRING } }. Innerhalb dieser Sequenz befindet sich die vollständige Struktur des klassischen Schlüssels (z.B. ECDSA P-256) und die vollständige Struktur des PQC-Schlüssels (z.B. ML-KEM-768). Beide Schlüssel müssen durch OID-Parameter beschrieben werden, aber diese Parameter befinden sich nicht im SPKI-Algorithmus, sondern in der Composite-Schicht. In der Praxis bedeutet dies, dass Composite-SPKI ein dreischichtiger Container ist: SPKI → BIT STRING → SEQUENCE → BIT STRING + BIT STRING. Dies erfordert wiederum ein Update der ASN.1-Parser, die bisher davon überzeugt waren, dass public_key immer ein roher Punkt oder Modul ist, der in einem einzigen BIT STRING eingebettet ist.

Das größte technische Problem ist die Größe. Der öffentliche Schlüssel ML-KEM-768 überschreitet ein Kilobyte, und ML-KEM-1024 ist über anderthalb Kilobyte groß. Nach Hinzufügen des ECDSA P-384-Schlüssels (der selbst etwa 97 Byte hat), beginnt die SPKI-Struktur, mehrere Kilobyte zu belegen. Unter Berücksichtigung von ASN.1-Headern, der Composite-Algorithmus-Kennung und der Sequenzverpackung kann Composite-SPKI zwischen 2 KB und sogar 10 KB groß sein. Und das ist nur ein Teil des Zertifikats. Im gesamten Zertifikat ist die SPKI-Struktur nur eines der Elemente von TBSCertificate, das auch Subject, Validity, Issuer und Erweiterungen enthält. Infolgedessen überschreitet ein hybrides Zertifikat natürlicherweise 10 KB und hat in typischen Implementierungen 13-17 KB. Dies ändert die Dynamik von TLS. Im Kontext des TLS-Handshakes ist entscheidend, dass das Zertifikat in der Certificate-Nachricht übertragen werden muss. TLS 1.2 und TLS 1.3 haben unterschiedliche Transportmethoden für Zertifikate, aber beide gehen davon aus, dass in einem TLS-Record Zertifikatsstrukturen bis zu ca. 16 KB Platz finden. Ein hybrides Zertifikat mit einer Größe von 17 KB passt nicht in einen einzelnen Record und erfordert eine Fragmentierung über mehrere Records. Dies ist an sich für die meisten modernen Clients kein Problem, aber viele IoT-Geräte, Router und Load Balancer implementieren vereinfachte TLS-Stacks und gehen davon aus, dass das Zertifikat in ein Fragment passt. Composite-SPKI bricht diese Annahme – und dies ist eine der schwerwiegendsten Implementierungshürden.

Es gibt noch einen anderen Aspekt: CT Logs (Certificate Transparency). CT Logs erfordern, dass jedes Zertifikat in einem konformen Format gespeichert wird und in angemessenen Größen passt. Viele CT-Implementierungen haben harte Grenzen für die Zertifikatsgröße in einem Log-Eintrag, normalerweise etwa 16 KB. Composite-SPKI kann diese Grenze überschreiten, was Log-Betreiber zwingt, ihre Software zu aktualisieren. CT ist ein kritisches Element für die Sicherheit des Zertifikats-Ökosystems, daher müssen seine Änderungen extrem vorsichtig vorgenommen werden. Semantisch führt Composite-SPKI noch eine weitere fundamentale Änderung ein: Das hybride Zertifikat repräsentiert nicht länger eine einzige kryptografische Identität. Es repräsentiert zwei Identitäten gleichzeitig – eine klassische und eine postquantische. Es existieren zwei private Schlüssel und zwei öffentliche Schlüssel, und jeder dieser Schlüssel kann für kryptografische Operationen verwendet werden. In einem klassischen Zertifikat stammt die TLS-Signatur von dem Schlüssel, der dem SPKI entspricht. In einem hybriden Zertifikat kann die TLS-Signatur je nach Handshake-Algorithmus entweder vom klassischen Schlüssel, vom PQC-Schlüssel oder von einer Kombination beider stammen. Letzteres ist besonders wichtig: In vollständigen Composite-Signatur-Implementierungen wird das Zertifikat gleichzeitig mit zwei Signaturen signiert – einer klassischen und einer PQC-Signatur. Dadurch existiert die Widerstandsfähigkeit gegen Quantenangriffe bereits auf Zertifikatsebene, nicht nur im Handshake. Derzeit dominieren jedoch noch Implementierungen, bei denen die Zertifikatssignatur klassisch ist, da CAs in klassischen Roots verankert sind.

Ein wichtiges Element der Composite-SPKI-Architektur ist auch die Interpretation von X.509-Erweiterungen. Erweiterungen wie BasicConstraints, KeyUsage oder ExtendedKeyUsage müssen beide Schlüssel betreffen, nicht nur den klassischen. Validierungsmechanismen, die diese Erweiterungen zuvor eindeutig interpretierten, müssen nun davon ausgehen, dass das Zertifikat sowohl für klassische als auch für PQC-Operationen verwendet werden kann. Dies erzwingt Änderungen in CA-Software, Bibliotheken und Browsern. Composite-SPKI ist im Wesentlichen eine neue Zertifikatsarchitektur, keine kosmetische Erweiterung. Es ändert die Art der Schlüsselkodierung, die Art der SPKI-Interpretation, die Art der Validierung, die Art des Zertifikatstransports und die Art ihrer Veröffentlichung in CT. Es ist das „Herz“ des hybriden Zertifikats – und das Fundament, ohne das nichts Weiteres realisiert werden könnte.

ASN.1 und PQC in X.509: Die Anatomie eines hybriden Zertifikats

Wenn Composite SPKI das Herz des hybriden Zertifikats ist, dann ist ASN.1, genauer gesagt seine binäre Form DER, sein Skelett. Es ist ASN.1, das die Art der PQC-Kodierung erzwingt, Sequenzen definiert, Längen bestimmt und Kompatibilität mit Validierungsmechanismen gewährleistet. In klassischen X.509-Zertifikaten waren die meisten dieser Regeln praktisch unsichtbar – die Verwendung von RSA und ECDSA war so vorhersehbar und stabil, dass kaum jemand in die TBSCertificate-Struktur schaute und Längen, Offsets und Tag-Kennungen analysierte. Hybride Zertifikate ändern all dies. Um ihre innere Architektur zu verstehen, muss man genau betrachten, wie ASN.1 Daten in X.509-Strukturen kodiert.

Ein X.509-Zertifikat besteht aus drei grundlegenden Elementen: TBSCertificate, signatureAlgorithm und signatureValue. TBSCertificate ist das wichtigste Element, da sich dort SPKI, Subject, Issuer, Validity und Erweiterungen befinden. Das hybride Zertifikat greift primär in SPKI ein, aber die Konsequenzen dieser Änderung wirken sich auf alle anderen Elemente von TBSCertificate und sogar auf die Zertifikatssignatur aus. Zunächst ändert sich die Länge von TBSCertificate, was wiederum den Offset von signatureValue ändert, da das Zertifikat eine kontinuierliche, in DER kodierte Sequenz ist. Wenn SPKI mehrere Kilobyte belegt und TBSCertificate 10 KB überschreitet, müssen viele Implementierungen mit Offset-Verschiebungen umgehen, die sie zuvor nie beobachtet haben. Bevor wir zu PQC im hybriden Zertifikat kommen, ist es erwähnenswert, dass X.509-Zertifikate DER – die deterministische Form von BER – verwenden. BER war ein flexibles Format, das verschiedene Repräsentationsweisen ermöglichte, aber genau der deterministische DER wurde in der TLS-Welt übernommen, um Eindeutigkeit zu gewährleisten. DER erzwingt Regeln, nach denen alle Werte auf eine unzweideutige Weise kodiert werden müssen. Das Problem ist, dass DER nicht mit hybriden Strukturen entworfen wurde, die große PQC-Felder enthalten. Dies führt zu technischen Schwierigkeiten, die ein genaues Verständnis erfordern.

PQC erscheint im hybriden Zertifikat an zwei Stellen: in SPKI als öffentlicher Schlüssel und in der Zertifikatssignatur als Teil der Composite-Signatur (sofern die CA hybride Signaturen unterstützt). Die bloße Tatsache, dass ein Zertifikat zwei unabhängige kryptografische Strukturen enthält, erzwingt Änderungen in mehreren ASN.1-Schichten. Zuerst muss in der TBSCertificate-Struktur die Kennung des Composite-Algorithmus eingebettet werden, gefolgt von der BIT STRING-Struktur, die eine Sequenz von zwei öffentlichen Schlüsseln enthält. Die Kodierung dieser Sequenz muss deterministisch sein, also gemäß den DER-Regeln durchgeführt werden. Alle Felder müssen mit den im Standard definierten Längen kodiert werden. Wenn die Länge 127 Bytes überschreitet, schreibt ASN.1 die Verwendung einer Mehrbyte-Länge vor – und hier taucht die erste wesentliche Komplikation auf. In vielen Bibliotheken, die DER implementieren, gibt es Optimierungen, die auf der Annahme basieren, dass Längen kurz sein werden. Composite-SPKI bricht diese Annahme, da die PQC-Sequenz groß ist und die Kodierung von Mehrbyte-Längen erfordert. Dies zwingt Parser, die Art der Dateninterpretation zu ändern.

Der zweite Schlüsselaspekt ist die Art der Kodierung des PQC-öffentlichen Schlüssels. Der ML-KEM-768-Schlüssel ist einfach ein Datenblock – eine Bytefolge, die einen Vektor im Gitterraum repräsentiert. ASN.1 behandelt ihn als BIT STRING, muss aber alle DER-Regeln einhalten. Dies schließt unter anderem die Verpflichtung ein, ein Byte „unused bits“ (normalerweise 0x00) hinzuzufügen. Der PQC-Schlüssel muss in eine Sequenz verpackt werden, die die OID des Algorithmus und den kodierten Schlüssel enthält. Dies ergibt eine ASN.1-Struktur, die der in ECDSA ähnelt, aber mit einem viel größeren Volumen. Composite-SPKI mit zwei öffentlichen Schlüsseln muss zwei solche Strukturen enthalten, die in eine Sequenz verpackt sind.

Einer der schwierigsten Aspekte von PQC in X.509 ist die Zertifikatssignatur. Klassische Zertifikate verwenden signatureAlgorithm und signatureValue zur Speicherung der Signatur. Im Fall von Hybriden können CAs weiterhin nur klassische Signaturen verwenden, aber letztendlich erfordert der Standard Composite-Signaturen. Composite-Signatur bedeutet, dass signatureValue nicht eine Signatur ist, sondern eine Sequenz von zwei Signaturen, kodiert als BIT STRING. Dies erforderte die Einführung einer neuen Signatur-Kennung – compositeSignature. Die signatureValue-Struktur muss als BIT STRING kodiert werden, der eine Sequenz enthält, die wiederum zwei BIT STRINGs enthält: einen mit der ECDSA-Signatur, den anderen mit der ML-DSA-Signatur. Dies ist eine große Änderung in RFC 5280, das die Existenz einer einzigen Signatur annimmt. Auf DER-Ebene tritt ein weiterer Aspekt auf: Die Längen von Composite-Signaturen sind sehr groß. Eine ECDSA P-256-Signatur belegt 64 Bytes, aber eine ML-DSA-2-Signatur belegt etwa 2,7 KB. Die kombinierte Signatur ist über 2,8 KB groß – und das ist nur die Signatur. Das gesamte Zertifikat kann 20 KB überschreiten. Dies hat enorme Konsequenzen für den TLS-Handshake und CT Logs, die oft Grenzen für die Zertifikatsgröße haben.

Im Kontext von CAs beeinflusst PQC den Validierungsprozess. CAs müssen beide öffentlichen Schlüssel identifizieren und deren Korrektheit bestätigen. SDR (Subject Distinguished Name), Validity und Erweiterungen ändern sich nicht – aber CAs müssen feststellen, ob beide Schlüssel den Anforderungen entsprechen. Zum Beispiel ist ML-KEM-512 zu schwach und kann nicht verwendet werden. CAs müssen auch feststellen, ob die Composite-Signatur korrekt ist. Die Validierung einer Composite-Signatur erfordert zwei unabhängige Verifizierungsoperationen – eine für die klassische Signatur, die andere für PQC. CAs müssen auch darauf achten, dass sich beide Signaturen auf dieselbe DER-Struktur des Zertifikats beziehen. Dies ist wichtig, da jegliche Unterschiede in DER zu einer fehlerhaften Validierung führen.

ASN.1 erzwingt auch die Einhaltung der Regeln der Pfadvalidierung. RFC 5280 verlangt, dass Clients signatureAlgorithm und signatureValue des Zertifikats verifizieren. Hybride Zertifikate haben einen signatureAlgorithm, der auf composite-signature verweist, aber signatureValue enthält zwei Signaturen gleichzeitig. Ein Client, der die Composite-OID versteht, verifiziert beide Signaturen. Ein Client, der die Composite-OID nicht versteht, wird versuchen, die klassische Signatur zu verwenden, wenn die CA das Zertifikat mit einem klassischen Algorithmus signiert. Dies ist genau der Mechanismus, der Abwärtskompatibilität gewährleistet. In der Praxis beeinflusst PQC auch X.509-Erweiterungen. EKU, KeyUsage und BasicConstraints bleiben unverändert – aber Implementierungen müssen sich bewusst sein, dass ein hybrides Zertifikat für zwei Arten kryptografischer Operationen verwendet werden kann. EKU vom Typ serverAuth bezieht sich nun auf zwei Schlüssel, nicht auf einen. CT-Mechanismen müssen auch hybride Zertifikate in Logs speichern. Für PQC-fähige Clients muss Composite-SPKI als Wert des klassischen und des PQC-Schlüssels interpretiert werden. Für Legacy-Clients wird Composite-SPKI als unbekannte Struktur gesehen, aber dies verursacht keinen Validierungsfehler des Zertifikats, solange die Signatur klassisch ist.

Zusammenfassend hat PQC X.509 auf einer tieferen Ebene verändert als jede Änderung seit der Entstehung des Standards. ASN.1 muss hybride Strukturen unterstützen, DER muss mehrbytegroße Felder kodieren, CAs müssen Composite-Signaturen unterstützen und Clients müssen Composite-SPKI interpretieren. All dies erfordert einen gründlichen Umbau des Zertifikats-Ökosystems.

Hybride CSR und Composite-Signaturen: Wie eine Zertifikatsanforderung 2025 aussieht

Während das hybride Zertifikat die Natur von X.509 verändert, verändert die hybride CSR die Natur des gesamten Prozesses der Entstehung des Zertifikats. Im klassischen Modell war die CSR ein beinahe triviales Dokument: ein öffentlicher Schlüssel, Subjektdaten, Erweiterungen und eine Signatur mit dem privaten Schlüssel. In der Hybrid-Version reicht nichts davon aus. Die CSR muss zwei öffentliche Schlüssel beschreiben, muss mit zwei Signaturen signiert werden, und ihre ASN.1-Struktur muss sowohl mit RFC 2986 (PKCS#10) als auch mit den kommenden PQC-Standards konform sein. Das bedeutet, dass sie aufhört, eine einzige Informationssequenz zu sein – sie wird zu einem Komposit, ähnlich wie SPKI im Zertifikat.

Um zu sehen, wie revolutionär die Änderung ist, lohnt es sich, in Erinnerung zu rufen, was eine CSR aus ASN.1-Sicht ist. PKCS#10 definiert die CSR als CertificationRequest mit den Feldern certificationRequestInfo, signatureAlgorithm und signature. Der Schlüsselteil ist certificationRequestInfo, das SPKI enthält. In traditionellen CSRs hat SPKI eine einzige Form: Beschreibung des Algorithmus und öffentlicher Schlüssel. In der hybriden CSR muss subjectPublicKeyInfo die neue Composite-Struktur widerspiegeln.

Hybride CSR verändert certificationRequestInfo strukturell

In der klassischen Form ist certificationRequestInfo eine deterministische Sequenz, die enthält:

• subject
• subjectPublicKeyInfo
• attributes

Mit dem Aufkommen von PQC und Composite ist der öffentliche Schlüssel kein einzelner Wert mehr. Die hybride CSR muss einführen:

1. Composite-OID, die anzeigt, dass SPKI ein Multi-Algorithmus-Container ist.
2. Eine Sequenz von zwei public_key, kodiert als BIT STRING, darunter:
   • klassisch (RSA/ECDSA),
   • PQC (ML-KEM).
3. Algorithmusparameter, die in der klassischen CSR optional waren und jetzt erzwungen sind.

Technisch sieht das so aus:

subjectPublicKeyInfo :: = SEQUENCE {
   algorithm AlgorithmIdentifier {COMPOSITE-ALGORITHM},
   subjectPublicKey BIT STRING {
        SEQUENCE {
            BIT STRING -- klassischer Schlüssel (ECDSA),
            BIT STRING -- PQC-Schlüssel (ML-KEM)
        }
   }
}

Dies ist das erste Mal in der Geschichte von PKCS#10, dass subjectPublicKey eine Sequenz ist, die andere Sequenzen enthält, anstelle eines klassischen Blocks roher Bits. Es gibt keine Möglichkeit, dies zu vereinfachen, ohne die Kompatibilität mit der PQC-Zukunft zu brechen – daher ist die Auflistung in diesem Fragment unvermeidlich.

Hybride CSR muss eine Komposit-Signatur enthalten, also composite signature

Hier kommen wir zur invasivsten Änderung. In der klassischen CSR:

• signatureAlgorithm spezifiziert z.B. ecdsa-with-SHA256,
• signature ist ein einzelner BIT STRING, der die Signatur enthält.

In der hybriden CSR reicht das nicht aus. Da certificationRequestInfo zwei Schlüssel (ECDSA und PQC) enthält, muss die CSR mit beiden Methoden signiert werden.

Es entsteht also die Struktur:

• signatureAlgorithm = compositeSignatureAlgorithm
• signature = BIT STRING, der eine SEQUENCE von zwei Signaturen enthält

Formal:

signature ::= BIT STRING {
    SEQUENCE {
       BIT STRING -- ECDSA-Signatur,
       BIT STRING -- ML-DSA-Signatur
    }
}

Warum ist das notwendig?
Weil die CA sonst keine Garantie hätte, dass der PQC-Schlüssel tatsächlich dem anfragenden Subjekt gehört. In klassischen CSRs ist die Signatur der Nachweis des Schlüsselbesitzes. In der Hybrid-Version muss es einen Nachweis geben für:

• den Besitz des klassischen Schlüssels,
• den Besitz des PQC-Schlüssels.

Die Sequenz von zwei Signaturen ist die einzige DER-konforme Konstruktion, die die binäre Konsistenz für die CA beibehält.

Hybride CSR erfordert ein Update der Attribute und die Notwendigkeit, Algorithmen explizit zu deklarieren

In klassischen CSRs wurde das Feld attributes hauptsächlich verwendet für:

• challengePassword
• extensionRequest

In der Hybrid-Version werden attributes entscheidend, da sie enthalten können:

• eine Deklaration der PQC-Unterstützung auf Client-Seite,
• bevorzugte PQC-Algorithmen,
• Parameter bezüglich hybrider Handshake-Mechanismen.

In der Praxis kann die CA in attributes etwas verlangen, das bisher überhaupt nicht existierte:

pqcPreferences ::= SEQUENCE {
    kemAlgorithm OBJECT IDENTIFIER,
    signatureAlgorithm OBJECT IDENTIFIER
}

Das bedeutet, dass der Client explizit deklarieren muss, welche PQC-Kombination er verwendet: ML-KEM-512, ML-KEM-768, ML-DSA-2, ML-DSA-3 usw. Und hier taucht ein ernstes Problem für die Kompatibilität auf. Viele alte PKCS#10-Bibliotheken ignorieren Felder, die sie nicht verstehen – aber sie dürfen die CSR-Signatur nicht beeinflussen, sonst schlägt die Validierung durch die CA fehl. Daher müssen attributes in der Hybrid-Version:

• streng DER-kodiert sein,
• dürfen die Struktur von certificationRequestInfo nach der Signierung nicht ändern,
• müssen in der durch ASN.1 definierten Reihenfolge geordnet sein.

Wenn attributes nicht konform kodiert werden, wird die CA die Composite-Signatur nicht verifizieren. Dies ist ein reales, praktisches Problem bei Hybrid-Implementierungen.

Implementierungsherausforderung: Generierung hybrider CSR in OpenSSL 3.x

OpenSSL 1.x unterstützte dies nicht und wird es niemals unterstützen.
OpenSSL 3.x unterstützt Composite teilweise, erfordert aber Patches und zusätzliche Provider.

Um eine hybride CSR zu generieren, muss die OpenSSL-Bibliothek so konfiguriert werden, dass:

1. Der klassische Provider (default) geladen wird.
2. Der PQC-Provider (z.B. liboqs-openssl) geladen wird.
3. Ein Composite-Key-Kontext erstellt wird:

   EVP_PKEY_CTX_new_from_name(NULL, "COMPOSITE", NULL)
   

4. Zwei Schlüssel injiziert werden:

   EVP_PKEY_set1_tls1_prf_key(key_ec)
   EVP_PKEY_set1_tls1_prf_key(key_pqc)
   

5. Die Composite-SPKI-Struktur generiert wird.
6. Die mit Composite-Signatur signierte CSR generiert wird.

In den meisten Linux-Distributionen ist dies ohne Neucompilierung von OpenSSL nicht möglich.

Validierung hybrider CSR auf Seiten der CA

Die CA muss durchführen:

1. Validierung des gesamten certificationRequestInfo in DER.
2. Validierung des klassischen Schlüssels.
3. Validierung des PQC-Schlüssels.
4. Validierung beider Signaturen innerhalb der Composite-Signatur.

Diese Schritte müssen in einer bestimmten Reihenfolge erfolgen, da die Composite-Signatur die Reihenfolge der Schlüssel nicht angibt – sie setzt voraus, dass die CA die Reihenfolge ihrer Einbettung in Composite-SPKI kennt. Wenn die CA die Reihenfolge der Signaturen verwechselt, wird die CSR ungültig.

Zusätzlich muss die CA prüfen:

• die Übereinstimmung der PQC-Algorithmen mit dem Sicherheitsprofil (z.B. keine Zulassung von ML-KEM-512),
• die korrekte OID-Struktur,
• das Fehlen unzulässiger Erweiterungen oder Attribute,
• keine Diskrepanzen zwischen SPKI und der Deklaration in attributes (falls der Client PQC-Preferences angegeben hat).

Dies ist ein sehr schwieriger Prozess. Heutige CAs implementieren praktisch dafür neue Pipelines – parallel zu den klassischen.

Hybride CSR verändert den Charakter der kryptografischen Identität

In der traditionellen CSR haben wir ein Schlüsselpaar. In der hybriden CSR haben wir:

• zwei Schlüsselpaare,
• zwei Signaturen,
• ein Dokument, das das Subjekt identifiziert.

Dies ändert das Konzept der Identität fundamental. Die CSR hört auf, ein Nachweis des Besitzes eines Schlüssels zu sein – sie wird zum Nachweis des Besitzes von zwei Schlüsseln, und zwar Schlüsseln unterschiedlichen Typs, die zu zwei verschiedenen Klassen mathematischer Funktionen gehören. Dies ist nicht länger das klassische PoP (Proof-of-Possession). Es ist Dual-PoP. Für die CA bedeutet dies ein völlig neues Sicherheitsmodell. Wenn einer der Schlüssel kompromittiert wird, verliert das hybride Zertifikat nicht an Wert – da der Handshake trotzdem mit dem zweiten Algorithmus durchgeführt werden kann.

Dies ist die höchste Stufe kryptografischer Redundanz in der Geschichte von TLS.

Auswirkung hybrider CSR auf die Zukunft von ACME

ACME, das Protokoll für die automatische Zertifikatsausstellung, erfordert, dass die CSR als base64-kodiertes DER gesendet wird. Hybride CSR ist 5-12x größer als klassische, daher beeinflusst sie:

• maximale Payload-Größen,
• die Art des CSR-Versands,
• die Notwendigkeit der Fragmentierung,
• die Signaturvalidierung.

Genau die hybride CSR ist einer der Gründe für die Entstehung von ACME 2.0 / 3.0, wo erscheinen:

• Unterstützung für PQC,
• Deklarationen hybrider Algorithmen,
• vielleicht Mechanismen zur vorherigen Aushandlung von PQC-Algorithmen.

Hybrider TLS-Handshake: Vollständige kryptografische Analyse Schritt für Schritt.

Der hybride TLS-Handshake ist der tiefste Eingriff in das TLS-Protokoll seit der Entstehung von TLS 1.3. Genau in der Phase des Schlüsselaustauschs, der Algorithmusaushandlung und der Erzeugung des gemeinsamen Geheimnisses (joint secret) sieht man, welch enorme Veränderung in der gesamten Architektur der Internetsicherheit stattgefunden hat. Hybride Zertifikate sind lediglich Container – der Handshake ist der Prozess, der tatsächlich beide Schlüssel verwendet: den klassischen und den postquantischen. Am wichtigsten ist es zu verstehen, dass TLS 1.3 nicht mit zwei parallelen Mechanismen für den Austausch von geheimen Materialien entworfen wurde. Das Protokoll selbst musste erweitert werden, aber auf eine Weise, die die Kompatibilität mit bestehenden Clients und Servern nicht bricht.

Die fundamentalste Veränderung ist die Art und Weise, wie der Client ClientHello sendet. Im klassischen TLS 1.3 enthält ClientHello eine Liste unterstützter ECDHE-Gruppen und einen ephemeren ECDH-öffentlichen Schlüssel. In der Hybrid-Version wird ClientHello zu einer doppelten Konstruktion: Es muss sowohl den klassischen key_share (z.B. X25519) als auch die PQC-KEM-Komponente (z.B. ML-KEM-768) enthalten. Natürlich erhöht dies die Größe von ClientHello, aber viel wichtiger ist, dass beide Handshake-Teile synchronisiert sein müssen. Der Client sendet nicht zwei separate Aushandlungsmechanismen – er sendet ein synergistisches Paket, in dem PQC und ECDHE logisch verknüpft sind. Um dies genau zu sehen, lohnt ein Blick auf die Struktur des hybriden ClientHello. Die Einführung der Felder kem_ids und kem_public_key ist notwendig, muss aber so durchgeführt werden, dass nicht standardkonforme Clients sie ignorieren können. Dieser Mechanismus ähnelt der Struktur von TLS-Erweiterungen, aber mit einem viel größeren kryptografischen Gewicht. Aus diesem Grund war es im hybriden ClientHello notwendig, zwei Schlüsselebenen präzise zu modellieren.

Die wichtigsten Elemente des hybriden ClientHello sind:

• classical_key_share – ECDHE-öffentlicher Schlüssel,
• kem_public_key – PQC-öffentlicher Schlüssel,
• supported_kem_ids – Liste der postquantischen Algorithmen, die der Client akzeptiert,
• cipher_suites – muss die Unterstützung für beide Modi widerspiegeln, aber dennoch mit TLS 1.3 konform sein.

Alle diese Elemente müssen so kodiert werden, dass Bibliotheken, die beim klassischen ECDHE bleiben, sie überspringen können. Dies ist die wichtigste Eigenschaft der Abwärtskompatibilität: Wenn ein Client PQC nicht versteht, kann er dennoch eine Sitzung mit einem hybriden Server aufbauen – er verwendet einfach ECDHE.

Hybrides TLS: Zwei unabhängige Geheimnisaustausche, parallel durchgeführt

Wenn der Server ein hybrides ClientHello empfängt, muss er mit einem hybriden ServerHello antworten. Strukturell bedeutet dies, dass der Server ebenfalls mit zwei Schlüsseln antwortet: klassischem ECDHE und PQC-KEM. Erst an dieser Stelle beginnt die eigentliche kryptografische Magie der Hybrid-Version – zwei unabhängige Mechanismen zur Geheimnisgenerierung beginnen parallel zu arbeiten.

Im klassischen Handshake:

• generiert der Client einen Kurvenpunkt kG,
• generiert der Server dG,
• das gemeinsame Geheimnis ist kdG,
• HKDF-Extract erzeugt daraus das handshake_secret.

Im Hybrid-Modell laufen zwei Prozesse gleichzeitig ab:

1. ECDHE:
   Klassischer Diffie-Hellman-Mechanismus, der das Geheimnis Z_classical generiert.
2. ML-KEM:
   PQC-KEM erzeugt das Geheimnis nicht basierend auf einer algebraischen Gruppeneigenschaft.
   Stattdessen generiert der Client:
   • ein zufälliges Geheimnis ss,
   • einen Chiffretext ct.
     Der Server dekapsuliert den Chiffretext und gewinnt genau dasselbe ss.

Dies ist ein Schlüsselkonzept: PQC-KEM liefert ein Geheimnis, das nicht von der algebraischen Struktur des öffentlichen Schlüssels abgeleitet ist. Daher kann selbst ein Quantencomputer, der den gesamten Handshake besitzt, das PQC-Geheimnis nicht rekonstruieren. Dies ist die Kollision zweier Welten der Kryptografie – der algebraischen und der gitterbasierten – zu einer vereint.

Kombinieren der Geheimnisse: Das Herz der hybriden Sicherheit

TLS 1.3 verwendet HKDF-Extract zur Generierung von handshake_secret. In der Hybrid-Version wird dieser Mechanismus so erweitert, dass beide Geheimnisse Eingaben für HKDF werden.

Der Mechanismus sieht folgendermaßen aus:

joint_secret = HKDF-Extract(
       salt = Z_classical,
       IKM  = Z_pqc
)

Das klassische Geheimnis wird zum „Salt“, PQC wird zur Eingabe, und HKDF erzeugt einen neuen Schlüssel, der beide Welten in einem kryptografischen Material vereint. Warum genau so?

• Wenn der klassische ECDHE gebrochen wird → schützt PQC die Sitzung weiterhin.
• Wenn in der Zukunft der PQC-Algorithmus gebrochen wird → schützt die klassische Kurve die Sitzung weiterhin.
• Wenn jemand heute den Datenverkehr abfängt → verhindert PQC die Entschlüsselung in der Zukunft.

Dieses Modell ist die Grundlage der Resistenz gegen „harvest now, decrypt later“. Es ist zu betonen, dass der hybride TLS-Handshake nicht einfach zwei Handshakes in einem ist. Es ist ein gemeinsamer Handshake, dessen Sicherheit die Summe der Sicherheiten beider Algorithmen ist.

Interoperabilitätsprobleme: Punkte, an denen die Hybrid-Version praktisch scheitert

Obwohl das Hybrid-Konzept mathematisch sauber ist, stoßen praktische Implementierungen auf ernsthafte Hindernisse. Das größte davon ist die Größe. Das hybride ClientHello kann um 4-10 KB größer sein. Dies führt dazu, dass:

• einige Server den Handshake aufgrund nicht standardkonformer Größen ablehnen,
• IoT-Geräte zu kleine Puffer haben,
• Load Balancer (insbesondere ältere F5-Generationen) ClientHello abschneiden,
• Middleboxes große ClientHello als Anomalien interpretieren und Verbindungen zurücksetzen.

Cloudflare hat mehrfach beschrieben, dass bei der PQC-Einführung die Hälfte der Probleme genau auf die Handshake-Größen zurückzuführen war. Der zweite Komplikationsbereich ist die Fragmentierung von TLS-Records. Hybride Zertifikate sind groß, und der hybride Handshake ist es auch. TLS muss viele Nachrichten in Records aufteilen, die in der richtigen Reihenfolge ankommen müssen. In der Praxis unterstützen viele Embedded-Implementierungen einfach keine korrekte Fragmentierung. Das dritte Problem sind PQC-unbewusste Bibliotheken, die:

• den PQC-Schlüssel überspringen,
• Handshake-Felder als unbekannte Erweiterungen interpretieren,
• Fallback auf ECDHE-only setzen.

Dies ist jedoch gerade der Vorteil der Hybrid-Version: Fallback funktioniert immer.

Finale des Handshakes: Gemeinsames Geheimnis und Übergang zur verschlüsselten Phase

Sobald joint_secret abgeleitet ist, sind die weiteren Schritte von TLS 1.3 identisch:

• handshake_secret → Client und Server generieren Handshake-Keys,
• Handshake-Keys → schützen die Phase cert verify, finished und den Rest des Handshakes,
• master_secret → generiert finale Sitzungsschlüssel.

Der wahre Unterschied verbirgt sich in der früheren Phase: Es ist nicht länger das Geheimnis eines Algorithmus, sondern ein Komposit zweier unterschiedlicher mathematischer Welten. Und genau das macht die TLS-Sitzung resistent gegen zukünftige Quantencomputer, funktioniert aber dennoch auf heutigen Geräten.

Implementierungen von PQC und hybriden Zertifikaten in der Praxis: OpenSSL 3.x, Cloudflare, Google, CA/B Forum und CT Logs

Während die Theorie von hybridem TLS, Composite-SPKI und Joint-Secret die Entwicklungsrichtung der globalen Internetsicherheit vorgibt, liegt die wahre Last der Revolution auf den Implementierungen. Genau in kryptografischen Bibliotheken, Zertifikatsladern, Validierungsmechanismen und CT-Log-Modulen sieht man, wie schwierig und tiefgreifend die Veränderungen sind. In diesem Teil betrachten wir die Schlüsselelemente des gesamten Ökosystems: OpenSSL 3.x als Fundament, Cloudflare und Google als Pioniere produktiver Implementierungen, CA/B Forum als standardisierende Einheit und Certificate Transparency Logs, die Zertifikate akzeptieren müssen, die sogar 10x größer als bisherige sind. Vor allem muss man verstehen, dass der Übergang zu PQC in TLS nicht einfach ein Update einer Bibliothek ist. Es ist ein Umbau der gesamten Sicherheitsarchitektur, angefangen von Low-Level-Funktionen bis hin zu komplexen Zertifizierungsvalidierungsmechanismen. Viele Bibliotheken, die bis heute sehr populär sind, implementieren nicht einmal eine korrekte DER-Kodierung für übermäßig große Schlüsselfelder. Andere haben zu kleine Puffer, um ein hybrides Zertifikat zu dekodieren. Dies führt dazu, dass die Zertifikate selbst derzeit ein Belastungstest für die gesamte Netzwerkinfrastruktur sind.

OpenSSL 3.x ist die erste Hauptversion der Bibliothek, die mit Blick auf die Unterstützung postquantischer KEM-Mechanismen und zukünftiger PQC-Signaturalgorithmen gebaut wurde. Die Einführung der sogenannten Provider-Architektur ermöglichte das Laden neuer Algorithmen als Module. Dies ist besonders im Kontext von ML-KEM und ML-DSA relevant, die nicht als einfache kryptografische Funktionen hinzugefügt werden können – sie erfordern dedizierte Strukturen zur Repräsentation von Schlüsseln, unterschiedliche Methoden zur Entropieerzeugung und spezifische mathematische Parameter.

OpenSSL 1.1.1 war für diese Rolle einfach nicht geeignet. Seine Architektur war zu eng mit klassischen Algorithmen wie RSA und ECDSA verbunden, und die Möglichkeit, neue OIDs und ASN.1-Strukturen zu laden, war begrenzt. Infolgedessen sind hybride Zertifikate auf OpenSSL 1.1.1 nicht verifizierbar – und das nicht aufgrund eines Fehlers, sondern aufgrund eines fundamentalen Mangels an Unterstützung für neue Konstruktionen.

In OpenSSL 3.x geschehen drei Dinge, die hybrides X.509 ermöglichen:

1. Provider-Modell – Möglichkeit, PQC-Algorithmen als separate Module zu definieren.
2. Flexible ASN.1-Schicht – Fähigkeit, PQC-Schlüssel und Composite-Strukturen zu verarbeiten.
3. Erweiterte Puffer und Limits – ermöglichen die Dekodierung von Zertifikaten mit einer Größe von 10-25 KB.

Diese sind es, die es überhaupt ermöglichen, ein hybrides Zertifikat ohne Fehler wie ASN1_TOO_LONG oder INVALID_BITSTRING_LENGTH zu dekodieren. Viele ältere Bibliotheken (LibreSSL, BoringSSL in Versionen vor 2024, Botan, mbedTLS) haben damit immer noch Probleme.

Cloudflare: Produktive Implementierung von PQC und reale Probleme in großem Maßstab

Cloudflare ist einer der größten TLS-Betreiber weltweit und bedient ~20 % des globalen HTTPS-Datenverkehrs. Genau dort sieht man am besten, wie Theorie auf Praxis trifft. Cloudflare implementierte den hybriden TLS-Handshake bereits 2023 unter Verwendung von Kyber + X25519 im Rahmen des sogenannten X25519Kyber768Draft. Weitere Implementierungen umfassten ML-KEM, was erst mit OpenSSL 3.x möglich war. Der wichtigste Aspekt der Cloudflare-Implementierungen ist die Dokumentation realer Probleme der Nutzer. Die größten Probleme betrafen:

• Abschneiden von ClientHello durch L7-Firewalls,
• ältere IoT-Geräte, die Handshake aufgrund der Größe ablehnen,
• Router und Modems, die key_share-Felder fehlerhaft interpretierten,
• Java-Bibliotheken, die Composite-OID nicht unterstützen,
• alte CDNs, die Zertifikate >10 KB als Anomalien behandelten**,
• Load Balancer (hauptsächlich F5, Fortinet), die hybride SPKI nicht dekodierten.

Cloudflare musste ein Fallback auf klassisches ECDHE für Clients einführen, die mit der Hybrid-Version nicht zurechtkamen. Dies ist kein Nachteil der Hybrid-Version – es ist ihre Stärke. Der hybride Handshake ist genau so entworfen, dass Clients, die PQC nicht kennen, nicht von TLS abgeschnitten werden. Cloudflare betont eines: Die größte Herausforderung von PQC ist nicht die Kryptografie, sondern die Kompatibilität und die Größe der Strukturen.

Google: Hybrider QUIC, Android, Chrome und HNDL – also PQC in der Praxis von Milliarden Nutzern

Google ging noch einen Schritt weiter als Cloudflare. Die Implementierung von PQC in Chrome bedeutet, dass Hybrid zur Alltäglichkeit wird – der Browser selbst führt einen Handshake basierend auf X25519 + ML-KEM durch, und der Nutzer weiß nicht einmal davon. Google testete PQC im Maßstab von Milliarden Handshakes und veröffentlichte einige der wichtigsten Daten:

• Der Anteil der Handshake-Fehler stieg nur um ~0,1 %.
• Die größten Probleme traten in Mobilfunknetzen und in „Betreiber“-Modems auf.
• QUIC war viel besser in der Handhabung größerer Strukturen als klassisches TCP+TLS.

Google entdeckte Tausende von Geräten, die klassisches TLS durchließen, aber Pakete mit großen ClientHello ablehnten – insbesondere auf asiatischen und afrikanischen Märkten, wo die Netzwerkinfrastruktur älter ist. Genau diese Analyse führte zur Schaffung des Mechanismus HNDL – Harvest Now, Decrypt Later, der definiert, dass eine Sitzung sicher sein sollte, selbst wenn der gesamte Datenverkehr abgefangen und über Jahrzehnte gespeichert wird.

CA/B Forum: Wie sieht die Standardisierung hybrider Zertifikate aus

CA/B Forum ist für die Standards von SSL/TLS-Zertifikaten verantwortlich. Die Einführung von PQC erforderte Änderungen auf der Ebene von:

• SPKI-Formaten,
• Composite-OIDs,
• Validierungsregeln,
• Art der Zertifikatskodierung,
• Interaktion mit CT Logs.

Das wichtigste Dokument ist derzeit der Entwurf zu Composite Keys and Signatures, der definiert, wie ECDSA- und ML-DSA-Schlüssel in einem SPKI koexistieren können. Er beschreibt auch den Fallback-Mechanismus für Legacy-Clients – genau den, der es Chrome oder Firefox ermöglicht, ein hybrides Zertifikat zu akzeptieren, selbst wenn sie die Composite-OID nicht verstehen.

CT Logs: Neue Generation von Logs für Zertifikate größer als 20 KB

Certificate Transparency erzwingt, dass jedes öffentliche Zertifikat in Logs veröffentlicht wird. Das Problem ist, dass CT-Logs in Zeiten von 1-3 KB Zertifikaten entworfen wurden. Hybride Zertifikate mit 15-25 KB begannen zu verursachen:

• Fehler „entry too large“,
• fehlerhaftes ASN.1-Parsing,
• Ablehnung von Zertifikaten mit Composite-OID,
• übermäßige Belastung des Log-Speichers.

Genau die CT-Logs erzwangen Änderungen in der Art der Zertifikatspufferung und das Auftreten sogenannter PQC-friendly logs.

Prognose 2025-2030 und Implementierungsempfehlungen: Wie man ein Unternehmen auf die Ära des postquantischen TLS vorbereitet

Die Perspektive des kommenden Jahrzehnts in der Internetsicherheit ist keine Abstraktion – es ist eine sehr präzise und konkrete technologische Richtung, die durch drei parallele Kräfte vorgegeben wird:

1. den regulatorischen und institutionellen Druck,
2. das reale Risiko des Abfangens von Datenverkehr und seiner zukünftigen Entschlüsselung,
3. sowie das Tempo der PQC-Implementierung durch die größten Internetbetreiber.

Wir treten in eine Phase ein, in der die Netzwerkinfrastruktur nicht mehr „hier und jetzt“ gebaut wird, sondern auch resistent gegen Angriffe sein muss, die erst in fünf, zehn oder mehr Jahren möglich werden. Hybride Zertifikate und hybrider TLS-Handshake sind – wie viele Unternehmen glauben – keine „experimentelle Option“. Sie sind eine natürliche Reifungsstufe des globalen Sicherheitsökosystems, genau wie der Übergang von SSL 3.0 zu TLS 1.2 oder von SHA-1 zu SHA-256. Der Unterschied besteht darin, dass sich die Veränderung diesmal auf die mathematische Struktur bezieht, die dem gesamten Protokoll zugrunde liegt.

Die größte Veränderung, die den Rhythmus der kommenden Jahre bestimmen wird, ist die Übernahme der finalen postquantischen Algorithmen durch NIST. ML-KEM (Kyber) und ML-DSA (Dilithium) haben aufgehört, Vorschläge zu sein – sie sind Standards geworden, die in Bibliotheken weltweit implementiert werden. Das bedeutet, dass alle Institutionen, unabhängig von der Branche, migrieren müssen. In der Praxis wird dies nicht eine Migration sein, sondern mehrere Stufen – zuerst in Bibliotheken (OpenSSL 3.x+), dann in Zertifikaten, danach im Handshake und schließlich in der Automatisierung (ACME, DevOps, CI/CD). Man kann PQC nicht „von hinten“ oder teilweise implementieren – es erfordert eine stabile Basis in Form kryptografischer Bibliotheken, die neue Algorithmen und Composite-OID unterstützen.

Es lohnt sich auch zu verstehen, wie die langfristigen Prognosen aussehen. Die Jahre 2025-2026 sind die Zeit der verbreiteten Implementierung hybrider Zertifikate durch CAs. 2027 beginnt die Phase, in der die Mehrheit der Internetdienste auf hybriden TLS-Handshake umstellt. Entscheidend wird das Jahr 2028 sein – dann werden staatliche Institutionen, Banken und kritische Infrastrukturen PQC-ready-Zertifikate als Sicherheitsstandard fordern. 2030 wiederum ist der Zeitpunkt, an dem alte Algorithmen, obwohl noch akzeptiert, als „Legacy“ angesehen werden – genau so, wie wir heute RSA 1024 oder SHA-1 betrachten. In der Praxis bedeutet dies, dass Unternehmen ihre Infrastruktur anders als bisher betrachten müssen. Risikoanalysen dürfen nicht davon ausgehen, dass heute verschlüsselte Daten für das nächste Jahrzehnt sicher sind. Im Modell eines postquantischen Angreifers ist ein verzögerter Angriff real: Datenverkehr wird heute abgefangen, archiviert und kann in der Zukunft entschlüsselt werden. Dies ändert alles – von der Auswahl der Algorithmen über die Lebensdauer von Zertifikaten bis hin zur Art ihrer Rotation. Dies führt uns zu praktischen Empfehlungen – nicht zu allgemeinen wie „installieren Sie OpenSSL 3“, sondern zu tatsächlichen Schritten, die eine mit der hybriden TLS-Welt konforme Infrastruktur aufbauen.

Erste Empfehlung: Audit von Bibliotheken und TLS-Stacks.
Viele Unternehmen nehmen an, dass sie „sicher“ sind, weil sie NGINX oder Apache verwenden. Das ist nicht wahr. Das Herz der gesamten Kryptografie sitzt nicht im HTTP-Server, sondern in der kryptografischen Bibliothek, die dieser Server verwendet. Wenn die Infrastruktur auf OpenSSL 1.1.1 läuft – ist sie nicht PQC-ready und wird es niemals sein. Wenn sie OpenSSL 3.x verwendet, aber mit deaktivierter Provider-Unterstützung – ebenfalls nicht. Der erste Schritt erscheint daher banal, ist aber absolut fundamental: Überprüfen, welche Bibliothek unter jedem Systemelement steckt. In der Enterprise-Welt ist die Liste der zu überprüfenden Komponenten viel länger: Load Balancer (F5, Citrix, HAProxy), Reverse Proxies, Anwendungsserver (Tomcat, Jetty), JVM, mTLS-Bibliotheken, IoT-Systeme, Embedded-Geräte, Operator-Gateways, Mailserver. Dies bedeutet, dass ein PQC-Audit die Infrastruktur breiter umfasst, als die meisten Unternehmen im Rahmen irgendeines Projekts angehen.

Zweite Empfehlung: Schrittweise Implementierung hybrider Zertifikate.
Dieser Prozess beginnt nicht in der Produktion. Zuerst müssen hybride Testzertifikate in Staging-Umgebungen implementiert werden, wobei beobachtet wird, welche Infrastrukturkomponenten mit Fehlern reagieren. Hybride Zertifikate unterscheiden sich in Größe, OID-Struktur, ASN.1-Kodierung und Validierungsweise. Infolgedessen sind sie ein natürlicher „Filter“: Alles, was mit PQC nicht zurechtkommt, tritt sofort zutage.

Dritte Empfehlung: Übernahme von hybridem TLS-Handshake bei kritischen Diensten.
Dienste, die langfristige Vertraulichkeit erfordern (Finanzen, Medizin, personenbezogene Daten, Dokumentenkreisläufe, öffentlicher Sektor), sollten hybriden TLS so schnell wie möglich implementieren. Weil genau diese Daten am meisten von „Harvest-now, decrypt-later“-Angriffen bedroht sind. Wenn jemand heute den Datenverkehr abfängt, kann er ihn mit ML-KEM selbst bei Besitz eines Quantencomputers in der Zukunft nicht entschlüsseln. Klassischer ECDHE bietet eine solche Widerstandsfähigkeit nicht.

Vierte Empfehlung: Vorbereitung von ACME und DevOps auf die postquantische Welt.
Hier beginnt ebenfalls eine Revolution. ACME muss so umgebaut werden, dass es hybride CSRs (Composite SPKI) generiert und Schlüssel in Dual-Key-Formaten speichert. CI/CD-Systeme müssen Updates erhalten, die die Generierung und Rotation hybrider Zertifikate ermöglichen. Automatisierung funktioniert nicht, wenn ihre Elemente keine neuen ASN.1-Strukturen unterstützen – und das ist leider ein häufiges Problem.

Schließlich betrifft die fünfte Empfehlung etwas, von dem viele Unternehmen nichts wissen: Hybride Zertifikate und hybrides TLS sind nur eine Übergangsphase. Sie sind kein Endziel. Das Ziel ist vollständig postquantisches TLS – eines, in dem das Zertifikat keinen ECDSA-Schlüssel mehr enthält, sondern nur ML-DSA, und der Handshake nicht ECDHE verwendet, sondern ausschließlich PQC-KEM. Dies wird erst möglich sein, wenn alle Client-Implementierungen von TLS bereit sind. Daher sind die Jahre 2025-2030 eine Zeit, die als Phase der Hybrid-Migration bezeichnet werden kann. Unternehmen, die früh in diese Phase eintreten, haben Zeit, Kompatibilitätsprobleme zu lösen und ihre Umgebungen schrittweise anzupassen. Unternehmen, die 2028 oder 2029 eintreten, werden mehrere Jahre Rückstand auf einmal aufholen müssen – oft unter Stress, unter regulatorischem oder marktseitigem Druck.

Daher ist die finale Empfehlung eindeutig: PQC ist keine „Option“, sondern eine Notwendigkeit – und je schneller die Infrastruktur auf Hybrid umgestellt wird, desto leichter wird der vollständige Migrationsprozess in einigen Jahren sein.
Hybride Zertifikate und hybrider TLS-Handshake sind nicht nur Technologie. Sie sind das Fundament der Widerstandsfähigkeit jedes Systems gegen zukünftige Angriffsformen. Sie jetzt zu implementieren, ist der einzige Weg, um nicht in einer Welt aufzuwachen, in der die Kryptografie, auf die wir zwei Jahrzehnte vertrauten, keine reale Sicherheit mehr bietet.

FAQ – Hybride Zertifikate 2025: Wie funktioniert TLS wirklich mit ECDSA + PQC-Signatur?

Was genau ist ein hybrides X.509-Zertifikat?

Ein hybrides X.509-Zertifikat ist ein Zertifikat, das zwei unabhängige öffentliche Schlüssel enthält: einen klassischen (meistens ECDSA P-256/P-384) und einen postquantischen (ML-DSA aus der NIST-PQC-Familie). Beide Schlüssel sind in einer gemeinsamen Composite-SPKI-Struktur platziert, wodurch das Zertifikat in klassischen Umgebungen funktionieren und gleichzeitig Widerstandsfähigkeit gegen zukünftige Quantenangriffe bieten kann.

Wie funktioniert die hybride Signatur ECDSA + PQC im Zertifikat?

Die hybride Signatur sind zwei unabhängige Signaturen, die von einem Subjekt ausgeführt werden:

• ECDSA signiert die TBS (To-Be-Signed)-Struktur des Zertifikats,
• ML-DSA signiert dasselbe TBS-Material.

Es entsteht eine „CompositeSignature“-Struktur, die der Client auf zwei Arten verwenden kann:

1. Klassische Verifizierung: Der Client überspringt den PQC-Teil und prüft nur ECDSA.
2. PQC-Verifizierung: Der Client ignoriert ECDSA und verifiziert ML-DSA.

Ein Client, der beide unterstützt, kann parallel verifizieren.

Ist ein hybrides Zertifikat mit heutigen Browsern kompatibel?

Ja. Wenn ein Browser PQC nicht unterstützt, ignoriert er einfach die Composite-Struktur und verwendet ECDSA – genau so, als wäre es ein normales ECDSA-Zertifikat. Dadurch besteht kein Risiko des Verlusts der Abwärtskompatibilität.

Wie validiert die CA eine CSR mit hybridem Schlüssel?

Die CA muss unterstützen:

• Composite SPKI,
• Composite-OID,
• doppelte CSR-Signatur,
• PQC-Bibliotheken im Backend (z.B. OpenSSL 3.x + PQC-Provider).

Die CA verifiziert beide Signaturen in der CSR, kann aber verlangen, dass mindestens eine Methode kryptografisch sicher ist (normalerweise ECDSA).

Verändert ein hybrides Zertifikat den TLS-Handshake?

Ja – der Handshake wird hybrid:

• Die klassische Seite verwendet ECDHE (Elliptic-Curve Diffie-Hellman),
• Die PQC-Seite verwendet KEM (Key Encapsulation Mechanism), meistens ML-KEM.

Beide Geheimnisse (klassisch + PQC) werden durch HKDF zu einem joint_secret kombiniert, der die Sitzung schützt. Dies stellt sicher, dass, selbst wenn ein Teil gebrochen wird, der andere die Daten weiterhin schützt.

Erhöhen hybride Zertifikate die Handshake-Größe?

Ja – und zwar erheblich.

• Ein klassisches ECDSA-Zertifikat hat normalerweise 1-3 KB,
• Ein hybrides Zertifikat kann 10-25 KB oder mehr haben.

Dies kann sich auswirken auf:

• alte TLS-Stacks,
• IoT mit kleinen Puffern,
• Server mit MTU-Limits,
• Geräte mit begrenztem Speicherplatz.

In standardmäßigen Umgebungen tritt das Problem nicht auf.

Werden hybride Zertifikate verpflichtend?

Nicht jetzt – aber sie werden de facto erforderlich in den Jahren:

• 2026-2027 – staatlicher und kritischer Sektor,
• 2027-2028 – Finanzsektor,
• 2028+ – die Mehrheit der kommerziellen Infrastruktur.

Zukünftige Standards aus der NSA CNSA 2.0-Linie und EU-Anforderungen (NIS2, CRA) werden dazu führen, dass klassische Algorithmen als Legacy-Kryptografie klassifiziert werden.

Kann man weiterhin nur ECDSA-Zertifikate verwenden?

Ja, aber:

• sie schützen nicht vor „Harvest-now, decrypt-later“-Angriffen,
• sie werden für hochvertrauliche Daten als unzureichend angesehen,
• sie werden ab 2028 als temporär behandelt.

ECDSA wird weiterhin verwendet, aber als Fallback, nicht als primärer Sicherheitsmechanismus.

Sind hybride Zertifikate schwieriger zu implementieren?

Ja – insbesondere im Backend. Probleme treten normalerweise auf in:

• Load Balancern (F5, Citrix, HAProxy),
• alten OpenSSL-Versionen,
• IoT/Embedded-TLS-Stacks,
• mTLS-Bibliotheken (Java, Go, Python),
• CT-Logs (Protokollierung großer Zertifikate).

In modernen Umgebungen (OpenSSL 3.x, neuere TLS-Bibliotheken) ist die Implementierung stabil.

Unterstützt ACME hybride Zertifikate?

Bisher nur experimentell. ACME v3.0 soll einführen:

• Composite-CSR,
• Unterstützung für Dual-Key,
• neue OIDs für PQC,
• Vorwärts-/Rückwärtskompatibilität.

Unternehmen, die Zertifikatsautomatisierung nutzen, müssen ihre CI/CD-Pipeline auf neue CSR-Typen vorbereiten.

Wie sieht die Verifizierung der hybriden Signatur im Browser aus?

Der Mechanismus ist einfach:

• wenn der Client PQC kennt, verifiziert er beide Signaturen (ECDSA + ML-DSA),
• wenn er PQC nicht kennt – verwirft er den Hybrid-Teil und verifiziert ECDSA.

Dadurch funktioniert das Zertifikat in der neuen und alten Welt.

Sind hybride Signaturen sicherer als klassische?

Ja – weil beide Algorithmen gleichzeitig gebrochen werden müssen (in der Praxis über viele Jahre unrealistisch). ECDSA schützt heute → PQC schützt morgen.

HEXSSL Insight ist eine Reihe von Expertenanalysen, die der Zukunft von TLS, PKI, Zertifikatsautomatisierung und kryptografischer Sicherheit gewidmet sind. Das Ziel der Serie ist die Vermittlung von Wissen über Trends, Technologien und regulatorische Veränderungen, die die Internet-Sicherheit beeinflussen.