Sichern Sie die Daten Ihres Unternehmens mit diesen Verschlüsselungsalgorithmen

Wichtige Erkenntnisse

• AES-256 (symmetrisch) ist der aktuelle Standard für die Verschlüsselung gespeicherter und übertragener Daten. Für Schlüsselaustausch, TLS und digitale Signaturen wird es mit RSA-3072 oder ECC P-384 (asymmetrisch) kombiniert.
• NIST SP 800-57 legt die Mindestschlüssellänge fest: RSA-2048/ECC P-256 bleiben kurzfristig nutzbar, aber NIST IR 8547 sieht vor, dass RSA und ECC um das Jahr 2030 veraltet sein und um das Jahr 2035 auf eine Liste nicht mehr zulässiger Protokolle gesetzt werden.
• Die Bereitstellung oder Rotation eines Verschlüsselungsalgorithmus in der Produktion erfordert Voraussetzungen, nummerierte Schritte, Validierungsprüfungen, Rollback und Audit-Protokollierung, nicht einen ad-hoc-Schlüsseltausch.
• Speichern und verwalten Sie Schlüssel in einem HSM oder einem verwalteten Schlüsselverwaltungsdienst. Schlüsselmaterial sollte niemals in Anwendungskonfigurationsdateien, Umgebungsvariablen oder der Quellcodeverwaltung gespeichert werden.
• Die Post-Quanten-Algorithmen (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA) sind finalisiert und sollten bereits jetzt in neue Architekturentscheidungen einbezogen werden, auch wenn sich dieser Leitfaden auf die heutigen Produktionsstandardalgorithmen konzentriert.

Veröffentlicht: Juli 2022. Aktualisiert: August 2026. Geprüft vom Kryptografie-Team von Encryption Consulting.

Was ist Kryptographie und welche Rolle spielen Verschlüsselung und Entschlüsselung dabei?

Kryptografie ist die Praxis, Informationen mithilfe mathematischer Verfahren so zu schützen, dass nur autorisierte Personen sie lesen oder verwenden können. Verschlüsselung und Entschlüsselung sind ihre beiden Kernoperationen: Die Verschlüsselung wandelt lesbare Daten (Klartext) mithilfe eines Algorithmus und eines Schlüssels in eine unlesbare Form (Chiffretext) um, und die Entschlüsselung macht diese Transformation für jemanden, der den korrekten Schlüssel besitzt, rückgängig. Dieser Leitfaden setzt voraus, dass Sie die Grundlagen der Verschlüsselung und Entschlüsselung bereits kennen. Ausführliche Definitionen finden Sie in den Artikeln des Encryption Consulting Education Center zu den Themen Kryptografie und Verschlüsselung . Im Folgenden geht es um die praktische Anwendung: Welche Algorithmen sind zu wählen und wie werden sie in einer Produktionsumgebung eingesetzt, regelmäßig aktualisiert, validiert und geprüft?

Welche Verschlüsselungsalgorithmen sollten Sie heute verwenden?

Im Wesentlichen decken zwei Algorithmenfamilien alle Anforderungen an die Verschlüsselung ab: symmetrische Algorithmen, die einen gemeinsamen Schlüssel für Ver- und Entschlüsselung verwenden, und asymmetrische Algorithmen, die ein mathematisch verknüpftes öffentliches und privates Schlüsselpaar nutzen. AES deckt den symmetrischen Bereich ab, RSA und ECC den asymmetrischen.

Advanced Encryption Standard (AES)

AES ist ein symmetrischer Blockchiffre-Algorithmus, der vom NIST in FIPS 197 standardisiert wurde. Er verschlüsselt Datenblöcke fester Größe mit einem gemeinsamen geheimen Schlüssel von 128, 192 oder 256 Bit. AES-256 ist die empfohlene Schlüssellänge für neue Implementierungen zum Schutz sensibler Unternehmensdaten, da sie den größten Schutz gegen Brute-Force-Angriffe bietet und als anerkannte Basis für Compliance-Rahmenwerke wie HIPAA, PCI DSS und DSGVO-konforme Datenschutzmaßnahmen gilt. AES-128 ist weiterhin zugelassen und auf leistungsschwächerer Hardware schneller, AES-256 ist jedoch die Standardwahl, wenn Daten eine lange Vertraulichkeitsdauer haben.

RSA (Rivest-Shamir-Adleman)

RSA ist ein asymmetrischer Algorithmus, der auf der Schwierigkeit der Faktorisierung großer Zahlen basiert. Er verwendet einen öffentlichen Schlüssel zur Verschlüsselung von Daten oder zur Überprüfung einer Signatur und einen privaten Schlüssel zur Entschlüsselung von Daten oder zur Erstellung einer Signatur. RSA wird häufig für den TLS-Schlüsselaustausch, die Codesignierung und die Zertifikatsausstellung eingesetzt. Für neue Implementierungen empfiehlt sich RSA-3072 oder höher. RSA-2048 ist gemäß den aktuellen NIST-Richtlinien zwar noch zulässig, steht aber näher an der Grenze zur Veraltung und bietet weniger Spielraum gegenüber fortschrittlichen Faktorisierungstechniken als RSA-3072. Informationen darüber, wie sich die Wahl des Padding-Schemas (PKCS#1 v1.5, OAEP oder PSS) auf die Sicherheit von RSA in der Praxis auswirkt, finden Sie unter „RSA Padding Explained“ .

ECC (Elliptic Curve Cryptography)

ECC ist ein asymmetrisches Verfahren, das auf der algebraischen Struktur elliptischer Kurven basiert. Es bietet vergleichbare Sicherheit wie RSA bei einer deutlich kleineren Schlüssellänge: Ein 256-Bit-ECC-Schlüssel (Kurve P-256) bietet in etwa die gleiche Sicherheitsmarge wie ein 3072-Bit-RSA-Schlüssel, und ein 384-Bit-ECC-Schlüssel (Kurve P-384) bietet eine noch höhere. Diese kleinere Schlüssellänge ermöglicht schnellere Handshakes und eine geringere Bandbreite. Daher hat sich ECC (typischerweise ECDSA für Signaturen und ECDH für den Schlüsselaustausch) als Standardverfahren für moderne TLS-, Mobil- und IoT-Anwendungen etabliert. Verwenden Sie P-256 als allgemeine Basis und P-384, wenn die Daten oder die Arbeitslast eine höhere Sicherheitsmarge erfordern.

Triple DES (3DES): Veraltet, nicht für neue Verwendung

Triple DES wendet den ursprünglichen DES-Verschlüsselungsalgorithmus dreimal mit zwei oder drei 56-Bit-Schlüsseln an. Vor zwei Jahrzehnten war es ein praktikabler Brückenalgorithmus, doch das NIST zog die SP 800-67 Revision 2, die Triple DES genehmigte, mit Wirkung zum 1. Januar 2024 zurück. Triple DES sollte in keinem neuen Design mehr verwendet werden, und jedes System, das es noch nutzt, benötigt einen Migrationsplan zu AES-256. Weitere Informationen zur Migration finden Sie unter „ Warum 3DES oder Triple DES offiziell eingestellt wird“.

Symmetrisch vs. asymmetrisch: Welches Modell für welchen Anwendungsfall?

Symmetrische Verschlüsselung (AES) ist schneller und recheneffizienter und eignet sich daher für große Datenmengen: Datenbanken, Dateisysteme, Backups und die Nutzdaten einer TLS-Sitzung nach Abschluss des Handshakes. Asymmetrische Verschlüsselung (RSA oder ECC) ist langsamer, löst aber ein Problem, das symmetrische Verschlüsselung nicht lösen kann: den Austausch eines Geheimnisses mit jemandem, mit dem man keinen gemeinsamen Schlüssel besitzt, und den Identitätsnachweis durch digitale Signaturen. In der Praxis verwenden Produktionssysteme beide Verfahren gemeinsam: Asymmetrische Algorithmen stellen Vertrauen her und tauschen einen Sitzungsschlüssel aus, während ein symmetrischer Algorithmus die eigentliche Verschlüsselung der großen Datenmengen übernimmt. Eine detailliertere Erläuterung der Funktionsweise gemeinsamer Schlüssel finden Sie unter „ Was ist symmetrische Verschlüsselung?“. Die Entscheidungstabelle weiter unten in diesem Leitfaden ordnet jedem Algorithmus seinen typischen Anwendungsfall in der Produktion und die empfohlene Schlüssellänge zu.

Welche Voraussetzungen müssen für den Einsatz oder die Rotation eines Verschlüsselungsalgorithmus in der Produktion erfüllt sein?

Bevor Sie einen produktiven Verschlüsselungsalgorithmus oder -schlüssel verwenden, vergewissern Sie sich, dass Folgendes gegeben ist:

1. Ein kryptografisches Inventar. Kennen Sie jedes System, jedes Zertifikat und jeden gespeicherten Datensatz, der den zu ändernden Algorithmus oder Schlüssel verwendet. Sie können nicht ändern, was Sie nicht gefunden haben.
2. Infrastruktur für das Schlüsselmanagement. Ein HSM oder ein verwalteter Schlüsselverwaltungsdienst (KMS) wird benötigt, um den neuen Schlüssel zu generieren, zu speichern und den Zugriff darauf zu steuern. Schlüssel dürfen niemals im Anwendungscode generiert oder gespeichert werden.
3. Zugriffskontroll- und Genehmigungsworkflow. Definierte Rollen für die Beantragung, Genehmigung und Durchführung einer Schlüsselrotation oder Algorithmusänderung, mit Aufgabentrennung für besonders wichtige Schlüssel.
4. Eine Sicherungskopie der aktuellen Schlüssel und der verschlüsselten Daten. Vor Beginn jeglicher Änderungen wurde geprüft, ob die Wiederherstellbarkeit sichergestellt ist.
5. Ein Wartungsfenster oder ein Fenster mit geringem Kundenaufkommen, wenn die Änderung eine erneute Verschlüsselung der Daten an Ort und Stelle erfordert, anstatt nur die neuen Schreibvorgänge zu verschlüsseln.
6. Ein Rückbauplan und ein Abholzungsplan, Beides wurde vor der Ausführung festgelegt und überprüft, nicht improvisiert, nachdem etwas schiefgegangen ist.

Wie implementiert oder rotiert man einen Verschlüsselungsalgorithmus in der Produktion?

Führen Sie diese Schritte für die Bereitstellung eines neuen Algorithmus oder eine geplante Schlüsselrotation durch:

1. Generieren Sie den neuen Schlüssel innerhalb des HSM oder KMS. Verwenden Sie den Zielalgorithmus und die Zielschlüssellänge (z. B. AES-256 oder RSA-3072). Exportieren Sie das Rohschlüsselmaterial niemals in ein allgemeines Dateisystem.
2. Registrieren Sie den neuen Schlüssel mit einer eindeutigen Schlüssel-ID oder Versionsnummer. So können Anwendungen explizit darauf verweisen, und alte und neue Schlüssel können während der Übergangsphase parallel existieren.
3. Setzen Sie den neuen Schlüssel zunächst in einem begrenzten Pilotprojekt ein. (einen Dienst, einen Datenspeicher oder ein Zertifikat) anstatt des gesamten Besitzes.
4. Neue Daten mit dem neuen Schlüssel verschlüsseln Der bestehende Chiffretext bleibt unter dem alten Schlüssel erhalten, es sei denn, eine vollständige Neuverschlüsselung ist aus Richtliniengründen erforderlich.
5. Führe die Validierungsprüfungen aus. Im Folgenden wird der Pilotumfang erläutert, bevor er weiter ausgedehnt wird.
6. Die Ausweitung auf den verbleibenden Umfang erfolgt schrittweise. Validierung in jeder Phase anstatt gleichzeitig in der gesamten Umgebung bereitzustellen.
7. Historische Daten mit dem neuen Schlüssel neu verschlüsseln oder migrieren Falls die Richtlinien dies erfordern, wird der Fortschritt anhand des vollständigen Inventars ab dem Schritt der Voraussetzungen verfolgt.
8. Den alten Schlüssel oder Algorithmus außer Betrieb nehmen erst nachdem jeder Kunde die Migration bestätigt hat und die Aufbewahrungsfrist für die mit dem alten Schlüssel verschlüsselten Daten abgelaufen ist.

Wie validiert man die Implementierung einer Verschlüsselungslösung, bevor der alte Algorithmus außer Betrieb genommen wird?

Prüfen Sie die Funktion vor der Außerbetriebnahme, nicht danach. Bestätigen Sie mindestens Folgendes:

• Die mit dem neuen Schlüssel oder Algorithmus verschlüsselten Daten lassen sich korrekt entschlüsseln und stimmen mit dem ursprünglichen Klartext überein (Prüfsummen- oder Hashwertvergleich mit einer bekannten, korrekten Kopie).
• Alle Anwendungsnutzer können den neuen Schlüssel über das HSM oder KMS mit den entsprechenden Berechtigungen erreichen, was unter der erwarteten Produktionslast getestet wurde.
• TLS-Handshakes, digitale Signaturen oder Zertifikatsketten, die auf dem neuen Algorithmus basieren, werden gegenüber den jeweiligen Clients, Browsern oder Partnersystemen korrekt validiert.
• Die Leistung (Latenz, Durchsatz) des neuen Algorithmus erfüllt die gleichen Service-Level-Ziele wie der alte, da asymmetrische Algorithmen mit größeren Schlüssellängen bei großem Umfang einen messbaren Handshake-Overhead verursachen.
• Backup- und Notfallwiederherstellungsprozesse können Daten wiederherstellen, die unter dem neuen Schlüssel verschlüsselt wurden. Dies wurde anhand einer tatsächlichen Wiederherstellung getestet, nicht nur anhand eines dokumentierten Verfahrens.

Wie lautet das Rollback-Verfahren, wenn eine Verschlüsselungsbereitstellung fehlschlägt?

Definieren Sie den Rollback-Auslöser und das Rollback-Verfahren vor dem Deployment, nicht während eines Vorfalls. Ein typischer Rollback:

1. Neue Schreibvorgänge unter dem neuen Schlüssel oder Algorithmus werden gestoppt und die Anwendungskonfiguration wird auf die vorherige Schlüssel-ID zurückgesetzt.
2. Prüfen Sie, ob der alte Schlüssel im HSM oder KMS noch aktiv ist (deshalb fordert der Voraussetzungsschritt Koexistenz statt sofortiger Deaktivierung).
3. Stellen Sie alle Daten wieder her, die während des fehlgeschlagenen Rollouts neu verschlüsselt wurden, sofern die Neuverschlüsselung bereits begonnen hatte.
4. Überprüfen Sie die Funktionalität der Anwendung anhand des wiederhergestellten Zustands mithilfe der gleichen Validierungsprüfungen, die auch für die Vorwärtsbereitstellung verwendet wurden.
5. Protokollieren Sie das Rollback-Ereignis, die Auslösebedingung und die Ursache und halten Sie den neuen Schlüssel oder die Algorithmusänderung zurück, bis die Ursache behoben und erneut getestet wurde.

Ein Rollback-Plan funktioniert nur, wenn der alte Algorithmus oder Schlüssel während der Pilotphase und der stufenweisen Einführung aktiv gehalten wurde. Deshalb ist die Außerbetriebnahme der letzte Schritt im oben beschriebenen Implementierungsprozess und kein früher.

Wie sollten Sie die Verwendung und Rotation von Verschlüsselungsschlüsseln protokollieren und überwachen?

Jeder Vorgang der Schlüsselgenerierung, des Zugriffs, der Rotation und der Außerbetriebnahme erfordert einen Prüfpfad, den ein Compliance-Auditor oder ein Incident-Responder unabhängig von dem Team, das die Aktion durchgeführt hat, überprüfen kann. Mindestens Folgendes muss protokolliert werden:

• Wer (oder welche Dienstidentität) hat jedes Schlüsselgenerierungs- oder -rotationsereignis angefordert, genehmigt und ausgeführt, jeweils mit einem Zeitstempel?
• Welche Schlüssel-ID oder -Version für jeden Verschlüsselungs- oder Entschlüsselungsvorgang verwendet wurde, damit Sie jeden Datensatz bis zu dem exakten Schlüssel zurückverfolgen können, der ihn geschützt hat.
• Jeder fehlgeschlagene Entschlüsselungsversuch oder jede Zugriffsverweigerung für einen Schlüssel ist oft das erste Anzeichen für eine Fehlkonfiguration oder einen versuchten unbefugten Zugriff.
• Wichtige Stilllegungsereignisse, einschließlich der Bestätigung, dass alle abhängigen Verbraucher zuvor migriert wurden.

Die meisten HSMs und verwalteten KMS-Plattformen generieren diese Protokollierung nativ; die operative Lücke besteht in der Regel darin, diese Protokolle an ein SIEM- oder Auditsystem weiterzuleiten, das Ihr Compliance-Team tatsächlich überprüft, anstatt sie im lokalen Protokollspeicher des HSM zu belassen.

Was sind häufige Implementierungsfehler und wie lassen sie sich beheben?

Symptom	Wahrscheinliche Ursache	Schritt zur Fehlerbehebung
Die Entschlüsselung schlägt nach einer Schlüsselrotation fehl.	Die Anwendung hat die alte Schlüsselreferenz zwischengespeichert oder wurde nicht auf die neue Schlüssel-ID aktualisiert.	Überprüfen Sie die Schlüsselreferenzkonfiguration der Anwendung und erzwingen Sie eine Cache-Aktualisierung oder einen Neustart in einem kontrollierten Fenster.
TLS-Handshake-Fehler nach dem Wechsel zu einer größeren Schlüssellänge	Ein älterer Client oder Load Balancer unterstützt den neuen Algorithmus oder die neue Kurve nicht.	Prüfen Sie die Kompatibilität von Clients und Zwischenschritten (Browser, API-Clients, Load Balancer) vor der Pilotphase, nicht erst nach der vollständigen Einführung.
Unerwarteter Latenzanstieg	Asymmetrische Operationen (insbesondere RSA) mit größerer Schlüssellänge erhöhen die CPU-Kosten pro Verbindung.	Stellen Sie sicher, dass die Wiederaufnahme von TLS-Sitzungen und das Verbindungspooling aktiviert sind; erwägen Sie ECC, um die Kosten pro Handshake zu reduzieren.
Einige Daten lassen sich auch nach Abschluss der „Rotation“ noch mit dem alten Schlüssel entschlüsseln.	Im kryptografischen Inventar aus dem Voraussetzungsschritt fehlte ein Datenspeicher oder ein Sicherungsarchiv.	Führen Sie die Erkennung des gesamten Inventars, einschließlich Backups und archivierter Systeme, erneut durch, bevor Sie den alten Schlüssel außer Betrieb nehmen.
Zugriff auf einen legitimen Dienst verweigert.	Die Zugriffsrichtlinie für den neuen Schlüssel wurde nicht an die Berechtigungen des alten Schlüssels angepasst.	Ändern Sie die IAM- oder HSM-Zugriffsrichtlinie zwischen altem und neuem Schlüssel vor der Pilotphase.

Welche operativen Ergebnisse sollten Sie messen?

Verfolgen Sie diese Ergebnisse, um festzustellen, ob die Implementierung oder Rotation eines Verschlüsselungsalgorithmus tatsächlich erfolgreich war und nicht nur, dass sie abgeschlossen wurde:

• Keine ungeplanten Ausfallzeiten auf die Schlüsselrotation oder Algorithmusänderung zurückzuführen, gemessen an Ihrem Standard-Vorfallsverfolgungssystem.
• 100 Prozent des kryptografischen Inventars wurden migriert zum neuen Schlüssel oder Algorithmus innerhalb des geplanten Zeitrahmens, wobei keine verwaisten Systeme mehr den alten Schlüssel oder Algorithmus verwenden.
• Bestehensquote der Compliance-Prüfung für Kontrollen im Zusammenhang mit der Verwaltung von Verschlüsselungsschlüsseln (Schlüsselrotationsrhythmus, Zugriffsprotokollierung, Algorithmusgenehmigung), die durch den Prüfpfad ab dem Protokollierungsschritt belegt werden.
• Mittlere Rotationszeit Ein Schlüssel oder Algorithmus, der über mehrere Rotationen hinweg verfolgt wird, sollte mit zunehmender Reife des Runbooks tendenziell abnehmen.
• Null ausgemusterte Schlüssel, die später noch in Gebrauch waren. wird durch den Entdeckungsschritt vor jeder Stilllegung bestätigt.

Welcher Verschlüsselungsalgorithmus passt zu Ihrem Anwendungsfall?

Algorithmus	Typ	Typischer Anwendungsfall	Empfohlene Schlüsselgröße
AES-256	Symmetrisch	Ruhende Daten (Datenbanken, Festplatten, Backups), TLS-Massenverschlüsselung	256-Bit-Schlüssel
AES-128	Symmetrisch	Latenzempfindliche oder ressourcenbeschränkte Arbeitslasten	128-Bit-Schlüssel (256-Bit-Schlüssel für langlebige Daten bevorzugt)
RSA	Asymmetrisch	TLS-Schlüsselaustausch, Codesignierung, Zertifikatsausstellung	Für Neuinstallationen ist eine Mindestarchitektur von 3072 Bit erforderlich; aktuell gilt eine Mindestarchitektur von 2048 Bit.
ECC (ECDSA / ECDH)	Asymmetrisch	Modernes TLS, Zertifikatssignierung, mobile und IoT-Geräte	P-256 Basiswert, P-384 für eine höhere Sicherheitsmarge
ML-KEM (FIPS 203)	Post-Quanten-, asymmetrische Schlüsselkapselung	Frühe Pilotprojekte für quantenresistenten Schlüsselaustausch neben klassischen Algorithmen	ML-KEM-768 oder ML-KEM-1024, implementierungsabhängig
Dreifaches DES (3DES)	Symmetrisch, traditionell	Nicht für neue Verwendungszwecke; die NIST-Zulassung wurde mit Wirkung zum 1. Januar 2024 zurückgezogen.	Nicht verfügbar, Migration zu AES-256

Warum sollten Organisationsdaten verschlüsselt und entschlüsselt werden?

• Schützt die Vertraulichkeit der Daten.

  Im Falle eines Systemangriffs sind korrekt verschlüsselte Daten für den Angreifer ohne den entsprechenden Schlüssel unlesbar, was den Schaden des Angriffs auch nach einem unbefugten Zugriff begrenzt.

• Unterstützt die Überprüfung der Datenintegrität.

  Digitale Signaturen und Hash-Funktionen ermöglichen es Ihnen, zu bestätigen, dass Daten während der Übertragung oder Speicherung nicht verändert wurden, was durch Verschlüsselung allein nicht gewährleistet werden kann.

• Sichert die Netzwerkkommunikation.

  Verschlüsselte Kanäle (TLS, VPNs) verhindern, dass ein Angreifer den Netzwerkverkehr abfängt und die übertragenen Daten liest oder manipuliert, und blockieren so Man-in-the-Middle-Angriffe.

• Schützt personenbezogene Daten und Gesundheitsdaten.

  Durch die Verschlüsselung personenbezogener Daten und geschützter Gesundheitsdaten bleiben diese Daten auch dann unlesbar, wenn unbefugte Benutzer Zugriff erlangen. Dies unterstützt die Einhaltung von HIPAA, DSGVO und CCPA.

• Schützt geistiges Eigentum.

  Die Verschlüsselung von Quellcode, Forschungsdaten und geschützten Inhalten begrenzt das Risiko, falls Speichersysteme oder Transportsysteme kompromittiert werden.

Welche Einschränkungen weisen diese Verschlüsselungsalgorithmen auf?

Kein einzelner Algorithmus bietet allein eine vollständige Lösung. Berücksichtigen Sie diese Einschränkungen bei der Planung einer Implementierung:

• Asymmetrische Operationen sind in großem Umfang rechenaufwändig. RSA und, in geringerem Maße, ECC verursachen messbare CPU- und Latenzkosten pro Verbindung. Aus diesem Grund werden sie in Produktionssystemen eher mit symmetrischer Verschlüsselung kombiniert, als sie für große Datenmengen zu verwenden.
• Die Schlüsselverwaltung ist schwieriger als die Algorithmenauswahl. Ein korrekt gewählter Algorithmus, der durch ein schwaches Schlüsselmanagementverfahren geschützt ist (Schlüssel in der Quellcodeverwaltung, keine Rotation, breiter Zugriff), ist nicht wirklich sicher.
• RSA und ECC sind einer langfristigen Bedrohung durch Quantencomputer ausgesetzt. Ein kryptografisch relevanter Quantencomputer könnte beide Sicherheitslücken mithilfe von Shors Algorithmus knacken. Dies stellt für die meisten Organisationen kein unmittelbares operatives Risiko dar, doch Daten mit hohen Vertraulichkeitsanforderungen sind bereits heute der systematischen Erfassung und späteren Entschlüsselung ausgesetzt.
• Post-Quanten-Algorithmen befinden sich in der operativen Reifephase noch. FIPS 203, 204 und 205 sind finalisierte Standards, aber die Unterstützung von Bibliotheken, Hardwarebeschleunigung und Protokollintegration (hybride klassische/PQC-Handshakes) werden noch von allen Anbietern eingeführt.
• Implementierungsfehler untergraben starke Algorithmen. Schwache Padding-Verfahren, mangelhafte Zufallszahlengenerierung und Seitenkanalangriffe haben in der Praxis bereits zu Ausfällen ansonsten solider Algorithmen geführt; die Stärke eines Algorithmus hängt maßgeblich von seiner Implementierung ab.

Was würde Encryption Consulting empfehlen?

Beginnen Sie mit der kryptografischen Bestandsaufnahme. Sie können keinen Algorithmus für Daten, die Sie nicht identifiziert haben, korrekt auswählen, bereitstellen oder rotieren. CBOM Secure von Encryption Consulting ermittelt und inventarisiert die bereits in Ihrer Umgebung verwendeten Algorithmen, Schlüssel und Zertifikate. Dadurch wird die obige Entscheidungstabelle zu einem konkreten Migrationsplan und nicht nur zu einer allgemeinen Referenz.

Sobald Sie wissen, was Sie schützen möchten, sollten Sie die Schlüsselerzeugung und -speicherung in ein Hardware-Sicherheitsmodul auslagern, anstatt die Schlüsseldaten in der Anwendungskonfiguration zu belassen. HSM-as-a-Service bietet Ihnen FIPS-140-konforme Schlüsselspeicherung ohne die Investitionskosten und den Betriebsaufwand für den Betrieb eigener HSM-Hardware. Die Implementierungsschritte in diesem Leitfaden setzen voraus, dass Sie diese Infrastruktur bereits besitzen.

Für Organisationen, die Unterstützung bei der Erstellung des Runbooks, der Auswahl der passenden Schlüssellängen für spezifische Compliance-Anforderungen oder der Planung der Pilotphase bis zum vollständigen Rollout benötigen, arbeitet der Encryption Advisory Service von Encryption Consulting eng mit Ihrem Team zusammen, um einen auf Ihre Umgebung zugeschnittenen Implementierungsplan anstelle einer generischen Checkliste zu entwickeln. Encryption Consulting ist nach ISO/IEC 27001:2022 und SOC 2 zertifiziert. Die in diesem Leitfaden empfohlenen Kontrollmaßnahmen entsprechen daher auch unseren eigenen Standards.

Fazit

Die Wahl des Verschlüsselungsalgorithmus ist der einfache Teil: AES-256 für ruhende und übertragene Daten, RSA-3072 oder ECC P-384 für Schlüsselaustausch und Signaturen sowie ein dokumentierter Migrationspfad für alle verbleibenden Triple-DES-Algorithmen. Der schwierigere Teil, der letztendlich darüber entscheidet, ob die Daten Ihres Unternehmens geschützt bleiben, ist die operative Disziplin bei der Implementierung: eine kryptografische Bestandsaufnahme vor Beginn, ein stufenweiser Rollout mit Validierung in jedem Schritt, ein getesteter Rollback-Plan, ein Audit-Trail für jedes wichtige Ereignis und messbare Ergebnisse, die Sie nach jeder Rotation überprüfen. Behandeln Sie die Implementierung von Verschlüsselungsalgorithmen wie jede andere Produktionsänderung mit der gleichen Sorgfalt, und sie wird keine wiederkehrende Quelle für Ausfälle, Beanstandungen bei Audits und ungeplante Rollbacks sein.

Häufig gestellte Fragen

Welcher Verschlüsselungsalgorithmus bietet aktuell die höchste Sicherheit für Unternehmensdaten? Für symmetrische Verschlüsselung gilt AES-256 als Standard für sensible Unternehmensdaten. Für asymmetrische Verschlüsselung werden RSA-3072 oder ECC P-384 für neue Implementierungen empfohlen. Es gibt keinen Algorithmus, der unabhängig vom Anwendungsfall universell „am sichersten“ ist. In Produktionssystemen wird üblicherweise die Kombination von AES für große Datenmengen mit RSA oder ECC für den Schlüsselaustausch und die Signaturerstellung eingesetzt.

Sollten wir auf RSA-3072 umsteigen, wenn wir derzeit RSA-2048 verwenden? RSA-2048 gilt gemäß den aktuellen NIST-Richtlinien weiterhin als Mindeststandard, daher besteht keine Dringlichkeit für einen sofortigen Wechsel. Für neue Systeme und Daten mit hohen Vertraulichkeitsanforderungen empfiehlt sich die Implementierung von RSA-3072 oder der Wechsel zu ECC P-256/P-384, welches eine gleichwertige oder höhere Sicherheit bei kürzerer Schlüssellänge und geringeren Kosten für den Handshake bietet.

Müssen wir uns jetzt schon mit Post-Quanten-Kryptographie auseinandersetzen? Das NIST hat seine ersten drei Post-Quanten-Standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA), im August 2024 finalisiert. Die meisten Organisationen müssen ihre Produktionssysteme heute noch nicht auf PQC-Algorithmen umstellen. Da Daten mit mehrjährigen Vertraulichkeitsanforderungen jedoch bereits jetzt der Gefahr des Sammelns und späteren Entschlüsselns ausgesetzt sind, lohnt es sich, jetzt mit dem Aufbau eines kryptografischen Inventars und eines Plans zur Krypto-Agilität zu beginnen, selbst wenn der Algorithmuswechsel selbst erst später erfolgt.

Wie oft sollten Verschlüsselungsschlüssel gewechselt werden? Die Wechselhäufigkeit hängt von der Funktion des Schlüssels, den geschützten Daten und Ihren Compliance-Anforderungen ab; es gibt kein allgemeingültiges Intervall. Wichtiger als die genaue Häufigkeit ist, dass der Wechsel stets einem dokumentierten und getesteten Ablaufplan folgt (Voraussetzungen, schrittweise Einführung, Validierung, Rücksetzung) und nicht einem Ad-hoc-Prozess, der je nach Ausführendem variiert.

Können wir während einer Migration verschiedene Verschlüsselungsalgorithmen in unserer Umgebung mischen? Ja, und in der Praxis ist dies sogar notwendig. Bei einer stufenweisen Einführung existieren alte und neue Algorithmen für einen bestimmten Zeitraum parallel, während die Anwender migrieren. Die in diesem Leitfaden beschriebene Voraussetzung für die Schlüsselverwaltungsinfrastruktur (ein HSM oder KMS mit eindeutigen Schlüssel-IDs) gewährleistet diesen sicheren Betrieb und ermöglicht bei Bedarf ein einfaches Rollback.

Referenzen

• NIST, FIPS 197, Advanced Encryption Standard (AES)
• NIST, SP 800-57 Teil 1 Revision 5, Empfehlung für das Schlüsselmanagement
• NIST, SP 800-131A Revision 2, Übergang bei der Verwendung kryptografischer Algorithmen und Schlüssellängen
• NIST, NIST zieht Sonderveröffentlichung 800-67 Revision 2 (Triple DES) zurück
• NIST, NIST veröffentlicht die ersten drei finalisierten Post-Quanten-Verschlüsselungsstandards (FIPS 203, 204, 205).