Einführung
Stellen Sie sich vor, Ihr Programm besitzt nun eine digitale Signatur mit dem Text „Ich bin authentisch und sicher“. Doch diese identische Signatur kann in fünf Jahren wertlos sein. Das ist vergleichbar mit einem Wachssiegel auf einem Brief, nur um später festzustellen, dass eine Maschine entwickelt wurde, die es präzise duplizieren kann.
Quantencomputing ist keine Science-Fiction mehr. Was einst nur in wissenschaftlichen Publikationen beschrieben wurde, rückt immer näher an Maschinen heran, die leistungsstark genug sind, um die mathematischen Grundlagen der von uns genutzten Kryptografie – RSA , ECC und Co. – zu entschlüsseln. Sobald das geschieht, geraten die Garantien für „vertrauenswürdige“ Software-Updates und signierte Binärdateien ins Wanken.
Und hier kommt der Clou: Angreifer müssen nicht warten. Sie können signierte Software schon heute sammeln, sie verstecken und geduldig abwarten. Diese Taktik hat einen Namen: Harvest Now, Decrypt Later (HNDL) . Sobald Quantencomputer mithalten können, werden diese sorgfältig gespeicherten Signaturen zu Einfallstoren. Stellen Sie sich Malware vor, die mit einem „gültigen“ digitalen Zertifikat maskiert ist und die Abwehrmechanismen einfach durchbrechen kann, weil die alten Berechnungen nicht mehr funktionieren.
Definition einer Enterprise-Codesignierungslösung: eine Signaturplattform, die private Schlüssel in zertifizierter Hardware schützt, die Signierung als durch Richtlinien erzwungenen Schritt in CI/CD integriert und einen Migrationspfad zu Post-Quanten-Signaturalgorithmen (ML-DSA, LMS/XMSS) unterstützt, evaluiert anhand benannter Plattformversionen, dokumentierter Formatunterstützung und Nachweisen, die Sie unabhängig überprüfen können und nicht nur auf Marketingaussagen beruhen.
Wichtige Erkenntnisse
- RSA- und ECDSA-Signaturen sind anfällig für das Harvest-Now-Forge-Later-Verfahren: Ein Angreifer, der heute ein signiertes Artefakt aufzeichnet, kann, sobald ein kryptografisch geeigneter Quantencomputer existiert, neue Signaturen fälschen, unabhängig davon, wie das Artefakt verteilt wurde.
- Langlebige signierte Artefakte, Firmware, industrielle Steuerungssoftware, Software für medizinische Geräte bergen das höchste Risiko, da sie nach der Bereitstellung nicht immer neu signiert oder gepatcht werden können.
- Die Unterstützung von Post-Quanten-Signaturalgorithmen (ML-DSA, LMS, XMSS) durch Verifizierer ist noch nicht flächendeckend. Bitte vergewissern Sie sich, dass die spezifischen Plattformen in Ihrem Bereitstellungspfad den Algorithmus tatsächlich verifizieren, bevor Sie ihn als Ihre einzige Signatur betrachten.
- Für einen detaillierteren technischen Vergleich zwischen LMS, XMSS und SLH-DSA sowie der vollständigen CNSA 2.0-Migrationsarchitektur siehe Vergleich von SLH-DSA, LMS und XMSS und Gestaltung der CNSA 2.0-Übergangsstrategien.
Warum ist die Code-Signierung besonders gefährdet?
Im Kern geht es bei der Code-Signierung um eines: Vertrauen. Wenn Sie ein Update herunterladen oder eine neue App installieren, soll die Signatur dieser Software zwei Dinge beweisen: von wem sie stammt und dass sie unterwegs nicht manipuliert wurde. Es ist wie die digitale Version der Siegelprüfung einer Medizinflasche.
Das Problem ist, dass die heutige Codesignierung fast immer auf RSA- oder ECC-Schlüsseln basiert. Beide Verfahren beruhen auf mathematischen Problemen, die für herkömmliche Computer schwer zu lösen, für Quantencomputer aber ein leichtes Ziel sind. Sobald diese Hürde überwunden ist, ist die Signatur kein Beweis mehr, sondern nur noch Dekoration.
Und die Risiken sind nicht abstrakt. Stellen Sie sich ein gefälschtes Software-Update vor, das aufgrund seiner gefälschten Signatur völlig legitim aussieht. Oder Malware, getarnt mit dem Zertifikat Ihres Unternehmens, die sich unter Ihrem Namen verbreitet. Neben dem technischen Chaos ist das Vertrauen der größte Schaden: Kunden, Partner und sogar Aufsichtsbehörden wird es nicht interessieren, wenn Sie erklären: „Quantum hat unsere Kryptografie geknackt.“ Sie werden Ihre Marke einfach auf unsicheren Geräten sehen.
Der Countdown zum Post-Quantum
Das NIST führt seit einigen Jahren den weltweit größten Krypto-Wettbewerb durch, testet, knackt und wählt schließlich die Algorithmen aus, die stark genug sind, um Quantenangriffe zu überstehen. Die ersten Standards sind bereits veröffentlicht, die übrigen folgen in Kürze. Das ist keine Theorie mehr, sondern Realität.
Die meisten Experten sind sich einig, dass wir noch drei bis fünf Jahre Zeit haben, bevor Quantenmaschinen die heutige Kryptographie ernsthaft beeinträchtigen. Klingt nach viel Zeit, oder? Der Haken daran ist, dass Software nicht mit der Veröffentlichung der nächsten Version verschwindet. Signierter Code lebt in eingebetteten Geräten, IoT-Sensoren, industriellen Steuerungssystemen und medizinischer Ausrüstung weiter – in Bereichen, in denen „einfach patchen“ nicht realistisch ist.
Deshalb ist Warten eine Strategie, die zum Scheitern verurteilt ist. Eine heute erstellte Signatur muss möglicherweise auch in zehn Jahren noch gültig sein. Wenn sie es nicht ist, kann das sorgsam aufgebaute Vertrauen in Ihre Lieferkette über Nacht zerstört werden. Die Frage ist nicht, ob Sie quantensichere Signaturen benötigen, sondern ob Sie vorbereitet sind, bevor Ihre Angreifer es sind.
Vorbereitung auf die quantensichere Code-Signierung
Um sich auf die Post-Quanten-Welt vorzubereiten, muss man nicht einfach eines Tages einen Schalter umlegen. Es geht darum, jetzt die Grundlagen zu legen. Ein paar konkrete Schritte machen den Unterschied:
- Kryptografisches Inventar: Sie können nichts reparieren, was Sie nicht wissen. Beginnen Sie damit, zu ermitteln, wo Ihre Signaturschlüssel tatsächlich gespeichert sind, welche Algorithmen sie verwenden und welche Systeme von ihnen abhängen. Stellen Sie sich das wie eine Anwesenheitskontrolle vor. Jeder Schlüssel, jedes Zertifikat, jeder Signaturprozess sollte sich melden.
- Krypto-Agilität: Einen Algorithmus fest in Ihr System zu kodieren, ist wie Beton über Ihr Schloss zu gießen. Sie wünschen sich Flexibilität, damit Sie bei neuen Standards Algorithmen austauschen können, ohne Ihre Systeme auseinanderzunehmen. Gestalten Sie Ihre Signaturprozesse so, dass sie Veränderungen unterstützen, anstatt sie zu fürchten.
- Hybride Ansätze: Da PQC Da die Standards noch verfeinert werden, ist es ein kluger Schritt, sie mit den heutigen Algorithmen zu kombinieren. Auf diese Weise erhalten Sie das Beste aus beiden Welten: das Vertrauen, auf das die Menschen bereits vertrauen, und zusätzlich eine Absicherung gegen zukünftige Quantenbedrohungen.
- Politik und Governance: Selbst die stärksten Algorithmen sind nutzlos, wenn Schlüssel ungeschützt herumliegen. Schützen Sie sie durch geeignete Speichersysteme (z. B. HSMs oder sichere Dienste), legen Sie fest, wer sie verwenden darf, und rotieren Sie sie, bevor sie veralten. Gute Regeln und Kontrolle verhindern Fehler und Missbrauch.
Wo CodeSign Secure passt
Die Vorbereitung auf den oben beschriebenen Übergang erfordert eine entsprechende Signaturinfrastruktur. Im Folgenden erfahren Sie konkret, was CodeSign Secure bietet und was Sie überprüfen sollten, bevor Sie es für einen bestimmten Anwendungsfall einsetzen:
- Unterstützung postquantenmechanischer Signaturen: CodeSign Secure v3.02 unterstützt ML-DSA (FIPS 204, auf den Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) und LMS (NIST SP 800-208) als abtrennbare Signaturen neben klassischem RSA und ECDSA, einschließlich dualer/hybrider Signaturen, bei denen ein Artefakt während des Übergangs sowohl eine klassische als auch eine Post-Quanten-Signatur trägt.
- HSM-gestützter Schlüsselspeicher: Private Schlüssel werden in FIPS 140-2 Level 3 zertifizierten HSMs gespeichert, die mit Thales Luna, Entrust nShield, Utimaco, Securosys und Cloud-HSMs von AWS und Azure integriert sind und damit die Mindestanforderungen des CA/Browser Forums für öffentlich vertrauenswürdige Codesignaturzertifikate gemäß FIPS 140-2 Level 2 übertreffen.
- CI/CD-Integration: Native Integration mit Jenkins, Azure DevOps, GitLab, Bamboo und TeamCity, wobei die Signierung als richtliniengesteuerte Pipeline-Phase und nicht als manueller Schritt erzwungen wird.
- Formatabdeckung: Windows-Executables und Treiber (SignTool, Mage, NuGet, ClickOnce, HLK/HCK), Java/Android (JAR, WAR, APK via JarSigner und APKSigner), macOS (.dmg, .ipa, .pkg), Linux (RPM, GPG), Docker-Images und Firmware-Binärdateien (.bin, .img, .hex, .fw, .dfu).
- Audit-Trail: Bei jedem Signierungsereignis werden der Artefakt-Hash, der Schlüsselbezeichner, das verwendete Zertifikat, die genehmigende Identität und der RFC 3161-Zeitstempel protokolliert, mit SIEM-Integration über OpenTelemetry (Grafana, Loki, Splunk).
Was vor dem Einsatz in der Produktion zu überprüfen ist
Zwei Punkte sollten Sie unabhängig überprüfen, anstatt sie einfach von einem Anbieter zu übernehmen: Erstens ist die Unterstützung von ML-DSA- und LMS-Signaturen durch Verifizierer plattformübergreifend noch nicht einheitlich. Stellen Sie daher sicher, dass die Bootloader, Update-Clients oder Betriebssystem-Verifizierer in Ihrem Bereitstellungspfad den Algorithmus tatsächlich erkennen, bevor Sie ihn als Ihre Produktionssignatur verwenden. Hybrid-Signaturverfahren wurden speziell entwickelt, um diese Lücke während der Übergangsphase zu schließen. Zweitens variiert die Unterstützung eines bestimmten PQC-Algorithmus und Parametersatzes durch die HSM-Firmware je nach Anbieter und Modell. Erkundigen Sie sich direkt bei Ihrem HSM-Anbieter nach dem genauen Parametersatz, den Sie verwenden möchten, da allgemeine Angaben zur PQC-Bereitschaft keine Unterstützung für ein bestimmtes Verfahren garantieren. Keine dieser Einschränkungen ist spezifisch für CodeSign Secure; sie gelten für jede Signaturplattform, die Post-Quanten-Algorithmen vor der universellen Unterstützung durch Verifizierer einsetzt. Es ist jedoch ratsam, diese Punkte für Ihre spezifische Umgebung zu überprüfen, anstatt sie allein aufgrund eines Produktdatenblatts anzunehmen.
Zur unabhängigen Bestätigung der hier genannten Standards durch Nicht-Hersteller verweisen wir auf die Veröffentlichungen FIPS 204 (ML-DSA) und SP 800-208 (LMS/XMSS) des NIST sowie auf die Code Signing Baseline Requirements des CA/Browser Forum für HSM und Widerrufsregeln, die unabhängig von der verwendeten Signaturplattform gelten.
Fazit
Die Entwicklung eines Quantencomputers, der RSA und ECC knacken kann, ist zu keinem bestimmten Zeitpunkt garantiert, aber das Risiko, dass die Technologie erst später genutzt wird, ist unabhängig von der Zeit relevant: Jedes heute signierte Artefakt, von dem erwartet wird, dass es jahrelang vertrauenswürdig bleibt – Firmware, industrielle Steuerungssoftware, eingebettete Geräte mit langer Lebensdauer – birgt dieses Risiko bereits jetzt, unabhängig davon, wann ein kryptografisch relevanter Quantencomputer tatsächlich Realität wird.
Die praktische Antwort besteht nicht in einer einmaligen Migration. Vielmehr geht es darum, das oben beschriebene kryptografische Inventar, die kryptografische Agilität und die hybride Signaturfähigkeit aufzubauen. So wird der Wechsel, sobald die Unterstützung von Post-Quanten-Signaturen durch Verifizierer ausgereift ist, zu einer Konfigurationsänderung und nicht zu einem kompletten Neuaufbau. CodeSign Secure unterstützt diesen Weg mit HSM-gestützter Schlüsselspeicherung, ML-DSA- und LMS-Signierung neben klassischen Algorithmen sowie CI/CD-integrierter Richtliniendurchsetzung. Die zugrunde liegende Arbeit – Inventar, Agilität und Tests mit Ihren spezifischen Verifizierern – ist jedoch unabhängig von der verwendeten Signaturplattform eines Unternehmens relevant.
Häufig gestellte Fragen
Erfordert CodeSign Secure den sofortigen Ersatz klassischer Signaturen?
Nein. Es unterstützt die duale Signatur, ein Artefakt, das sowohl eine klassische als auch eine postquantenmechanische Signatur trägt, sodass Systeme, die den neuen Algorithmus noch nicht verifizieren, weiterhin dem klassischen vertrauen, während aktualisierte Systeme eine quantenresistente Verifizierung erhalten.
Welche HSM-Anbieter werden von CodeSign Secure unterstützt?
Thales Luna, Entrust nShield, Utimaco und Securosys sowie Cloud-HSMs von AWS und Azure. Bitte erkundigen Sie sich bei Ihrem jeweiligen Anbieter, welche PQC-Algorithmen und Parametersätze seine Firmware unterstützt, da dies je nach Modell variiert.
Welche Post-Quanten-Signaturalgorithmen werden heute unterstützt?
ML-DSA (FIPS 204) auf den Sicherheitsstufen 44, 65 und 87 sowie LMS (NIST SP 800-208) als detachable Signaturen neben RSA und ECDSA.
Wird die Unterstützung dieser Algorithmen durch Verifizierer bereits flächendeckend angeboten?
Nein. Vergewissern Sie sich, dass die spezifischen Bootloader, Update-Clients und OS-Verifizierer in Ihrem Bereitstellungspfad ML-DSA oder LMS erkennen, bevor Sie sich auf eines der beiden als alleinige Signatur verlassen; genau diese Lücke soll die doppelte Signatur während des Übergangs schließen.
Die Software, die Sie heute signieren, muss möglicherweise auch in zehn Jahren noch vertrauenswürdig sein. Der Aufbau eines kryptografischen Bestands und die nötige Agilität machen dies möglich.
