EN 303 645

EN 303 645 – Cybersicherheitsstandard für IoT-Geräte für Verbraucher

ETSI EN 303 645 (vollständiger Titel: Cyber Security for Consumer Internet of Things: Baseline Requirements) ist der europäische – und mittlerweile weltweit anerkannte – grundlegende Cybersicherheitsstandard für IoT-Geräte für Verbraucher. Er wurde vom ETSI (Europäisches Institut für Telekommunikationsnormen) entwickelt und im Juni 2020 erstmals veröffentlicht. Der Standard definiert 13 Sicherheitsbestimmungen und 5 Datenschutzbestimmungen, die das Mindestniveau an Cybersicherheit festlegen, das jedes mit dem Internet verbundene Verbrauchergerät aufweisen sollte.

Die EN 303 645 steht im Zentrum des regulatorischen Ökosystems der EU für IoT-Sicherheit: Sie wird im delegierten Rechtsakt zur RED referenziert, ist Teil der Harmonisierungs-Roadmap für die CRA und wurde als Grundlage für nationale Cybersicherheits-Kennzeichnungssysteme im Vereinigten Königreich, in Singapur, Finnland und Deutschland übernommen.

Wichtige Fakten

Die 13 Sicherheitsbestimmungen

Die EN 303 645 gliedert ihre Anforderungen in 13 nummerierte Bestimmungen. Jede Bestimmung enthält eine Mischung aus verbindlichen Anforderungen (SHALL) und Empfehlungen für bewährte Verfahren (SHOULD):

Bestimmung 1: Keine universellen Standardpasswörter

Die wirkungsvollste Bestimmung. Jedes IoT-Gerät muss entweder:

• ohne Standardpasswort ausgeliefert werden, wobei der Benutzer bei der Einrichtung eines festlegen muss, oder
• über ein gerätespezifisches, eindeutiges Passwort verfügen, das so generiert wird, dass es nicht vorhersagbar ist

Gemeinsam genutzte Standard-Anmeldedaten (z. B. admin/admin, root/1234), die für alle Einheiten eines Modells identisch sind, sind verboten. Diese eine Bestimmung eliminiert den häufigsten IoT-Angriffsvektor des letzten Jahrzehnts – Credential Stuffing gegen Standardpasswörter.

Auswirkungen auf die Hardware: Eindeutige, gerätespezifische Passwörter müssen sicher im nichtflüchtigen Speicher abgelegt sein und ein Zurücksetzen auf Werkseinstellungen überdauern (oder nach dem Zurücksetzen neu generiert werden). Dies erfordert einen Provisionierungsprozess während der Fertigung.

Bestimmung 2: Implementierung einer Richtlinie zur Offenlegung von Schwachstellen

Hersteller müssen eine klare, zugängliche Richtlinie zur Offenlegung von Schwachstellen (Vulnerability Disclosure Policy, VDP) veröffentlichen, die:

• Kontaktinformationen für Sicherheitsforscher bereitstellt
• den Mindestzeitraum angibt, für den Schwachstellenmeldungen angenommen werden
• den erwarteten Reaktionsprozess und Zeitrahmen definiert

Dies ist eine organisatorische Anforderung – keine Hardwareanforderung –, muss aber erfüllt sein, bevor das Produkt auf den EU-Markt gelangt.

Bestimmung 3: Software aktuell halten

Geräte müssen Sicherheitsupdates für die Software unterstützen, und:

• Update-Prozesse müssen für den Benutzer einfach sein (kein Fachwissen erfordern)
• Das Gerät muss den Benutzer benachrichtigen, wenn ein Sicherheitsupdate verfügbar ist
• Updates müssen zeitnah erfolgen – kritische Schwachstellen müssen umgehend behoben werden
• Updates müssen für den definierten Support-Zeitraum des Geräts verfügbar sein
• Das Gerät darf kein Downgrade auf eine anfällige Firmware-Version zulassen

Auswirkungen auf die Hardware: Erfordert eine sichere OTA-Update-Fähigkeit mit Rollback-Schutz. Wenn der MCU keinen Anti-Rollback-Schutz implementieren kann (z. B. über monotone Zähler im sicheren Speicher), werden Firmware-Downgrade-Angriffe möglich.

Bestimmung 4: Sensible Sicherheitsparameter sicher speichern

Anmeldedaten, kryptografische Schlüssel und andere sensible Parameter müssen mit angemessenem Schutz gespeichert werden. Hartcodierte Anmeldedaten in der Firmware sind verboten.

Auswirkungen auf die Hardware: Sensible Parameter sollten in hardwaregeschütztem Speicher abgelegt werden (Secure Element, durch TrustZone geschützter Speicher, durch eFuse gesperrte Bereiche). Eine rein softwarebasierte Speicherung im Standard-Flash-Speicher ist für Anwendungsfälle mit hohen Sicherheitsanforderungen unzureichend.

Bestimmung 5: Sicher kommunizieren

Die gesamte Gerätekommunikation muss Folgendes verwenden:

• Verschlüsselten Transport – die Übertragung sensibler Daten im Klartext ist verboten
• Authentifizierte Endpunkte – das Gerät muss überprüfen, ob es mit dem beabsichtigten Server/Dienst kommuniziert
• Aktuelle, bewährte Protokolle – veraltete Protokolle (SSLv3, TLS 1.0, WEP, WPA) dürfen nicht verwendet werden

Diese Bestimmung erfordert mindestens TLS 1.2 (TLS 1.3 empfohlen) für die Internetkommunikation und eine angemessene Verschlüsselung für die Kommunikation zwischen dem lokalen Netzwerk und dem Gerät.

Bestimmung 6: Exponierte Angriffsflächen minimieren

Das Gerät darf nur die Dienste exponieren, die für seine beabsichtigte Funktionalität notwendig sind:

• Unbenutzte Netzwerkschnittstellen, Ports und Dienste müssen standardmäßig deaktiviert sein
• Physische Schnittstellen (JTAG, UART-Debug-Schnittstellen) müssen in der Produktions-Firmware deaktiviert oder geschützt sein
• Netzwerkdienste dürfen nicht mit höheren Berechtigungen ausgeführt werden, als erforderlich

Auswirkungen auf die Hardware: Physische Debug-Schnittstellen (JTAG, SWD) sollten durch OTP-Fuses gesperrt oder in Produktionsgeräten dauerhaft deaktiviert werden. Ein aktiviertes JTAG bei Produktionseinheiten ist ein häufiger Befund bei Sicherheitsaudits.

Bestimmung 7: Software-Integrität sicherstellen

Das Gerät muss die Integrität der Software beim Start und während eines Updates überprüfen:

• Secure Boot – kryptografische Verifizierung der Firmware vor der Ausführung
• Update-Validierung – Firmware-Updates müssen vor der Installation verifiziert werden
• Jeder Versuch einer Software-Modifikation muss erkannt und behandelt werden

Auswirkungen auf die Hardware: Vollständige Secure-Boot-Kette vom Boot-ROM bis zur Anwendungs-Firmware, die in der Hardware verankert ist (in OTP-Fuse gespeicherter Root-Schlüssel). Rein softwarebasierte Integritätsprüfungen können umgangen werden.

Bestimmung 8: Sicherheit personenbezogener Daten gewährleisten

Geräte, die personenbezogene Daten verarbeiten oder speichern, müssen:

• eine angemessene Verschlüsselung für gespeicherte personenbezogene Daten verwenden (Data-at-Rest)
• Benutzern Mechanismen zur Kontrolle ihrer personenbezogenen Daten bereitstellen
• keine personenbezogenen Daten ohne entsprechende Zustimmung des Benutzers übertragen
• das sichere Löschen von Daten unterstützen (Zurücksetzen auf Werkseinstellungen, das personenbezogene Daten tatsächlich löscht)

Bestimmung 9: Systeme widerstandsfähig gegen Ausfälle machen

Geräte sollten bei Netzwerkausfällen in einem eingeschränkten, aber funktionsfähigen Modus weiterarbeiten und sollten:

• nicht aufgrund eines Ausfalls eines Netzwerkdienstes in einen dauerhaft unbrauchbaren Zustand geraten
• die Wiederherstellung nach fehlgeschlagenen Updates unterstützen

Bestimmung 10: System-Telemetriedaten untersuchen

Hersteller sollten Telemetriedaten von Geräten im Feld überwachen, um Sicherheitsanomalien zu erkennen. Diese Bestimmung ist größtenteils eine Empfehlung (SHOULD) und keine verbindliche Anforderung (SHALL).

Bestimmung 11: Benutzern das Löschen personenbezogener Daten erleichtern

Geräte sollten Benutzern einen einfachen, zugänglichen Mechanismus zum Löschen aller personenbezogenen Daten bieten – eine Funktion zum Zurücksetzen auf Werkseinstellungen mit bestätigter, vollständiger Datenlöschung.

Bestimmung 12: Installation und Wartung einfach gestalten

Einrichtungs- und Wartungsprozesse sollten vom Benutzer kein spezielles Sicherheitswissen erfordern. Sicherheit sollte standardmäßig („by default“) gegeben sein und keine Konfiguration durch den Benutzer erfordern, um aktiv zu sein.

Bestimmung 13: Eingabedaten validieren

Geräte sollten alle über Benutzeroberflächen, APIs und Netzwerkdienste empfangenen Eingaben validieren, um Injection-Angriffe und die Ausnutzung von Pufferüberläufen zu verhindern.

EN 303 645 und EN 18031: Beziehung und Unterschiede

Eine häufige Quelle der Verwirrung ist die Beziehung zwischen der EN 303 645 und der neueren Normenreihe EN 18031:

Praktischer Hinweis: Für Funkanlagen, die Konformität mit dem delegierten Rechtsakt zur RED nachweisen müssen, ist die EN 18031 die primär anzuwendende harmonisierte Norm. Die EN 303 645 bleibt als grundlegende Referenz, für die Planung der CRA-Konformität, für die Konformität auf dem britischen Markt und als Fundament für viele nationale Cybersicherheits-Kennzeichnungssysteme von hoher Relevanz.

EN 303 645 und nationale/internationale Regelungen

Die EN 303 645 wurde weltweit als technische Grundlage für die Regulierung der IoT-Cybersicherheit übernommen:

Ein Produkt, das die Konformität mit EN 303 645 erreicht, verfügt über eine starke Grundlage für die Cybersicherheitsanforderungen mehrerer nationaler Märkte – was die Norm zu einem De-facto-Standard für den globalen Markt macht.

Konformitätsprüfung: ETSI TS 103 701

Die ETSI TS 103 701 ist die begleitende Testspezifikation zur EN 303 645. Sie bietet:

• Spezifische Testfälle für jede Bestimmung
• Definierte Testmethoden (Black-Box, White-Box, Dokumentationsprüfung)
• Erfolgs-/Fehlschlagskriterien für jede Anforderung

Zugelassene Prüflabore verwenden die TS 103 701, um strukturierte Prüfberichte zu erstellen, die als Nachweis in der technischen Dokumentation für die Einhaltung gesetzlicher Vorschriften dienen.

Zusammenfassung der Anforderungen auf Hardware-Ebene

Aus unserer Erfahrung

Bei der Durchführung von Gap-Analysen nach EN 303 645 für IoT-Produkte für Verbraucher beobachten wir immer wieder die folgenden Muster:

Bestimmung 1 wird bei etwa 60 % der Erstbewertungen nicht erfüllt. Obwohl es sich um die bekannteste Anforderung der EN 303 645 handelt, bleiben gemeinsam genutzte Standard-Anmeldedaten die häufigste Nichtkonformität, die wir feststellen. Die Anmeldedaten sind oft nicht admin/admin – dessen sind sich die Hersteller bewusst –, sondern ein vom Gerätemodell abgeleitetes Standardpasswort (z. B. die letzten 4 Ziffern einer MAC-Adresse), das algorithmisch vorhersagbar ist. Die ETSI TS 103 701 prüft explizit auf vorhersagbare gerätespezifische Anmeldedaten, nicht nur auf universelle. Die Behebung erfordert sowohl eine Änderung bei der Provisionierung auf Hardware-Ebene (einzigartige Anmeldedaten, die bei der Fertigung mit einem HSM generiert und injiziert werden) als auch eine Änderung des Produktionsprozesses. Wir empfehlen, dies als eine Aufgabe des Fertigungs-Engineerings und nicht als eine Firmware-Aufgabe zu behandeln.

Bestimmung 6 JTAG-Entdeckung: der häufigste Befund bei Sicherheitsaudits. Bei über 80 % der Hardware-Sicherheitsbewertungen, bei denen wir Produktionseinheiten (keine Entwicklungsmuster) erhalten, ist der JTAG- oder SWD-Debug-Zugang noch aktiv. Hersteller testen typischerweise mit Entwicklungsmustern, bei denen JTAG absichtlich aktiviert ist, und der Produktions-Firmware-Build enthält das Brennen der OTP-Fuse nicht als letzten Fertigungsschritt. Das Ergebnis ist ein Produktionsgerät, bei dem jeder Angreifer mit einer 30-€-Debug-Sonde den gesamten Flash-Speicher auslesen, Anmeldedaten extrahieren, den Secure Boot umgehen und beliebige Firmware installieren kann. Wir implementieren einen obligatorischen Verifizierungsschritt für gesperrtes JTAG in den Produktionstestvorrichtungen: Jede Einheit, die nach dem Programmierschritt in der Produktion auf einen JTAG-Verbindungsversuch reagiert, wird aussortiert.

Bestimmung 3 Anti-Rollback: häufig behauptet, selten korrekt implementiert. Viele Hersteller geben an, dass ihr OTA-Update-System ein Firmware-Downgrade verhindert. In der Praxis stellen wir fest, dass dies als Software-Versionsprüfung in der Anwendungs-Firmware implementiert ist – was von jedem Angreifer, der das Gerät bereits kompromittiert hat, trivial umgangen werden kann. Ein echter Anti-Rollback-Schutz gemäß EN 303 645 erfordert einen monotonen Hardware-Zähler in einem manipulationsresistenten Speicherbereich, der nicht dekrementiert werden kann. Auf Geräten ohne Secure Element oder TrustZone-fähigen SoC ist dies architektonisch unmöglich, rein in Software korrekt zu implementieren. Die Auswahl eines Chipsatzes, der Anti-Rollback hardwareseitig unterstützt, muss eine Designentscheidung des ersten Tages sein.

Bestimmung 5 TLS 1.0/1.1 Legacy-Backend-Verbindungen. Ein Produkt kann eine perfekte TLS-1.3-Implementierung auf dem Gerät haben – und dennoch Bestimmung 5 nicht erfüllen, wenn das Cloud-Backend, mit dem es sich verbindet, die Unterstützung für TLS 1.0 oder 1.1 für ältere Clients beibehält. Die EN 303 645 testet das ausgehandelte Protokoll, nicht nur die Mindestfähigkeit des Geräts. Wir finden dies am häufigsten bei Produkten, die sich mit bestehenden Unternehmens-Backends verbinden, die nicht aktualisiert wurden, als die Geräte-Firmware auf TLS 1.2+ umgestellt wurde. Die Lösung liegt auf der Backend-Seite, nicht auf der Geräteseite – und oft außerhalb der direkten Kontrolle des Hardwareherstellers, wenn eine gemeinsam genutzte Cloud-Plattform verwendet wird.

Verwandte Begriffe

• EN 18031 – Die Nachfolge-Normenreihe für die Konformität mit dem delegierten Rechtsakt zur RED, die auf den Prinzipien der EN 303 645 aufbaut.
• Delegierter Rechtsakt zur RED – Das Rechtsinstrument, das die Konformität mit EN 303 645 / EN 18031 für mit dem Internet verbundene Funkanlagen verbindlich gemacht hat.
• CRA – Cyberresilienz-Verordnung der EU; die EN 303 645 bildet einen Teil der technischen Grundlage für die Cybersicherheitsanforderungen der CRA.
• Secure Boot – Zentrale Hardwareanforderung, die durch Bestimmung 7 ausgelöst wird.
• OTA-Update – Erforderlich durch Bestimmung 3; muss Anti-Rollback und Signaturverifizierung umfassen.
• Hardware-Vertrauensanker (Root of Trust) – Untermauert die Bestimmungen 4 und 7.

Offizielle Quellen

• ETSI EN 303 645 V2.1.1 – kostenloser Download (etsi.org)
• ETSI TS 103 701 – Konformitätstestspezifikation für EN 303 645 (kostenloser Download)
• Delegierter Rechtsakt zur RED (EU) 2022/30 – EUR-Lex
• ETSI Cyber Security for Consumer IoT – ETSI-Übersichtsseite

Die Konformität mit EN 303 645 wird zunehmend zu einer grundlegenden Erwartung für vernetzte Hardwareprodukte, die auf den EU-, britischen und globalen Märkten eingeführt werden. Inovasense führt Gap-Analysen zu allen 13 Bestimmungen der EN 303 645 durch – wir gleichen bestehende Hardwarefähigkeiten mit jeder SHALL-Anforderung ab, identifizieren notwendige Änderungen an Hardware oder Produktionsprozessen (Provisionierung, Sperrung von Debug-Ports, sicherer Speicher) und erstellen testreife Dokumentationen für die Einreichung bei einem zugelassenen Labor. Sehen Sie sich unsere Expertise im Bereich Embedded Security und unsere Dienstleistungen zur EU-Konformität an.