CRA-konforme Architektur für sichere Codesignierung

Am 10. Dezember 2024 trat der Cyber ​​Resilience Act ( CRA ) der Europäischen Union als Verordnung (EU) 2024/2847 in Kraft. Erstmals in der Geschichte wurden Cybersicherheitsanforderungen für Produkte mit digitalen Elementen im gesamten EU-Binnenmarkt rechtsverbindlich – kein freiwilliger Rahmen, sondern eine Marktzugangsvoraussetzung, die mit Geldbußen von bis zu 15 Millionen Euro oder 2.5 % des weltweiten Jahresumsatzes , je nachdem, welcher Betrag höher ist, untermauert wird.

Ab dem 11. September 2026 müssen Hersteller, Importeure und Händler ausgenutzte Sicherheitslücken und schwerwiegende Sicherheitsvorfälle aktiv an ENISA und die nationalen CSIRTs melden. Für Organisationen, die vernetzte Geräte entwickeln, herstellen oder vertreiben, definiert der CRA neu, was die Auslieferung eines Produkts bedeutet.

Dieser Blog erläutert detailliert, was die CRA konkret von einer Codesignaturarchitektur verlangt , ordnet diese Anforderungen den technischen Kontrollen zu, die zu ihrer Erfüllung erforderlich sind, und erklärt, warum Organisationen, die ihre Signaturinfrastruktur noch nicht angepasst haben, die Zeit davonläuft, dies vor Ablauf der jeweiligen Compliance-Frist zu tun.

Codesignatur-Konformität, definiert als: Betrieb einer Signaturarchitektur, die gleichzeitig zwei separate Regelungen für denselben Signaturvorgang erfüllt: die Integritäts- und Offenlegungspflichten des EU Cyber ​​Resilience Act auf Produktebene sowie die Zertifikatslebenszyklusregeln des CA/Browser Forum für Gültigkeit, Widerruf, Schlüsselschutz und Zeitstempelung. Die Durchsetzung erfolgt durch HSM-gestützte Schlüssel, dokumentierte Genehmigungsworkflows und auditierbare Protokolle.

Wichtige Erkenntnisse

• Für denselben Signaturvorgang gelten zwei separate Konformitätsregelungen: die CRA (EU-Recht, produktbezogen) und die CA/Browser Forum Baseline Requirements (Branchenregeln, zertifikatsbezogen). Eine konforme Architektur erfüllt beide, nicht nur eine von beiden.
• CRA-Termine: Inkrafttreten am 10. Dezember 2024; Meldung von Schwachstellen/Vorfällen ab dem 11. September 2026; vollständige Einhaltung und CE-Kennzeichnung bis zum 11. Dezember 2027.
• Termine des CA/Browser Forums: Private Schlüssel in FIPS 140-2 Level 2+/Common Criteria EAL4+ Hardware seit Juni 2023; Widerrufsauslöser erweitert, um verdächtigen Code gemäß Abstimmung CSC-22 (April 2024) abzudecken; Timestamp Authority-Schlüssel in Offline-Hardware-Kryptomodulen seit April 2025 erforderlich; maximale Zertifikatsgültigkeit von 460 Tagen gemäß Abstimmung CSC-31 für Zertifikate, die am oder nach dem 1. März 2026 ausgestellt wurden.
• Eine bestätigte Kompromittierung des Schlüssels muss gemäß den Code Signing Baseline Requirements innerhalb von 24 Stunden widerrufen werden; ein vom Abonnenten beantragter Widerruf muss innerhalb eines Werktages berücksichtigt werden.
• Die vollständige Historie der Änderung der Zertifikatsgültigkeit selbst finden Sie hier: Die neue Gültigkeitsänderung des Code-Signatur-Zertifikats verstehenDieser Artikel konzentriert sich auf die von beiden Regimen geforderte Compliance-Architektur und nicht auf die Wahlhistorie an sich.

Was der Cyber ​​Resilience Act tatsächlich erfordert

Die Verordnung gilt für alle „Produkte mit digitalen Elementen“, die auf dem EU-Markt in Verkehr gebracht werden. Diese Kategorie ist so weit gefasst, dass sie praktisch jedes vernetzte Hardwaregerät und die darauf laufende Software umfasst. Router, Smart-Home-Geräte, medizinische Geräte, industrielle Steuerungen, Laptops, Server, IoT-Sensoren und die dazugehörige Firmware fallen darunter.

Die Verordnung basiert auf dem Grundprinzip der Sicherheit durch Design. Produkte müssen so konzipiert, entwickelt und gewartet werden, dass ihre Cybersicherheit über ihre gesamte erwartete Lebensdauer gewährleistet ist. Es handelt sich nicht um eine einmalige Zertifizierung, sondern um eine kontinuierliche Verpflichtung, die gemäß Artikel 13 Absatz 8 für einen Mindestunterstützungszeitraum von fünf Jahren oder, falls kürzer, für die erwartete Produktlebensdauer gilt.

Speziell für die Codesignierung legt das CRA mehrere Verpflichtungen fest, die sich direkt aus seinen Kernanforderungen ergeben:

Die Integrität von Software und Firmware muss entlang der gesamten Lieferkette und während des gesamten Produktlebenszyklus gewährleistet sein. Jedes mit einem Produkt ausgelieferte Firmware-Image und jedes Update muss auf Authentizität und Unveränderlichkeit verifizierbar sein. Dies erfordert eine kryptografische Signaturinfrastruktur mit nachweisbaren Kontrollen darüber, wer signieren darf, was signiert werden darf und welche Prüfprotokolle existieren.

Sichere Update-Mechanismen sind ausdrücklich vorgeschrieben. Gemäß Artikel 13 sind Hersteller verpflichtet, die automatische Installation von Sicherheitsupdates zu gewährleisten und Mechanismen zur Überprüfung der Update-Authentizität zu implementieren. Ein Update-System ohne kryptografische Signaturprüfung erfüllt diese Anforderung nicht.

Die koordinierte Offenlegung von Sicherheitslücken gemäß Artikel 14 bedeutet, dass die Hersteller über die operative Infrastruktur verfügen müssen, um festzustellen, welche Produktlinien von einer bestimmten Sicherheitslücke betroffen sind, ENISA innerhalb von 24 Stunden nach Kenntnisnahme einer aktiv ausgenutzten Sicherheitslücke zu benachrichtigen und innerhalb von 72 Stunden einen vollständigen Triagebericht vorzulegen.

Es wird ein maschinenlesbares SBOM benötigt, das alle im Produkt enthaltenen Softwarekomponenten dokumentiert. Für die Signatur bedeutet dies, dass die Herkunft jeder Firmware-Komponente nachvollziehbar und dokumentierbar sein muss.

Zuordnung von CRA-Anhang I zu technischen Signaturkontrollen

Anhang I der CRA legt die spezifischen Sicherheitsanforderungen fest, die Produkte mit digitalen Elementen erfüllen müssen. Für Firmware und eingebettete Software lassen sich diese Anforderungen direkt in konkrete technische Kontrollen umsetzen.

CRA-Anhang I-Anforderung	Artikelreferenz	Erforderliche technische Kontrolle
Sicherheit durch Design: Risiken angemessen für den beabsichtigten Verwendungszweck behandeln	Art. 1	Sichere Bootkette: unveränderliche BootROM/OTP-Anker mit gerätespezifischen Schlüsseln; jede Bootphase wird vor der Ausführung kryptografisch verifiziert
Daten- und Codeintegrität: Schutz der Integrität gespeicherter Daten, übertragener Daten und ausführbarer Programme	Art. 2(f)	Firmware-Signierung: HSM-gebundene Schlüssel signieren jedes Firmware-Artefakt; SUIT/FIT/UEFI-Manifeste liefern Herkunftsnachweis und Manipulationssicherheit.
Zugangskontrolle: Schutz vor unbefugtem Zugriff	Art. 2(d)	M-of-N-Signaturquorum: Produktionsfirmware darf nicht von einer einzelnen Person signiert werden; dies wird durch rollenbasierte Zugriffskontrolle (RBAC) der Signaturplattform sichergestellt.
Vorfallminderung: die Auswirkungen von Sicherheitsvorfällen reduzieren	Art. 2(k)	Produktspezifische Schlüsselisolierung: Eine Sicherheitslücke betrifft ein einzelnes Produkt, nicht das gesamte Portfolio.
Keine bekannten Schwachstellen: Produkte müssen ohne bekannte ausnutzbare Schwachstellen ausgeliefert werden.	Art. 2(a)	Vorabprüfung auf Schwachstellen: Firmware-Artefakte werden vor der Signierungsfreigabe anhand bekannter CVE-Datenbanken geprüft.
Minimierte Angriffsfläche: Alle externen Schnittstellen einschränken	Art. 2(j)	Geräteattestierung: DICE/TPM/PSA/TEE liefern einen Laufzeitnachweis dafür, dass nur verifizierter, unveränderter Code ausgeführt wird.

Die andere Hälfte der Codesignatur-Konformität: Anforderungen des CA-/Browser-Forums

Die CRA regelt das Produkt; sie sagt nichts über das Zertifikat aus, unter dem der Signaturschlüssel ausgestellt wurde. Das sind die Basisanforderungen des CA/Browser Forums für die Ausstellung und Verwaltung öffentlich vertrauenswürdiger Code-Signaturzertifikate, und jede Organisation, die mit einem öffentlich vertrauenswürdigen Zertifikat signiert, muss beide Anforderungen gleichzeitig und im Rahmen desselben Signaturvorgangs erfüllen.

Dies sind keine Empfehlungen; jede Empfehlung hat ein bestimmtes Gültigkeitsdatum und eine spezifische Abstimmungsreferenz:

Datum des Inkrafttretens	Stimmzettel / Änderung	Anforderung
1. Juni 2023	CA/B Forum Schlüsselschutz-Update	Private Schlüssel für die Codesignierung MÜSSEN in einem Hardware-Kryptomodul generiert und gespeichert werden, das FIPS 140-2 Level 2 oder Common Criteria EAL4+ erfüllt; die softwarebasierte Schlüsselgenerierung ist nicht mehr zulässig.
April 2024	Stimmzettel CSC-22	Die Widerrufsauslöser wurden über die bestätigte Kompromittierung von Schlüsseln hinaus erweitert und umfassen nun auch verdächtigen Code sowie böswillige oder unautorisierte Signieraktivitäten.
Juni 2024	Anforderungen des CA/B Forum Signing Service	Drittanbieter-Signaturdienste, die Schlüssel im Auftrag eines Abonnenten verwalten, MÜSSEN sich formalen Konformitätsbewertungsaudits unterziehen (z. B. WebTrust für Zertifizierungsstellen, ETSI EN 319 401).
April 2025	Aktualisierung der Zeitstempel im CA/B-Forum	Die privaten Schlüssel der Timestamp Authority MÜSSEN in Offline-Hardware-Kryptomodulen geschützt werden.
1. März 2026	Stimmzettel CSC-31	Die maximale Gültigkeitsdauer von Codesignaturzertifikaten wurde für Zertifikate, die an oder nach diesem Datum ausgestellt werden, von 39 Monaten auf 460 Tage reduziert.

Widerruf

Gemäß den Basisanforderungen §4.9.1.1 muss eine Zertifizierungsstelle (CA) ein Codesignaturzertifikat innerhalb von 24 Stunden widerrufen, nachdem sie die Kompromittierung des privaten Schlüssels bestätigt hat. Ein Widerrufsantrag eines Abonnenten oder eine Meldung über die Unberechtigtkeit des ursprünglichen Antrags muss gemäß §4.9.1.2 innerhalb eines Werktages bearbeitet werden. Seit der Abstimmung CSC-22 gilt diese 24-Stunden-Frist auch dann, wenn verdächtiger Code – und nicht nur eine bestätigte Schlüsselkompromittierung – mit dem Zertifikat in Verbindung gebracht wird. Praktisch bedeutet dies, dass eine Organisation innerhalb weniger Stunden wissen muss, welches Zertifikat welches Artefakt signiert hat, um den Widerruf beantragen zu können, bevor die Erkennungsmechanismen der CA dies zu einem ungünstigeren Zeitpunkt für sie erledigen.

Zeitstempeln

Ein vertrauenswürdiger Zeitstempel gemäß RFC 3161 gewährleistet die Verifizierbarkeit einer Signatur auch nach Ablauf des Signaturzertifikats. Ohne einen solchen Zeitstempel wäre ein mit einem inzwischen abgelaufenen 460-Tage-Zertifikat signiertes Artefakt ab dem Tag des Zertifikatsablaufs ungültig. Seit April 2025 verpflichtet das CA/B Forum Zeitstempelstellen, ihre Signaturschlüssel in Offline-Hardware-Kryptomodulen zu schützen. Dies erhöht die Anforderungen an Zeitstempelanbieter für eine konforme Signaturpipeline. Stellen Sie sicher, dass Ihre Zeitstempelstelle diese Anforderung direkt erfüllt; eine Codesignaturplattform kann dies nicht allein kompensieren.

Erneuerung

Die Verkürzung der Gültigkeitsdauer von 39 Monaten auf 460 Tage verdreifacht nahezu die Häufigkeit der notwendigen Erneuerung von Codesignaturzertifikaten. Ein manueller Erneuerungsprozess, der im alten Zyklus lediglich umständlich war, wird im neuen zu einem echten Betriebsrisiko: Ein mitten im Release-Zyklus abgelaufenes Zertifikat blockiert die Signierung vollständig. Das Zertifikatslebenszyklusmanagement muss Codesignaturzertifikate als nachverfolgte, automatisch erneuerte Anlageklasse behandeln und nicht als einmalige Anschaffung, an die sich ein Team alle paar Jahre erinnern muss.

Konsequenzen für den Schlüsselschutz

Die HSM-Vorschrift vom Juni 2023 schloss die bisherige Option für Zertifikate mit geringerer Sicherheit: die softwarebasierte Schlüsselerzeugung. Jeder öffentlich vertrauenswürdige Codesignaturschlüssel muss nun innerhalb eines Hardwaremoduls gemäß FIPS 140-2 Level 2 (oder höher) oder Common Criteria EAL4+ generiert und darf nicht mehr von diesem exportiert werden. Dies entspricht der Architekturanforderung, die auch die Hardware-Vertrauensankerstelle gemäß Artikel 13(1)(c) des CRA unabhängig davon vorschreibt. Genau hier ergänzen sich die beiden Compliance-Regelungen, anstatt separate Arbeitsschritte zu verursachen.

Schlüsselisolationsarchitektur

Die operativ bedeutendste architektonische Änderung, die die CRA von den meisten Organisationen fordert, ist der Übergang von einer gemeinsam genutzten Signaturschlüsselinfrastruktur zur produktspezifischen Schlüsselisolation.

Das Modell mit gemeinsamem Schlüssel ist der Standard für Organisationen, die Codesignierung ohne formale Governance eingeführt haben. Ein einziger Signaturschlüssel, beispielsweise auf einem USB-Token oder einem Build-Server gespeichert, wird verwendet, um die Firmware für jedes Produkt zu signieren. Es ist einfach zu verwalten und funktioniert technisch. Gemäß dem Code-Records Act (CRA) stellt es jedoch einen Verstoß gegen die strukturelle Compliance dar.

Darum ist diese Unterscheidung wichtig:

Architektur mit gemeinsamem Schlüssel

Alle Produktlinien verwenden denselben Signaturschlüssel. Wenn dieser Schlüssel kompromittiert wird:

• Alle damit gekennzeichneten Produkte sind gleichzeitig betroffen.
• Der Wirkungsbereich umfasst das gesamte Portfolio.
• Die in Artikel 14 vorgesehene 24-Stunden-Meldepflicht gegenüber der ENISA muss alle betroffenen Produkte gleichzeitig erfassen, ohne dass die Möglichkeit besteht, den Umfang der Auswirkungen abzuschätzen.
• Antwort zur Einhaltung der Vorschriften: Ohne produktbezogene Aufzeichnungen ist dies innerhalb von 24 Stunden nicht möglich.

Schlüsselarchitektur pro Produkt

Jede Produktlinie verfügt über einen eigenen Schlüssel, der intern generiert und in einer separaten HSM- Partition gespeichert wird. Wenn ein Schlüssel kompromittiert wird:

• Nur das Produkt, das mit diesem Schlüssel verknüpft ist, ist betroffen.
• Der Explosionsradius beschränkt sich auf eine einzelne Produktlinie.
• Die Mitteilung nach Artikel 14 deckt einen definierten Bereich ab, der präzise und schnell beantwortet werden kann.
• Antwort zur Einhaltung der Vorschriften: Der Prüfpfad identifiziert sofort betroffene Produkte, Signaturvorgänge und Firmware-Versionen.

Für einen Hersteller mit vier Produktlinien bedeutet das Modell mit gemeinsamem Schlüssel ein potenzielles Marktrücknahmeverfahren und gleichzeitige Abhilfemaßnahmen für alle Produkte. Die produktspezifische Trennung hingegen bedeutet, dass nur ein Produkt betroffen ist, drei weiterhin normal funktionieren und die Meldung präzise und nicht panisch erfolgt.

Die Umstellung auf die produktspezifische Schlüsselisolation erfüllt auch die Anforderungen der CRA an die Lieferkettenverantwortlichkeit gemäß Artikel 13 §5. Die Konformitätsbewertungsdokumentation für die CE-Kennzeichnung muss nachweisen, dass der Signaturschlüssel jedes Produkts über eine eigene Verwaltung, Zugriffskontrollen und einen eigenen Prüfpfad verfügt.

Anbieterneutrale Unterzeichnung

Eine der praktischen Herausforderungen für Hersteller, die die CRA-Vorgaben erfüllen wollen, ist die Vielfalt der Siliziumarchitekturen in ihren Produktportfolios. Ein Unternehmen, das sowohl einen Consumer-Router (ARM TrustZone), ein Smart Appliance (MCU/IoT), einen Industriecontroller (RISC-V) als auch ein Serverprodukt (x86/UEFI) herstellt, sieht sich vier unterschiedlichen Plattform-Ökosystemen gegenüber, die jeweils über verschiedene Signatur-Toolchains, unterschiedliche Firmware-Formate (SUIT, FIT, UEFI-Manifeste) und unterschiedliche Hardware-Root-of-Trust-Mechanismen (DICE, TPM, PSA, TEE) verfügen.

Die CRA legt keinen Wert auf diese Komplexität und fordert einheitliche, nachvollziehbare Kontrollen für alle Produkte im Geltungsbereich. Eine herstellerneutrale Signaturarchitektur löst dieses Problem, indem sie die plattformspezifische Signatur-Toolchain von der zugehörigen Richtlinien-Engine entkoppelt. Anstatt vier separate Signatur-Workflows mit vier separaten Schlüsselverwaltungsverfahren und vier separaten Prüfprotokollen zu erstellen, sorgt eine zentrale Richtlinien-Engine für eine einheitliche Governance auf allen Plattformtypen, während plattformspezifische Integrationen die Format- und Protokolldetails für jede Plattform übernehmen.

Die Architekturschichten funktionieren wie folgt:

Hardwarebasierte Vertrauensbasis: FIPS 140-2-zertifizierte HSMs stellen die Schlüsselspeicherung und Signiervorgänge für alle Plattformen bereit. Die Unterstützung von ML-DSA und SLH-DSA gewährleistet quantenresistente Signierung über dieselbe Infrastruktur wie für klassische Algorithmen.

Zentrale Richtlinien-Engine: Die HSM-gestützte Signaturverwaltung wendet einheitliche rollenbasierte Zugriffskontrolle (RBAC), Quorumsanforderungen (M-of-N) und Genehmigungsworkflows über alle Produktlinien und Plattformen hinweg an. Änderungen an den Signaturrichtlinien werden überall gleichzeitig wirksam.

CI/CD und Audit-Schicht: Signierung, Attestierung und unveränderliche Protokollgenerierung erfolgen während der Build-Phase und erzeugen den Artefakt-Hash, die Schlüssel-ID, die Genehmigeridentität, die Pipeline-Phase und den Zeitstempel, die die Audit-Anforderungen der CRA erfordern.

Konforme Ausgaben: Jede Plattform erhält die signierte Firmware im nativen Format mit dem entsprechenden Manifesttyp: SUIT für IoT/MCU, FIT für ARM/Embedded Linux, UEFI-Manifest für x86-Serverplattformen und RISC-V-spezifische Attestierung. Der ENISA-Berichtsworkflow liefert strukturierte, SRP-fähige Ausgaben, die die 24-Stunden-Benachrichtigungspflicht direkt erfüllen.

Diese Architektur erfüllt die CRA-Anforderung an einheitliche Kontrollen über alle Produktlinien hinweg, ohne dass ein separates Compliance-Programm für jede Siliziumplattform erforderlich ist.

Checkliste für Maßnahmen zur Einhaltung der Vorschriften

Nutzen Sie dies als Vorbereitungssequenz für Audits, die beide Regime abdeckt, und nicht als einmalige Einrichtungsaufgabe:

1. Gemäß den Anforderungen des CA/B Forums vom Juni 2023 muss sichergestellt werden, dass jeder private Code-Signatur-Schlüssel, unabhängig von der Produktlinie, innerhalb eines FIPS 140-2 Level 2+ (oder Common Criteria EAL4+) HSM generiert und niemals von diesem exportiert wird.
2. Umstellung von einem gemeinsamen Signaturschlüssel auf eine produktspezifische Schlüsselisolation, bei der sich der Schlüssel jeder Produktlinie in einer eigenen HSM-Partition und einer eigenen Zugriffskontrollliste befindet.
3. Die Genehmigung durch das M-of-N für die Produktionsunterzeichnung muss durchgesetzt werden, damit keine einzelne Person einseitig unterschreiben und versenden kann. Es muss sichergestellt werden, dass dies durch die Richtlinien-Engine der Signaturplattform und nicht nur durch den Prozess selbst gewährleistet wird.
4. Registrieren Sie jedes Code-Signatur-Zertifikat in einem Zertifikatslebenszyklus-Managementprozess, der für 460-Tage-Erneuerungszyklen ausgelegt ist, nicht für den alten 39-Monats-Zyklus.
5. Vergewissern Sie sich, dass Ihre Zeitstempelbehörde ihre eigenen Schlüssel in einem Offline-Hardware-Kryptomodul gemäß der Anforderung vom April 2025 schützt und dass jede Signatur zum Zeitpunkt der Unterzeichnung mit einem Zeitstempel versehen wird.
6. Entwickeln Sie die Fähigkeit (oder bestätigen Sie, dass Sie über die Fähigkeit verfügen), innerhalb weniger Stunden jedes Artefakt zu identifizieren, das mit einem bestimmten Zertifikat oder Schlüssel signiert ist, damit eine Widerrufsfrist von 24 Stunden oder eine ENISA-Benachrichtigungsfrist erreichbar und nicht nur ein Wunschtraum ist.
7. Bewahren Sie Signaturereignisprotokolle, Artefakt-Hashes, Genehmigeridentitäten und Zertifikatsherkunft mindestens für die von der CRA vorgeschriebene Mindestsupportperiode von fünf Jahren auf, länger, wenn die erwartete Lebensdauer Ihres Produkts diesen Zeitraum überschreitet.
8. Wenn Sie einen externen Signaturdienst nutzen, vergewissern Sie sich, dass dieser das seit Juni 2024 vorgeschriebene Konformitätsbewertungsaudit (WebTrust oder ETSI EN 319 401) abgeschlossen hat, anstatt dies einfach anzunehmen.

Wie CodeSign Secure von Encryption Consulting hilft

CodeSign Secure ist die Enterprise-Plattform für das Code-Signatur-Management von Encryption Consulting. Sie wurde entwickelt, um die Infrastrukturkontrollen bereitzustellen, die für die Einhaltung der CRA-Vorschriften in allen in diesem Blog behandelten Bereichen erforderlich sind.

HSM-gestütztes Schlüsselmanagement: CodeSign Secure speichert alle privaten Signaturschlüssel in FIPS 140-2 Level 3-zertifizierten Hardware-Sicherheitsmodulen (HSMs) und ist mit Thales Luna, Entrust nCipher, Utimaco, Securosys sowie Cloud-HSMs von AWS und Azure kompatibel. Die produktspezifische Schlüsselisolation wird auf HSM-Partitionsebene gewährleistet: Jede Produktlinie erhält einen eigenen, dedizierten Schlüssel, der in der Hardware generiert und niemals exportiert wird. Dies erfüllt direkt die Anforderungen der CRA an einen Hardware-Root of Trust gemäß Artikel 13(1)(c) sowie die Anforderung an die produktspezifische Isolation gemäß Artikel 13 §5.

M-of-N-Signaturquorum und RBAC: Das rollenbasierte Zugriffskontrollmodell der Plattform erzwingt die M-of-N-Genehmigungsanforderungen für die Signierung von Produktions-Firmware. Keine einzelne Person kann einen Signiervorgang initiieren und genehmigen. Signieranfragen, Genehmigungen und Ablehnungen werden protokolliert. Die RBAC-Konfiguration selbst ist auditierbar und versionskontrolliert und stellt die dokumentierte Signaturrichtlinie bereit, die für CRA-Konformitätsbewertungen erforderlich ist.

Unveränderliche Protokollierung: Jedes Signaturereignis in CodeSign Secure erzeugt einen unveränderlichen Protokolleintrag, der den Artefakt-Hash, die Schlüsselkennung, das verwendete Zertifikat, die genehmigende Identität und den RFC-3161-Zeitstempel erfasst. Die Protokolle werden zentral und getrennt von der Signaturinfrastruktur gespeichert.

Plattformübergreifende Firmware-Formatunterstützung: CodeSign Secure unterstützt die Signierung von Firmware-Artefakten in allen Formaten, die ein vielfältiges Produktportfolio erfordert: .bin, .img, .hex, .fw, .dfu und .efi. Damit wird die Anforderung der CRA nach einheitlichen Kontrollen über alle Produktlinien hinweg erfüllt, ohne dass die Signaturinfrastruktur für jede Plattform neu aufgebaut werden muss.

Unterstützung für Post-Quanten-Kryptographie: CodeSign Secure v3.02 unterstützt produktionsreife ML-DSA (FIPS 204, Sicherheitsstufen ML-DSA-44, ML-DSA-65 und ML-DSA-87) und SLH-DSA (FIPS 205) als abtrennbare Signaturen neben klassischen Algorithmen. Für Hersteller von Produkten mit mehr als fünfjährigen CRA-Supportverpflichtungen bietet die PQC-Signatur bereits heute Schutz vor der HNDL-Bedrohung, noch bevor CRQC verfügbar ist.

CI/CD-Pipeline-Integration: CodeSign Secure lässt sich über API- und Befehlszeilenschnittstellen in Azure DevOps, Jenkins, GitLab CI und andere gängige Pipeline- Plattformen integrieren. Die Signierung der Firmware ist ein kontrollierter, richtlinienbasierter Schritt in der Build-Pipeline und kein manueller Vorgang.

Fazit

Der Cyber ​​Resilience Act hat die Firmware-Signierung von einer bewährten Sicherheitsmaßnahme zu einer verbindlichen Rechtspflicht erhoben. Die erste Umsetzungsmaßnahme, die Meldepflichten für Vorfälle und Schwachstellen gemäß Artikel 14, tritt am 11. September 2026 in Kraft. Die vollständige Einhaltung der Vorschriften, einschließlich der CE-Kennzeichnung, ist bis zum 11. Dezember 2027 erforderlich. Die Infrastruktur, die zur Einhaltung dieser beiden Fristen benötigt wird – produktspezifische Schlüsselisolierung, HSM-gestützte Signierung, M-von-N-Quoren, 10-jährige Audit-Trails und auf Schwachstellenprüfungen basierende Signierungs-Workflows – benötigt 12 bis 18 Monate für die Konzeption und Implementierung.

Die Organisationen, die am besten für die Einhaltung der CRA-Vorschriften aufgestellt sind, sind nicht diejenigen, die erst im Dezember 2027 mit dem Aufbau ihrer Signaturarchitektur beginnen. Sie sind diejenigen, die sie jetzt aufbauen, bevor die Meldepflichten ab September 2026 die Lücken in ihrer aktuellen Infrastruktur aufdecken.

Bei Encryption Consulting bietet CodeSign Secure die von der CRA geforderte Signaturinfrastruktur – von der HSM-gestützten Schlüsselisolation über unveränderliche Prüfprotokolle bis hin zur Post-Quantum-Signatur, die die HNDL-Bedrohung innerhalb des von der CRA vorgegebenen Unterstützungszeitraums adressiert.

Häufig gestellte Fragen

Sind die CRA- und die CA/Browser-Forum-Basisanforderungen identisch?

Nein. Der Cybersecurity Regulation Act (CRA) ist EU-Recht, das die Cybersicherheit von Produkten mit digitalen Elementen regelt. Die CA/Browser Forum Baseline Requirements sind Branchenregeln für die Ausstellung und Verwaltung öffentlich vertrauenswürdiger Zertifikate, einschließlich Code-Signatur-Zertifikaten. Eine Organisation, die ein öffentlich vertrauenswürdiges Zertifikat für ein unter den CRA fallendes Produkt verwendet, muss beide Anforderungen gleichzeitig erfüllen.

Wie lange habe ich Zeit, ein Codesignaturzertifikat nach einer Schlüsselkompromittierung zu widerrufen?

Gemäß den Anforderungen an die Code-Signatur (Abschnitt 4.9.1.1) muss eine Zertifizierungsstelle (CA) die Zertifizierung innerhalb von 24 Stunden nach Bestätigung einer Schlüsselkompromittierung widerrufen. Seit der Abstimmung CSC-22 (April 2024) gilt diese 24-Stunden-Frist nicht nur für bestätigte Kompromittierungen, sondern auch für Zertifikate, die mit verdächtigem Code oder unautorisierten Signaturaktivitäten in Verbindung stehen.

Warum sank die Gültigkeitsdauer des Codesignaturzertifikats auf 460 Tage?

Mit der Abstimmung CSC-31 wurde die maximale Gültigkeitsdauer von Code-Signatur-Zertifikaten, die am oder nach dem 1. März 2026 ausgestellt werden, von 39 Monaten auf 460 Tage reduziert. Dies entspricht dem branchenweiten Trend des CA/Browser Forums, die Lebensdauer von Zertifikaten zu verkürzen, um das Risiko einzelner Zertifikate zu begrenzen.

Spielt die Zeitstempelung noch eine Rolle, wenn Zertifikate jetzt schneller ablaufen?

Das ist von größerer Bedeutung. Ein vertrauenswürdiger RFC-3161-Zeitstempel sorgt dafür, dass eine Signatur auch nach Ablauf ihres Zertifikats gültig bleibt; mit einer Gültigkeitsdauer von 460 Tagen anstelle von 39 Monaten ist die Wahrscheinlichkeit, dass Artefakte verifiziert werden können, weitaus höher, nachdem ihr ursprüngliches Signaturzertifikat bereits abgelaufen ist.

Wie lange muss ich die Unterlagen zur Unterzeichnungsprüfung mindestens aufbewahren?

Mindestens die von der CRA gemäß Artikel 13(8) festgelegte Mindestunterstützungsdauer von fünf Jahren, oder länger, wenn die erwartete Lebensdauer Ihres Produkts fünf Jahre übersteigt. Die Aufzeichnungen sollten jeden Signaturvorgang dem jeweiligen Schlüssel, Genehmiger, Artefakt-Hash und Zertifikat zuordnen.