Integrität auf Embedded-Linux-Geräten unter dem Cyber Resilience Act

Wie schon bei der Vertraulichkeit führt der Cyber Resilience Act (CRA) auch die Integrität als grundlegende Cybersicherheitsanforderung auf. In diesem Beitrag betrachten wir, was das für Embedded-Linux-Geräte bedeutet.

Anhang I, Teil I(2) legt fest, dass Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden:

(f) die Integrität von gespeicherten, übermittelten oder anderweitig verarbeiteten Daten, seien es personenbezogene oder andere, sowie von Befehlen, Programmen und Konfigurationen gegen jede vom Nutzer nicht autorisierte Manipulation oder Veränderung schützen und Beschädigungen melden

Wie erfüllt ein Embedded-Linux-Gerät diese Anforderung nun tatsächlich? Die Integritätsanforderung des CRA ist so weit gefasst, wie sie klingt. Sie umfasst nicht nur (personenbezogene und nicht personenbezogene) Daten, sondern auch Befehle, Programme und Konfigurationen, und sie gilt unabhängig davon, ob das Gerät diese Werte speichert, übermittelt oder aktiv verarbeitet.

Es gibt keine einzelne technische Maßnahme, die all diese Werte in jedem Zustand schützt. Je nach Produkt und Threat Model kann Integrität Maßnahmen für die Boot-Kette, Software-Updates, gespeicherte Daten, Anwendungs-Binaries, Konfiguration, Befehle und die Kommunikation mit anderen Systemen erfordern.

Umfang der CRA-Integritätsanforderung

Dieser gliedert sich in zwei Teile:

Betroffene Werte

gespeicherte, übermittelte oder anderweitig verarbeitete Daten, seien es personenbezogene oder andere, sowie Befehle, Programme und Konfigurationen

Der CRA nennt Daten, Befehle, Programme und Konfigurationen, schreibt aber keine feste Liste von Komponenten oder Maßnahmen vor. Nach Artikel 13 muss die Cybersicherheits-Risikobewertung angeben, ob und wie die Anforderungen aus Anhang I, Teil I(2) auf das Produkt zutreffen. Für Embedded-Geräte bedeutet das, dass der Hersteller ein Threat Model benötigt. Es sollte aufzeigen, welche Werte ein Angreifer verändern könnte, welche Wege ihm dafür offenstehen und welche Folgen das hätte.

Bei einem Embedded-Gerät können zu den betroffenen Werten der Bootloader, der Kernel, die Kernel-Kommandozeile, Anwendungs-Binaries, die Konfiguration sowie Nachrichten oder Befehle gehören, die mit anderen Systemen ausgetauscht werden. Die Anforderung beschränkt sich daher nicht auf Nutzerdaten oder personenbezogene Daten. Selbst ein Gerät, das überhaupt keine personenbezogenen Daten speichert, fällt unter die Integritätsanforderung.

Erforderlicher Schutz

schützen … gegen jede vom Nutzer nicht autorisierte Manipulation oder Veränderung und Beschädigungen melden

Für ein Embedded-Linux-Gerät heißt das, relevante Werte gegen unbefugte Veränderung zu schützen, Integritätsverletzungen dort zu erkennen, wo es angebracht ist, und Beschädigungen zu melden. Die passenden Technologien hängen vom jeweiligen Wert und vom Threat Model ab.

In manchen Fällen erfordert der Schutz gegen unbefugte Veränderung zusätzlich Authentizität. Das Gerät muss überprüfen, dass Software, Konfiguration, Befehle oder Daten aus einer autorisierten Quelle stammen.

Integritätsmaßnahmen für Embedded Linux

Embedded-Linux-Geräte benötigen in der Regel Integritätsmaßnahmen auf mehreren Ebenen. Die folgenden Beispiele sind ein Ausgangspunkt, keine Checkliste für jedes Produkt:

• Secure Boot: um die Integrität und Authentizität jeder Komponente der Boot-Kette zu überprüfen, bevor das Gerät sie ausführt. Setzen Sie Secure Boot sorgfältig um: Angreifer können Eingaben außerhalb der Vertrauenskette missbrauchen, etwa die Kernel-Kommandozeile oder die Bootloader-Umgebung, um Schutzmechanismen zu umgehen.

• Signierte Updates: um die Authentizität und Integrität von Firmware-, Betriebssystem- und Anwendungs-Updates zu überprüfen, bevor das Gerät sie installiert. Je nach Produkt kann dazu auch ein Rollback-Schutz nötig sein.

• Integrität von Data at Rest: um Veränderungen oder Beschädigungen gespeicherter Daten zu erkennen. Je nach Ebene und Anwendungsfall lässt sich dies durch unterschiedliche Mechanismen umsetzen, etwa:

  • dm-verity für Read-only-Block-Devices
  • dm-integrity für beschreibbare Block-Devices, optional in Kombination mit dm-crypt für authentifizierte Verschlüsselung.
  • Linux IMA und EVM für Dateiintegrität und ausgewählte Datei-Metadaten.
  • fs-verity für Read-only-Dateiinhalte.

• Zugriffskontrolle: um die Integrität zu wahren, indem eingeschränkt wird, wer oder was relevante Werte verändern darf. Ein Gerät kann Zugriffskontrolle auf verschiedenen Ebenen umsetzen, zum Beispiel mit Dateisystem-Berechtigungen, Linux Security Modules wie SELinux oder AppArmor, oder mit Autorisierungsprüfungen auf Anwendungsebene für APIs (etwa REST oder GraphQL).

• Integrität von Data in Transit: um unbefugte Veränderungen von Daten zu erkennen, während das Gerät sie mit anderen Systemen austauscht, und veränderte Daten abzuweisen, zum Beispiel mit TLS.

• Trusted Execution Environments: um ausgewählten Code und ausgewählte Daten während der Verarbeitung zu schützen. So können TEEs Integritäts- und Vertraulichkeitsschutz bieten, selbst wenn ein Angreifer das Hauptbetriebssystem kompromittiert, abhängig vom TEE-Design und vom Threat Model.

Fazit

Die wichtigste Erkenntnis lautet: Die Integritätsanforderung des CRA ist breit gefasst, und keine einzelne Funktion kann sie erfüllen. Je nach Threat Model benötigt das Produkt möglicherweise mehrere sich ergänzende Technologien.

Zur Erinnerung: Ein Verstoß gegen den CRA ist mit empfindlichen Geldbußen verbunden. Die zentralen Pflichten gelten ab dem 11. Dezember 2027. Danach kann ein Verstoß gegen die grundlegenden Cybersicherheitsanforderungen Geldbußen von bis zu 15.000.000 EUR oder 2,5 % des gesamten weltweiten Jahresumsatzes nach sich ziehen.

Wenn Sie Unterstützung dabei brauchen, ein Threat Model abzuleiten, passende Integritätsmechanismen auszuwählen oder zu überprüfen, ob Ihre bestehenden Maßnahmen die relevanten Bedrohungen abdecken, helfen wir Ihnen gerne.