IoT-Sicherheit im gesamten System
Ein IoT-Produkt benötigt Maßnahmen für Gerät, Netz, Anwendung und Betrieb. Mit Zweck und Bedrohungsmodell beginnen und angemessene Maßnahmen wählen. Hardwaregestütztes Vertrauen kann Startprüfung und Schlüsselisolierung stärken, repariert aber keine fehlende API-Autorisierung und verhindert nicht jeden Vorfall.
| Bereich | Empfohlene technische Arbeit | Zu prüfende Grenze |
|---|---|---|
| Identität | Eindeutige Zugangsdaten, sichere Provisionierung und Widerruf | Gültige Identität erlaubt nicht jede Handlung |
| Firmware | Start- und Update-Images soweit geeignet authentifizieren | Signierte Software kann Schwachstellen enthalten |
| Kommunikation | Geeignete Verschlüsselung und Gegenstellenprüfung | Verschlüsselung repariert keinen unsicheren Endpunkt |
| Schnittstellen | Minimale Rechte, Eingabeprüfung und Debugschutz | Wartung und Wiederherstellung mitprüfen |
| Betrieb | Segmentierung, Überwachung und kontrollierte Patches | Verfügbarkeit und Sicherheit begrenzen Änderungen |
| Lebenszyklus | Unterstützungsfristen, Meldestelle und Abhängigkeiten | Ein Sicherheitschip ersetzt keine laufende Unterstützung |
Bestehende Geräte verbessern
Netzisolation, Zugangsbeschränkungen und Firmwarepatches können bestehende Geräte verbessern. Hardwareisolierung kann ein neues Board erfordern; Startprüfung hängt von Silizium, Provisionierung und Wiederherstellung ab. Die Flotte bewerten, bevor pauschal vollständige Nachrüstbarkeit oder Unmöglichkeit späterer Verbesserung behauptet wird.
Kosten und Normen
Komponenten, Entwicklung, Provisionierung, Prüfungen und Unterstützung für tatsächliches Produkt und Volumen kalkulieren. Ein allgemeiner Stückpreis oder Schadensbetrag beweist keine Projektrendite. IEC 62443 und ETSI EN 303 645 können einschlägige Entwürfe unterstützen; eine Norm oder ein Bauteilzertifikat weist keine vollständige CRA-Konformität automatisch nach. Ausgabe, Anwendungsbereich und Rechtsverweis prüfen.
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.
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.
Updates und Wiederherstellung
Ein Over-the-Air-Update (OTA) überträgt Software oder Firmware über eine drahtlose Verbindung. Fernupdates können auch kabelgebundene Netze nutzen; automatische Installation ist eine andere Eigenschaft. Ein sicherer Entwurf authentifiziert Update und Ziel, schützt Signierschlüssel, prüft Versionsregeln und behandelt Stromausfälle sicher. A/B-Partitionen sind eine Wiederherstellungsstrategie, keine allgemeine Pflicht. RFC 9019 beschreibt eine IoT-Updatearchitektur, kein fertiges verpflichtendes Manifestformat. Das Gerät benötigt Prüfmaterial, nicht den privaten Signierschlüssel der gesamten Flotte. Beschädigte Images, falsche Ziele, abgebrochene Schreibvorgänge, widerrufene Schlüssel und unzulässige ältere Versionen testen.
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.
Unterstützung, Updates und Nachweise
CRA Anhang I verlangt anwendbare Mechanismen für sichere Schwachstellenbehandlung und Updates. Automatische Sicherheitsupdates haben Bedingungen und Ausnahmen; automatisch bedeutet nicht drahtlos. Artikel 13 Absatz 8 bestimmt die Unterstützung, grundsätzlich mindestens fünf Jahre; bei kürzerer erwarteter Nutzung entspricht sie dieser, während längere Nutzung längere Unterstützung erfordern kann. Die SBOM muss maschinenlesbar sein und mindestens Abhängigkeiten der obersten Ebene abdecken.
Meldung als gesonderte Pflicht
CRA Artikel 14 betrifft aktiv ausgenutzte Schwachstellen und schwere Vorfälle mit Auswirkungen auf die Produktsicherheit, nicht jede CVE. Beide verlangen eine Frühwarnung binnen 24 Stunden und eine Meldung binnen 72 Stunden ab Kenntnis. Der abschließende Schwachstellenbericht folgt binnen 14 Tagen nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme; der Bericht zum schweren Vorfall binnen eines Monats nach der Vorfallsmeldung. Meldung, Konformitätsbewertung und Updates sind getrennte Pflichten.
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.
Lassen sich bestehende Geräte absichern?
Netzmaßnahmen und Firmwarepatches helfen häufig. Hardwareänderungen hängen von Silizium, Provisionierung und Wiederherstellung ab. Produkt und Flotte bewerten.
Was kostet Sicherheit?
Komponenten, Entwicklung, Provisionierung, Prüfung und Unterstützung nach tatsächlichem Umfang kalkulieren. Ein universeller Stückbetrag ist unzuverlässig.