© alexandersikov / 123RF.com

Noch können Quantencomputer keine kryptografischen Verfahren knacken, aber niemand weiß, wie lange das noch so bleibt. Wer sich heute schon quantenresistent wappnen will, stößt allerdings auf etliche Hindernisse.

Es kann gut sein, dass es auch in den kommenden 40 Jahren in jedem Jahr immer wieder aufs Neue heißt, innerhalb nächsten 20 Jahre stünden nun tatsächlich praktisch einsetzbare Quantencomputer bereit. Genau dasselbe hieß es in den letzten 40 Jahren für Kernfusionskraftwerke. Doch niemand mag die Hand dafür ins Feuer legen, dass nicht doch ein Physiker oder Mathematiker einen Geistesblitz hat und es in einigen Jahren Quantencomputer gibt, die tatsächlich aktuelle Kryptoalgorithmen wie RSA und ECDSA zur Makulatur werden lassen.

Gut also, dass das amerikanische National Institute of Standards and Technology (NIST) im August 2024 quantenresistente Nachfolgeverfahren standardisiert hat. Damit ist die Welt für den Fall der Quantencomputerfälle gerüstet – oder? Bei näherem Hinsehen ist für komplexe Querschnittsinfrastrukturen wie eine PKI (Public Key Infrastructure) die Vorbereitung auf den Umstieg momentan in etwa so weit gediehen wie ein Hausbau, bei dem eben die Steine geliefert wurden und die Bauarbeiter anfangen, die Baugrube für das Fundament auszuheben. Allerdings liegt noch kein Bauplan vor, weil die Architekten verschiedene Entwürfe für den Grundriss geliefert haben und sich über die Form des Dachs nicht einig sind. Derweil wird der Bauherr genötigt, spätestens in fünf Jahren einzuziehen.

Quantencomputer und PKI

Mit der Entwicklung ausreichend starker Quantencomputer steht die Sicherheit klassischer asymmetrischer Kryptoverfahren wie RSA und ECDSA jedenfalls auf der Kippe [1]. Mit dem Algorithmus von Shor lässt sich das Problem der Faktorisierung großer Ganzzahlen sowie das Problem des diskreten Logarithmus, auch auf elliptischen Kurven, durch einen Quantencomputer mit ausreichender Rechenleistung in polynomialer Zeit lösen. In welchem Zeitrahmen Quantencomputer tatsächlich zur Bedrohung für aktuelle kryptografische Verfahren werden, lässt sich aktuell nur vermuten. Das BSI schätzt in einer aktuellen Studie, dass das “mindestens ein Jahrzehnt, wahrscheinlicher zwei” dauern wird, “sofern keine Disruptionen stattfinden” [2].

Auch wenn man derzeit sowohl über den Zeitraum als auch die grundsätzliche Möglichkeit der Entwicklung eines kryptografisch relevanten Quantencomputers nur Spekulationen anstellen kann, löste der lange Vorlauf bis zum praktischen Einsatz von alternativen Verfahren entsprechende Aktivitäten aus. In Reaktion auf die Bedrohung klassischer asymmetrischer Verfahren durch Quantencomputer entstand das Feld der Postquantenkryptografie (Post-Quantum Cryptography, PQC). PQC beschäftigt sich mit der Entwicklung asymmetrischer Verfahren, deren zugrunde liegende Probleme auch Quantencomputer nicht beschleunigt lösen können.

Die US-Standardisierungsbehörde NIST richtet seit 2016 einen Wettbewerb zur Ermittlung von neuen, gegen Quantencomputer resistenten Verfahren aus. Aktuell wurden mit dem Module-Lattice-Based Digital Signature Algorithm (ML-DSA [3], früher CRYSTALS-Dilithium) und dem Stateless Hash-Based Digital Signature Algorithm (SLH-DSA [4], ehemals SPHINCS+) zwei Signaturverfahren als Standard publiziert. Den quantenresistenten Verfahren ist gemeinsam, dass sie im Hinblick auf die Größe der Signaturen und Schlüssel sowie die Rechenzeit den klassischen Verfahren klar unterlegen sind [5]. Weiterhin existiert für diese Verfahren und die ihnen zugrunde liegenden mathematischen Probleme kein Beweis für die Nichtexistenz eines schnellen Angriffs auf herkömmlichen oder Quantencomputern.

Diese Problematik veranschaulicht das Schlüsselaustauschverfahren SIKE: Als hoffnungsvoller Kandidat kam es bis in die vierte Runde des NIST-Wettbewerbs, um dann von Forschern aufgrund bislang nicht beachteter mathematischer Eigenschaften in kürzester Zeit auf einem herkömmlichen Rechner gebrochen zu werden [6]. Das BSI empfiehlt den Einsatz quantenresistenter Verfahren daher auch grundsätzlich nur in Kombination mit einem klassischen Verfahren als sogenanntes Hybridverfahren [7].

Herausforderung PKI

In Forschung und Praxis liegt der Fokus der Untersuchungen im Bereich quantenresistente Verfahren bislang vor allem auf Verfahren für den asymmetrischen Schlüsselaustausch und deren Anwendung beispielsweise in TLS [8] oder bei sicherem Messaging [9]. Im Vordergrund steht die Bedrohung durch Angriffe nach dem Prinzip “store now, decrypt later” [10]: Angreifer könnten verschlüsselte Kommunikation, die klassische Verfahren wie RSA anwendet, schon jetzt (verschlüsselt) speichern (“Store now”), um sie später, wenn ein Quantencomputer entsprechender Stärke existiert, entschlüsseln zu können (“Decrypt later”). Dieses Angriffsszenario sorgt für direkten Handlungsbedarf, vor allem im Bereich hochsensibler Daten, die auch über einen langen Zeitraum vertraulich gehalten werden sollen.

Bei digitalen Signaturverfahren ist ein solcher Angriff zwar prinzipiell ebenfalls möglich. Signaturen zur Authentifizierung sind jedoch meist mit einem Gültigkeitszeitraum versehen und werden ab dem Gültigkeitsende daher nicht mehr anerkannt. Für die Einstufung des Risikos einer Bedrohung durch Quantencomputer ist folglich vor allem die beabsichtigte Nutzungsdauer der privaten Schlüssel entscheidend: Sie kann erheblich länger sein. Einige der langlebigsten privaten Schlüssel finden sich nicht in Messenger-Protokollen, die Schlüssel regelmäßig rotieren und mit Perfect Forward Secrecy die Entschlüsselung älterer Nachrichten verhindern, sondern in den Root-CA-Zertifikaten von Public-Key-Infrastrukturen (PKIs). Um Probleme durch auslaufende CA-Zertifikate zu minimieren, haben diese oftmals sehr lange Gültigkeiten von mehreren Jahren bis Jahrzehnten.

Ein weiteres Einsatzfeld langlebiger Signaturschlüssel sind Firmware-Signaturen. Google empfiehlt dafür in einem Blog-Beitrag den Einsatz Hash-basierter quantenresistenter Verfahren wie SLH-DSA, da angenommen wird, die langfristige Sicherheit der Hash-basierten Verfahren sei normalerweise höher [11]. Das liegt daran, dass sich die Sicherheit von Hash-basierten Verfahren auf die jeweils verwendete Krypto-Hash-Funktion reduzieren lässt. Die gilt im Vergleich zu auf Gittern (Lattices) basierenden Verfahren als besser von der kryptologischen Forschung untersucht und erprobt.

Für die Einschätzung eines angemessenen Migrationszeitraums hat Michele Mosca eine Ungleichung aufgestellt, die auf drei Variablen basiert [12]:

• x: Wie viele Jahre müssen die verwendeten Schlüssel gültig sein?
• y: Wie viele Jahre erfordert die Migration des Systems auf quantenresistente Verfahren?
• z: In wie vielen Jahren wird mit einem ausreichend starken Quantencomputer gerechnet, der die Sicherheit der aktuell eingesetzten Verfahren kompromittiert?

Falls eine Migration zu quantenresistenten Algorithmen sofort gestartet wird, benötigt diese y Jahre. Die letzten erzeugten klassischen Schlüssel müssen dann selbst nochmals x Jahre lang sicher bleiben. Bei x + y > z besteht für den Zeitraum x + y – z ein Risiko für die Sicherheit der verwendeten Schlüssel. Bei beabsichtigten Nutzungsdauern im Bereich von 15 bis 30 Jahren für Root-CA-Zertifikate wird diese Ungleichung schnell ungünstig. Dabei gilt es zu berücksichtigen, dass sich Zertifikate auch sperren lassen oder bei einer vollständigen Migration ersetzt werden können. In diesem Fall ist die Nutzungsdauer entsprechend kürzer. Gleichwohl lässt sich festhalten, dass man eine Migration auf PQC-Verfahren nicht zu spät angehen sollte. Das gilt ganz besonders für langlebige Root-Zertifikate.

Andererseits ist davon auszugehen, dass die meisten Public-Key-Infrastrukturen eine längere Migrationsphase benötigen, die den Parallelbetrieb von quantenresistenten und klassischen Verfahren erfordert. Eine PKI muss eine Vielzahl von unterschiedlichen Anwendungen und Gerätetypen unterstützen, die sich teilweise nur eingeschränkt mit neuer Funktionalität ausstatten lassen. In einem Unternehmensnetz zählen dazu beispielsweise Drucker, Netzwerkkomponenten, PCs, Server, Appliances und so weiter. Ein zügiger Umstieg auf quantenresistente Verfahren zu einem festen Stichtag ist daher für viele Einsatzszenarien nicht realistisch. Andererseits sollte man im Sinne von Moscas Ungleichung in Fällen, in denen die beteiligten Anwendungen quantenresistente Verfahren nutzen können, nicht zu lange mit dem Umstieg warten.

Ansätze

Der wohl naheliegendste Ansatz für die Migration einer PKI auf quantensichere Verfahren ist der parallele Aufbau einer zusätzlichen PKI-Hierarchie, die durchgängig quantensichere Verfahren verwendet. Das kann in Reinform erfolgen oder wie etwa vom BSI empfohlen hybrid in Kombination mit einem etablierten Signaturverfahren wie RSA oder ECDSA. So lassen sich verschiedene PKI-Anwendungsfälle Schritt für Schritt mit dem erhofften Sicherheitsgewinn auf die neue Infrastruktur migrieren. Legacy-Anwendungen oder Komponenten, die die neuen Verfahren (noch) nicht unterstützen, können für einen festzulegenden Migrationszeitraum weiter die klassische PKI verwenden.

Die Vergabe von Zertifikaten kann sich in diesem Ansatz nach drei einfachen Policy-Regeln richten: Legacy-Zertifikatsinhaber erhalten ein Zertifikat aus der klassischen PKI-Hierarchie. PQC-fähige Zertifikatsinhaber, die ihr Zertifikat in Einsatzszenarien verwenden, bei denen alle Zertifikatsprüfer (Relying Parties) ebenfalls PQC-fähig sind, erhalten ein Zertifikat aus der quantenresistenten PKI-Hierarchie. PQC-fähige Zertifikatsinhaber, die ihr Zertifikat in Einsatzszenarien verwenden, bei denen mindestens einige mögliche Zertifikatsprüfer (Relying Parties) nicht PQC-fähig sind, erhalten zwei Zertifikate, je eines aus beiden PKI-Hierarchien.

In der Praxis können sich für den zweiten und dritten Typ der Zertifikatsinhaber möglicherweise Probleme aufgrund der auf ein Vielfaches (ein Faktor von 7,5 erscheint nicht unrealistisch, siehe unten) gestiegenen Größe von Zertifikaten und Schlüsseln ergeben. Vor besondere Herausforderungen stellt jedoch der dritte Typ den Zertifikatsinhaber: Wie kann er entscheiden, welches seiner beiden Zertifikate er nutzen soll?

Im Fall von TLS bietet das Protokoll bereits einen Lösungsansatz für Server beziehungsweise Clients, die über je ein klassisches und ein quantenresistentes Zertifikat verfügen: Bei der Verwendung von TLS 1.2 oder früher kann der Server davon ausgehen, dass der TLS-Client eine Legacy-Komponente ist, und nutzt sein klassisches TLS-Serverzertifikat. Kommt dagegen TLS 1.3 zum Einsatz und der Client signalisiert bei der Cryptographic Negotiation im Client-Hello [13], dass er das passende quantenresistente Signaturverfahren unterstützt, verwendet der TLS-Server sein quantenresistentes TLS-Serverzertifikat. Anderenfalls nutzt er das klassische. Bei einer eventuellen TLS-Client-Authentifikation verwendet ein PQC-fähiger Client sein quantenresistentes TLS-Clientzertifikat, falls der Server ebenfalls ein quantenresistentes Zertifikat gesendet hat, anderenfalls sein klassisches.

Das lässt sich jedoch nicht direkt auf alle zertifikatsnutzenden Sicherheitsprotokolle übertragen: Beim IPsec-Schlüsselaustausch kann man ähnlich verfahren wie bei TLS. Wird ein altes Schlüsselaustausch-Protokoll wie IKEv1 genutzt, ist davon auszugehen, dass es sich bei der Gegenseite um eine Legacy-Komponente handelt, und wählt das Legacy-Zertifikat aus. Bei IKEv2 [14] findet zunächst im »IKE_SA_INIT«-Exchange eine Aushandlung statt, die auch den Schlüsselaustauschmechanismus umfasst. Dafür wurden mit RFC 9370 [15] bereits Kennungen für quantenresistente Schlüsselaustauschalgorithmen vergeben. Einigen sich IKEv2-Initiator und -Responder auf einen solchen Algorithmus, können beide davon ausgehen, dass die Gegenseite bereits PQC-fähig ist und – sofern vorhanden – ihr quantenresistentes Zertifikat nutzen. Anderenfalls bleibt es beim Legacy-Zertifikat.

Allerdings könnte es im Einzelfall passieren, dass die Gegenstelle zwar einen quantenresistenten Schlüsselaustausch beherrscht, aber dennoch keine PQC-Zertifikate nutzen kann. RFC 9370 [15] richtet sich explizit gegen Angriffe nach dem Muster “Store now, decrypt later” und geht davon aus, dass die Authentifikation per Signatur mit klassischen Algorithmen stattfindet.

Bei einer zertifikatsbasierten PKINIT-Authentifikation [16] beim Abruf eines Kerberos-Tickets [17] ist bereits das Request-Attribut »PA_PK_AS_REQ« signiert. Ein PQC-fähiger Client mit zwei Zertifikaten muss sich also entscheiden, welches davon er nutzt, um mit dem zugehörigen Private-Key den Request zu signieren. Hier bietet sich folgende Strategie an: Zunächst nutzt der Client sein quantenresistentes Zertifikat. Falls das Kerberos Key Distribution Center (KDC) ein Legacy-System ist und das nicht versteht, antwortet es mit einer Fehlermeldung, etwa mit »KDC_ERR_CANT_VERIFY_CERTIFICATE«. In diesem Fall wiederholt der Client den Anmeldeversuch mit seinem Legacy-Zertifikat. Allerdings kann es hierbei durch den Fehlversuch zu Fehlermeldungen und Alarmen kommen. Das KDC wiederum wählt sein Serverzertifikat analog des vom Client empfangenen Zertifikatstyps aus.

Bei S/MIME muss man beim Einsatz von PQC-Verfahren grundsätzlich mit getrennten Zertifikaten arbeiten, da die quantenresistenten Algorithmen für Signatur und Key Encapsulation unterschiedliche Schlüssel haben. Diese Schlüsseltrennung unterstützen viele, aber nicht alle der heutigen E-Mail-Clients.

Für die S/MIME-Verschlüsselung kann der Inhaber eines E-Mail-Postfachs sowohl ein Legacy-Verschlüsselungszertifikat als auch ein quantenresistentes bereitstellen, zum Beispiel in einem LDAP-Verzeichnis. Absender mit einem Legacy-E-Mail-Client werden das quantenresistente Zertifikat nicht validieren können, sodass im Idealfall automatisch das Legacy-Zertifikat zur Verschlüsselung verwendet wird.

Neue E-Mail-Clients sollten ebenso automatisch das quantenresistente Zertifikat zur Verschlüsselung nutzen, sofern ein solches für den Empfänger zum Abruf bereitsteht. Hier treten jedoch im Einzelfall unter Umständen Fehlentscheidungen auf, da potenzielle Absender S/MIME-Verschlüsselungszertifikate auf unterschiedlichen Wegen erhalten können. Dazu zählen neben LDAP unter anderem auch signierten S/MIME-Mails und eine manuelle Konfiguration.

Eine quantenresistente S/MIME-Signatur kann man bei einer signierten und verschlüsselten Mail verwenden, sofern die Verschlüsselungszertifikate aller Empfänger quantenresistent sind, anderenfalls wählt man das Legacy-Signaturzertifikat. Eine nur signierte, aber nicht verschlüsselte Mail fällt unter die nachfolgend betrachteten allgemeinen digitalen Signaturen.

Digitale Signaturen haben diverse Einsatzszenarien, unter anderem bei Dokumenten wie PDFs, XML-Signaturen, JSON Web Signatures (JWS), Codesignaturen, reinen S/MIME-Signaturen oder Timestamps. Oft ist es zum Zeitpunkt der Signaturerstellung noch nicht vollständig klar, welche Anwendungskomponenten die Signatur später prüfen werden und wann das geschieht. Um so weit wie möglich die Sicherheit durch quantenresistente Verfahren zu nutzen, ohne dabei Legacy-Signaturvalidierer auszuschließen, muss man also zweimal signieren, mit beiden Zertifikaten und Schlüsselpaaren.

Dabei sollte idealerweise die quantenresistente Signatur so eingebettet werden, dass Legacy-Komponenten sie ignorieren, ohne einen Fehler zu melden. Bei CMS-basierten Signaturen – also in den meisten oben genannten Fällen, mit Ausnahme von XML-Signaturen und JWS) – bietet es sich an, ein unsigniertes Attribut ähnlich der »countersignature« [18] zu verwenden. Allerdings bezieht sich eine »countersignature« ausschließlich auf den – im betrachteten Fall nicht quantenresistenten – Signature-Wert der primären Signatur und nicht direkt auf den »messageDigest«. Man muss also gegebenenfalls ein ähnliches, aber neues CMS-Attribut spezifizieren, dessen Signatur auch explizit den »messageDigest« der insgesamt zu signierenden Daten einbezieht.

JWS unterstützt das Anbringen mehrerer Signaturen. Allerdings bleibt es der validierenden Anwendung überlassen, ob es ihr genügt, eine der Signaturen erfolgreich validieren zu können oder ob alle erfolgreich validiert werden müssen [19]. Für XML-Signaturen wären weitergehende Erweiterungen zu definieren, um eine alternative, für Legacy-Komponenten ignorierbare quantenresistente Signatur einzubetten.

Ein Exot unter den X.509-Zertifikaten sind die Verified Mark Certificates, mit deren Hilfe E-Mail-Clients das verifizierte Unternehmenslogo der Absender-Domain einer E-Mail anzeigen können [20]. Dazu muss der Download-URI für das Verified Mark Certificate in einem TXT-Record in der DNS-Domain des Mailabsenders bereitstehen. Dabei ist nur ein URI für genau ein Zertifikat vorgesehen.

Um in der Migrationsphase von Legacy-Zertifikaten zu quantenresistenten Zertifikaten eine möglichst hohe Flexibilität zu erreichen, wurden daher Ansätze entwickelt und teilweise bereits standardisiert, um die Informationen zu klassischen und quantenresistenten Schlüsseln und Signaturen in einem einzigen Zertifikat zu kodieren. Damit braucht der Zertifikatsinhaber stets nur dieses eine Zertifikat. Die Entscheidung, ob klassische oder quantenresistente Verfahren zum Einsatz kommen (können), wird zum Zertifikatsprüfer (Relying Party) verlagert.

Im ITU-T-Standard X.509, der Public-Key-Zertifikate spezifiziert, wurde bereits 2019 für eine sanfte Migration aller PKI-Teilnehmer auf einen neuen Signaturalgorithmus die Möglichkeit geschaffen, einen alternativen öffentlichen Schlüssel anzugeben. Optional wird das Zertifikat von der ausstellenden CA doppelt signiert, jeweils mit einem herkömmlichen Schlüssel und als alternative Signatur mit einem quantenresistenten Schlüssel. Damit lassen sich die Zertifikate in einer einzigen PKI verteilen, die Entscheidung über die Verwendung des quantenresistenten Verfahrens bleibt den jeweiligen Relying-Party-Anwendungen überlassen. Für die alternativen Signaturen werden X.509-Zertifikatserweiterungen verwendet. Das hat den Vorteil, dass Anwendungen, die diese Erweiterung nicht unterstützen, die Erweiterung einfach ignorieren und weiterhin das klassische Signaturverfahren nutzen können. Durch den Standard lässt sich die Verifizierung von Zertifikaten mit alternativer Signatur somit in drei Fälle unterscheiden.

Der erste Fall betrifft Implementierungen, die die Erweiterung nicht unterstützen und erkennen. Da die Erweiterung als nicht-kritisch deklariert ist, ignoriert die Implementierung sie und verifiziert wie bei einem regulären X.509-Zertifikat die klassische Signatur. Wäre die Erweiterung als kritisch angegeben, könnte das Zertifikat nicht erfolgreich validiert werden.

Daneben kann es Implementierungen geben, die die Erweiterung unterstützen, den für die alternative Signatur verwendeten Algorithmus aber nicht. Sie ignorieren die alternative Signatur und verifizieren das Zertifikat genauso wie eine Implementierung, die die Erweiterung nicht unterstützt.

Im Idealfall unterstützt die Implementierung sowohl die Erweiterung als auch das für die alternative Signatur verwendete Signaturverfahren. Sie verifiziert dann standardgemäß nur die alternative Signatur.

Bonnell et al. stellen im Internet-Draft “A Mechanism for Encoding Differences in Paired Certificates” [21] einen weiteren Ansatz für eine Migration von Zertifikaten vor, der keine plötzliche Umstellung aller Clients erfordert. Wie der Name schon andeutet, handelt es sich dabei um eine Zertifikatserweiterung, die es einem Zertifikat ermöglicht, “zu einem anderen zu werden”. Das Zertifikat enthält Informationen, aus denen sich ein weiteres Zertifikat mit einem anderen Signaturverfahren rekonstruieren lässt. Auf diese Weise lassen sich zwei Zertifikate mit gleichem Subject und so weiter erstellen und in einem Zertifikat transportieren. Der Internet-Draft verwendet dazu ebenfalls X.509-Zertifikatserweiterungen.

Der Vorteil dieses Ansatzes im Vergleich zu den in X.509 beschriebenen alternativen Signaturen liegt darin, dass jeder öffentliche Schlüssel hier in einem eigenen vollwertigen Zertifikat mit eigener Serial Number steht und sich die gemeinsam enkodierten Zertifikate bei Bedarf auch einzeln einsetzen lassen.

Stand der Dinge

Für die Interoperabilität verschiedener Anwendungen und Geräte in einer PKI ist es essenziell, dass diese einheitlichen Standards und Protokollen folgen. Ein großes Hindernis bei der Migration auf eine quantenresistente PKI, insbesondere im Hinblick auf neue Erweiterungen für Zertifikate, ist die Fragmentierung der verschiedenen Standards. So wird der Aufbau von Public-Key-Zertifikaten und Zertifikatssperrlisten im Standard X.509 der ITU-T festgeschrieben. Andere etablierte Protokolle wie OCSP und Certificate Transparency werden wiederum in RFCs der IETF beschrieben. Der Umgang mit den in X.509 spezifizierten alternativen Signaturen ist daher auch nur für die ebenfalls in X.509 beschriebenen Mechanismen festgelegt. Für eine Anwendung in anderen Protokollen gibt es kein festgelegtes Vorgehen.

Im Rahmen einer Bachelor-Arbeit untersuchte einer der Autoren dieses Beitrags [22] die Bibliotheken OpenSSL (mit dem Open Quantum Safe Provider für quantenresistente Verfahren), die Java-Version von Bouncy Castle sowie die PKI-Lösung EJBCA hinsichtlich ihrer Unterstützung quantenresistenter Verfahren. Für die untersuchten Lösungen war eine triviale Verwendung quantenresistenter Signaturverfahren in X.509-Zertifikaten problemlos möglich.

Die Kapselung der kryptografischen Primitive in den Anwendungen ermöglicht die Integration der quantenresistenten Signaturen in X.509-Zertifikate bei allen untersuchten Implementierungen. EJBCA beschränkte sich zum Zeitpunkt der Untersuchung auf die “einfache” Verwendung von PQC-Verfahren; seit Version 8.3 werden nach Herstellerangaben auch Zertifikate mit alternativen Signaturen nach X.509 unterstützt [23]. Bei einzelnen Funktionalitäten wie Sperrmechanismen oder den vorgestellten Migrationsmechanismen konnten Abweichungen und Einschränkungen festgestellt werden. Eine Übersicht der Implementierungen findet sich in der Tabelle “Bibliotheken im Vergleich”.

Bei der Erstellung von Paired Certificates nach dem Internet-Draft von Bonnell et al. konnte in Bouncy Castle ein Bug entdeckt und den Entwicklern gemeldet werden, der bei einer Generierung von Paired Certificates mit gleichem Subject und Issuer zu einem Fehler führt. Dieser Fehler wurde laut Angabe der Entwickler zwischenzeitlich behoben.

Auch im Zusammenspiel der untersuchten Implementierungen traten Probleme auf. Die Bibliotheken OpenSSL und Bouncy Castle unterstützen zwar beide die Integration hybrider Signaturen in X.509-Zertifikate, verwenden jedoch unterschiedliche Ansätze zur Kodierung der Signaturen. Dadurch sind die Implementierungen in der Praxis nicht miteinander kompatibel. Hier fehlt es an einem einheitlichen Standard, nach dem Entwickler sich richten können.

Bouncy Castle nutzt den von Ounsworth et al. in einem Internet Draft [24] vorgestellten Ansatz zur Enkodierung der Signaturen. Dabei werden für die zusammengesetzte Signatur die zwei Object Identifier (OIDs) der verwendeten Signaturverfahren angegeben. Zudem werden die beiden Signaturen als »SEQUENCE« behandelt, lassen sich also aus der ASN1-Kodierung wieder einfach zerlegen. OpenSSL hingegen gibt den kombinierten Algorithmus als ein einzelnes Signaturverfahren mit einem einzigen OID an (beispielsweise das Verfahren RSA3072 Dilithium2 für die Kombination von RSA 3072 Bit mit ML-DSA auf NIST-Level 2). Die Signaturen sind konkateniert und als einzelner Bit-String im Zertifikat enthalten. Dieses Implementierungsdetail spielt für den Anwender keine Rolle, da die Verfahren bei zusammengesetzten Signaturen per Spezifikation nur kombiniert verwenden dürfen. Es führt allerdings dazu, dass die Implementierungen die verwendeten Signaturen untereinander nicht korrekt verifizieren können.

Bouncy Castle unterstützt die Erstellung von Zertifikaten mit einer alternativen Signatur nach dem in X.509 standardisierten Verfahren. Die entsprechende Erweiterung für einen alternativen öffentlichen Schlüssel lässt sich dabei automatisiert bei der Zertifikatserstellung erzeugen. Bei der abschließenden Erstellung des X.509-Zertifikats lässt sich – zusätzlich zu dem klassischen öffentlichen Schlüssel – der alternative öffentliche Schlüssel angeben. Die Implementierung signiert das Zertifikat daraufhin gemäß den Vorgaben des in X.509 festgelegten Verfahrens und erzeugt ein valides Zertifikat mit einer gültigen Signatur.

OpenSSL bietet keine Out-of-the-box-Lösung für die Erstellung von Zertifikaten mit alternativer Signatur. Erweiterungen lassen sich jedoch über Konfigurationsdateien frei angeben. Eine Möglichkeit besteht darin, das zu signierende TBSCertificate manuell zu erzeugen, die alternative Signatur darauf zu berechnen und anschließend ein Zertifikat mit den entsprechenden Erweiterungen mittels OpenSSL zu erstellen. Das erfordert jedoch (zumindest initial) größere manuelle Arbeiten.

Der Einsatz von PQC-Algorithmen erhöht die Größe der Zertifikate erheblich. In der Untersuchung konnte bei einem minimalen X.509-Zertifikat mit RSA-2048-Bit-Signatur und ML-DSA in der NIST-Stufe 3 eine Vergrößerung um einen Faktor von mehr als 7,5 festgestellt werden; bei SLH-DSA beträgt dieser Faktor sogar mehr als 22. Die Größe der untersuchten Zertifikate wird vor allem von dem quantenresistenten Signaturverfahren bestimmt. Komplexere Zertifikate mit alternativen Signaturen oder Paired Certificates sind daher nur geringfügig größer als Zertifikate, die nur eine einfache PQC-Signatur nutzen. Eine vergleichende Aufstellung von quantenresistenten Zertifikaten, welche mit Bouncy Castle erzeugt wurden, findet sich in der Tabelle “Größenvergleich der Zertifikate”. Bouncy Castle bietet keine Unterstützung für zusammengesetzte Signaturen mit demselben Signaturverfahren, weshalb die betreffende Zeile keine Werte enthält.

Derzeit gibt es abgesehen von der kompletten zweigleisigen Implementierung einer klassischen und einer quantenresistenten PKI-Hierarchie noch keine durchgängige Lösung, die alle Datenformate und Protokolle berücksichtigt, in denen potenziell Signaturen oder öffentliche Schlüssel auftauchen. Die oben dargestellten Lösungen für Alternative Signature oder Paired Certificates betrachten naheliegenderweise zunächst X.509-Zertifikate und -CRLs, teilweise auch PKCS#10 Certificate Signing Requests (CSR).

Im weiteren Verlauf des Wegs zu quantenresistenten Public-Key-Infrastrukturen gibt es jedoch weitere Aspekte zu betrachten und, je nach Lösungsansatz, Ergänzungen zu spezifizieren und zu implementieren. Dazu zählen die Signatur von OCSP-Responses und optional OCSP-Requests sowie die Verwendung von Public-Key-Hashes als Identifier, insbesondere in Key-Identifier-Erweiterungen und OCSP-Requests, aber auch etwa in DANE. Hinzu kommt CRMF als alternatives Antragsformat zu PKCS#10-CSR im CMP-Protokoll.

Es braucht Signaturen in Zertifikatsmanagementprotokollen wie CMC, CMP und SCEP-Signaturen, die die für viele öffentlich gültige Zertifikate geforderte, korrekte Veröffentlichung in Certificate-Transparency-Logs bestätigen. Außerdem fehlt bislang eine Möglichkeit, mit Public Keys von quantenresistenten reinen Key-Encapsulation-Mechanismen eine Proof-of-Possession-Signatur (zum Nachweis des Besitzes des zugehörigen Private Keys) für PKCS#10-CSR oder CRMF zu erstellen.

Bislang gibt es erst wenige Hardware-Security-Module (HSM) zum sicheren Verwahren und Nutzen von CA-Schlüsseln einer PKI, die quantenresistente Verfahren unterstützen. Eine Sicherheitszertifizierung können solche HSMs frühestens dann erwerben, wenn die einschlägige Standardisierung abgeschlossen ist und entsprechende Prüfrichtlinien vorliegen.

Fazit und Empfehlungen

Das Anwenden quantenresistenter Signaturverfahren zur Authentifizierung allgemein und speziell in Public-Key-Infrastrukturen hat im Vergleich zu quantenresistenten Verschlüsselungsverfahren bei Standardisierung und Implementierung aktuell eine niedrigere Priorität. Zwar existieren bereits verschiedene Ansätze, die jedoch alle noch weiter ausgearbeitet und korrekt implementiert werden müssen. Möglicherweise müssen diese Implementierungen dann auch noch zertifiziert werden. PKI-Betreiber stehen also vor der Herausforderung, einerseits getrieben von Moscas Ungleichung auf dem Weg zu einer quantenresistenten PKI voranzuschreiten. Andererseits bewegen sie sich dabei auf noch unzureichend kartografiertem Terrain, das unterschiedliche Kartenmacher beschreiben.

Je genauer der PKI-Betreiber die Anwendungen und Komponenten kennt, die seine Zertifikate nutzen (im Sinne einer “geschlossenen” PKI), desto besser lässt sich die Migration planen. Selbst dann müssen passende Produkte bereitstehen. Die Autoren schätzen, dass der notwendige Prozess der Standardisierung und Implementierung noch etwa fünf Jahre in Anspruch nehmen wird. Das deckt sich mit der Planung der National Security Agency (NSA), ab 2030 die Migration zu quantenresistenten Public-Key-Infrastrukturen für den entsprechend regulierten Bereich in den USA zu beginnen und sie bis 2033 abzuschließen [25]. Die Empfehlung für PKI-Betreiber lautet daher, für den Zeitraum ab 2030 mit einer PKI-Migration zu rechnen und größere Umstellungen an der PKI bis dahin aufzuschieben, wenn möglich. Sollte vorher ein quantenresistentes Root-CA-Zertifikat notwendig werden, ist es sinnvoll, analog zu den Empfehlungen von Google und der NSA für Firmware-Signaturen auf die besser erprobten Hash-basierten Signaturverfahren zu setzen.

Ein wichtiges Auswahlkriterium bei der Beschaffung jeglicher neuer zertifikatsnutzender Komponenten und Dienstleistungen sollte bis dahin die Kryptoagilität sein sowie die Bereitschaft der Hersteller, per Update die Unterstützung quantenresistenter Verfahren und Protokolle nachzurüsten. Das gilt sowohl für die PKI selbst als auch allgemein für Systeme oder Anwendungen wie TLS-Server. (jcb)