Aufbau digitalen Vertrauens durch CRA-konforme Code-Signierung

Einführung

Der Cyber ​​Resilience Act (CRA) ist eine EU-Verordnung zur Verbesserung der Cybersicherheit und digitalen Resilienz aller Produkte mit digitalen Komponenten, darunter IoT-Geräte, Medizinprodukte und industrielle Systeme. Er legt gemeinsame Standards für Hardware- und Softwareprodukte fest, die direkt oder indirekt mit einem Gerät oder Netzwerk verbunden sind.

Gemäß dem CRA müssen die Hersteller die Sicherheit während des gesamten Produktlebenszyklus gewährleisten (Artikel 13), indem sie Anforderungen wie die Meldung von Sicherheitsvorfällen und die Bereitstellung automatischer Sicherheitsupdates erfüllen. Dies unterstreicht die entscheidende Bedeutung sicherer Codierungs- und Entwicklungspraktiken bei diesen vielfältigen digitalen Produkten. 

Die Nichteinhaltung der CRA ist kostspielig und kann Bußgelder von bis zu 15 Millionen Euro oder 2.5 % des weltweiten Umsatzes nach sich ziehen. Dies unterstreicht die Notwendigkeit starker kryptografischer Kontrollen, sicherer Code-Signierung und durchgängiger Integrität der Software-Lieferkette, um die kontinuierliche Einhaltung der CRA-Vorschriften und digitales Vertrauen zu gewährleisten. 

CRA-konforme Codesignierung, definiert: ein Codesignierungsprogramm, bei dem jede Kontrolle, Schlüsselspeicherung, Zugriffstrennung, Zeitstempelung, Widerrufung, Audit-Protokollierung einem bestimmten CRA-Artikel zugeordnet ist, wobei eine klare Trennlinie gezogen wird zwischen dem, was die Verordnung explizit vorschreibt, und dem, was eine dringend empfohlene Praxis zur Erreichung ihrer umfassenderen Ziele der Sicherheit durch Design darstellt, untermauert durch Nachweise, die eine Konformitätsbewertung tatsächlich überprüfen kann.

Wichtige Erkenntnisse

• Nicht jede bewährte Vorgehensweise bei der Codesignierung ist eine wörtliche Vorgabe der CRA (Certificate of Regulatory Affairs). Einige, wie die Multi-Faktor-Authentifizierung (MFA) für den Zugriff auf die Signatur oder separate Test- und Produktionsschlüssel, sind dringend empfohlene Maßnahmen, um einer umfassenderen, risikobasierten Verpflichtung nachzukommen, die die CRA explizit formuliert. Diese Unterscheidung ist wichtig für die Dokumentation der Einhaltung der Vorschriften.
• Diese Seite ordnet die einzelnen, CRA-konformen Codesignaturverfahren spezifischen Artikeln zu, Anforderung für Anforderung. Informationen zur Dual-Regime-Architektur, die CRA mit den Abstimmungsanforderungen des CA/Browser Forums kombiniert, sowie eine konsolidierte Aktionscheckliste finden Sie hier. CRA-konforme Architektur für sichere Codesignierung.
• Das HSM-Mandat des CA/Browser Forums (FIPS 140-2 Level 2 oder höher, gültig ab 1. Juni 2023) gilt für alle öffentlich vertrauenswürdigen Codesignaturschlüssel unabhängig vom CRA-Geltungsbereich; die CRA-Konformität ersetzt diese Grundlage nicht, sondern ergänzt sie.
• Für eine unterbrochene Vertrauenskette ist kein gestohlener Schlüssel erforderlich: Die BootHole-Schwachstelle beeinträchtigte Secure Boot durch einen Fehler in der Signaturverifizierungslogik von GRUB2 selbst, obwohl gültige Schlüssel vorhanden und Secure Boot durchgehend aktiviert waren.

Was ist Code-Signing? 

Die Codesignierung ist wie ein digitaler Stempel, der beweist, dass Software oder Updates aus einer vertrauenswürdigen Quelle stammen und nicht verändert wurden. Sie funktioniert mit zwei speziellen Schlüsseln – einem privaten und einem öffentlichen –, die die Identität der Software verifizieren und ihre sichere Verwendung gewährleisten.

Es gibt zwei Haupttypen von Code Signing-Zertifikaten: 

• Standardzertifikate: Diese liefern einen grundlegenden Beweis dafür, dass die Software vom richtigen Herausgeber stammt und nicht verändert wurde. 
• Extended Validation (EV)-ZertifikateDiese gehen noch einen Schritt weiter, indem sie strengere Identitätsprüfungen und zusätzliche Sicherheitsmaßnahmen, wie die Speicherung von Schlüsseln auf sicherer Hardware, vorschreiben. Produkte, die dem Cyber ​​Resilience Act entsprechen, verwenden häufig EV-Zertifikate weil sie ein höheres Vertrauen bieten und weniger Warnungen bei der Installation der Software durch die Benutzer ausgeben.

 Kurz gesagt: Durch die Code-Signierung können Benutzer der Software vertrauen, indem sie ihre Herkunft bestätigen und sicherstellen, dass sie sicher und unverfälscht ist.

So funktioniert Code Signing

• Erstellen eines eindeutigen Fingerabdrucks:  Ein kryptografischer Hash (wie beispielsweise SHA-256) wird von der Software generiert. Dieser Hashwert dient als eindeutiger digitaler Fingerabdruck; ändert sich auch nur ein einziges Byte, ändert sich auch der Fingerabdruck. 
• Generieren der digitalen Signatur: Der Herausgeber verschlüsselt diesen Hash mit seinem privaten Schlüssel und erstellt so eine digitale Signatur, die sowohl für die Software als auch für den Unterzeichner eindeutig ist. 
• Beifügen eines Identitätsnachweises:  Die digitale Signatur und ein Code Signing-Zertifikat (das den öffentlichen Schlüssel und die verifizierte Identität des Herausgebers enthält) sind im Lieferumfang der Software enthalten. 
• Überprüfen des Codes:  Wenn Benutzer die Software herunterladen oder installieren, verwendet ihr System den öffentlichen Schlüssel, um die Signatur zu überprüfen. Stimmt diese mit dem aktuellen Hash der Software überein, gilt der Code als echt und unverfälscht. 

Warum Code Signing für die CRA-Compliance wichtig ist

Code Signing spielt eine entscheidende Rolle bei der Erfüllung der CRA-Anforderungen, indem es sicherstellt, dass Software authentisch, vertrauenswürdig und vor Manipulationen geschützt ist. Es unterstützt direkt mehrere wichtige Compliance-Bereiche: 

• Sicherheit in der Lieferkette: Code Signing ist für die Einhaltung der CRA-Vorschriften unerlässlich, da es die Sicherheit der Lieferkette direkt stärkt, indem es die Authentizität und Integrität jeder Softwarekomponente überprüft, einschließlich der Abhängigkeiten, die anfällig für Manipulationen oder böswillige Einfügungen sind. Dies stellt sicher, dass die an die Benutzer ausgelieferte Software vertrauenswürdig und manipulationssicher ist und erfüllt die kritischen CRA-Anforderungen an Softwareintegrität, Rückverfolgbarkeit und Supply Chain Risikominderung. 
• Integritätsschutz: Das CRA verlangt, dass Software, Befehle und Konfigurationen vor unbefugten Änderungen geschützt bleiben (Artikel 6 und Anhang I legen die technischen Anforderungen an die Cybersicherheit fest). Code Signing erfüllt diese Anforderung, indem es kryptografische Signaturen verwendet, um zu beweisen, dass die Software seit der Signierung nicht verändert wurde. So werden sowohl Entwickler als auch Endbenutzer vor kompromittiertem Code geschützt. 
• Sicherer Startvorgang: Gemäß dem CRA müssen Geräte die Authentizität der Software in jeder Phase des Startvorgangs überprüfen (Artikel 6 und 13, unterstützt durch Anhang I). Sichere Boot-Mechanismen basieren auf der Code-Signierung, um eine Vertrauenskette aufzubauen, die bei hardwarebasierten Roots beginnt und sich durch jede Ebene der Firmware und Software erstreckt, die während des Bootvorgangs geladen wird. 
• Sichere Updates: Um den CRA-Standards zu entsprechen, dürfen Geräte nur authentische und vertrauenswürdige Software-Updates akzeptieren (Artikel 5, 6 und 13). Durch Code Signing wird sichergestellt, dass Updates vor der Installation überprüft werden, wodurch Systeme vor böswilligen oder unbefugten Änderungen geschützt werden. 
• Überprüfbarkeit und Rückverfolgbarkeit: Die Einhaltung der CRA-Vorschriften erfordert von Unternehmen, Kontrolle und Verantwortlichkeit über Software-Signaturprozesse nachzuweisen (Artikel 13 und 31). Code-Signatursysteme generieren umfassende Prüfprotokolle, die dokumentieren, wer was wann und mit welchen Schlüsseln signiert hat. Dies liefert klare Beweise bei CRA-Konformitätsprüfungen. 

Secure Boot: Aufbau der Vertrauenskette 

Secure Boot ist ein Eckpfeiler der CRA-Konformität und gewährleistet, dass beim Einschalten eines Geräts ausschließlich authentifizierter und unveränderter Code ausgeführt wird. Es etabliert eine Vertrauenskette, einen schrittweisen Validierungsprozess, der in der Hardware beginnt und sich durch alle Softwareebenen des Systems erstreckt.

• Hardware-Root of Trust (RoT): Der sichere Bootvorgang beginnt mit der Hardware-Root of Trust, in der Regel einem unveränderlichen Boot-ROM, das direkt in die Chips des Geräts eingebettet ist. Reale Implementierungen der Hardware-Root of Trust umfassen Technologien wie Trusted Platform Module (TPM) und Secure Enclave. Diese Module speichern und schützen fest codierte öffentliche Schlüssel-Hashes oder Root-Signaturschlüssel, die nach der Herstellung nicht mehr verändert werden können. Beim Gerätestart wird dieses ROM bzw. Sicherheitsmodul als erstes ausgeführt und verankert die Vertrauenskette für alles, was als Nächstes geladen wird.  
• Bootloader-Verifizierung und kryptografische AgilitätNach dem Start des sicheren Bootvorgangs überprüft das Boot-ROM die digitale Signatur des Bootloaders mithilfe eines vertrauenswürdigen öffentlichen Schlüssels, der in sicherer Hardware (z. B. TPM oder Secure Enclave) gespeichert ist. Schlägt die Überprüfung fehl, stoppt das Gerät oder wechselt in den Wiederherstellungsmodus, um unautorisierten Code zu blockieren. Nach erfolgreicher Validierung prüft der Bootloader nachfolgende Softwarekomponenten wie sekundäre Bootloader oder den Betriebssystemkernel. Diese Schritte können aktualisiert werden, um die Sicherheit zu erhöhen oder neue kryptografische Algorithmen zu implementieren, ohne die Vertrauenskette zu unterbrechen.
• Betriebssystem- und Anwendungsüberprüfung: Nachdem der Kernel und die Kernkomponenten des Betriebssystems geladen wurden, setzt Secure Boot seine Validierungskette fort. Es überprüft die Integrität von Root-Dateisystemen, Gerätetreibern und Anwendungen auf Benutzerebene und führt sie nur aus, wenn ihre kryptografischen Signaturen gültig sind. In komplexeren Systemen kann dieser Schutz auf Firmware, verschlüsselte Dateisysteme und einzelne Anwendungen ausgeweitet werden, um das Vertrauen auf jeder Betriebsebene zu gewährleisten. 
• Umsetzung in der Praxis: In der Praxis verwendet Secure Boot branchenübliche Kryptografie, üblicherweise RSA oder ECC für digitale Signaturen und SHA-256 für Hashing. Jede Phase des Bootvorgangs wird von einer vertrauenswürdigen Stelle signiert, und jedes Update oder jede Konfigurationsänderung muss vor der Ausführung validiert werden. Viele moderne Geräte implementieren zudem zertifikatsbasierte Schlüsselhierarchien und nutzen Hardware-Sicherheitsmodule (HSMs) um private Schlüssel sicher zu speichern.

Wird diese Vertrauenskette unterbrochen, beispielsweise durch einen durchgesickerten oder ungepatchten Schlüssel, der es einem Angreifer ermöglicht, einen schädlichen Bootloader einzuschleusen, kann der Schutz vor sicherem Booten vollständig versagen. Die „BootHole“-Sicherheitslücke ist ein klares Beispiel dafür, wie Angreifer Schwachstellen in den Signaturprüfungen von GRUB2 ausnutzten, um trotz aktiviertem sicheren Booten die Kontrolle über Geräte zu übernehmen. Dies verdeutlicht, warum CRA-geschützte Geräte starke Verschlüsselung verwenden, Signaturschlüssel schützen und Sicherheitspatches aktuell halten müssen, um diese Risiken zu vermeiden. 

Die entscheidende Rolle von HSMs 

Der Schutz der privaten Schlüssel, die für die Code-Signierung verwendet werden, ist unerlässlich. Werden diese Schlüssel kompromittiert, könnten Angreifer scheinbar legitime Schadsoftware verbreiten. Um dies zu verhindern, müssen Code-Signing-Schlüssel in HSMs gespeichert werden. Diese manipulationssicheren Geräte generieren, speichern und verwenden kryptografische Schlüssel sicher, ohne sie Software oder externem Zugriff auszusetzen. 

Seit dem 1. Juni 2023 schreibt das CA/Browser Forum vor, dass alle privaten Code-Signaturschlüssel auf Hardware gespeichert werden müssen, die nach FIPS 140-2 Level 2 oder höher (oder einem gleichwertigen Standard) zertifiziert ist, um vertrauenswürdige Code-Signaturzertifikate zu erhalten. Viele moderne HSMs erfüllen auch den neueren FIPS 140-3-Standard und bieten damit eine zukunftssichere Option. Darüber hinaus unterstützen diese HSMs häufig Remote- und Cloud-basiertes Signieren mit sicherer Attestierung, sodass verteilte Teams kryptografische Schlüssel sicher verwalten können, ohne die Sicherheit zu gefährden. Dies erhöht die Sicherheit der Software-Lieferkette und entspricht aktuellen Cybersicherheitsstandards. 

Zu den Vorteilen von HSMs gehören:

• Nicht extrahierbare Schlüssel, geschützt im HSM. 
• Manipulationserkennung mit automatischer Schlüsselzerstörung bei Einbruchsversuchen. 
• Rollenbasierte Zugriffskontrolle, die sicherstellt, dass nur autorisiertes Personal Zugriff auf Schlüssel hat. 
• Unveränderliche Prüfprotokolle aller kryptografischen Vorgänge. 

Best Practices für CRA-konforme Code-Signierung 

Die Tabelle unten unterscheidet zwischen den tatsächlichen Vorgaben der CRA und den dringend empfohlenen Vorgehensweisen zur Erfüllung dieser Vorgaben, da die Vermischung der beiden ein häufiger Dokumentationsfehler bei einer Konformitätsbewertung ist.

Praxis	Status	CRA-Basis
Zugangskontrolle und sicheres Schlüsselmanagement	Erforderlich	Artikel 13 Absatz 1 Buchstabe c
Spezifischer Mechanismus: Multi-Faktor-Authentifizierung oder rollenbasierter Zugriff	Empfohlen (keine spezifische Vorgabe der CRA)	Unterstützt die allgemeine Verpflichtung gemäß Artikel 13 Absatz 1 Buchstabe c).
Zeitstempelung signierter Artefakte	Empfohlen	Unterstützt die Rückverfolgbarkeitsziele gemäß Artikel 6 / Anhang I
Separate Test- und Produktionssignaturschlüssel	Empfohlen (nicht explizit angegeben)	Unterstützt die risikobasierte Trennung des Umfelds gemäß Artikel 13.
Manipulationssichere Prüfprotokollierung und technische Dokumentation	Erforderlich	Artikel 31
Malware-/Schwachstellenscan vor der Signierung	Erforderlich (Produkte dürfen keine bekannten, ausnutzbaren Sicherheitslücken aufweisen)	Anhang I
Periodische Schlüsselrotation	Empfohlen	Unterstützt den Umgang mit Schwachstellen gemäß Artikel 13 Absatz 1 Buchstabe c und Anhang I Teil II.
Automatisierte Signierung in kontrollierten CI/CD-Pipelines	Erforderlich (strenge Kontrolle der Produktions-/Aktualisierungsprozesse)	Artikel 13 (1) (b)
Dokumentiertes, erprobtes Widerrufsverfahren	Erforderlich (unverzügliche Reaktion auf Vorfälle)	Artikel 13(1)(e)

Erneuerungsrhythmus gemäß den aktuellen Wahlregeln

Unabhängig von CRA selbst hat das CA/Browser Forum die maximale Gültigkeitsdauer öffentlich vertrauenswürdiger Codesignaturzertifikate auf 460 Tage für Zertifikate verkürzt, die am oder nach dem 1. März 2026 ausgestellt wurden. Jeder CRA-konforme Schlüsselverwaltungsprozess sollte daher eine Erneuerung etwa alle 15 Monate vorsehen, nicht wie bisher üblich alle 39 Monate, da ein Zertifikatsablauf die Signierung neuer Releases verhindert, unabhängig davon, wie CRA-konform der Rest der Pipeline ist.

Wie Verschlüsselungsberatung helfen kann 

Encryption Consulting bietet CodeSign Secure an , eine umfassende Codesignaturlösung für Unternehmen, die Organisationen dabei helfen soll, strenge Cybersicherheitsanforderungen wie die der EU-CRA zu erfüllen.

CodeSign Secure bewältigt die wichtigsten Herausforderungen der CRA-Compliance durch die Bereitstellung von: 

• HSM-gestützter Schlüsselschutz: Private Signaturschlüssel bleiben sicher in FIPS 140-2 Level 3-zertifizierten HSMs gespeichert, wodurch sichergestellt wird, dass kein Risiko einer Offenlegung oder eines Diebstahls der Schlüssel besteht. Dies entspricht vollständig den Branchenanforderungen und Best Practices, die für die CRA-Konformität unerlässlich sind. 
• Automatisierung und CI/CD-Integration: Die Lösung lässt sich nahtlos in gängige DevOps-Pipelines und automatisierte Build-Workflows integrieren und stellt sicher, dass die Sicherheit niemals die Entwicklungsgeschwindigkeit oder Innovation behindert. 
• Richtliniendurchsetzung und granulare Zugriffskontrolle: Organisationen können detaillierte Sicherheitsrichtlinien definieren und durchsetzen, Signaturberechtigungen automatisieren und das Signatur-Lebenszyklusmanagement teamübergreifend steuern und so die Audit- und Rechenschaftsanforderungen der CRA unterstützen. 
• Umfassende Prüfprotokolle: Detaillierte Ereignisprotokollierung, mehrstufige Genehmigungen und Quorumkontrollen stellen sicher, dass jede Signaturaktion verfolgt, validiert und konform ist, was die Konformitätsbewertungen der CRA vereinfacht. 
• Skalierbare Bereitstellungsmodelle: Encryption Consulting unterstützt Cloud-, Hybrid- und On-Premises-Bereitstellungen und ermöglicht Unternehmen jeder Größe die Einführung einer robusten Code-Signierung ohne übermäßigen Infrastrukturaufwand. 
• Unterstützung hybrider Signaturalgorithmen (traditionell und PQC): Wir ermöglichen die Verwendung sowohl traditioneller kryptografischer Algorithmen wie RSA & ECC (ECDSA) als auch Post-Quantenkryptographie (PQC) Algorithmen wie ML-KEM, ML-DSA, LMS und mehr in hybriden Signatur-Workflows. Dies gewährleistet die langfristige Widerstandsfähigkeit digitaler Signaturen gegen neu auftretende Quantenbedrohungen. 

Ein Hersteller von IoT-Geräten stand vor Herausforderungen hinsichtlich der CRA-Compliance, insbesondere bei der sicheren Verwaltung von Code-Signaturschlüsseln und der Rückverfolgbarkeit jeder Version. Wir lösten diese Probleme durch die Integration von HSMs in die Umgebung zum Schlüsselschutz, Multi-Faktor-Authentifizierung für den Zugriff und automatisierter Code-Signatur in die CI/CD-Pipeline. Manipulationssichere Audit-Protokollierung wurde ebenfalls aktiviert, um die strengen Rückverfolgbarkeits- und Dokumentationsanforderungen der CRA zu erfüllen. Strenge Schlüsselsperrverfahren stellten sicher, dass kompromittierte Schlüssel schnell ungültig gemacht werden konnten, was für die Schwachstellenbehandlung und Vorfallsreaktion der CRA von entscheidender Bedeutung ist. 

Fazit

Die Einhaltung der EU-Copyright-Richtlinien (CRA) zielt darauf ab, Vertrauen in jede Zeile Code zu schaffen, die Ihr Unternehmen liefert. Codesignierung in Kombination mit Secure Boot und HSMs gewährleistet, dass nur verifizierte und manipulationssichere Software Benutzer und Geräte erreicht. Unternehmen wird empfohlen, eine CRA-Gap-Analyse durchzuführen oder ihre aktuellen Codesignierungs-Workflows zu überprüfen, um Compliance-Lücken zu identifizieren und zu schließen.

Eine ordnungsgemäße Umsetzung der CRA-Compliance reduziert Lieferkettenrisiken, ermöglicht sichere Updates und fördert das Vertrauen der Benutzer. Gleichzeitig stärkt der Schutz von Signaturschlüsseln, die Aufrechterhaltung von Prüfprotokollen und die Integration der Codesignierung in Entwicklungsabläufe die Sicherheitslage und gewährleistet die vollständige Übereinstimmung mit den CRA-Anforderungen. 

Mit CodeSign Secure von Encryption Consulting automatisieren und vereinfachen Sie die Compliance, schützen Ihre Software-Lieferkette und sorgen für sichere Innovationen. In der heutigen vernetzten Welt ist sicheres Code Signing nicht nur ein Compliance-Schritt, sondern auch der Nachweis der Vertrauenswürdigkeit Ihrer Software. 

Häufig gestellte Fragen

Ist von der CRA eine spezielle Codesignatur vorgeschrieben?

Die CRA nennt „Codesignierung“ zwar nicht als separate Anforderung, doch die in den Artikeln 6 und 13 sowie in Anhang I festgelegten Verpflichtungen hinsichtlich Integrität, sicherer Aktualisierung und Rückverfolgbarkeit sind in der Praxis ohne sie kaum zu erfüllen. Die Codesignierung ist der gängige Mechanismus, den die meisten Hersteller zur Erfüllung dieser Verpflichtungen nutzen, und keine gesonderte Vorschrift.

Ist die Multi-Faktor-Authentifizierung für den Signaturzugriff eine Anforderung der CRA?

Nicht explizit. Artikel 13(1)(c) verlangt generell eine angemessene Zugriffskontrolle und ein sicheres Schlüsselmanagement; die Multi-Faktor-Authentifizierung (MFA) ist eine dringend empfohlene Methode, um dieser Verpflichtung nachzukommen, aber keine explizit genannte Anforderung.

Worin unterscheidet sich dieser Artikel von dem anderen CRA-Compliance-Artikel von Encryption Consulting?

Diese Seite ordnet einzelne Codesignaturverfahren spezifischen CRA-Artikeln zu, jeweils eine Anforderung nach der anderen. Die CRA-Konformitätsarchitektur für sichere Codesignatur beschreibt die übergeordnete Architektur, einschließlich der Wechselwirkungen zwischen CRA-Verpflichtungen und separaten Zertifikatsregeln von Zertifizierungsstellen/Browserforen auf derselben Signaturinfrastruktur, und bietet eine zusammenfassende Checkliste mit Maßnahmen.

Kann eine unterbrochene Vertrauenskette auch ohne gestohlenen Signaturschlüssel entstehen?

Ja. Die BootHole-Schwachstelle beeinträchtigte Secure Boot durch einen Fehler in der Signaturprüfung von GRUB2, nicht durch Schlüsseldiebstahl. Die Schlüssel blieben gültig und Secure Boot blieb durchgehend aktiviert; die Verifizierungslogik selbst war die Schwachstelle.