Code-Signing-Krise: Lieferkettensicherheit vor 2030 verbessern

Typ: Technisches Briefing
Veröffentlicht: Februar 2026
Schlagwörter: Code-Signing, Software-Lieferkette, ML-DSA, ECDSA, Quantenbedrohung, CNSA 2.0, NIS2, SolarWinds, SBOM

Zusammenfassung

Code-Signing ist der digitale Handschlag, der Nutzern signalisiert: „Diese Software wurde nicht manipuliert." Doch die Algorithmen, auf denen die heutige Signaturinfrastruktur basiert – RSA und ECDSA – werden einem kryptanalytisch relevanten, fehlertoleranten Quantencomputer, der Shors Algorithmus im großen Maßstab ausführt, nicht standhalten [1]. Dieser Artikel kartiert die Angriffsfläche der Lieferkette, analysiert reale Vorfälle, die Schwachstellen im Code-Signing ausgenutzt haben.

Kernaussagen auf einen Blick

  • Supply-Chain-Angriffe nehmen stark zu: SolarWinds (2020), 3CX (2023) und die xz-Utils-Backdoor (2024) zeigen, wie Build-Pipelines und Software-Vertrauensmechanismen zu hocheffizienten Angriffsvektoren werden können [7][8][9].
  • Code-Signing basiert auf quantenanfälliger Kryptographie: Die meisten Signatur-Pipelines verwenden nach wie vor RSA-2048 oder ECDSA-P256 – beide sind anfällig für Shors Algorithmus auf einem kryptanalytisch relevanten Quantencomputer [1].
  • Der regulatorische Druck ist konkret: NSA CNSA 2.0 empfiehlt die Verwendung von CNSA-2.0-Algorithmen für neue Software-/Firmware-Signaturen ab 2025 und den Abschluss der Umstellung bis 2030 [4]. Eine gemeinsame Erklärung von Behörden aus 18 EU-Mitgliedstaaten empfiehlt, die sensibelsten Anwendungsfälle spätestens Ende 2030 gegen „Store Now, Decrypt Later" zu schützen [5].
  • ML-DSA und SLH-DSA sind standardisiert: NIST hat FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) im Jahr 2024 finalisiert [2][3].
  • Hybride/duale Signaturansätze können die Migration erleichtern: Die Machbarkeit hängt vom Signaturcontainer und dem Verifier-Ökosystem ab; zusammengesetzte (Multi-Algorithmus) Signaturprofile für PKI werden derzeit standardisiert [10].
  • Spätes Handeln ist teuer: Zertifikatsrotation, Widerruf und erneutes Signieren über eine große Softwarelandschaft hinweg ist eine mehrmonatige, teamübergreifende Operation – beginnen Sie, bevor es zu einer Incident-Response-Übung wird.

Warum Code-Signing wichtiger ist, als Sie denken

Stellen Sie sich vor: Ein routinemäßiges Betriebssystem-Update landet auf Ihrem Laptop. Es sieht legitim aus, ist vom Hersteller signiert, und Ihr System installiert es ohne Bedenken. Doch im Hintergrund hat ein Angreifer die Binärdatei stillschweigend ausgetauscht und die Signatur des Herausgebers gefälscht. Herzlichen Glückwunsch – Sie wurden soeben durch einen Supply-Chain-Angriff kompromittiert.

Code-Signing soll genau dieses Szenario verhindern. Eine digitale Signatur auf einer Binärdatei, einem Firmware-Image, einem Container oder Paket bietet zwei Garantien: Integrität (der Code wurde seit der Signierung durch den Herausgeber nicht verändert) und Herkunftsnachweis (die Signatur lässt sich auf einen vertrauenswürdigen Herausgeber zurückführen). Die Vertrauenskette reicht von einer Root-Zertifizierungsstelle über eine Zwischen-CA bis zum Signaturzertifikat des Herausgebers – und schließlich zum Hash des Artefakts, den Ihr Rechner vor der Installation prüft.

Der Geltungsbereich ist umfassender, als vielen bewusst ist. Code-Signing betrifft nicht nur Windows-.exe-Dateien. Es schützt npm- und PyPI-Pakete, Docker-Container-Images, Linux-Kernelmodule, Firmware-Blobs, UEFI-Secure-Boot-Ketten, mobile Apps auf iOS und Android und praktisch jede Software, die von einem Entwickler zu einem Endnutzer gelangt. Bricht diese Vertrauenskette an irgendeinem Punkt, wirken sich die Folgen auf Millionen von Geräten aus.

Die Angriffsfläche der Lieferkette: Reale Präzedenzfälle

Supply-Chain-Angriffe sind längst keine Theorie mehr. Sie finden im großen Maßstab statt, und einige der verheerendsten Vorfälle der letzten Jahre zielten gezielt auf die Code-Signing-Infrastruktur ab.

🔥 SolarWinds (2020)

Angreifer kompromittierten die Build-Pipeline von SolarWinds und schleusten Schadcode in die Orion-IT-Management-Plattform ein. Das trojanisierte Update wurde digital signiert und über normale Update-Kanäle verteilt. Erste Berichte nannten bis zu ~18.000 Kundendownloads betroffener Orion-Versionen (potenzielle Exposition), während die bestätigte nachgelagerte Kompromittierung eine kleinere Gruppe hochwertiger Opfer betraf. [7]

📞 3CX (2023)

Ein kaskadierender Supply-Chain-Angriff begann, als ein 3CX-Mitarbeiter trojanisierte Handelssoftware herunterlud. Die Angreifer nutzten den Zugang, um die Build-Umgebung von 3CX zu kompromittieren und einen trojanisierten Desktop-Client als signiertes Installationspaket zu verteilen. Die potenzielle Reichweite war angesichts der berichteten Kundenbasis von 3CX (oft mit ~600.000 angegeben) erheblich. [8]

🐧 xz Utils (2024)

Eine mehrjährige Social-Engineering- und Maintainer-Infiltrationskampagne führte dazu, dass Schadcode in xz/liblzma eingeschleust wurde (insbesondere Versionen 5.6.0 und 5.6.1). Der Vorfall verdeutlicht, dass das Lieferkettenrisiko nicht auf gestohlene Signaturzertifikate beschränkt ist: vertrauenswürdige Maintainerschaft und Release-Engineering können ebenso kritisch sein. [9]

⚠️ Der gemeinsame Nenner

In jedem Fall war die Signaturinfrastruktur selbst das Ziel. Schlüssel in Software-HSMs gespeichert, unzureichend rotierte Anmeldedaten, CI/CD-Secrets in Build-Pipelines offengelegt oder – am heimtückischsten – Vertrauen in Personen, die kritische Open-Source-Abhängigkeiten pflegten. Sobald der Signaturschlüssel oder die Build-Pipeline kompromittiert ist, wird die Signatur zu einer Waffe, die die Reichweite des Angreifers verstärkt, anstatt ihn zu blockieren.

Die Quantenbedrohung für Code-Signing

Wir haben ausführlich über die Harvest-Now, Decrypt-Later-Bedrohung für verschlüsselte Kommunikation geschrieben. Aber hier ist, was Code-Signing noch dringender betroffen macht als den Schlüsselaustausch:

🚨 Das Szenario, das wir verhindern müssen

Es ist 2032. Ein gut finanzierter Angreifer bricht den ECDSA-P256-Schlüssel hinter dem Firmware-Signaturzertifikat eines großen Embedded-Systems-Herstellers. Er erstellt ein gefälschtes Firmware-Update für einen weit verbreiteten industriellen IoT-Sensor und verbreitet es über den legitimen Update-Kanal des Herstellers. Jedes Gerät, das die (nun fälschbare) Signatur prüft, installiert die bösartige Firmware ohne Widerspruch. Das Ergebnis? Tausende kompromittierte Geräte in kritischer Infrastruktur – und keine kryptographische Spur, um die Fälschung zu erkennen.

Schätzungen, wann ein kryptanalytisch relevanter Quantencomputer RSA/ECDSA brechen könnte, variieren stark. Politische und risikobezogene Leitlinien konzentrieren sich daher auf Migrationszeitpläne statt auf die Vorhersage eines einzelnen Bruchdatums. Für Hochsicherheitsumgebungen bietet CNSA 2.0 konkrete Planungsmeilensteine für Signaturanwendungen (neue Software/Firmware bis 2025; vollständige Umstellung bis 2030) [4].

Was heute verfügbar ist: ML-DSA, SLH-DSA und hybride Ansätze

Die gute Nachricht? NIST hat 2024 nicht nur den Post-Quanten-Schlüsselaustausch standardisiert, sondern auch zwei einsatzbereite Post-Quanten-Signaturverfahren finalisiert:

Algorithmus Standard Öffentlicher Schlüssel Signatur Typische Leistung Annahme
RSA-2048 PKCS #1 256 B 256 B Langsames Signieren, schnelle Verifikation (weit optimiert) Faktorisierung ❌ Quanten
ECDSA-P256 FIPS 186-5 64 B 64 B Schnelles Signieren und Verifizieren (weit optimiert) ECDLP ❌ Quanten
ML-DSA-65 FIPS 204 1.952 B 3.309 B Schnelle Verifikation; größere Schlüssel/Signaturen Module-LWE ✅ Quanten
ML-DSA-87 FIPS 204 2.592 B 4.627 B Schnelle Verifikation; größere Schlüssel/Signaturen Module-LWE ✅ Quanten
SLH-DSA-128f FIPS 205 32 B 17.088 B Sehr große Signaturen; Signieren vergleichsweise langsam Hash-basiert ✅ Quanten

Die Leistung variiert erheblich je nach Implementierung und Hardware. Hinweis: NIST FIPS 204 definiert ML-DSA-Signaturkodierungen von 3.309 B (ML-DSA-65) und 4.627 B (ML-DSA-87); ältere Quellen zu CRYSTALS-Dilithium nennen oft 3.293 B bzw. 4.595 B für die entsprechenden Parametersätze. Für kontinuierlich aktualisierte, reproduzierbare Messungen siehe Open Quantum Safe Benchmarking für liboqs [12].

ML-DSA (ehemals CRYSTALS-Dilithium) ist der führende Kandidat für die meisten Code-Signing-Anwendungsfälle. Seine Verifikationsgeschwindigkeit – vergleichbar mit ECDSA – macht ihn auch für eingeschränkte Geräte praktikabel, die bei jedem Start Signaturen prüfen müssen. Der Kompromiss sind größere Schlüssel und Signaturen (etwa 50–75× größer als ECDSA), was sich auf Zertifikatsketten und Bandbreite auswirkt.

SLH-DSA (ehemals SPHINCS+) bietet eine konservative Alternative, die ausschließlich auf Hash-Funktionen basiert – keine Gitterannahmen nötig. Der Nachteil? Signaturen wachsen auf ~17 kB an und das Signieren ist um Größenordnungen langsamer. Es eignet sich am besten als Backup-Algorithmus oder für Szenarien, in denen die zusätzliche Sicherheitsmarge die Kosten rechtfertigt.

💡 Hybrides / duales Signieren: Ein praktisches Übergangsmuster

Eine gängige Kurzfriststrategie ist duales Signieren: Für dasselbe Artefakt wird eine klassische Signatur (z. B. ECDSA) und eine Post-Quanten-Signatur (z. B. ML-DSA) erzeugt. Das operative Ziel ist einfach – Kompatibilität wahren und gleichzeitig quantenresistente Verifikation ermöglichen – aber die Details hängen vom Ökosystem ab.

Wichtiger Hinweis: „Einfach Signaturen aneinanderhängen" ist nicht universell kompatibel. Einige Formate und Tools unterstützen mehrere Signaturen oder mehrere Unterzeichner; andere benötigen neue Container oder Metadaten. Für PKI-/X.509-Umgebungen werden zusammengesetzte (Multi-Algorithmus) Signaturprofile aktiv standardisiert [10].

Die Tooling-Unterstützung wächst rasant. AWS KMS unterstützt die Erzeugung und Verwendung von ML-DSA-Schlüsseln für Signaturoperationen [11]. Auf Plattformseite nutzt IBM z16 quantensichere und klassische Signaturen parallel, um die Firmware-Vertrauenskette beim Secure Boot zu schützen [13].

Regulatorischer Druck: CNSA 2.0, NIS2 und BSI

Regulierungsbehörden warten nicht darauf, dass die Quantenbedrohung Realität wird – sie setzen jetzt harte Fristen. Wenn Sie Software, Firmware oder Infrastruktur für Behörden oder Kunden aus kritischen Sektoren handhaben, sind diese Termine faktisch nicht verhandelbar.

Regulatorischer Zeitplan: Übergeordnete Planungsmeilensteine für das Signieren
!
2025 — CNSA 2.0 (NSS)
Neue Software und Firmware sollte bis 2025 CNSA-2.0-Signaturalgorithmen verwenden. [4]
↓
!
2030 — CNSA 2.0 (NSS)
Sämtliche eingesetzte Software und Firmware sollte bis 2030 auf CNSA-2.0-konforme Signaturen umgestellt sein. [4]
↓
!
Ende 2030 — Gemeinsame Erklärung der EU
Behörden aus 18 EU-Mitgliedstaaten empfehlen, die sensibelsten Anwendungsfälle spätestens Ende 2030 gegen „Store Now, Decrypt Later" zu schützen. [5]

Die einheitliche Botschaft über alle Leitlinien und Regulierungen hinweg lautet, dass langlebige Integritätsmechanismen (wie Software- und Firmware-Signaturen) planmäßig migriert werden müssen, statt in einer Last-Minute-Notfallsituation. CNSA 2.0 bezieht explizit Software- und Firmware-Signaturen ein und gibt konkrete Meilensteine vor [4]. In der EU macht NIS2 ein „dem Stand der Technik" entsprechendes Cybersicherheits-Risikomanagement zur gesetzlichen Pflicht, mit Bußgeldobergrenzen von bis zu 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen und 1,4 % für wichtige Einrichtungen (die Umsetzung in den Mitgliedstaaten kann variieren) [6].

Für einen detaillierten, phasenweisen Migrationsplan, der auf deutsche KMU zugeschnitten ist – einschließlich Fördermöglichkeiten – siehe unsere Quantensichere Roadmap für GmbHs.

Nächster Schritt

Code-Signing ist der Punkt, an dem die Quantenbedrohung auf die Software-Lieferkette trifft – und beide Probleme beschleunigen sich. Die Angriffe von 2020–2024 nutzten prozessuale Schwächen in der Signaturinfrastruktur aus; die Angriffe der 2030er Jahre könnten kryptographische ausnutzen. Die gute Nachricht ist, dass die Algorithmen, Tools und regulatorischen Rahmenbedingungen zur Behebung bereits existieren. Die schlechte Nachricht? Das Zeitfenster zum Handeln schließt sich schnell.

Für tiefergehende Einblicke in die hier besprochenen Technologien erkunden Sie unsere verwandten Artikel:

Referenzen

  1. NIST IR 8105 (Final): Report on Post-Quantum Cryptography. NIST CSRC. https://csrc.nist.gov/pubs/ir/8105/final
  2. NIST FIPS 204 (Final): Module-Lattice-Based Digital Signature Standard (ML-DSA). https://csrc.nist.gov/pubs/fips/204/final
  3. NIST FIPS 205 (Final): Stateless Hash-Based Digital Signature Standard (SLH-DSA). https://csrc.nist.gov/pubs/fips/205/final
  4. NSA: Commercial National Security Algorithm Suite 2.0 (Meilensteine für Software- & Firmware-Signaturen; Dokument datiert Sep 2022, Ver. 1.0). https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
  5. BSI (und Partner aus 17 weiteren EU-Mitgliedstaaten): Gemeinsame Erklärung zum Übergang zur Post-Quanten-Kryptographie (27. Nov. 2024). https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/PQC-joint-statement.pdf
  6. Richtlinie (EU) 2022/2555 (NIS2) — Amtsblatt-PDF (Bußgeldobergrenzen und Durchsetzung). https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32022L2555
  7. SolarWinds: An Investigative Update of the Cyberattack (Mai 2021). https://www.solarwinds.com/blog/an-investigative-update-of-the-cyberattack
  8. Volexity: 3CX Supply Chain Compromise Leads to ICONIC Incident (30. März 2023); mit Kontext zur berichteten Kundenbasis. https://www.volexity.com/blog/2023/03/30/3cx-supply-chain-compromise-leads-to-iconic-incident/
  9. BSI-Cybersicherheitswarnung: Kritische Backdoor in XZ für Linux (CVE-2024-3094) (Apr. 2024). https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2024/2024-223608-1032.pdf
  10. IETF LAMPS: Composite Signatures for use in Internet PKI (draft-ietf-lamps-pq-composite-sigs). https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/
  11. AWS Key Management Service (AWS KMS): ML-DSA-Unterstützung für Post-Quanten-Signaturen (Ankündigung und Dokumentation). https://aws.amazon.com/about-aws/whats-new/2025/06/aws-kms-post-quantum-ml-dsa-digital-signatures/
  12. Open Quantum Safe: Continuous Benchmarking (liboqs Signatur-/KEM-Leistung). https://openquantumsafe.org/benchmarking/
  13. IBM Redbooks: Transitioning to Quantum-Safe Cryptography on IBM Z (Secure Boot nutzt quantensichere und klassische Signaturen parallel). https://www.redbooks.ibm.com/redpieces/pdfs/sg248525.pdf