Zum Inhalt springen
Inovasense

Hardware Root of Trust

Ein Hardware-Vertrauensanker verankert bestimmte Sicherheitsfunktionen in hardwaregestützten Mechanismen, auf deren Integrität das System vertraut.

Autor:
Inovasense Team
Aktualisiert:
Definition
Ein Hardware-Vertrauensanker verankert bestimmte Sicherheitsfunktionen in hardwaregestützten Mechanismen, auf deren Integrität das System vertraut.

Vertrauensanker, Schlüsselrollen und Grenzen

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.

Funktionsweise und Grenzen von Secure Boot

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: Anforderungen und technische Entscheidungen

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-Anwendungsbereich und Termine

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.

Praktische Checkliste

  1. Produkt, Verwendungszweck, Markt und rechtlichen Anwendungsbereich bestimmen.
  2. Genaue Vorschriften, Termine und Normausgaben einschließlich Einschränkungen erfassen.
  3. Zulässiges Bewertungsverfahren und erforderliche Nachweise bestimmen.
  4. Risiken, Prüfungen, Produktversionen und Erklärungen in der technischen Dokumentation verknüpfen.
  5. Verantwortung für Änderungen, Unterstützung und Behördenanfragen zuweisen.

Die Liste unterstützt die Planung; die einschlägigen gesetzlichen Anforderungen bestimmen die abschließende Bewertung.

Primärquellen