Die Kryptographie-Richtlinie steuert, wie deine Organisation Verschlüsselung, digitale Signaturen und Schlüsselmanagement einsetzt. Technisch ist sie nur ein Control (A 8.24), aber in der Praxis steckt dahinter ein komplettes Kryptokonzept: von der Algorithmenauswahl über den Schlüssellebenszyklus bis zum Umgang mit kompromittierten Schlüsseln. Kryptographie ist die letzte Verteidigungslinie — wenn sie versagt, hilft auch die beste Zugriffskontrolle nicht mehr.
Das BSI widmet dem Thema den Baustein CON.1 und die Technische Richtlinie TR-02102, die als verbindliche Referenz für Algorithmenauswahl und Schlüssellängen gilt. Weiter unten findest du die vollständige Vorlage.
Was regelt diese Richtlinie?
Die Vorlage gliedert sich in drei Hauptbereiche:
Kryptographische Grundregeln (Abschnitt 3) — Algorithmenauswahl basierend auf Klassifizierungsstufe und BSI TR-02102, Verschlüsselungspflicht für mobile Geräte und Speichermedien, Umgang mit verschlüsseltem Datenverkehr an Content-Inspection-Gateways (DLP, Malware-Scanner), Export- und Länderbeschränkungen, SLAs mit externen Krypto-Dienstleistern (CAs, HSM-Provider, Cloud-Key-Management).
Schlüsselmanagement (Abschnitt 4) — Der umfangreichste Teil der Vorlage mit elf Teilprozessen: Schlüsselerzeugung (Hardware-Zufallszahlengenerator oder zertifizierte Bibliotheken), Zertifikatsausstellung und -prüfung, sichere Verteilung über separaten Kanal, Speicherung in HSMs oder verschlüsselten Key Vaults, Rotationszyklen (TLS-Zertifikate jährlich, Signaturschlüssel zweijährlich), Kompromittierungsreaktion (sofortiger Widerruf, Risikobewertung), Widerruf und Deaktivierung (CRL/OCSP innerhalb 24 Stunden), Wiederherstellung und Backup (mindestens zwei physisch getrennte Standorte), Zerstörung (kryptographische Löschung oder physische Vernichtung), Protokollierung aller Aktivitäten, Verfahren für behördliche Herausgabeveerlangen.
Kryptoinventar (Abschnitt 5) — Eine jährlich aktualisierte Aufstellung aller kryptographischen Einsatzzwecke: Zweck, verantwortliche Person, Algorithmus und Parameter, eingesetztes Produkt, Schlüsselstatus. Grundlage für den jährlichen Algorithmen-Review.
Warum ist Schlüsselmanagement so wichtig?
Die beste Verschlüsselung ist wertlos, wenn der Schlüssel falsch verwaltet wird. Ein Schlüssel, der im Klartext in einer Konfigurationsdatei liegt, in einem Log-File auftaucht oder nach Ablauf nie rotiert wurde, hebelt den gesamten Schutz aus.
Die Vorlage widmet deshalb elf von siebzehn Abschnitten dem Schlüsselmanagement. Die wichtigsten Punkte:
- Schlüssel nie im Klartext — weder in Datenbanken, Konfigurationsdateien, Skripten noch in Log-Files
- Getrennte Schlüssel pro Zweck — ein Schlüssel für Verschlüsselung, ein anderer für Signaturen
- Automatische Warnungen 30 Tage vor Zertifikatsablauf
- Kompromittierter Schlüssel = sofortiger Widerruf plus Risikobewertung, ob Daten neu verschlüsselt werden müssen
- Backup an zwei physisch getrennten Standorten — verschlüsselt und getrennt von den Daten, die sie schützen
So führst du die Richtlinie ein
- 01
Kryptoinventar erstellen
Liste alle Stellen auf, an denen deine Organisation Kryptographie einsetzt: TLS-Zertifikate, VPN-Tunnel, Full-Disk-Encryption auf Laptops, Datenbankverschlüsselung, digitale Signaturen, E-Mail-Verschlüsselung. Für jeden Eintrag: Algorithmus, Schlüssellänge, Produkt, letzte Rotation, verantwortliche Person. Das ist gleichzeitig der Abschnitt 5 der Vorlage.
- 02
Algorithmen gegen BSI TR-02102 prüfen
Vergleiche dein Inventar mit den aktuellen Empfehlungen der BSI TR-02102. Gibt es noch SHA-1-Hashes? TLS 1.0? RSA-1024? Alles, was unter den Mindestempfehlungen liegt, muss auf die Migrationsliste. Die Vorlage verlangt diesen Review jährlich.
- 03
Schlüsselmanagement-Prozess definieren
Lege fest, wer Schlüssel erzeugen darf, wo sie gespeichert werden (HSM, Key Vault, Secure Enclave), wie die Rotation funktioniert und was bei Kompromittierung passiert. Die Vorlage definiert elf Teilprozesse — du musst nicht alle am ersten Tag operationalisieren, aber Erzeugung, Speicherung, Rotation und Kompromittierungsreaktion sind das Minimum.
- 04
Vorlage anpassen
Ersetze Platzhalter, streiche was nicht zutrifft (kein HSM? kein eigenes PKI? Keine Exportbeschränkungen?), und ergänze eure spezifischen Rotationszyklen und Produkte. Die Liste erlaubter Algorithmen übernimmst du direkt aus der BSI TR-02102.
- 05
Zertifikats-Monitoring aufsetzen
Nichts ist unangenehmer als ein abgelaufenes TLS-Zertifikat um 3 Uhr nachts. Die Vorlage verlangt automatische Warnungen 30 Tage vor Ablauf. Tools wie Certbot, cert-manager (Kubernetes) oder kommerzielle Zertifikatsmanagement-Plattformen automatisieren die Erneuerung gleich mit.
Wo es in der Praxis schiefgeht
1. Veraltete Algorithmen im Einsatz. SHA-1, TLS 1.0, RSA-1024 — alles längst überholt, aber in Legacy-Systemen noch im Einsatz. Ohne jährlichen Algorithmen-Review gegen die BSI TR-02102 fällt das nie auf.
2. Schlüssel in Konfigurationsdateien. API-Keys, Datenbankpasswörter und Verschlüsselungsschlüssel im Klartext in .env-Dateien oder Git-Repositories. Die Vorlage verbietet das explizit: Schlüsselmaterial darf nie in Log-Files, Fehlermeldungen oder Debugging-Output erscheinen.
3. Kein Rotationszyklus. TLS-Zertifikate werden einmal installiert und danach vergessen. Verschlüsselungsschlüssel für Datenbanken laufen seit Jahren unverändert. Die Vorlage definiert konkrete Zyklen: TLS jährlich, Signatur zweijährlich, Datenverschlüsselung nach Klassifizierungsstufe.
4. Kein Plan für Kompromittierung. Ein Schlüssel wird kompromittiert, aber niemand weiß, welche Systeme betroffen sind oder wie der Widerruf funktioniert. Ohne Kryptoinventar und dokumentierten Kompromittierungsprozess wird jede Schlüsselkompromittierung zum Feuerwehreinsatz.
5. Backup ohne Trennung. Schlüssel-Backups liegen auf demselben System wie die verschlüsselten Daten. Die Vorlage verlangt Backup an mindestens zwei physisch getrennten, zugriffskontrollierten Standorten — und getrennt von den Daten, die sie schützen.
Vorlage: Kryptographie-Richtlinie
Dokumentenkontrolle
Eigentümer: [RICHTLINIEN_EIGENTÜMER_ROLLE, z. B. Informationssicherheitsbeauftragte/r]
Genehmigt von: [GENEHMIGER_NAME_UND_ROLLE]
Version: [VERSION]
Gültig ab: [GÜLTIGKEITSDATUM]
Nächste Überprüfung: [NÄCHSTES_ÜBERPRÜFUNGSDATUM]
1. Rechtliche/Regulatorische Grundlage
ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Anhang A — Technologische Maßnahmen:
- A 8.24 — Einsatz von Kryptographie
BSI IT-Grundschutz:
- CON.1.A1 (Auswahl geeigneter kryptographischer Verfahren)
- CON.1.A2 (Datensicherung bei Einsatz kryptographischer Verfahren)
- CON.1.A4 (Geeignetes Schlüsselmanagement)
- CON.1.A5 (Sichere Löschung und Vernichtung von kryptographischen Schlüsseln)
- CON.1.A9 (Festlegung von Kriterien zur Auswahl von Hard- oder Software mit kryptographischen Funktionen)
- CON.1.A10 (Entwicklung eines Kryptokonzepts)
- CON.1.A15 (Reaktion auf praktische Schwächung eines kryptographischen Verfahrens)
- CON.1.A19 (Erstellung eines Kryptokatasters)
Die BSI Technische Richtlinie TR-02102 (Kryptographische Verfahren: Empfehlungen und Schlüssellängen) wird als maßgebliche Quelle für Algorithmenauswahl und Schlüssellängen angewendet.
Weitere jurisdiktionsspezifische Gesetze und Vorschriften — insbesondere Datenschutzrecht (DSGVO), Exportkontrollen für kryptographische Technologien und branchenspezifische Vertraulichkeitsanforderungen — sind im Rechtsregister aufgeführt und werden durch Verweis einbezogen.
2. Zweck & Geltungsbereich
Diese Richtlinie legt Regeln für den wirksamen Einsatz von Kryptographie und die Verwaltung kryptographischer Schlüssel bei [IHR_ORGANISATIONSNAME] fest. Sie stellt den ordnungsgemäßen und wirksamen Einsatz kryptographischer Verfahren zum Schutz der Vertraulichkeit, Authentizität und Integrität von Informationen in Übereinstimmung mit geschäftlichen, informationssicherheits- und datenschutzrechtlichen Anforderungen sicher.
Die Richtlinie gilt für alle Beschäftigten, IT-Systeme, Anwendungen und Dienste, die Informationen erzeugen, verarbeiten, speichern oder übertragen, die einen kryptographischen Schutz benötigen. Dies umfasst Beschäftigte, Auftragnehmer und Dritte mit Zugriff auf die Informations- und Kommunikationsinfrastruktur der Organisation.
Kryptographie wird eingesetzt, um folgende Informationssicherheitsziele zu erreichen:
- Vertraulichkeit: Verschlüsselung schützt sensible oder kritische Informationen, ob gespeichert oder übertragen, sodass nur autorisierte Empfänger sie lesen können.
- Integrität & Authentizität: Digitale Signaturen und Message Authentication Codes verifizieren, dass gespeicherte oder übertragene Informationen nicht verändert wurden und vom angegebenen Absender stammen. Dateiintegritätsprüfungs-Algorithmen erkennen unbefugte Änderungen. Kryptographische Hash-Verfahren (SHA-256 oder stärker) stehen zur forensischen Beweismittelsicherung bereit.
- Nicht-Abstreitbarkeit: Kryptographische Verfahren liefern Nachweise für das Eintreten oder Nicht-Eintreten eines Ereignisses oder einer Handlung und verhindern, dass eine Partei ihre Beteiligung leugnen kann.
- Authentisierung: Kryptographische Verfahren authentisieren Benutzer und Systementitäten, die Zugriff auf Systemnutzer, Entitäten und Ressourcen anfordern oder mit ihnen Transaktionen durchführen.
3. Kryptographische Richtlinie (A 8.24)
Der technische Einsatz kryptographischer Verfahren allein reicht nicht aus, um Vertraulichkeit, Integrität und Authentizität zu gewährleisten. Organisatorische Maßnahmen ergänzen die technischen Kontrollen zu einem umfassenden Kryptokonzept. Die folgenden Regeln regeln die Auswahl, Bereitstellung und Nutzung von Kryptographie in der gesamten Organisation.
3.1 Allgemeine Grundsätze
- Rahmen der Kryptographie-Richtlinie: Diese Richtlinie stellt die themenspezifische Richtlinie zur Kryptographie dar. Sie definiert die allgemeinen Grundsätze für den Schutz von Informationen durch kryptographische Mittel, maximiert den Nutzen kryptographischer Verfahren und minimiert die Risiken unangemessener oder falscher Anwendung.
3.2 Auswahl von Algorithmen & Verschlüsselungsstärke
- Klassifizierungsbasierte Stärke: Das erforderliche Schutzniveau wird durch die Klassifizierung der zu schützenden Informationen bestimmt. Art, Stärke und Qualität des kryptographischen Algorithmus werden entsprechend gewählt — höhere Klassifizierungsstufen erfordern stärkere Algorithmen und längere Schlüssellängen.
- Genehmigte Algorithmen & Standards: Es werden nur etablierte Algorithmen verwendet, die von der Kryptographie-Community intensiv geprüft wurden und für die keine Sicherheitsschwachstellen bekannt sind. Die Organisation folgt den Empfehlungen der BSI Technischen Richtlinie TR-02102 zur Auswahl von Algorithmen, Betriebsarten und Mindestschlüssellängen. Eine Liste genehmigter kryptographischer Algorithmen, Lösungen und Einsatzpraktiken wird geführt und jährlich überprüft.
Bei der Auswahl kryptographischer Hardware oder Software werden folgende Kriterien bewertet: Funktionsumfang, Interoperabilität mit bestehenden Systemen, Fehlerverhalten und Widerstandsfähigkeit gegen Missbrauch, geplante Einsatzdauer des kryptographischen Verfahrens im Verhältnis zu den verwendeten Schlüssellängen, rechtliche und regulatorische Anforderungen sowie datenschutzrechtliche Implikationen. Zertifizierte kryptographische Produkte werden bevorzugt, sofern die Zertifizierung die relevanten kryptographischen Aspekte abdeckt.
3.3 Verschlüsselung mobiler Geräte & Speichermedien
- Verschlüsselung mobiler Geräte & Medien: Informationen auf mobilen Endgeräten (Laptops, Smartphones, Tablets) und auf Wechselspeichermedien werden im Ruhezustand mittels Vollverschlüsselung oder Container-basierter Verschlüsselung geschützt. Über Netzwerke zu oder von solchen Geräten übertragene Informationen werden durch Transport-Layer-Verschlüsselung (TLS 1.2 oder höher, IPsec-VPN) geschützt.
3.4 Auswirkungen auf Inhaltsprüfungs-Kontrollen
- Inhaltsprüfungs-Kontrollen: Wo verschlüsselter Datenverkehr Sicherheitsmaßnahmen umgeht, die auf Inhaltsprüfung angewiesen sind (z. B. Malware-Erkennungs-Gateways, Data-Loss-Prevention-Filter, Content-Filter-Proxies), werden kompensierende Maßnahmen umgesetzt. Dazu gehören Endpunkt-basiertes Anti-Malware-Scanning, TLS-Inspektion am Gateway, wo rechtlich und technisch machbar, sowie Sicherheitsmaßnahmen auf Anwendungsebene, die vor der Verschlüsselung greifen.
3.5 Rechtliche & grenzüberschreitende Anforderungen
- Regulatorische & Export-Beschränkungen: Vor dem Einsatz kryptographischer Verfahren werden anwendbare Vorschriften und nationale Beschränkungen identifiziert — insbesondere bei grenzüberschreitenden Datenflüssen. Import- und Exportbeschränkungen für kryptographische Hard- und Software werden für jede beteiligte Jurisdiktion bewertet. Wo rechtliche Anforderungen in Konflikt stehen (z. B. Datenschutzgesetze verlangen Verschlüsselung, während das Zielland deren Nutzung einschränkt), wird vor dem Transfer eine Risikobewertung durchgeführt und dokumentiert.
3.6 Externe kryptographische Dienstleister
- Service Level Agreements: Verträge mit externen Anbietern kryptographischer Dienste (z. B. Zertifizierungsstellen, Managed-HSM-Anbieter, Cloud-Key-Management-Dienste) enthalten ausdrückliche Bestimmungen zu Haftung, Dienstzuverlässigkeit, Key-Escrow-Bedingungen, Vorfallreaktionszeiten und Auditrechten. Service Level Agreements definieren Wiederherstellungsziele für Zertifikatsausstellung, -widerruf und Schlüsselwiederherstellungsvorgänge.
4. Schlüsselmanagement (A 8.24)
Ein angemessenes Schlüsselmanagement erfordert sichere Prozesse für die Erzeugung, Speicherung, Archivierung, den Abruf, die Verteilung, den Rückzug und die Vernichtung kryptographischer Schlüssel. Das Schlüsselmanagementsystem basiert auf einem abgestimmten Satz von Standards, Verfahren und sicheren Methoden, die den gesamten Schlüssellebenszyklus abdecken. Jeder kryptographische Schlüssel dient nur einem Zweck — insbesondere werden für Verschlüsselung und digitale Signatur getrennte Schlüssel verwendet.
4.1 Schlüsselerzeugung
- Schlüsselerzeugung: Kryptographische Schlüssel werden mit genehmigten Schlüsselerzeugern in einer sicheren Umgebung erzeugt. Hardware-Zufallszahlengeneratoren oder zertifizierte kryptographische Bibliotheken stellen die Entropie-Quelle bereit. Voreingestellte oder vorinstallierte Schlüssel in kryptographischer Hardware oder Software werden vor dem produktiven Einsatz ersetzt. Schlüssel für verschiedene kryptographische Systeme und Anwendungen werden getrennt erzeugt, um die Auswirkungen einer einzelnen Schlüsselkompromittierung zu begrenzen.
4.2 Public-Key-Zertifikate
- Zertifikatsausstellung: Public-Key-Zertifikate werden von vertrauenswürdigen Zertifizierungsstellen bezogen. Interne Zertifikate werden über die eigene PKI-Infrastruktur der Organisation oder einen vertraglich gebundenen CA-Dienst ausgestellt. Jeder Zertifikatsantrag wird vor der Ausstellung gegen die Identität der antragstellenden Entität validiert.
- Authentizitätsprüfung von Zertifikaten: Bevor man sich auf einen öffentlichen Schlüssel einer dritten Partei verlässt, wird dessen Authentizität über die Zertifikatskette verifiziert. Der Zertifikatswiderrufsstatus wird vor der Nutzung über CRL oder OCSP geprüft. Selbstsignierte Zertifikate werden nur in ausdrücklich dokumentierten Ausnahmen mit kompensierenden Maßnahmen akzeptiert.
4.3 Schlüsselverteilung & Aktivierung
- Schlüsselverteilung & Aktivierung: Schlüssel werden über sichere Kanäle an die vorgesehenen Empfänger verteilt, die vom Datenkanal getrennt sind. Symmetrische Schlüssel werden niemals im Klartext über denselben Kommunikationsweg wie die verschlüsselten Daten übertragen. Nach Empfang werden Schlüssel über ein dokumentiertes Verfahren aktiviert, das die Integrität und Authentizität des empfangenen Schlüsselmaterials bestätigt.
4.4 Schlüsselspeicherung & -schutz
- Schlüsselspeicherung & Zugriff: Kryptographische Schlüssel werden in dedizierten Schlüsselspeichern (Hardware Security Modules, verschlüsselte Key Vaults, Secure Enclaves) gespeichert. Der Zugriff auf Schlüssel ist durch rollenbasierte Zugriffskontrolle auf autorisiertes Personal und Systeme beschränkt. Langlebige kryptographische Schlüssel werden zusätzlich offline, außerhalb der operativen IT-Systeme, an einem physisch gesicherten Ort aufbewahrt.
- Integritätsschutz: Alle Schlüssel werden durch Integritätsprüfungen (z. B. Prüfsummen, HMAC) vor unbefugter Veränderung und versehentlichem Verlust geschützt, sowohl im Ruhezustand als auch während der Übertragung.
- Vertraulichkeit geheimer und privater Schlüssel: Geheime Schlüssel (symmetrisch) und private Schlüssel (asymmetrisch) werden vor unbefugter Nutzung und Offenlegung geschützt. Sie werden verschlüsselt gespeichert, nur über sichere Kanäle übertragen und nur durch authentisierte, autorisierte Prozesse zugänglich gemacht. Schlüsselmaterial erscheint niemals in Protokolldateien, Fehlermeldungen oder Debug-Ausgaben.
- Physische Sicherheit der Schlüssel-Infrastruktur: Geräte zur Erzeugung, Speicherung und Archivierung von Schlüsseln (HSMs, Key-Server, Smartcard-Personalisierungsstationen) werden in physisch gesicherten Bereichen mit Zugangskontrolle, Umgebungsüberwachung und manipulationssicherer Ausstattung betrieben.
4.5 Schlüsselrotation & Lebenszyklus
- Schlüsselrotation: Kryptographische Schlüssel werden in Intervallen gewechselt, die durch Risikobewertung und die Sensibilität der geschützten Daten bestimmt werden. Rotationspläne werden pro Schlüsseltyp dokumentiert: TLS-Zertifikate jährlich, Signaturschlüssel alle zwei Jahre, Verschlüsselungsschlüssel für gespeicherte Daten entsprechend der Klassifizierungsstufe. Automatisierte Rotation wird eingesetzt, wo technisch machbar.
- Aktivierungs- & Deaktivierungsdaten: Jeder Schlüssel hat definierte Aktivierungs- und Deaktivierungsdaten. Technische Kontrollen setzen diese Daten durch, sodass Schlüssel nur innerhalb ihres festgelegten Gültigkeitszeitraums nutzbar sind. Ablaufende Schlüssel und Zertifikate lösen automatisierte Warnungen mindestens 30 Tage vor der Deaktivierung aus, um rechtzeitige Erneuerung zu ermöglichen.
4.6 Umgang mit kompromittierten Schlüsseln
- Reaktion auf Schlüsselkompromittierung: Ein dokumentiertes Verfahren legt die Schritte fest, die bei Verdacht auf oder bestätigter Schlüsselkompromittierung zu befolgen sind. Der kompromittierte Schlüssel wird sofort widerrufen und alle darauf angewiesenen Systeme werden identifiziert und aktualisiert. Ein neuer Schlüssel wird erzeugt und verteilt. Der Vorfall wird an die/den Informationssicherheitsbeauftragte/n gemeldet und über den Vorfallmanagementprozess dokumentiert. Wenn der kompromittierte Schlüssel klassifizierte Informationen geschützt hat, ermittelt eine Risikobewertung, ob eine Neuverschlüsselung der betroffenen Daten erforderlich ist.
4.7 Schlüsselwiderruf & Deaktivierung
- Schlüsselwiderruf & Deaktivierung: Schlüssel werden widerrufen, wenn sie kompromittiert wurden, wenn der Schlüsselinhaber die Organisation verlässt oder wenn das zugehörige System oder die Anwendung außer Betrieb genommen wird. Widerrufene Schlüssel werden innerhalb von 24 Stunden zu Zertifikatswiderrufslisten hinzugefügt oder im Schlüsselmanagementsystem als inaktiv markiert. Wenn ein Benutzer die Organisation verlässt, werden seine Schlüssel widerrufen und archiviert (nicht vernichtet), um die zukünftige Entschlüsselung historischer Daten zu ermöglichen, sofern gesetzlich erforderlich.
4.8 Schlüsselwiederherstellung & Sicherung
- Schlüsselwiederherstellung: Ein dokumentiertes Schlüsselwiederherstellungsverfahren stellt sicher, dass verschlüsselte Informationen zugänglich bleiben, wenn ein Schlüssel verloren geht oder beschädigt wird. Wiederherstellungsmechanismen (z. B. Key Escrow, Secret Sharing, Masterkey-Entschlüsselung) werden jährlich getestet. Für langfristig gespeicherte verschlüsselte Daten bestätigen regelmäßige Prüfungen, dass die archivierten Schlüssel und die zugehörige kryptographische Software oder Hardware weiterhin nutzbar sind.
- Schlüsselsicherung & -archivierung: Kryptographische Schlüssel werden verschlüsselt gesichert und getrennt von den geschützten Daten gespeichert. Sicherungskopien werden an mindestens zwei physisch getrennten, zugangskontrollierten Standorten aufbewahrt. Archivierte Schlüssel werden für die im Datenaufbewahrungsplan erforderliche Dauer aufbewahrt, zusammen mit der zugehörigen kryptographischen Software oder Algorithmen-Dokumentation, die zu ihrer Nutzung erforderlich ist.
4.9 Schlüsselvernichtung
- Schlüsselvernichtung: Schlüssel, die nicht mehr benötigt werden, werden mit genehmigten Methoden (kryptographische Löschung, physische Vernichtung der Schlüsselmedien) sicher vernichtet. Das Vernichtungsverfahren und die verwendeten Methoden werden dokumentiert. Vor der Vernichtung eines Schlüssels wird geprüft, dass keine verschlüsselten Daten, die zukünftigen Zugriff erfordern, von diesem Schlüssel abhängen. Das Vernichtungsereignis wird mit Zeitstempel, verantwortlicher Person und verwendeter Methode protokolliert.
4.10 Protokollierung & Audit
- Protokollierung & Audit: Alle Schlüsselmanagement-Aktivitäten werden protokolliert — einschließlich Schlüsselerzeugung, -verteilung, -aktivierung, -rotation, -widerruf, -wiederherstellung und -vernichtung. Protokolle werden manipulationssicher gespeichert, gemäß dem Protokollaufbewahrungsplan der Organisation aufbewahrt und regelmäßig von der/dem Informationssicherheitsbeauftragten überprüft. Anomalien in Schlüsselnutzungsmustern (z. B. ungewöhnliche Zugriffshäufigkeit, Zugriff außerhalb der Geschäftszeiten) lösen Warnungen zur Untersuchung aus.
4.11 Rechtliche Zugriffsanfragen
- Rechtliche Zugriffsanfragen: Ein Verfahren regelt die Reaktion auf rechtliche Anfragen zum Zugriff auf kryptographische Schlüssel oder entschlüsselte Daten (z. B. Gerichtsbeschlüsse, die verschlüsselte Informationen unverschlüsselt als Beweismittel fordern). Solche Anfragen werden vor der Herausgabe von Schlüsselmaterial oder entschlüsselten Daten durch die Rechtsabteilung geprüft. Alle Offenlegungen werden mit der Rechtsgrundlage, dem Umfang, der genehmigenden Stelle und dem Datum dokumentiert.
Der Gesamtansatz zum Schlüsselmanagement — einschließlich der Methoden zur Erzeugung, zum Schutz und zur Wiederherstellung kryptographischer Schlüssel — ist in den obigen Unterabschnitten beschrieben. Dieser Ansatz deckt den vollständigen Schlüssellebenszyklus ab und adressiert die Wiederherstellung verschlüsselter Informationen im Falle verlorener, kompromittierter oder beschädigter Schlüssel durch dokumentierte Wiederherstellungs- und Sicherungsverfahren.
5. Kryptokataster
Ein Kryptokataster wird geführt und mindestens jährlich aktualisiert. Für jede Gruppe von IT-Systemen, die kryptographische Funktionen nutzen, werden folgende Informationen erfasst:
- Zweck: Der Anwendungsfall (z. B. Vollverschlüsselung, TLS für Kommunikation, digitale Signaturen, VPN-Tunnel).
- Verantwortliche Person: Der Systemeigentümer oder Administrator, der für die kryptographische Umsetzung verantwortlich ist.
- Algorithmus & Parameter: Der verwendete kryptographische Algorithmus, der Betriebsmodus und die Schlüssellänge.
- Produkt: Das eingesetzte kryptographische Hardware- oder Softwareprodukt (einschließlich Version).
- Schlüssellebenszyklus-Status: Aktueller Schlüsselgültigkeitszeitraum, letztes Rotationsdatum und nächste geplante Rotation.
Das Kataster ist mit dem Asset-Inventar der Organisation querverknüpft und dient als Grundlage für die jährliche Algorithmenüberprüfung (siehe Überprüfung & Pflege).
6. Rollen & Verantwortlichkeiten
- Geschäftsleitung: Genehmigt diese Richtlinie, stellt Ressourcen für die kryptographische Infrastruktur bereit und stellt die Ausrichtung an Geschäftszielen und rechtlichen Anforderungen sicher.
- Informationssicherheitsbeauftragte/r (ISB): Pflegt diese Richtlinie, definiert genehmigte Algorithmen und Schlüssellängen, überprüft das Kryptokataster, bewertet die Auswirkungen geschwächter Algorithmen und koordiniert die Vorfallreaktion bei Schlüsselkompromittierungen.
- IT-Betrieb / Schlüsseladministratoren: Setzen die in dieser Richtlinie definierten kryptographischen Maßnahmen und Schlüsselmanagementverfahren um. Erzeugen, verteilen, rotieren, sichern und vernichten Schlüssel gemäß den dokumentierten Prozessen. Pflegen das Kryptokataster und stellen rechtzeitige Zertifikatserneuerung sicher.
- System- & Anwendungseigentümer: Stellen sicher, dass kryptographische Anforderungen für ihre Systeme während Design und Beschaffung identifiziert werden. Wählen kryptographische Lösungen aus der genehmigten Liste aus und integrieren sie gemäß dieser Richtlinie.
- Alle Beschäftigten: Nutzen kryptographische Werkzeuge wie angewiesen (z. B. Verschlüsselung von Laptops, VPN-Nutzung für Remote-Zugriff, Überprüfung digitaler Signaturen). Melden vermutete Schlüsselkompromittierungen oder kryptographische Fehler unverzüglich an die/den Informationssicherheitsbeauftragte/n.
7. Überprüfung & Pflege
Diese Richtlinie und das zugehörige Kryptokataster werden überprüft:
- Mindestens jährlich auf Grundlage des Kryptokatasters, um zu verifizieren, dass alle eingesetzten Algorithmen, Schlüssellängen und kryptographischen Produkte sicher bleiben und keine bekannten Schwachstellen bestehen.
- Wenn die BSI Technische Richtlinie TR-02102 oder gleichwertige internationale Empfehlungen mit neuen Algorithmen- oder Schlüssellängenleitfäden aktualisiert werden.
- Nach jedem kryptographischen Vorfall (Schlüsselkompromittierung, Offenlegung einer Algorithmusschwäche, CA-Einbruch).
- Wenn neue rechtliche oder regulatorische Anforderungen identifiziert werden, die die Kryptographie betreffen (z. B. Änderungen bei Exportkontrollen, Post-Quantum-Readiness).
- Nach wesentlichen Änderungen an der IT-Landschaft, den Geschäftsprozessen oder dem Risikoprofil der Organisation.
Wird ein eingesetzter Algorithmus als geschwächt befunden, stellt der in dieser Richtlinie definierte Reaktionsprozess sicher, dass der betroffene Algorithmus entweder gehärtet (z. B. erhöhte Schlüssellänge) oder durch eine sichere Alternative ersetzt wird, bevor die Schwäche ausgenutzt werden kann.
Document control
Owner: [POLICY_OWNER_ROLE, e.g. Information Security Officer]
Approved by: [APPROVER_NAME_AND_ROLE]
Version: [VERSION]
Effective date: [EFFECTIVE_DATE]
Next review: [NEXT_REVIEW_DATE]
1. Legal/Regulatory Basis
ISO/IEC 27001:2022 / ISO/IEC 27002:2022, Annex A — Technological Controls:
- A 8.24 — Use of Cryptography
BSI IT-Grundschutz:
- CON.1.A1 (Selection of Suitable Cryptographic Procedures)
- CON.1.A2 (Data Backup When Using Cryptographic Procedures)
- CON.1.A4 (Suitable Key Management)
- CON.1.A5 (Secure Deletion and Destruction of Cryptographic Keys)
- CON.1.A9 (Definition of Criteria for the Selection of Hardware or Software with Cryptographic Functions)
- CON.1.A10 (Creation of a Crypto Concept)
- CON.1.A15 (Response to Practical Weakening of a Cryptographic Procedure)
- CON.1.A19 (Creation of a Crypto Inventory)
BSI Technical Guideline TR-02102 (Cryptographic Mechanisms: Recommendations and Key Lengths) is applied as the authoritative source for algorithm selection and key length recommendations.
Additional jurisdiction-specific laws and regulations — in particular data protection law (GDPR), export controls on cryptographic technology and sector-specific confidentiality requirements — are listed in the Legal Register and incorporated by reference.
2. Purpose & Scope
This policy establishes rules for the effective use of cryptography and the management of cryptographic keys at [YOUR_ORGANISATION_NAME]. It ensures proper and effective use of cryptographic techniques to protect the confidentiality, authenticity and integrity of information in accordance with business, information security and privacy requirements.
The policy applies to all personnel, IT systems, applications and services that generate, process, store or transmit information requiring cryptographic protection. This includes employees, contractors and third parties with access to the organisation's information and communication infrastructure.
Cryptography is applied to achieve the following information security objectives:
- Confidentiality: Encryption protects sensitive or critical information, whether stored or transmitted, so that only authorised recipients can read it.
- Integrity & Authenticity: Digital signatures and message authentication codes verify that stored or transmitted information has not been altered and originates from the claimed sender. File integrity checking algorithms detect unauthorised modifications. Cryptographic hash procedures (SHA-256 or stronger) are available for forensic evidence preservation.
- Non-repudiation: Cryptographic techniques provide evidence of the occurrence or non-occurrence of an event or action, preventing a party from denying involvement.
- Authentication: Cryptographic techniques authenticate users and system entities requesting access to or transacting with system users, entities and resources.
3. Cryptographic Policy (A 8.24)
The technical use of cryptographic procedures alone is insufficient to guarantee confidentiality, integrity and authenticity. Organisational measures complement the technical controls to form a comprehensive cryptographic concept. The following rules govern the selection, deployment and use of cryptography across the organisation.
3.1 General Principles
- Cryptographic Policy Framework: This policy constitutes the topic-specific policy on cryptography. It defines the general principles for the protection of information through cryptographic means, maximises the benefits of cryptographic techniques and minimises the risks of inappropriate or incorrect use.
3.2 Algorithm Selection & Cipher Strength
- Classification-Based Strength: The required level of protection is determined by the classification of the information being protected. The type, strength and quality of the cryptographic algorithm are selected accordingly — higher classification levels require stronger algorithms and longer key lengths.
- Approved Algorithms & Standards: Only established algorithms that have been intensively examined by the cryptographic community and for which no security vulnerabilities are known are used. The organisation follows the recommendations of BSI Technical Guideline TR-02102 for the selection of algorithms, cipher modes and minimum key lengths. A list of approved cryptographic algorithms, solutions and usage practices is maintained and reviewed annually.
When selecting cryptographic hardware or software, the following criteria are evaluated: functional scope, interoperability with existing systems, error safety and resilience against misuse, projected lifetime of the cryptographic procedure relative to the key lengths employed, legal and regulatory requirements and data protection implications. Certified cryptographic products are preferred where certification covers the relevant cryptographic aspects.
3.3 Mobile Device & Storage Media Encryption
- Mobile Device & Media Encryption: Information held on mobile user endpoint devices (laptops, smartphones, tablets) and on removable storage media is encrypted at rest using full-disk or container-based encryption. Information transmitted over networks to or from such devices is protected by transport-layer encryption (TLS 1.2 or higher, IPsec VPN).
3.4 Impact on Content Inspection Controls
- Content Inspection Controls: Where encrypted traffic bypasses security controls that rely on content inspection (e.g. malware detection gateways, data loss prevention filters, content filtering proxies), compensating measures are implemented. These include endpoint-based anti-malware scanning, TLS inspection at the gateway where legally and technically feasible, and application-layer security controls that operate before encryption is applied.
3.5 Legal & Cross-Border Requirements
- Regulatory & Export Restrictions: Before deploying cryptographic techniques, applicable regulations and national restrictions are identified — particularly for cross-border data flows. Import and export restrictions on cryptographic hardware and software are assessed for each jurisdiction involved. Where legal requirements conflict (e.g. data protection laws mandate encryption while a destination country restricts its use), a risk assessment is conducted and documented before the transfer proceeds.
3.6 External Cryptographic Service Providers
- Service Level Agreements: Contracts with external suppliers of cryptographic services (e.g. certificate authorities, managed HSM providers, cloud key management services) include explicit provisions for liability, service reliability, key escrow conditions, incident response times and the right to audit. Service level agreements define recovery time objectives for certificate issuance, revocation and key recovery operations.
4. Key Management (A 8.24)
Appropriate key management requires secure processes for generating, storing, archiving, retrieving, distributing, retiring and destroying cryptographic keys. The key management system is based on an agreed set of standards, procedures and secure methods covering the entire key lifecycle. Each cryptographic key serves only one purpose — in particular, separate keys are used for encryption and digital signature operations.
4.1 Key Generation
- Key Generation: Cryptographic keys are generated using approved key generators in a secure environment. Hardware random number generators or certified cryptographic libraries provide the entropy source. Default or pre-installed keys in cryptographic hardware or software are replaced before operational use. Keys for different cryptographic systems and applications are generated separately to limit the impact of a single key compromise.
4.2 Public Key Certificates
- Certificate Issuance: Public key certificates are obtained from trusted certificate authorities. Internal certificates are issued through the organisation's own PKI infrastructure or a contracted CA service. Each certificate request is validated against the identity of the requesting entity before issuance.
- Certificate Authenticity Verification: Before relying on a public key from a third party, its authenticity is verified through the certificate chain. Certificate revocation status is checked via CRL or OCSP before use. Self-signed certificates are only accepted in explicitly documented exceptions with compensating controls.
4.3 Key Distribution & Activation
- Key Distribution & Activation: Keys are distributed to intended recipients through secure channels that are separate from the data channel. Symmetric keys are never transmitted in plaintext over the same communication path as the encrypted data. Upon receipt, keys are activated through a documented procedure that confirms the integrity and authenticity of the received key material.
4.4 Key Storage & Protection
- Key Storage & Access: Cryptographic keys are stored in dedicated key stores (hardware security modules, encrypted key vaults, secure enclaves). Access to keys is restricted to authorised personnel and systems through role-based access control. Long-lived cryptographic keys are additionally stored offline, outside the operational IT systems, in a physically secured location.
- Integrity Protection: All keys are protected against unauthorised modification and accidental loss through integrity checks (e.g. checksums, HMAC) applied to key material at rest and during transfer.
- Confidentiality of Secret & Private Keys: Secret keys (symmetric) and private keys (asymmetric) are protected against unauthorised use and disclosure. They are stored encrypted, transmitted only through secure channels and accessed only through authenticated, authorised processes. Key material never appears in log files, error messages or debugging output.
- Physical Security of Key Infrastructure: Equipment used to generate, store and archive keys (HSMs, key servers, smart card personalisation stations) is housed in physically secured areas with access control, environmental monitoring and tamper-evident protection.
4.5 Key Rotation & Lifecycle
- Key Rotation: Cryptographic keys are changed at intervals defined by risk assessment and the sensitivity of the protected data. Rotation schedules are documented per key type: TLS certificates annually, signing keys biennially, encryption keys for stored data according to classification level. Automated rotation is used wherever technically feasible.
- Activation & Deactivation Dates: Each key has defined activation and deactivation dates. Technical controls enforce these dates so that keys are only usable within their designated validity period. Expiring keys and certificates trigger automated alerts at least 30 days before deactivation to allow timely renewal.
4.6 Compromised Key Handling
- Compromised Key Response: A documented procedure defines the steps to follow when a key compromise is suspected or confirmed. The compromised key is immediately revoked and all systems relying on it are identified and updated. A new key is generated and distributed. The incident is reported to the Information Security Officer and documented through the incident management process. Where the compromised key protected classified information, a risk assessment determines whether re-encryption of the affected data is required.
4.7 Key Revocation & Deactivation
- Key Revocation & Deactivation: Keys are revoked when they are compromised, when the key holder leaves the organisation or when the associated system or application is decommissioned. Revoked keys are added to certificate revocation lists or marked as inactive in the key management system within 24 hours. When a user leaves the organisation, their keys are revoked and archived (not destroyed) to allow future decryption of historical data if legally required.
4.8 Key Recovery & Backup
- Key Recovery: A documented key recovery procedure ensures that encrypted information remains accessible if a key is lost or corrupted. Recovery mechanisms (e.g. key escrow, secret sharing, master key decryption) are tested annually. For long-term stored encrypted data, regular checks confirm that the archived keys and the associated cryptographic software or hardware remain usable.
- Key Backup & Archival: Cryptographic keys are backed up in encrypted form and stored separately from the data they protect. Backup copies are held in at least two physically separate, access-controlled locations. Archived keys are retained for the period required by the data retention schedule, along with the associated cryptographic software or algorithm documentation needed to use them.
4.9 Key Destruction
- Key Destruction: Keys that are no longer needed are securely destroyed using approved methods (cryptographic erasure, physical destruction of key media). The destruction procedure and the methods used are documented. Before destroying a key, a check confirms that no encrypted data requiring future access depends on that key. The destruction event is logged with timestamp, responsible person and method used.
4.10 Logging & Auditing
- Logging & Auditing: All key management activities are logged — including key generation, distribution, activation, rotation, revocation, recovery and destruction. Logs are stored in a tamper-evident format, retained according to the organisation's log retention schedule and reviewed periodically by the Information Security Officer. Anomalies in key usage patterns (e.g. unusual access frequency, access outside business hours) trigger alerts for investigation.
4.11 Legal Access Requests
- Legal Access Requests: A procedure governs responses to legal requests for access to cryptographic keys or decrypted data (e.g. court orders requiring encrypted information in unencrypted form as evidence). Such requests are reviewed by legal counsel before any key material or decrypted data is released. All disclosures are documented with the legal basis, scope, approving authority and date.
The overall approach to key management — including the methods for generating, protecting and recovering cryptographic keys — is described in the subsections above. This approach covers the full key lifecycle and addresses the recovery of encrypted information in the case of lost, compromised or damaged keys through documented recovery and backup procedures.
5. Cryptographic Inventory
A cryptographic inventory is maintained and updated at least annually. For each group of IT systems using cryptographic functions, the following information is recorded:
- Purpose: The use case (e.g. full-disk encryption, TLS for communication, digital signatures, VPN tunnels).
- Responsible Person: The system owner or administrator accountable for the cryptographic implementation.
- Algorithm & Parameters: The cryptographic algorithm, cipher mode and key length in use.
- Product: The cryptographic hardware or software product deployed (including version).
- Key Lifecycle Status: Current key validity period, last rotation date and next scheduled rotation.
The inventory is cross-referenced with the organisation's asset inventory and serves as the basis for the annual algorithm review (see Review & Maintenance).
6. Roles & Responsibilities
- Top Management: Approves this policy, allocates resources for cryptographic infrastructure and ensures alignment with business objectives and legal requirements.
- Information Security Officer (ISO): Maintains this policy, defines approved algorithms and key lengths, reviews the cryptographic inventory, assesses the impact of weakened algorithms and coordinates incident response for key compromises.
- IT Operations / Key Administrators: Implement the cryptographic controls and key management procedures defined in this policy. Generate, distribute, rotate, back up and destroy keys in accordance with the documented processes. Maintain the cryptographic inventory and ensure timely certificate renewal.
- System & Application Owners: Ensure that cryptographic requirements are identified for their systems during design and procurement. Select cryptographic solutions from the approved list and integrate them in accordance with this policy.
- All Personnel: Use cryptographic tools as instructed (e.g. encrypt laptops, use VPN for remote access, verify digital signatures). Report suspected key compromises or cryptographic failures immediately to the Information Security Officer.
7. Review & Maintenance
This policy and the associated cryptographic inventory are reviewed:
- At least annually, based on the cryptographic inventory, to verify that all deployed algorithms, key lengths and cryptographic products remain secure and no known vulnerabilities exist.
- When the BSI Technical Guideline TR-02102 or equivalent international recommendations are updated with new algorithm or key-length guidance.
- After any cryptographic incident (key compromise, algorithm weakness disclosure, certificate authority breach).
- When new legal or regulatory requirements affecting cryptography are identified (e.g. export control changes, quantum computing readiness mandates).
- Following significant changes to the organisation's IT landscape, business processes or risk profile.
If a deployed algorithm is found to be weakened, the response process defined in this policy ensures that the affected algorithm is either hardened (e.g. increased key length) or replaced by a secure alternative before the weakness can be exploited.
Quellen
- ISO/IEC 27002:2022 Abschnitt 8.24 — Einsatz von Kryptographie
- BSI IT-Grundschutz CON.1 — Kryptokonzept
- BSI TR-02102 — Kryptographische Verfahren: Empfehlungen und Schlüssellängen