CRA Kryptografie: Vertraulichkeit, Integrität und Schlüsselmanagement richtig umsetzen

Der Cyber Resilience Act verlangt, dass relevante gespeicherte, übertragene oder anderweitig verarbeitete Daten gegen unbefugte Offenlegung und Manipulation geschützt werden. Anhang I nennt dafür ausdrücklich Verschlüsselung nach dem Stand der Technik als mögliches Mittel. Entscheidend ist aber nicht nur der Algorithmus, sondern das gesamte Schlüssel- und Vertrauensmodell.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Technische Produktsicherheit. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was verlangt der CRA bei Vertraulichkeit und Integrität?

Anhang I Teil I Nummer 2 Buchstaben e und f verlangen Schutz der Vertraulichkeit und Integrität von gespeicherten, übertragenen oder anderweitig verarbeiteten Daten. Das betrifft personenbezogene und andere Daten ebenso wie Befehle, Programme und Konfigurationen. Manipulationen, die nicht vom Nutzer autorisiert sind, sollen verhindert beziehungsweise erkennbar sein.

Die konkrete Maßnahme folgt der CRA-Risikobewertung. Nicht jede Information braucht identische Verschlüsselung, aber sensible Zugangsdaten, Schlüssel, Konfigurationen oder vertrauliche Nutzerdaten benötigen regelmäßig stärkere Kontrollen als öffentliche Produktinformationen.

Muss jedes Produkt alle Daten verschlüsseln?

Nein. Der CRA verlangt einen risikobasierten Schutz und nennt Verschlüsselung relevanter Daten als Beispiel. Die Frage ist deshalb, welche Daten Schutz benötigen, welche Angreifer realistisch sind und ob Vertraulichkeit, Integrität oder beides entscheidend ist.

Öffentliche Firmwaredateien müssen nicht geheim sein, brauchen aber möglicherweise starken Integritätsschutz. Zugangstokens oder private Schlüssel müssen dagegen sowohl vertraulich als auch vor Manipulation geschützt sein.

Was bedeutet Verschlüsselung „at rest“?

At-rest-Verschlüsselung schützt Daten, wenn sie auf einem Gerät, Datenträger, in einer Datenbank oder einem Backup gespeichert sind. Sie kann beispielsweise verhindern, dass ein entnommener Speicherchip oder gestohlener Datenträger unmittelbar Klartext offenlegt.

Entscheidend ist das Angreifermodell. Liegt der Entschlüsselungsschlüssel direkt neben den Daten und ist für denselben Angreifer ohne weitere Hürde zugänglich, kann die Verschlüsselung nur begrenzten Schutz bieten.

Was bedeutet Verschlüsselung „in transit“?

In-transit-Verschlüsselung schützt Daten während der Übertragung zwischen Produkt, App, Backend, Cloud oder anderen Geräten. Etablierte sichere Transportprotokolle verhindern Abhören und Manipulation, wenn sie korrekt konfiguriert und Zertifikate beziehungsweise Gegenstellen zuverlässig geprüft werden.

Ein verschlüsselter Kanal ist nicht automatisch sicher, wenn das Produkt beliebige Zertifikate akzeptiert oder alte unsichere Protokolle erlaubt. Konfiguration und Validierung gehören deshalb in den Testplan.

Wie werden kryptografische Verfahren ausgewählt?

Hersteller sollten etablierte, breit geprüfte Verfahren und Bibliotheken verwenden, die dem aktuellen Stand der Technik entsprechen. Eigene Kryptografie ist riskant, weil kleine Design- oder Implementierungsfehler die gesamte Schutzwirkung zerstören können.

Die Auswahl sollte dokumentiert und regelmäßig überprüft werden. Was heute angemessen ist, kann während eines langen Supportzeitraums veralten. Deshalb braucht es eine Crypto-Agility-Strategie für Protokolle, Schlüssellängen oder Algorithmen.

Was ist Schlüsselmanagement?

Schlüsselmanagement umfasst Erzeugung, Verteilung, Speicherung, Nutzung, Rotation, Sicherung, Widerruf und Löschung kryptografischer Schlüssel. Genau hier entstehen in der Praxis viele Schwachstellen.

Sollte jedes Gerät einen individuellen Schlüssel haben?

Bei vielen Produktarten ist eine individuelle Geräteidentität deutlich robuster als ein geteilter globaler Schlüssel. Wird ein gemeinsames Geheimnis aus einem Gerät extrahiert, kann sonst eine gesamte Produktflotte betroffen sein.

Ob individuelle Schlüssel technisch erforderlich sind, hängt von Risiko und Architektur ab. Bei hohen Auswirkungen sollte die Risikobewertung ausdrücklich betrachten, welchen Blast Radius eine einzelne Schlüsselkompromittierung hätte.

Wie schützt man private Schlüssel?

Private Schlüssel sollten nur den Komponenten zugänglich sein, die sie tatsächlich benötigen. Je nach Produkt können Betriebssystem-Key-Stores, TPM, Secure Elements, HSM oder andere geschützte Speicher geeignet sein. Der CRA schreibt keine bestimmte Hardwaretechnologie pauschal vor.

Wichtig sind Zugriffstrennung und Extraktionsschutz. Ein administrativer Nutzer sollte nicht automatisch alle Geräte- oder Signaturschlüssel auslesen können, wenn dies nicht für seine Aufgabe erforderlich ist.

Welche Rolle spielen Zertifikate?

Zertifikate verbinden einen öffentlichen Schlüssel mit einer Identität oder Vertrauensstellung. Produkte müssen Zertifikatsketten, Gültigkeit, Hostnamen und gegebenenfalls Widerruf korrekt prüfen. „TLS aktiviert“ ist keine ausreichende Aussage, wenn die Gegenstelle nicht validiert wird.

Auch Ablauf und Erneuerung gehören in den Lebenszyklus. Ein Produkt mit zehnjähriger Nutzung darf nicht nach zwei Jahren unwartbar werden, weil ein fest eingebettetes Zertifikat abläuft.

Was bedeutet Crypto Agility?

Crypto Agility ist die Fähigkeit, kryptografische Algorithmen, Parameter oder Vertrauensanker während des Produktlebenszyklus sicher zu ändern. Sie ist besonders bei langen Supportzeiträumen relevant, weil Standards und Angriffsmöglichkeiten sich entwickeln.

Ein Produkt sollte nicht ohne Not so gebaut sein, dass ein einzelner fest codierter Algorithmus oder Root-Schlüssel nur durch Hardwaretausch ersetzt werden kann. Update- und Migrationsfähigkeit gehören deshalb in Secure by Design.

Wie schützt Kryptografie Softwareupdates?

Security Updates müssen sicher verteilt werden. Digitale Signaturen oder vergleichbare Integritäts- und Herkunftsprüfungen können verhindern, dass manipulierte Pakete installiert werden. Das Produkt sollte die Prüfung selbst zuverlässig durchführen und bei Fehlern sicher abbrechen.

Der Beitrag CRA-Sicherheitsupdates erläutert Updateprozess, Rollback und Archivierung. Kryptografie ist dabei ein technischer Baustein, nicht der gesamte Prozess.

Wie schützt man Datenintegrität ohne Vertraulichkeit?

Nicht jede Information muss geheim sein, kann aber gegen Manipulation geschützt werden müssen. Beispiele sind öffentliche Firmwareimages, Konfigurationsdateien, Update-Metadaten oder Befehle. Hashes, MACs oder digitale Signaturen können je nach Szenario Integrität und Authentizität unterstützen.

Welche Technik passt, hängt davon ab, wer Änderungen autorisieren darf und welche Schlüsselbeziehung existiert. Ein einfacher ungeschützter Hash erkennt zufällige Fehler, schützt aber nicht unbedingt vor einem aktiven Angreifer.

Wie geht man mit Passwörtern um?

Passwörter sollten grundsätzlich nicht reversibel im Klartext gespeichert werden. Für Benutzerpasswörter sind dafür geeignete Passwort-Hashing-Verfahren mit individuellen Salts und angemessenen Kostenparametern vorgesehen. Passwörter sind keine gewöhnlichen Verschlüsselungsdaten.

Reset- und Authentisierungsprozesse müssen ebenfalls sicher sein. Der Artikel CRA Zugriffsschutz behandelt den gesamten Identity-Lifecycle.

Welche Rolle spielt sichere Zufälligkeit?

Schlüssel, Nonces, Tokens und Resetcodes können nur dann sicher sein, wenn ihre Zufallswerte ausreichend unvorhersagbar sind. Schwache Zufallsquellen haben in der Vergangenheit viele kryptografische Systeme kompromittiert.

Hersteller sollten Plattformmechanismen für kryptografisch sichere Zufallszahlen verwenden und bei Embedded-Geräten prüfen, wie Entropie beim ersten Start verfügbar ist.

Wie werden kryptografische Funktionen getestet?

Tests sollten nicht versuchen, etablierte Kryptografie mathematisch neu zu beweisen. Sie prüfen vielmehr korrekte Implementierung und Konfiguration: Zertifikatsvalidierung, Schlüsselrotation, Fehlerfälle, Zufallsquellen, Protokollparameter, Speicherung und Widerruf.

Diese Prüfungen gehören in das regelmäßige CRA Security Testing. Besonders wichtig sind negative Tests mit abgelaufenen, falschen oder manipulierten Zertifikaten und Signaturen.

Wie geht man mit Legacy-Protokollen um?

Unsichere Altprotokolle sollten nicht standardmäßig aktiviert bleiben, nur weil einzelne Altkunden sie noch verwenden. Wenn eine Übergangsunterstützung erforderlich ist, sollte sie dokumentiert, risikobewertet und möglichst separat aktivierbar sein.

Das ist auch eine Secure-by-Default-Frage: Neue Installationen sollten nicht aus Kompatibilitätsgründen mit einer unnötig schwachen Baseline starten.

Was gilt für Backups?

Backups können dieselben sensiblen Daten und Schlüssel enthalten wie das aktive Produkt. Sie müssen deshalb angemessen geschützt und Zugriffe kontrolliert werden. Außerdem ist zu prüfen, ob ein Restore veraltete oder bereits widerrufene Schlüssel reaktiviert.

Ein Recovery-Test sollte diese Sicherheitsfolgen berücksichtigen. Verfügbarkeit und Vertraulichkeit müssen zusammen gedacht werden.

Wie dokumentiert man Kryptografie für den CRA?

Die technische Dokumentation sollte Datenkategorien, Schutzbedarf, verwendete Mechanismen, Schlüssel-Lifecycle, relevante Vertrauensanker, Updatefähigkeit und Testnachweise beschreiben. Geheimschlüssel selbst gehören selbstverständlich nicht in die Dokumentation.

Wichtig ist die Begründung aus der Risikobewertung. So wird erkennbar, warum bestimmte Daten verschlüsselt werden und andere nur Integritätsschutz benötigen.

Welche Fehler treten häufig auf?

• Eigene Kryptografie statt etablierter Bibliotheken.
• Ein globaler Schlüssel für alle Geräte.
• Hardcodierte Secrets im Quellcode oder Firmwareimage.
• Keine Zertifikatsprüfung trotz TLS.
• Keine Rotation oder kein Widerruf möglich.
• Schlüssel landen in Logs oder Backups ungeschützt.
• Veraltete Protokolle bleiben standardmäßig aktiv.

Wie können KMU ein Kryptografie-Inventar aufbauen?

Ein einfaches Inventar listet Zweck, Daten, Algorithmus beziehungsweise Protokoll, Schlüsselart, Speicherort, Owner, Rotation und Abhängigkeit auf. Dadurch wird sichtbar, wo kritische Schlüssel oder veraltete Verfahren existieren.

Das Inventar muss nicht öffentlich sein. Es dient Entwicklung, Risikobewertung und technischen Reviews und sollte bei größeren Produktänderungen aktualisiert werden.

Wie werden kryptografische Abhängigkeiten in der Lieferkette behandelt?

Viele Produkte nutzen TLS-Stacks, Crypto-Libraries, Secure Elements oder Cloud-Key-Management von Dritten. Hersteller sollten Supportstatus, Security Advisories und Updatefähigkeit dieser Komponenten kennen. Der CRA Lieferanten- & Drittkomponentencheck kann solche Abhängigkeiten strukturiert erfassen.

Eine zentrale Kryptobibliothek ohne langfristigen Support kann den eigenen Produkt-Supportzeitraum begrenzen. Diese Abhängigkeit gehört deshalb in das Lifecycle-Management.

Wie reagiert man auf kompromittierte Schlüssel?

Ein Schlüsselvorfall braucht vorab definierte Maßnahmen: Widerruf, Austausch, Re-Provisionierung, Update, Nutzerinformation und Analyse betroffener Produkte. Je nach Schlüssel kann die Kompromittierung eine einzelne Instanz oder eine gesamte Produktfamilie betreffen.

Wenn der Vorfall die Produktsicherheit erheblich beeinträchtigt oder mit aktiver Ausnutzung zusammenhängt, sind zusätzlich CRA-Meldepflichten zu prüfen.

Wie oft sollte das Kryptografie-Inventar überprüft werden?

Ein jährlicher Basisreview und zusätzliche Prüfungen bei größeren Produktänderungen sind für viele Hersteller ein praktikabler Ausgangspunkt. Dabei werden Protokolle, Algorithmen, Schlüssellängen, Zertifikatslaufzeiten, Bibliotheksversionen und geplante Supportdauer miteinander abgeglichen.

Besonders wichtig sind Komponenten mit langem Lifecycle. Wenn ein Zertifikat oder Root-Key deutlich vor dem Produkt-Supportende ausläuft, braucht es rechtzeitig einen Migrationsweg statt einer Notlösung kurz vor dem Ablaufdatum.

Was passiert, wenn ein Verfahren nicht mehr dem Stand der Technik entspricht?

Dann sollte der Hersteller Risiko, betroffene Produktversionen und Migrationsmöglichkeiten bewerten. Je nach Bedeutung kann ein Security Update, eine neue Konfiguration oder ein geplanter Wechsel in einer Folgeversion erforderlich sein. Crypto Agility reduziert den Aufwand, weil die Architektur Änderungen bereits vorsieht.

Bei sicherheitsrelevanten Migrationen sollte das neue Verfahren parallel getestet und der Übergang so gestaltet werden, dass Nutzer nicht unbemerkt auf eine schwächere Fallback-Konfiguration zurückfallen.

Welche Rolle spielt die Fertigung beim Schlüsselmanagement?

Bei Hardwareprodukten entstehen Geräteidentitäten häufig während Produktion oder Provisionierung. Testschlüssel, Produktionsschlüssel und Hersteller-Backends müssen klar getrennt sein. Zugriff auf Provisionierungsstationen sollte beschränkt und nachvollziehbar sein, damit kein unkontrolliertes Kopieren von Seriengeheimnissen möglich ist.

Auch Reparatur und Austauschgeräte brauchen definierte Prozesse. Ein zurückgesetztes Gerät darf nicht versehentlich mit einer fremden Identität oder einem bereits widerrufenen Schlüssel erneut in Betrieb gehen.

Wie behandelt man kryptografische Fallbacks?

Fallbacks können notwendig sein, um mit älteren Gegenstellen zu kommunizieren, dürfen aber nicht unbemerkt ein Downgrade auf unsichere Verfahren ermöglichen. Hersteller sollten dokumentieren, welche Protokolle oder Algorithmen akzeptiert werden, wann ein Fallback ausgelöst wird und ob der Nutzer beziehungsweise Administrator darüber informiert werden muss.

Wo eine alte Variante nur noch für einzelne Bestandskunden benötigt wird, sollte sie nicht Teil der allgemeinen sicheren Grundeinstellung sein. Eine gezielte Freischaltung mit klarer Risikoinformation ist meist besser als ein global aktivierter Legacy-Modus.

Wie werden kryptografische Änderungen freigegeben?

Änderungen an Signaturverfahren, Root-Zertifikaten, Schlüsselableitung oder Transportprotokollen sollten ein eigenes Security Review erhalten. Fehler in solchen zentralen Funktionen können sehr viele Produktinstanzen gleichzeitig betreffen und sind später schwer zurückzunehmen.

Ein kontrollierter Rollout, Kompatibilitätstests und eine dokumentierte Rückfallstrategie reduzieren das Risiko. Bei Schlüsselrotationen sollte außerdem geprüft werden, ob alte Vertrauensanker kontrolliert auslaufen und nicht dauerhaft parallel aktiv bleiben.

Wo stehen Vertraulichkeit und Integrität im CRA?

Die ausdrücklichen Anforderungen finden sich in Anhang I Teil I Nummer 2 Buchstaben e und f der Verordnung (EU) 2024/2847. Dort werden Schutz der Vertraulichkeit und Integrität relevanter Daten sowie der Einsatz geeigneter technischer Maßnahmen einschließlich Verschlüsselung genannt.