Mit dem Bedrohungsmodell beginnen
Schutzgüter bestimmen: Gerätezugangsdaten, Signierinfrastruktur, personenbezogene Daten, Steuerbefehle und Verfügbarkeit. Prüfen, wer jede Schnittstelle erreichen kann und ob Angreifer das Gerät besitzen können. Auswirkungen auf die Personensicherheit bewerten. Maßnahmen nach Risiken wählen und Prüfungen dokumentieren; ein Bauteilzertifikat zertifiziert nicht das gesamte Produkt.
Praktischer Entwurfs- und Prüfablauf
- Vertrauensgrenzen zwischen Anwendung, privilegierter Firmware, Peripherie und Backend bestimmen.
- Private Signierschlüssel von Prüfmaterial trennen; Provisionierung, Rotation und Widerruf planen.
- Start-, Debug- und Speicherschutz für die genaue Geräterevision wählen.
- Updates authentifizieren und Wiederherstellung nach abgebrochenen Schreibvorgängen testen.
- Dienste begrenzen, Nutzer und Geräte authentifizieren und API-Berechtigungen prüfen.
- Falsches Image, widerrufene Zugangsdaten, alte Versionen, fehlerhafte Eingaben und Verbindungsverlust testen.
- Abhängigkeiten, Schwachstellenbewertung, Freigabenachweise und Unterstützungsplan pflegen.
Prüfergebnisse müssen Ziel, Konfiguration und Angriffsannahmen nennen. Ein erfolgreicher Secure-Boot-Test beweist keine Widerstandsfähigkeit gegen jeden physischen oder Laufzeitangriff.
Hardwarevertrauen und Schlüsselschutz
Ein Hardware-Vertrauensanker verankert bestimmte Sicherheitsfunktionen in hardwaregestützten Mechanismen, auf deren Integrität das System vertraut. Geschützter Startcode, Schlüsselmaterial, isolierte Ausführung oder ein Sicherheitsbaustein können dazugehören. Öffentlicher Prüfschlüssel oder dessen Hash sind nicht der geheime private Signierschlüssel: Letzteren schützt der Hersteller normalerweise in seiner Signierinfrastruktur. TrustZone, TPM und Secure Element haben unterschiedliche Rollen; keines bildet automatisch eine vollständige Architektur oder Produktzertifizierung. Manipulationsresistenz bezieht sich auf ein Bedrohungsmodell und Sicherheitsniveau, nicht auf die Garantie physisch unmöglicher Schlüsselextraktion. Debugzugang, Fehlerinjektion, Seitenkanäle und Schlüsselwiederherstellung getrennt bewerten.
Secure Boot: Schutz und Grenzen
Secure Boot authentifiziert Startsoftware vor ihrer Ausführung. In einem üblichen Embedded-Entwurf prüft geschützter anfänglicher Verifikationscode einen signierten Bootloader, der die Anwendung prüft. Stufen und Algorithmen hängen von Prozessor und Implementierung ab. Secure Boot schützt vor unbefugtem Image-Austausch; es beweist keine Schwachstellenfreiheit zugelassener Software und verhindert nicht alle Laufzeitangriffe. Measured Boot zeichnet Messwerte für spätere Bewertung auf; Messung allein blockiert die Ausführung nicht unbedingt. Anti-Rollback und geschützte Wiederherstellung sind weitere zu bewertende und zu testende Entwurfsentscheidungen.
CRA und Technologiewahl
CRA-Anforderungen sind ergebnisorientiert und technologieneutral, abhängig von Risikobewertung und Anwendbarkeit. Secure Boot, Hardware-Vertrauensanker, TPM, TrustZone und drahtloses OTA können geeignete technische Maßnahmen sein; sie sind keine allgemeinen gesetzlichen Pflichten für jedes Produkt. Dokumentieren, warum die gewählten Maßnahmen die Anforderungen erfüllen, statt eine Architektur mit Konformität gleichzusetzen.
CRA-Termine und Anwendungsbereich
Der CRA trat am 10. Dezember 2024 in Kraft. Artikel 14 gilt für Meldungen seit 11. September 2026; die Hauptanforderungen gelten ab 11. Dezember 2027. Artikel 69 enthält Übergangsregeln für früher in Verkehr gebrachte Produkte. Produkte unter MDR oder IVDR sind nach Artikel 2 Absatz 2 ausgeschlossen; weitere Ausnahmen und nichtkommerzielle freie/Open-Source-Software sind ebenfalls zu prüfen.
Häufige Fragen
Verlangt der CRA immer Secure Boot?
CRA-Anforderungen sind ergebnisorientiert und technologieneutral, abhängig von Risikobewertung und Anwendbarkeit. Secure Boot, Hardware-Vertrauensanker, TPM, TrustZone und drahtloses OTA können geeignete technische Maßnahmen sein; sie sind keine allgemeinen gesetzlichen Pflichten für jedes Produkt. Dokumentieren, warum die gewählten Maßnahmen die Anforderungen erfüllen, statt eine Architektur mit Konformität gleichzusetzen.
Garantiert ein Secure Element Konformität?
Nein. Es kann bestimmte Schlüssel und Vorgänge schützen; Konformität betrifft das gesamte Produkt samt Anforderungen, Prozessen und Nachweisen.