CRA – warum IoT-Hersteller noch in diesem Jahr mit der Umstellung ihrer Authentifizierungsverfahren beginnen sollten

Vor etwas über einem Jahr wurden IoT-Hersteller mit den neuen Vorgaben des Cyber Resilience Acts (CRA) konfrontiert. Bis Ende 2027 haben sie Zeit, die neuen Richtlinien in ihre Abläufe und Prozesse zu integrieren. Gelingt ihnen dies nicht, werden sie ihre IoT-Geräte nicht mehr auf dem EU-Markt absetzen können.

Der neue CRA, er verbietet nicht nur schwache Passwörter. Er verbietet gemeinsam genutzte und fest codierte Anmeldedaten in der IoT-Geräteflotte. Das in der Firmware eingebettete Client-Geheimnis? Es ist nicht mehr Compliance-konform. Der API-Schlüssel, der jedem Gerät zugewiesen wird? Nicht mehr konform. Der JWT-Signaturschlüssel, der in der gesamten Produktlinie verwendet wird? Auch nicht mehr konform. Die neue Verordnung verlangt, dass jedes Gerät über eine eigene, kryptografisch sichere Identität verfügt; und dass die Eigentümer vom Hersteller in die Lage versetzt werden, ihre Anmeldedaten zu widerrufen, wenn ein Gerät kompromittiert worden ist. Verstößt ein Hersteller gegen diese neuen Vorgaben, muss er mit massiven Strafen rechnen – bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Mit den bisherigen Authentifizierungsverfahren, wie OAuth2, JWT oder API-Schlüssel, wird sich die Authentifizierung damit ab Ende 2027 nicht mehr Compliance-konform realisieren lassen. Denn um einen Token zu erhalten, benötigen diese Verfahren fest codierte Anmeldedaten:

• OAuth2 Client Credentials Flow erfordert, dass das IoT-Gerät eine client_id und ein client_secret speichert, um ein Zugriffstoken anfordern zu können. Dabei handelt es sich aber um statische Werte, die in die Firmware eingebrannt sind – genau um das also, was die CRA verbietet.
• JWT-Authentifizierungerfordert, dass das IoT-Gerät einen privaten Signaturschlüssel besitzt, mit dem er die Tokens generiert. Dieser Schlüssel muss vom Hersteller bereitgestellt werden. Handelt es sich um denselben Schlüssel für die gesamte Flotte, hat der Hersteller gegen die CRA-Anforderungen für eindeutige Identitäten verstoßen.
• API-Schlüssel und PATs– sind per Definition statische Zeichenfolgen, die in das Gerät eingebettet sind.

Diese Methoden ersetzen also lediglich ein fest codiertes Geheimnis (ein Passwort) durch ein anderes fest codiertes Geheimnis (ein Client-Geheimnis, einen Signaturschlüssel oder ein Token). Sie lösen das CRA-Compliance-Problem nicht, sie verpacken es nur neu.

Wirklich lösen lässt sich dieses Bootstrap-Problem nur mit einem Mutual TLS-Verfahren mit X.509-Zertifikat. Denn hier kann der private Schlüssel auf dem IoT-Gerät selbst generiert werden – und muss nirgendwo anders vorhanden sein. Während der Herstellung generiert das Gerät intern sein eigenes Schlüsselpaar – idealerweise in einem Hardware-Sicherheitsmodul, aus dem der private Schlüssel buchstäblich nicht extrahiert werden kann. Das Gerät sendet nur eine Zertifikatssignierungsanforderung (die den öffentlichen Schlüssel enthält) an die Zertifizierungsstelle. Das signierte Zertifikat wird dann zurückgesandt. Das Verfahren erfordert keine gemeinsamen Geheimnisse, keine fest codierten Anmeldedaten und keine Übertragung sensibler Daten während der Bereitstellung.

Bis Ende Dezember 2027 haben IoT-Hersteller nun noch Zeit, Ihre Geräteflotte in Punkto Authentifizierung auf Vordermann zu bringen. Das klingt nach viel Spielraum – ist es aber nicht. Denn IoT-Hersteller müssen bedenken:

• Hardware-Designzyklen dauern 18 bis 24 Monate
• die Einrichtung der Architektur einer PKI-Infrastruktur benötigt Zeit
• ihre Fertigung erfordert die Integration der Zertifikatsbereitstellung
• das Backend benötigt mTLS-Unterstützung

Wollen sie also auch nach 2027 noch IoT-Geräte auf dem europäischen Markt absetzen dürfen, sollten sie jetzt – so schnell wie möglich – mit der Umstellung auf mTLS/X.509 beginnen.

Jiannis Papadakis, Director of Solutions Engineering bei Keyfactor