Sicherung der Zukunft der Code-Signierung mit CNSA 2.0-Konformität und PQC

Einführung

Die rasanten Fortschritte im Quantencomputing sind kein theoretisches Problem mehr, sondern eine drohende Bedrohung für die klassische Kryptografie. Algorithmen wie Shors Algorithmus, der große Ganzzahlen faktorisieren und diskrete Logarithmen exponentiell schneller berechnen kann als jeder klassische Algorithmus, drohen Algorithmen wie RSA und ECC zu brechen. Ebenso führt die Verwendung von Grovers Algorithmus zur Schwächung der symmetrischen Verschlüsselung, indem er die Schlüsselstärke effektiv halbiert und damit die Integrität kryptografischer Systeme mit kürzeren Schlüssellängen gefährdet. Dies hat erhebliche Auswirkungen auf grundlegende Sicherheitsprotokolle wie TLS, VPNs, digitale Signaturen und insbesondere die Code-Signierung.

Die US-amerikanische National Security Agency (NSA) hat die Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) eingeführt und veröffentlicht. Diese kryptografische Maßnahme erfordert die Verwendung von Post-Quanten-Kryptographie (PQC)-Algorithmen zur Sicherung nationaler Sicherheitssysteme (NSS) und vertraulicher Kommunikation. CNSA 2.0 ist nicht nur eine Empfehlung, sondern eine strategische Neuausrichtung, die von der Regierungspolitik unterstützt wird und darauf abzielt, Systeme sowohl gegen aktuelle als auch gegen zukünftige kryptanalytische Fähigkeiten abzusichern.

CNSA 2.0 benennt explizit ML-KEM (für Schlüsselkapselung) und ML-DSA (für digitale Signaturen) als erforderliche PQC-Algorithmen, die beide vom NIST im PQC-Standardisierungsprozess aufgrund ihrer hohen Sicherheits- und Leistungsmerkmale ausgewählt wurden. Diese Algorithmen basieren auf Gittern und basieren auf mathematischen Problemen, die im Gegensatz zu RSA und ECC als resistent gegen Quantenangriffe gelten. In diesem Blogbeitrag untersuchen wir die Details von CNSA 2.0 und seine algorithmischen Grundlagen. Wir zeigen außerdem, wie die Code Signing Solution von Encryption Consulting CodeSign Secure, ermöglicht es Organisationen, beim Übergang in die Post-Quanten-Ära Vertrauen, Integrität und Compliance bei der Softwareverteilung aufrechtzuerhalten.

Was ist CNSA 2.0?

CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) ist die neueste Suite kryptografischer Algorithmen, die von der US-amerikanischen National Security Agency (NSA) zur Sicherung nationaler Sicherheitssysteme (NSS) im Postquantenzeitalter vorgeschrieben wird. CNSA 2.0 wurde im September 2022 veröffentlicht und stellt einen bedeutenden Wandel in der kryptografischen Strategie dar. Es wurde ausdrücklich darauf ausgelegt, Risiken sowohl durch klassische als auch durch Quantenangriffe abzuwehren. Es ersetzt die älteren Protokolle CNSA 1.0 und Suite B und bringt nationale kryptografische Sicherheitsstandards mit modernen quantenresistenten Initiativen in Einklang.

Anders als die Post-Quantum Cryptography (PQC)-Standardisierung des NIST, die Algorithmen für den allgemeinen kommerziellen Einsatz bereitstellen soll, hat die NSA klare und dringende Erwartungen an den Übergang zu PQC durch CNSA 2.0 gesetzt, insbesondere in Umgebungen mit hohem Vertrauensniveau wie der Code-Signierung. Die Suite erzwingt den Einsatz quantenresistenter Algorithmen, da diese selbst gegen Quantencomputer hohe Sicherheit bieten und gleichzeitig veraltete Algorithmen wie RSA, DSA und Finite-Field-DH ablösen. Ob Sie die Produktsicherheit leiten, DevOps-Pipelines verwalten, kryptografische Systeme entwerfen oder die Einhaltung gesetzlicher Vorschriften sicherstellen – dieser Wandel betrifft Sie.

Entdecken Sie unseren ausführlichen Blog Beitrag um mehr über CNSA 2.0 im Detail zu erfahren.

CNSA 2.0 Kryptografische Algorithmen

Um den Herausforderungen durch fortgeschrittene klassische Bedrohungen und zukünftige Quantenangriffe zu begegnen, führt die CNSA 2.0-Suite eine Reihe kryptografischer Algorithmen entsprechend den verschiedenen Anwendungsfällen innerhalb nationaler Sicherheitssysteme (NSS) ein. Diese Algorithmen werden nach ihrer Anwendung kategorisiert, von der Software- und Firmware-Signierung bis hin zur universellen Public-Key-Kryptografie.

1. Algorithmen zur Software- und Firmware-Signierung

Einer der wichtigsten Anwendungsfälle, die unter CNSA 2.0 abgedeckt werden, ist die Code-Signierung. Bei der Code-Signierung handelt es sich um den Prozess der digitalen Signatur von Software, Firmware oder Updates, um zu beweisen, dass diese authentisch sind und nicht verändert wurden.

Da PQC immer dringlicher wird, zeichnen sich Hash-basierte Signaturalgorithmen durch ihre Reife, Sicherheitsgarantien und NSA-Zulassung im Rahmen der CNSA 2.0-Suite aus. Zwei primäre Algorithmen, Leighton-Micali Signature (LMS) und eXtended Merkle Signature Scheme (XMSS), bilden das Rückgrat der vertrauenswürdigen Code-Signatur zum Schutz nationaler Sicherheitssysteme (NSS) in einer Post-Quanten-Welt.

Diese Algorithmen unterscheiden sich grundlegend von traditionellen RSA- und ECDSA-Verfahren. Während letztere auf zahlentheoretischen Annahmen (z. B. diskreten Logarithmen oder ganzzahligen Faktorisierungsproblemen) beruhen, basieren LMS und XMSS auf den Sicherheitseigenschaften kryptografischer Hashfunktionen, wie z. B. Urbildresistenz, Kollisionsresistenz und Zweiturbildresistenz. Diese Eigenschaften bleiben selbst unter Grovers Algorithmus, der nur eine quadratische Beschleunigung bietet, quantenangriffsresistent und bieten somit das höchste Sicherheitsniveau.

Sowohl LMS als auch XMSS sind zustandsbehaftete Signaturverfahren. Das bedeutet, dass jede Signatur eindeutige interne Statusinformationen benötigt, die sicher verwaltet und nach jedem Signaturvorgang atomar aktualisiert werden müssen. Im Gegensatz zu RSA oder ECDSA, wo derselbe private Schlüssel zum Generieren mehrerer Signaturen verwendet werden kann, sind LMS/XMSS-Schlüssel an eine feste Anzahl gültiger Signaturen gebunden. Dies liegt daran, dass die Wiederverwendung eines Schlüsselstatus oder das Signieren zweier verschiedener Nachrichten mit demselben Status die Sicherheit gefährden und Angreifern das Fälschen zusätzlicher Signaturen ermöglichen kann.

In der Praxis führt dies zu strengen Anforderungen an:

• Statuspersistenz und Rollback-Schutz: Insbesondere in eingebetteten oder Firmware-Umgebungen müssen Systeme ein Rollback auf einen vorherigen Signaturstatus verhindern (z. B. aufgrund von Stromausfall oder Systemabstürzen).
• Atomare Signiervorgänge: Dies bezieht sich auf die Erkennung jeglicher Unterbrechung während der Signierung und die Möglichkeit zur Wiederherstellung, um eine erneute Verwendung zu vermeiden.
• Audit-Protokollierung und Schlüsselverwendungsverfolgung: Um die Integrität bei Neustarts oder Systemmigrationen sicherzustellen, muss ein Signaturzähler gepflegt und geschützt werden.

BMS

LMS, ursprünglich von Leighton und Micali entwickelt, ist für eingeschränkte Umgebungen wie Bootloader, Smartcards und Hardware-Sicherheitsmodule (HSMs). Es verwendet eine hierarchische Struktur von Merkle-Bäumen, wobei jedes Blatt mit einer Einmalsignatur (OTS) verknüpft ist. Das Schema unterstützt Parametersätze die eine Abstimmung zwischen Leistung, Größe und Sicherheit ermöglichen.

Aspekt	Details
Signaturgröße	1.2 KB – 3 KB
Leistung	LMS ist rechnerisch schneller als XMSS und daher für Echtzeit-Signaturvorgänge auf Geräten mit begrenzter CPU oder begrenztem Speicher attraktiv.
Luftüberwachung	Ideal für Umgebungen, in denen eine sichere und effiziente Firmware-Signierung entscheidend ist (z. B. IoT, BIOS/UEFI).

Einer der Vorteile von LMS ist seine zustandsloser Prüfer Modell. Dies bedeutet, dass für die Verifizierungsroutinen kein Status beibehalten werden muss, sodass LMS-Signaturen selbst in minimalen Umgebungen wie ROM-basierten Bootloadern oder Geräten mit Air-Gap-Funktion leicht validiert werden können.

XMSS

XMSS, spezifiziert in RFC 8391, bietet mehr Funktionen als LMS und führt Vorwärtssicherheit mit pseudozufälliger Schlüsselgenerierung und optionaler Schlüsselrandomisierung ein. Es eignet sich für Anwendungsfälle, die eine längerfristige kryptografische Sicherheit und anspruchsvollere Schlüsselverwaltungsmechanismen erfordern.

Aspekt	Details
Signaturgröße	Typischerweise 2 KB bis 5 KB, abhängig von Parametersätzen und Sicherheitsstufen.
Sicherheitseigentum	Bietet Vorwärtssicherheit, da es einen binären Merkle-Baum mit Hash-Ketten verwendet, um Einmalschlüssel abzuleiten. Dadurch wird sichergestellt, dass jede Signatur auch dann nicht gefälscht werden kann, wenn ein interner Status durchsickert.
Luftüberwachung	Geeignet für Umgebungen mit hoher Sicherheit, die einen starken Schlüsselschutz erfordern.

Der Rechenaufwand von XMSS ist höher als bei LMS, weshalb es sich besser für Systeme mit höherer Sicherheit und leistungsstarken Verarbeitungskapazitäten eignet, wie etwa Firmware-Signaturserver, sichere Codeverteilungsdienste oder Enterprise-PKI-Infrastrukturen, die auf PQC umstellen.

Hier ist ein kurzer Vergleich von LMS und XMSS, zwei nach NIST SP 800-208 standardisierten, hashbasierten digitalen Signaturschemata, die für die sichere Signierung von Firmware und Software entwickelt wurden:

Algorithmus	Funktion	Normen	Kenngrößen
Leighton-Micai-Signatur (LMS)	Asymmetrischer Algorithmus zum digitalen Signieren von Firmware und Software	NIST-SP 800-208	Alle Parameter für alle Klassifizierungsstufen zugelassen. SHA-256/192 empfohlen.
Erweitertes Merkle-Signaturschema (XMSS)	Asymmetrischer Algorithmus zum digitalen Signieren von Firmware und Software	NIST-SP 800-208	Alle Parameter sind für alle Klassifizierungsstufen zugelassen.

2. Quantenresistente Public-Key-Algorithmen

Mit dem Aufkommen des Quantencomputings gelten traditionelle Public-Key-Verfahren wie RSA, DH, ECDSA und ECDH nicht mehr als zukunftssicher. Im Rahmen der CNSA 2.0-Roadmap hat die NSA eine Reihe quantenresistenter Public-Key-Algorithmen definiert, die zukünftige NSS-Implementierungen steuern sollen. Während die endgültige Fassung des NIST FIPS Die Standardisierung dieser Algorithmen steht noch aus. Durch die frühzeitige Ankündigung der NSA können Entwickler, Anbieter und NSS-Betreiber jedoch mit der entsprechenden Planung und Entwicklung beginnen.

Da Public-Key-Algorithmen den Kern der Code-Signierung bilden, digitale Signaturen Die mit diesen Algorithmen generierten Codes garantieren die Authentizität und Integrität von Software und Firmware. Daher empfiehlt CNSA 2.0 ausdrücklich die sofortige Einführung hashbasierter Signaturverfahren wie Leighton-Micali Signature (LMS) und eXtended Merkle Signature Scheme (XMSS) für die Code-Signatur. Diese sind bereits standardisiert und für den Einsatz in nationalen Sicherheitssystemen (NSS) zugelassen.

Algorithmus	Funktion	Normen	Kenngrößen
ML-KEM	Asymmetrischer Algorithmus zur Schlüsselermittlung	FIPS203	Verwenden Sie Level-V-Parameter für alle Klassifizierungsstufen
ML-DSA	Asymmetrischer Algorithmus für digitale Signaturen	FIPS204	Verwenden Sie Level-V-Parameter für alle Klassifizierungsstufen

Anpassung von CNSA 2.0 an Code Signing-Praktiken 

Während Quantencomputing immer praktischer wird, sind traditionelle kryptografische Mechanismen, insbesondere solche, die auf RSA und ECC basieren, aufgrund ihrer Schwachstellen existenziellen Risiken ausgesetzt. Code Signing, ein grundlegendes Element der Sicherheit in der Software-Lieferkette, reagiert besonders empfindlich auf diese Änderungen. Es stellt sicher, dass Software-, Firmware- und Konfigurationsupdates aus einer vertrauenswürdigen Quelle stammen, während der Übertragung nicht manipuliert werden und vom Signierer nicht zurückgewiesen werden können.

Daher wird die Firmware-Signierung unter CNSA 2.0 als der „Signaturanwendungsfall mit der höchsten Priorität“ im Post-Quanten-Übergang identifiziert. Die Dringlichkeit rührt daher, dass in vielen Systemen der Firmware-Validierungsalgorithmus bei der Bereitstellung festgelegt wird und sich oft in unveränderlicher Hardware oder Boot-Level-Firmware befindet. Die ausgewählten Algorithmen LMS und XMSS sind vom NIST bereits in der Sonderveröffentlichung 800-208 standardisiert, im Gegensatz zu einigen anderen Post-Quanten-Signaturen, die sich noch in der Evaluierungsphase befinden, und die NSA erwähnt ausdrücklich die Notwendigkeit einer sofortigen Implementierung dieser Post-Quanten-Signaturschemata. Darüber hinaus unterstreicht CNSA 2.0 auch die Bedeutung der neu genehmigten Algorithmen des NIST, ML-KEM für den Schlüsselaustausch und ML-DSA für Signaturen, sobald diese vollständig standardisiert und in Hard- und Software unterstützt sind.

Navigieren durch die CNSA 2.0-Richtlinie und algorithmische Compliance für die Code-Signierung

Da die NSA ihren Übergangsfahrplan für quantenresistente Kryptografie (QRC) durch die CNSA 2.0 empfiehlt, müssen Organisationen, die nationale Sicherheitssysteme (NSS) aufbauen oder unterstützen, ihre Code-Signing-Implementierungen nun an einem präzisen Satz von Algorithmen ausrichten und betriebliche Einschränkungen einhalten.

Während CNSA 2.0 kryptografische Richtlinien vorgibt, ist es für kommerzielle Anbieter entscheidend, die Einhaltung von Richtlinien, insbesondere der in CNSSP 15, NSM-10 und der zugehörigen CNSS/NIAP-Dokumentation, zu verstehen. Wenn Ihr Unternehmen Software oder Firmware für NSS entwickelt, müssen Sie daher nicht nur die richtige Suite kryptografischer Algorithmen (CNSA 2.0) verwenden, sondern auch mehrere Richtlinien verschiedener Sicherheitsbehörden einhalten.

Die für jedes Produkt erforderliche kryptografische Haltung, insbesondere für Produkte, die vertrauliche Code-Signaturen oder Signaturvalidierungen durchführen, hängt von seiner Klassifizierung und seinem Anwendungsfall ab.

Für Geräte des Typs 1 (normalerweise in klassifizierten oder taktischen Systemen verwendet), kryptografische Implementierungen werden durch drei grundlegende Dokumente geregelt: CJCSN 6510.04, CNSSAM 01-07 und NSM-5 leitet die kryptografische Modernisierung für taktische und klassifizierte Systeme und erfordert ausdrücklich kryptografische Algorithmen, die für Code-Signaturvorgänge geeignet sind und eine sichere Firmware-Authentifizierung und -Integrität gewährleisten.

Darüber hinaus erfordern diese Dokumente gemeinsam die Verwendung von CNSA 2.0-zugelassenen kryptografischen Tools und geben klare Anweisungen dazu, wann und wie diese zu verwenden sind, insbesondere in Fällen, in denen die Firmware sicher bleiben muss und nach der Bereitstellung nur schwer aktualisiert werden kann.

Auf dem kommerzielle SeiteInsbesondere für Anbieter, die NSS- oder NIAP-validierte (National Information Assurance Partnership) Umgebungen bedienen möchten, muss die Compliance mit den genannten Richtlinien übereinstimmen:

• CNSSP 15: listet die genehmigten CNSA 2.0-Algorithmen auf, die von Code-Signaturschlüsseln und -prozessen befolgt werden müssen. Dadurch wird sichergestellt, dass alle digitalen Signaturen auf Software, die in nationalen Sicherheitssystemen (NSS) verwendet wird, stark genug sind, um zukünftigen Quantenangriffen standzuhalten.
• CNSSP 11 und NSM-10: Diese Richtlinien erfordern die Verwendung quantensicherer Algorithmen wie LMS und XMSS in Ihren Systemen und sagen Ihnen genau, wann und wo Sie diese verwenden dürfen (z. B. zum Signieren von Firmware).
• CNSSP 156: Diese Richtlinie definiert den offiziellen Migrationszeitraum (2025–2030) für die Umstellung von der alten Kryptografie (CNSA 1.0) auf den sichereren CNSA 2.0-Standard, einschließlich kryptografischer Algorithmen, die speziell für die Code-Signierung verwendet werden, und ermöglicht gleichzeitig Flexibilität für Systeme, die teuer oder schwer zu aktualisieren sind.

Ein wichtiger Punkt ist: Wenn Ihr System voraussichtlich nach 2030 genutzt wird, müssen Sie von Anfang an CNSA 2.0-zugelassene Algorithmen verwenden. CNSA 1.0 bleibt für bestimmte Legacy-Systeme akzeptabel, jedoch nur, wenn die kurzfristige kryptografische Gültigkeit oder die betriebliche Machbarkeit die weitere Verwendung rechtfertigen.

Algorithmusauswahl für Software- vs. Firmware-Signierung

Die NSA behandelt die Signierung von Software und Firmware als unterschiedliche Anwendungsfälle, die auf drei technischen Überlegungen beruhen:

1. Reife der Standards

Hash-basierte Signaturalgorithmen, LMS und XMSS, wurden zuvor von NIST über SP 800-208 standardisiert und verfügen über eine CAVP-Validierung, was sie zu den derzeit zugelassenen Optionen für die Software- und Firmware-Signatur unter CNSA 2.0 macht, während andere quantenresistente Signaturen möglicherweise nicht so einfach für die Integration verfügbar sind.

Diese Algorithmen sind „zustandsbehaftet“, d. h. sie erfordern eine sorgfältige Verwaltung der Einmalschlüssel. Sie eignen sich besonders für langfristige Systeme wie Firmware in eingebetteten oder eingeschränkten Geräten, bei denen eine spätere Aktualisierung des Signaturprozesses möglicherweise nicht praktikabel ist. Da LMS und XMSS bereits kommerziell verfügbar und validiert sind, empfiehlt die NSA, sie jetzt einzusetzen, anstatt auf die Verfügbarkeit neuerer Algorithmen zu warten.

ML-DSA, ein zustandsloser und gitterbasierter Signaturalgorithmus, ist ebenfalls unter CNSA 2.0 zugelassen, lässt sich aber möglicherweise nicht so einfach integrieren. Er kann zwar für alle Signieranwendungen, einschließlich Software und Firmware, eingesetzt werden, dürfte aber in Szenarien nützlicher sein, in denen eine große Anzahl von Signaturen benötigt wird oder die Signierung in einer verteilten Umgebung erfolgt. Nach der Validierung ist ML-DSA allgemein verfügbar und dürfte für viele Organisationen die bevorzugte Wahl sein. Jede Implementierung von ML-DSA oder ML-KEM muss jedoch FIPS 203 und 204 strikt einhalten, um als CNSA 2.0-konform zu gelten.

2. Dringlichkeit

Die NSA hat der Firmware-Signierung Priorität eingeräumt, da die kryptografischen Grundlagen wie Stammzertifikate, öffentliche Schlüssel oder sichere Boot-Schlüssel tief in der Hardware verankert sind und nach der Bereitstellung nicht einfach aktualisiert werden können. Daher ist die Sicherung eingebetteter Firmware mit quantensicheren Signaturen von höchster Priorität.

3. Leistungsausrichtung

LMS/XMSS verursachen höhere Leistungskosten (z. B. größere Signaturgrößen, langsamere Vorgänge), aber die Firmware-Signatur erfolgt selten und lokalisiert, was sie zur idealen Wahl macht. In Softwareumgebungen mit hohem Durchsatz kann ML-DSA nach der Validierung später übernommen werden.

Daher genehmigt die NSA derzeit nur LMS und XMSS für die Signierung in NSS-Umgebungen. Multi-Tree-Varianten wie HSS (Hierarchical Signature Scheme) und XMSSMT (XMSS Multi-Tree), die bereits in NIST SP 800-208 enthalten sind, sind für NSS noch nicht zulässig, wahrscheinlich aufgrund der Komplexität ihrer Multi-Tree-Statusverwaltung.

Im Zuge der CNSA 2.0-Umstellung werden Anbieter voraussichtlich mit der Integration der LMS- und XMSS-Signaturverifizierung in BIOS, UEFI und eingebettete Bootloader beginnen. Diese Hash-basierten Signaturschemata bieten quantenresistenten Schutz und sind derzeit die einzigen von der NSA für den Einsatz in NSS zugelassenen PQC-Algorithmen.

Hinweis: Validiertes ML-DSA wird aufgrund seiner Zustandslosigkeit, Effizienz und starken mathematischen Grundlage in strukturierten Gittern letztendlich zur bevorzugten Lösung für Umgebungen mit hohem Durchsatz und verteilter Signatur werden.

Die Position der NSA ist jedoch klar: Der Übergang von LMS zu XMSS muss jetzt beginnen, insbesondere für Firmware-Anwendungsfälle, da:

• Die erwartete Verzögerung bei der ML-DSA-Validierung und der Verfügbarkeit von Werkzeugen,
• Die langen Hardware-Lebenszyklen in kritischen NSS-Systemen,
• Die Opportunitätskosten des Wartens können zu unsicheren Post-Quantum-Bereitstellungen führen, die nicht aktualisiert werden können.

Nach der Validierung bietet ML-DSA betriebliche Vorteile, darunter:

• Bessere Skalierbarkeit über CI/CD-Pipelines hinweg,
• Vereinfachte Schlüsselverwaltung ohne Statusverfolgung,
• Reduzierter Signaturgrößen-Overhead im Vergleich zu LMS/XMSS in einigen Konfigurationen.

Mehr über Hash-basierte Algorithmen

SHA-384 und SHA-512 in CNSA 2.0

CNSA 2.0 besagt, dass die Auswahl von SHA-2 (SHA-384 und SHA-512) für die Sicherheit ausreichend ist und ihre breite Akzeptanz in der Geschäftswelt eine nahtlose Interoperabilität zwischen Systemen gewährleistet. SHA-384 wird aufgrund seiner nachgewiesenen Stärke und der internen Analyse der NSA als zentrale, anerkannte Hash-Funktion für die Sicherheit genannt. SHA-512 wurde explizit in CNSA 2.0 für Szenarien aufgenommen, in denen Leistungsoptimierungen entscheidend sind. Dies liegt daran, dass seine 64-Bit-Wortstruktur besonders auf modernen 64-Bit-Prozessoren vorteilhaft ist und oft einen schnelleren Durchsatz bei vergleichbaren Sicherheitsgarantien bietet.

Der Einsatz von SHA-512 bringt jedoch eine wichtige Überlegung mit sich: die Interoperabilität. Bei der Integration von Drittanbieter- oder Altsystemen, die standardmäßig SHA-384 verwenden, müssen Entwickler die Abstimmung zwischen den Komponenten sicherstellen, um Fehler bei der Signaturprüfung, der HMAC-Generierung oder der Message-Digest-Kompatibilität zu vermeiden.

Verwendung anderer Hash-Funktionen

Es gibt besondere Bedingungen, unter denen andere Hashfunktionen zulässig sind:

• Abgeschnittene SHA-2-Varianten (z. B. SHA-256/192): Wenn ein kryptografischer Algorithmus (von der NSA oder NIST genehmigt) die Verwendung solcher verkürzten Varianten in seiner Konstruktion ausdrücklich definiert. Beispielsweise sind sie in LMS zulässig.
• SHA-3-Familie (SHA3-384, SHA3-512): Obwohl sie für den allgemeinen NSS-Einsatz nicht allgemein zugelassen sind, sind sie für interne Hardwareprozesse wie die Generierung von Zufallszahlen oder die Schlüsselableitung innerhalb von Chips akzeptabel.

Wenn beispielsweise eine hardwareisolierte, sichere Ausführungsumgebung Key Derivation Function (KDF)-Operationen intern mit SHA3-512 ausführt, ohne den Hash extern offenzulegen, liegt dies im Rahmen akzeptabler Praxisgrenzen.

[eCBOM]

Wichtige Überlegungen zur Integration von LMS und XMSS in Code Signing-Workflows

Während Unternehmen auf quantensichere Code-Signaturen mit Hash-basierten Signaturschemata wie LMS (Leighton-Micali Signature) und XMSS (eXtended Merkle Signature Scheme) umsteigen, müssen mehrere einzigartige betriebliche Herausforderungen bewältigt werden, um Sicherheit und Arbeitsablaufkontinuität zu gewährleisten.

1. HSM-Kompatibilität

Die meisten kommerziellen HSMs sind für RSA oder ECDSA optimiert, die keine Signaturen protokollieren müssen. LMS und XMSS unterscheiden sich jedoch, da sie die sichere Speicherung des Signaturstatus (wie Zähler oder Baumindizes) innerhalb des Moduls erfordern. Daher benötigen viele HSMs Firmware-Updates oder spezielle Add-ons, um diese neuen Signaturtypen ordnungsgemäß zu unterstützen. Daher entwickelt sich die Unterstützung für LMS/XMSS, die häufig Firmware-Upgrades oder spezielle Module erfordert. Andernfalls könnten Schlüssel außerhalb des HSMs verarbeitet werden, was ihre Sicherheit beeinträchtigt.

2. Zustandssynchronisierung in verteilten Umgebungen

In modernen DevOps und CI / CD-PipelinesDie Code-Signatur wird häufig auf mehrere Knoten oder Server verteilt. Die zustandsbehaftete Natur von LMS und XMSS bedeutet, dass jede Signatur einen eindeutigen Teil der Signaturkapazität des privaten Schlüssels beansprucht. Die Wiederverwendung von Statusparametern kann den gesamten Schlüssel gefährden. Dies erfordert einen sorgfältig koordinierten Ansatz, bei dem der Signaturstatus über alle Signaturknoten hinweg konsistent synchronisiert wird. 

3. Sichere Zustandssicherungen

Die Sicherung privater LMS- oder XMSS-Schlüssel ist komplexer als herkömmliche Schlüsselsicherungen, da der aktuelle Signaturstatus (z. B. Signaturzähler oder Merkle-Baum-Indizes) präzise und sicher gespeichert werden muss. Der Sicherungsprozess muss manipulationssicher und resistent gegen Rollback- oder Replay-Angriffe sein, da die Wiederherstellung eines veralteten Status zur Wiederverwendung von Signaturen und damit zur Gefährdung der Sicherheit führen kann. Daher setzen Unternehmen häufig benutzerdefinierte Tools oder sichere Enklaven ein, um diese sensiblen Statusinformationen zu schützen und die Konsistenz der Sicherungen mit laufenden Signaturvorgängen sicherzustellen. 

HSM-Integration für quantensichere Code-Signierung

Da Unternehmen beginnen, quantenresistente digitale Signaturen wie LMS und XMSS zu verwenden, spielen Hardware-Sicherheitsmodule (HSMs) eine entscheidende Rolle bei der Durchsetzung von Sicherheit, Compliance und Betriebskontinuität.

Im Gegensatz zu herkömmlichen kryptografischen Algorithmen verwenden LMS und XMSS Einmalsignaturschlüssel, die von einem privaten Masterschlüssel (Seed) abgeleitet werden. Jede Signatur muss einen eindeutigen abgeleiteten Schlüssel verwenden, der mit einem sicheren Zähler verfolgt wird. Das HSM stellt Folgendes sicher:

• Pro Schlüsselpaar wird eine begrenzte Anzahl an Signaturen generiert
• Die Einmalnutzungsregel wird über die interne Statusverwaltung durchgesetzt
• Abgeleitete Schlüssel werden nicht wiederverwendet oder unangemessen exportiert

Jede private Schlüsselableitung ist deterministisch und basiert auf einem Zähler. Das bedeutet, dass jeder abgeleitete private Schlüssel nur eine Signatur erzeugen kann. Diese einzigartige Anforderung stellt operative Anforderungen an das kryptografische System. HSMs erzwingen diesen Status intern und verhindern unbefugtes Zurücksetzen oder Duplizieren der Signaturumgebung, was andernfalls die Integrität von LMS/XMSS gefährden würde.

Die Rolle der Hybrid-Kryptographie

Während sich die Cybersicherheitsbranche auf das Post-Quanten-Zeitalter vorbereitet, sind hybride Kryptografielösungen, die klassische Algorithmen wie RSA oder ECC mit Post-Quanten-Kryptografie-Algorithmen (PQC) kombinieren, zu einer beliebten Übergangsstrategie geworden. Diese Lösungen zielen darauf ab, Daten sowohl vor der aktuellen als auch vor der zukünftigen Bedrohungslandschaft zu schützen.

Dieser zweischichtige Ansatz stellt sicher, dass die PQC-Schicht die Daten auch dann schützt, wenn ein leistungsstarker Quantencomputer einen klassischen Algorithmus knackt. Sollten die neuen PQC-Algorithmen hingegen unerwartete Schwächen aufweisen, bietet die klassische Schicht weiterhin ein gewisses Maß an Schutz. Hybride Kryptografie trägt dazu bei, Risiko und Sicherheit in Einklang zu bringen, während PQC-Standards noch getestet und eingeführt werden.

Die NSA verlangt jedoch in ihrer CNSA 2.0-Richtlinie keine Hybridlösungen für nationale Sicherheitssysteme (NSS). Die Behörde vertraut auf die Leistungsfähigkeit der zugelassenen PQC-Algorithmen und befürwortet eine direkte Umstellung auf diese quantensicheren Standards.

Die NSA räumt jedoch ein, dass einige Industriestandards vorübergehend hybride Implementierungen erfordern könnten, insbesondere aufgrund der größeren Schlüssel- und Signaturgrößen von PQC-Algorithmen. Sie warnt jedoch davor, dass hybride Systeme zusätzliche Komplexität und Kompatibilitätsprobleme mit sich bringen können. Daher wird hybride Kryptografie als vorübergehende Maßnahme und nicht als langfristige Lösung betrachtet.

Wie kann Verschlüsselungsberatung helfen? 

Encryption Consulting unterstützt Unternehmen und Regierungen bei der Implementierung von CNSA 2.0-konformen Signaturinfrastrukturen mit vollständiger PQC- und Hybrid-Krypto-Unterstützung. 

CodeSign Secure v3.02 unterstützt PQC sofort und verschafft Unternehmen einen Vorsprung bei der Anpassung an die nächste Ära der Geheimschrift ohne dabei die Benutzerfreundlichkeit oder Leistung zu beeinträchtigen. Das ist jetzt ein kluger Schachzug und für die Zukunft ein notwendiger. 

Bei der Umstellung auf CNSA 2.0 geht es nicht nur um die Auswahl des richtigen Algorithmus. Es geht um den Aufbau einer End-to-End-Codesignierungsstrategie, die Schlüssel schützt, Workflows automatisiert, Richtlinien durchsetzt und Compliance gewährleistet. Genau das ist es CodeSign Secure wurde gebaut für.  

So unterstützt CodeSign Secure CNSA 2.0:  

• LMS- und XMSS-fähig: Unterstützt bereits die für die Signierung von Software und Firmware erforderlichen Post-Quantum-Signaturschemata.
• HSM-gestützter Schlüsselschutz: Ihre privaten Schlüssel bleiben in FIPS 140-2 Level 3 HSMs geschützt, sodass keine Offenlegung erfolgt.
• Integrierte Statusverfolgung: Verwaltet automatisch den Status für LMS und XMSS, um sicherzustellen, dass jede Signatur konform ist.
• DevOps-freundlich: Lässt sich nativ in Jenkins, GitHub Actions, Azure DevOps und mehr integrieren.
• Richtliniengesteuerte Sicherheit: Verwenden Sie RBAC, Freigaben durch mehrere Genehmiger (M von N) und benutzerdefinierte Sicherheitsrichtlinien, um jeden Aspekt Ihrer Code-Signierung zu kontrollieren.
• Auditfähige Protokollierung: Erhalten Sie vollständige Transparenz über jeden Signaturvorgang für einfaches Reporting und Compliance.

Egal, ob Sie Software für Windows, Linux, macOS, Docker, IoT-Geräte oder Cloud-Plattformen signieren, CodeSign Secure ist bereit, Ihnen beim sicheren und effizienten Übergang zu helfen.  

Fazit 

CNSA 2.0 ist da und mehr als nur eine Empfehlung: Es ist ein Fahrplan zur Verbesserung Ihrer Sicherheitsmaßnahmen. Wenn Sie in der Softwareentwicklung, Infrastruktur oder Compliance tätig sind, ist jetzt der richtige Zeitpunkt für die Planung.  

Mit CodeSign Secure erhalten Sie die Tools und Automatisierung, die Sie benötigen, um:  

• Beginnen Sie mit der Signierung mit CNSA 2.0-kompatiblen Algorithmen
• Schützen Sie Ihre Schlüssel und setzen Sie strenge Richtlinien durch
• Halten Sie Termine ein, ohne die Entwicklung zu verlangsamen

Willst du sehen wie es funktioniert? 

Sprechen Sie uns an info@encryptionconsulting.com um eine Demo zu vereinbaren oder mehr darüber zu erfahren, wie CodeSign Secure kann Ihnen dabei helfen, konform und sicher zu bleiben.