Warum 3DES oder Triple DES offiziell eingestellt wird

Veröffentlicht: März 2022. Aktualisiert: August 2026. Geprüft vom Verschlüsselungsberatungsteam von Encryption Consulting.

3DES, auch Triple DES oder TDEA (Triple Data Encryption Algorithm) genannt, ist ein symmetrischer Blockchiffre, der durch dreimaliges Ausführen des ursprünglichen DES- Algorithmus pro Datenblock mit zwei oder drei Schlüsseln entsteht. Das NIST führte ihn in den 1990er-Jahren als Übergangslösung ein, nachdem sich der 56-Bit-Schlüssel von DES als zu kurz erwiesen hatte. Banken, Zahlungsnetzwerke und Regierungssysteme setzten ihn daraufhin flächendeckend für ruhende und übertragene Daten ein. Diese Übergangslösung hat nun ausgedient. Die vom NIST veröffentlichten Richtlinien untersagen die Verwendung von 3DES für jegliche neue Verschlüsselung, und unabhängige Kryptoanalysen lieferten der Branche Jahre vor Ablauf der Frist einen konkreten, praktischen Grund, die Nutzung einzustellen.

Warum wird 3DES eingestellt?

3DES wird eingestellt, da seine 64-Bit-Blockgröße bei modernen Datenmengen keine ausreichende Sicherheitsmarge mehr bietet. Dies hat das NIST schriftlich bestätigt. NIST SP 800-131A Revision 2 legt fest, dass die Verschlüsselung mit Drei-Schlüssel-TDEA bis zum 31. Dezember 2023 als veraltet gilt und danach für neue Anwendungen nicht mehr zulässig ist. Die Zwei-Schlüssel-TDEA-Verschlüsselung war bereits zuvor nicht mehr zulässig. Das NIST bekräftigte dies 2023 mit einer formellen Mitteilung, dass es SP 800-67 Revision 2 , die Spezifikation, die TDEA selbst definiert, mit Wirkung zum 1. Januar 2024 zurückziehen wird. Nach diesem Datum ist TDEA kein zugelassener Blockchiffre mehr zum Schutz neuer Daten. Er ist nur noch für die Entschlüsselung, das Entpacken des Schlüssels und die MAC-Verifizierung von Daten zulässig, die bereits vor dem Stichtag geschützt wurden.

Die Rücknahme der Regelung kam nicht überraschend. Das NIST hatte die Abschaffung bereits am 19. Juli 2018 in einem Entwurf angekündigt und Anbietern und Unternehmen damit rund fünf Jahre Vorlaufzeit eingeräumt, bevor die Regelung in Kraft trat. Der Zeitraum zwischen dem Entwurf von 2018 und dem Inkrafttreten der Regelung zwischen 2023 und 2024 gab der Branche Zeit für die Migration. Wie die folgenden Implementierungsbeispiele zeigen, haben jedoch viele ältere Systeme diese Frist verpasst.

Worin unterscheidet sich 3DES vom ursprünglichen DES?

DES ist ein symmetrischer Verschlüsselungsalgorithmus mit einem einzigen 56-Bit-Schlüssel, der vor Jahrzehnten durch Brute-Force-Hardware überholt wurde. 3DES wurde entwickelt, um die Nutzungsdauer von DES zu verlängern, ohne die Hardware zu verändern. Dazu wird der gleiche DES-Algorithmus in drei Durchläufen ausgeführt: typischerweise Verschlüsselung mit Schlüssel 1, Entschlüsselung mit Schlüssel 2 und anschließende erneute Verschlüsselung mit Schlüssel 3 (die sogenannte „EDE“-Konstruktion). Mit drei wirklich unabhängigen Schlüsseln ergibt sich so eine effektive Schlüsselstärke von etwa 112 Bit anstelle der theoretischen 168 Bit. Grund dafür ist die bekannte Reduzierung der Schlüsselstärke durch einen sogenannten „Meet-in-the-Middle“-Effekt bei dreifacher Verschlüsselung. Diese zusätzliche Schlüsselstärke sicherte 3DES weitere zwei Jahrzehnte Einsatzzeit, die zugrundeliegende Blockgröße von 64 Bit blieb jedoch unverändert. Genau diese Blockgröße führte schließlich zu den Nachteilen von 3DES.

Was ist die Sweet32-Sicherheitslücke?

Sweet32 ist ein Angriff, der auf Kollisionen mit Geburtstagszahlen basiert und unter CVE-2016-2183 für TLS und CVE-2016-6329 für OpenVPN geführt wird. Er ermöglicht es Angreifern, Klartext von beliebigen 64-Bit-Blockchiffren, einschließlich 3DES und Blowfish, wiederherzustellen, sobald genügend Daten mit einem einzigen Schlüssel verschlüsselt wurden. Die Forscher Karthikeyan Bhargavan und Gaetan Leurent vom INRIA veröffentlichten den Angriff auf der ACM CCS 2016 und dokumentierten ihn auf sweet32.info.

Der Mechanismus ist eine direkte Anwendung des Geburtstagproblems auf die Ausgabe von Blockchiffren. Bei einem 64-Bit-Block kann ein Angreifer, der etwa 2^32 Blöcke (ca. 32 GB) verschlüsselten Text mit einem Schlüssel beobachten kann, Blockkollisionen feststellen. Diese Kollisionen geben über eine XOR-Verknüpfung der kollidierenden Blöcke Informationen über den zugrundeliegenden Klartext preis. Im Proof-of-Concept der Forscher gegen HTTPS konnte ein Angreifer, der bösartigen JavaScript-Code in den Browser eines Opfers einschleusen konnte, um dauerhaften verschlüsselten Datenverkehr zu erzeugen, nach dem Sammeln von etwa 785 GB Daten einen 16 Byte großen Authentifizierungs-Cookie wiederherstellen – eine Menge, die über eine Verbindung, die weniger als zwei Tage lang offen blieb, durchaus realisierbar ist. Der 128-Bit-Block von AES führt zu einer so weit außerhalb der praktischen Reichweite liegenden Grenze für das Geburtstagproblem (etwa 2^64 Blöcke), dass derselbe Angriff nicht anwendbar ist.

Sweet32 ist für den Zeitplan der Abschaffung relevant, da es eine abstrakte, langfristige kryptografische Schwachstelle in einen nachweisbaren, reproduzierbaren Angriff auf reale Protokolle verwandelt hat. Es ist der praktische Beweis für die von NIST festgelegte Frist zur Einhaltung der Vorschriften und keine separate, unabhängige Erkenntnis.

Wie wählt man einen Ersatzalgorithmus aus?

Für nahezu jeden Anwendungsfall, in dem derzeit 3DES zum Einsatz kommt, ist AES-256 der direkte Ersatz. Die Wahl des Algorithmus richtet sich nach dem Datenzustand und dem Protokoll und nicht nach Gewohnheit.

• Datenübertragung (TLS, VPN-Tunnel, Messaging): Verwenden Sie AES-256-GCM, einen authentifizierten Verschlüsselungsmodus, der Vertraulichkeit und Integrität gleichermaßen gewährleistet. Er ist die Standardempfehlung in TLS 1.2 und die einzige universelle AEAD-Familie, die in TLS 1.3 übernommen wurde.
• Ruhende Daten (Festplatten, Datenbanken, Backups): Verwenden Sie AES-256 im XTS-Modus, der speziell für die Blockspeicherverschlüsselung entwickelt wurde, oder AES-256-GCM, wenn eine authentifizierte Verschlüsselung einzelner Datensätze erforderlich ist.
• Reine Softwareumgebungen ohne AES-NI: Wir verwenden ChaCha20-Poly1305, eine AEAD-Verschlüsselung, die in reiner Software gut funktioniert und keinen dedizierten Hardware-Befehlssatz benötigt, was sie zu einer vernünftigen Alternative auf älteren oder leistungsschwächeren CPUs macht.
• Zahlungskarten- und Tokenisierungssysteme, die eine feste Feldlänge oder ein festes Feldformat beibehalten müssen: Evaluieren Sie eine vom NIST zugelassene formatbewahrende Verschlüsselung (FF1 oder FF3-1), anstatt anzunehmen, dass das Blockverhalten von 3DES durch AES ersetzt werden kann, ohne das umgebende Datenformat zu verändern.

Vermeiden Sie die standardmäßige Auswahl eines Modus. AES im ECB-Modus gibt Muster im Klartext preis und sollte daher niemals verwendet werden. AES-CBC benötigt einen separaten Message Authentication Code (MAC), um Padding-Oracle-Angriffe (Lucky 13, POODLE) zu verhindern, die in der Vergangenheit CBC-basierte TLS-Verschlüsselungen kompromittiert haben. GCM und XTS existieren speziell, damit Implementierer diesen Schutz nicht manuell implementieren müssen.

Welches realweltliche Bedrohungsmodell gibt es heute für 3DES?

Das praktische Risiko, das von der fortgesetzten Verwendung von 3DES ausgeht, hängt stark davon ab, wie die Verschlüsselung eingesetzt wird, und nicht nur von der Tatsache, dass sie als veraltet gilt.

• Verbindungen mit hohem Volumen, langer Lebensdauer, die im Netzwerk beobachtbar sind (Eine TLS-Sitzung oder ein VPN-Tunnel, der offen bleibt und Dutzende von Gigabytes unter einem Schlüssel überträgt) sind das Szenario, das Sweet32 tatsächlich anvisiert, und das Szenario, bei dem 3DES heute ein nachweislich ausnutzbares Risiko darstellt.
• Anwendungen mit geringem Datenvolumen, Offline-Betrieb oder abgeschottete Systeme (Eine einzelne verschlüsselte Datei, ein Batch-Export, eine isolierte Legacy-Schnittstelle ohne vom Angreifer kontrollierte Datenverkehrserzeugung) erreichen in der Praxis bei weitem nicht die Geburtstagsgrenze, weshalb das NIST weiterhin die Legacy-Entschlüsselung zulässt, anstatt die sofortige Neuverschlüsselung jedes historischen 3DES-Artefakts vorzuschreiben.
• Das Compliance-Risiko besteht unabhängig vom Verkehrsaufkommen. Prüfer, die anhand der PCI DSS-, FIPS 140-3-Validierung oder einer NIST-konformen internen Richtlinie prüfen, werden jede 3DES-Verschlüsselung neuer Daten nach dem 31. Dezember 2023 als nicht konform kennzeichnen, unabhängig davon, ob Sweet32 in der konkreten Implementierung praktisch ausnutzbar ist.

Das ehrliche Bedrohungsmodell beruht somit auf zwei unterschiedlichen Faktoren, die zum selben Schluss führen: einem kryptanalytischen Faktor (Sweet32, besonders anfällig für Protokolle mit hohem Datenaufkommen) und einem Compliance-Faktor (das NIST-Verbot, das einheitlich gilt). Jeder Faktor allein rechtfertigt eine Migration; zusammen entkräften sie jedoch jeglichen Grund, 3DES in neuen Designs beizubehalten.

Wie migriert man von 3DES zu AES?

Die Migration von 3DES zu AES ist eher ein Problem der Reihenfolge als der Codierung. Die folgenden Schritte gewährleisten, dass die Interoperabilität während des Projekts nicht beeinträchtigt wird.

1. Bei jeder 3DES-Nutzung ein Inventar erstellen. Suchen Sie nach 3DES in der TLS-Verschlüsselungssuite-Konfiguration, VPN-Richtlinien, Datenbank- und Dateiverschlüsselungseinstellungen, HSM-Schlüsselzeremonien und Anwendungscode, einschließlich herstellerspezifischer und Firmware-Komponenten, die es möglicherweise fest codiert haben. Ein kryptografisches Erkennungstool wie CBOM Secure findet diese Instanzen in Code, Zertifikaten und Schlüsselspeichern, anstatt auf manuelle Prüfungen angewiesen zu sein.
2. Klassifizieren Sie jede Nutzung nach Datensensibilität, Protokoll und Gegenpartei. Ein TLS-Listener, den Sie von Anfang bis Ende kontrollieren, wird anders migriert als eine Zahlungsnetzwerkschnittstelle, bei der auch die Gegenpartei umziehen muss.
3. Wählen Sie für jede Anwendung den AES-Modus und die Schlüssellänge aus. unter Verwendung der oben genannten Richtlinien (GCM für Transit, XTS für Ruhe, ChaCha20-Poly1305, wo AES-NI nicht verfügbar ist).
4. Testen Sie die Interoperabilität mit jedem Vertragspartner und Kunden. Das System muss auch die neue Verschlüsselung unterstützen, einschließlich älterer TLS-Clients, veralteter HSM-Firmware und Drittanbieterintegrationen, die möglicherweise zuerst selbst ein Upgrade benötigen.
5. Führen Sie ein Übergangsfenster mit doppelter Unterstützung durch. Wenn sowohl 3DES als auch AES angeboten werden, wird standardmäßig AES verwendet, damit nicht migrierte Gegenparteien in den Protokollen sichtbar sind, bevor Sie die Umstellung erzwingen.
6. Nachgelagerte Systeme neu verschlüsseln und neue AES-Schlüssel generieren unter ordnungsgemäßen Schlüsselverwaltungsmechanismen und nicht durch Ableitung aus dem alten 3DES-Schlüsselmaterial.
7. 3DES durch neue Verschlüsselungsmethoden ersetzen sobald das Dual-Support-Fenster keine verbleibenden AES-unfähigen Clients mehr anzeigt, während gleichzeitig die Möglichkeit erhalten bleibt, ältere 3DES-geschützte Daten zu entschlüsseln, wie es die NIST-Richtlinien weiterhin zulassen.
8. Dokumentieren Sie die Änderung als Nachweis der Einhaltung.Da die Prüfer einen datierten Nachweis verlangen werden, dass die neue Verschlüsselung bis zum jeweiligen Stichtag nicht mehr auf 3DES setzt.

Kompromisse zwischen Leistung und Interoperabilität mit Altsystemen

3DES war bereits vor seiner Abschaffung die langsamere Option, da der DES-Algorithmus dreimal pro Block vollständig ausgeführt wird. AES ist auf nahezu allen modernen Hardwarekomponenten schneller, insbesondere mit AES-NI, dem dedizierten CPU-Befehlssatz, der seit Anfang der 2010er-Jahre in praktisch jedem Server- und Desktop-Prozessor vorhanden ist und die AES-Verschlüsselung und -Entschlüsselung in Hardware beschleunigt. Wo AES-NI nicht verfügbar ist, wie beispielsweise bei einigen eingebetteten Controllern und älteren Mikrocontrollern, ist ChaCha20-Poly1305 in der Regel die schnellere, rein softwarebasierte Alternative zu beiden Verschlüsselungsverfahren.

Die Performance ist selten der schwierigste Teil einer 3DES-Migration; die Interoperabilität mit älterer Hardware hingegen schon. Kassenterminals und Geldautomatennetze werden häufig anhand einer bestimmten Liste von Verschlüsselungsalgorithmen zertifiziert, manchmal in Verbindung mit einer PCI-PTS-Gerätezulassung, die 3DES DUKPT (Derived Unique Key Per Transaction) explizit vorschreibt. Mainframe-Anwendungen und ältere HSM-Firmware stellen AES-Modi möglicherweise nicht über ihre bestehende API bereit, ohne dass ein Firmware- oder Software-Upgrade erforderlich ist, das der Hersteller für ausgemusterte Hardware nicht mehr priorisiert. Feldgeräte, industrielle Steuerungssysteme und einige IoT-Geräte wurden mit in die Firmware integrierter 3DES-Verschlüsselung entwickelt, die nicht per Fernzugriff aktualisiert werden kann. In all diesen Fällen hängt die Entscheidung für einen Algorithmus von der Entscheidung für Hardware und Herstellersupport ab. Daher dauern Migrationen für ältere Systeme typischerweise Jahre, nicht Wochen.

Welche Abhängigkeiten bestehen hinsichtlich des Schlüsselmanagements während der Migration?

Die Abschaffung von 3DES betrifft eher das Schlüsselmanagement als den Verschlüsselungsalgorithmus selbst, und genau diesen Aspekt unterschätzen Organisationen in der Regel.

• Neugestaltung der Schlüsselhierarchie: 3DES-Implementierungen, insbesondere in Zahlungsnetzwerken, verwenden üblicherweise doppelt oder dreifach lange Schlüsselbündel mit Prüfschlüsseln (KCVs) zur Verifizierung. AES-Schlüssel sind einzelne Werte fester Länge. Daher müssen die zugehörige Schlüsselhierarchie, das Speicherformat und die auf 3DES-Schlüsselbündeln basierenden Verifizierungswerkzeuge neu konzipiert und nicht nur neu befüllt werden.
• Wichtige Zeremonien der High School: Wo 3DES-Schlüssel durch formelle, bezeugte Schlüsselzeremonien generiert und injiziert wurden, benötigen die AES-Ersatzschlüssel typischerweise eine gleichwertige Zeremonie, insbesondere in PCI- oder FIPS 140-3-regulierten Umgebungen, in denen der Nachweis der Schlüsselverwahrung eine Prüfungsanforderung ist.
• PIN-Block- und Kartendatenformate: Zahlungssysteme, die auf dem ISO 9564 PIN-Blockformat basieren und DES/3DES-Operationen nutzen (einschließlich der PIN-Übersetzung zwischen Acquirer und Issuer), erfordern eine sorgfältige Formatzuordnung, wenn sich die zugrunde liegende Verschlüsselung ändert, da nicht nur die Verschlüsselung, sondern auch das PIN-Blockformat selbst Teil des Interoperabilitätsvertrags zwischen den Parteien ist.
• Kontinuität der wichtigsten Sorgerechtsfragen: Die Außerbetriebnahme alter 3DES-Schlüssel darf erst erfolgen, wenn für jedes System, das noch ältere, 3DES-geschützte Daten entschlüsseln muss, ein dokumentierter und getesteter Weg zur Verfügung steht. Die fortgesetzte Zulassung der Entschlüsselung älterer Daten durch das NIST beruht gerade darauf, dass historische Daten mit dem Datum der Außerbetriebnahme nicht verloren gehen.
• Krypto-Agilität für den nächsten Übergang: Organisationen, die dies als einmalige Umstellung von 3DES auf AES betrachten, kehren oft zu derselben Starrheit zurück, die die 3DES-Migration so schwierig gemacht hat. Die Entwicklung der neuen Schlüsselarchitektur unter Berücksichtigung des aktuellen und zukünftigen Übergangs nach der Quantentechnologie vermeidet eine Wiederholung dieses Projekts in wenigen Jahren.

3DES vs. AES-256: Direkter Vergleich

Eigenschaft	3DES (Three-Key TDEA)	AES-256
Schlüsselgröße	168 Bit nominal, etwa 112 Bit effektiv	256 Bits
Block Größe	64 Bits	128 Bits
Sicherheitsmarge	Anfällig für Geburtstagskonflikte (Sweet32) um etwa 2^32 Blöcke (ca. 32 GB) unter einem Schlüssel	Geburtstagsgrenze etwa 2^64 Blöcke; praktisch nicht erreichbar
Leistung	Langsam; drei aufeinanderfolgende DES-Durchläufe pro Block, keine dedizierte Hardwarebeschleunigung	Schnell; hardwarebeschleunigt durch AES-NI auf modernen CPUs
Aktueller NIST-Status	Für neue Verschlüsselung nach dem 31. Dezember 2023 nicht mehr zulässig (SP 800-131A Rev. 2); SP 800-67 Rev. 2 wurde am 1. Januar 2024 zurückgezogen; die Entschlüsselung älterer Systeme ist weiterhin möglich.	Genehmigt (FIPS 197); die Standardempfehlung für neue symmetrische Verschlüsselung

Wo wird 3DES heute noch eingesetzt?

3DES ist nicht aus Produktionsumgebungen verschwunden, nur weil es verboten wurde. Es taucht nach wie vor am häufigsten in folgenden Bereichen auf:

• Zahlungsterminals und Geldautomatennetze Die PIN-Verschlüsselung erfolgt mit 3DES DUKPT, oft weil die Hardware des physischen Terminals vor Jahren anhand einer festen Liste von Verschlüsselungsverfahren zertifiziert wurde und seitdem nicht ersetzt wurde.
• Mainframe-Anwendungen wo 3DES vor Jahrzehnten in COBOL oder ähnliche Legacy-Anwendungscodes fest einprogrammiert wurde und nie überarbeitet wurde, weil die Anwendung immer noch funktioniert.
• Ältere HSMs und Schlüsselverwaltungssysteme Die Anwendung verwendet Firmware-Versionen, die vor der Unterstützung von AES in der spezifischen API, die sie aufruft, entwickelt wurden, selbst wenn die HSM-Hardware selbst AES unterstützt.
• Legacy-VPN- und IPsec-Gateways konfiguriert mit 3DES-Verschlüsselungssuiten, die nach der ersten Bereitstellung nie aktualisiert wurden, was häufig erst bei einer Sicherheitsbewertung oder einem Penetrationstest entdeckt wird.
• Eingebettete und industrielle Steuerungssystemgeräte bei einer Firmware, die nicht per Fernzugriff aktualisiert werden kann, wobei der Austausch des Verschlüsselungsalgorithmus den Austausch des physischen Geräts erfordert.

Alle diese Kategorien haben eine Gemeinsamkeit: Das Hindernis für die Migration ist selten der AES-Algorithmus selbst, sondern die damit verbundenen Einschränkungen in Hardware, Firmware oder Herstellerunterstützung.

Einschränkungen

Diese Anleitung beschreibt die Veröffentlichungen des NIST und die Ergebnisse der Sweet32-Studie; sie ersetzt keine spezifische Konformitätsprüfung für Ihre Umgebung. Einige Grenzwerte sollten explizit genannt werden:

• Die NIST-Richtlinien regeln die Systeme der US-Bundesregierung und werden in der Privatwirtschaft weithin als Maßstab übernommen. Organisationen, die anderen Regulierungsrahmen unterliegen (PCI-DSS-Richtlinien, regionales Datenschutzrecht, branchenspezifische Vorgaben), sollten jedoch ihre eigenen geltenden Fristen überprüfen, anstatt davon auszugehen, dass die NIST-Termine wortwörtlich gelten.
• Die praktischen Auswirkungen von Sweet32 hängen vom Datenverkehrsaufkommen und der Verbindungslebensdauer ab, wie im Abschnitt zum Bedrohungsmodell beschrieben; es ist kein Beweis dafür, dass jede 3DES-Implementierung heute aktiv ausgenutzt wird, sondern nur, dass der Angriff demonstriert und unter realistischen Bedingungen reproduzierbar ist.
• Die Entschlüsselung von zuvor mit 3DES verschlüsselten Daten ist nach den aktuellen NIST-Richtlinien weiterhin zulässig, diese Regelung ist jedoch nicht unbegrenzt. NIST kann diese Position in zukünftigen Veröffentlichungen überarbeiten, daher sollten Organisationen mit großen Mengen an älteren, mit 3DES verschlüsselten Daten die derzeitige Ausnahme nicht als dauerhaft betrachten.
• Die Hardware- und Firmware-Beschränkungen älterer Systeme sind stark hersteller- und gerätespezifisch; die oben genannten Einsatzbeispiele sind gängige Muster und keine vollständige Liste aller Umgebungen, in denen 3DES noch anzutreffen sein kann.

Was würde Encryption Consulting empfehlen?

Beginnen Sie mit der Ermittlung, nicht mit einem Verschlüsselungsaustausch. Die meisten Organisationen, die sich mit einer Frage zu 3DES an uns wenden, wissen gar nicht, wie viele Systeme diesen Algorithmus noch verwenden. Unsere kryptografische Bestandsaufnahme, die CBOM Secure automatisiert , durchsucht Code-Repositories, Zertifikatsspeicher, HSMs und Netzwerkkonfigurationen, um eine fundierte Liste der Systeme zu erstellen, die 3DES (und alle anderen veralteten Algorithmen) noch einsetzen. Wir verlassen uns dabei nicht auf die Konfigurationen, an die sich das Team vor fünf Jahren erinnert.

Wir betrachten die Migration daher als einen Prozess der Krypto-Agilität und nicht als einmalige Problemlösung. Organisationen, die mit der Abschaffung von 3DES am meisten zu kämpfen haben, sind diejenigen, die Algorithmen fest in Anwendungen, Firmware und Schlüsselhierarchien verankert haben – ohne Abstraktionsschicht für einen späteren Austausch. Genau diese Starrheit wird den nächsten Übergang zu Post-Quanten-Algorithmen genauso schwierig gestalten, wenn wir nicht jetzt handeln. Unser Ansatz für Krypto-Agilität und unsere Beratungsleistungen im Bereich Verschlüsselung zielen darauf ab, diese Ursache zu beheben: Zuerst eine Bestandsaufnahme, dann ein priorisierter Migrationsplan, geordnet nach Risiko (beginnend mit netzwerkexponierten 3DES-Anwendungen mit hohem Datenaufkommen, bei denen Sweet32 ein aktuelles Problem darstellt), und schließlich eine Schlüsselmanagement-Architektur, die den nächsten Algorithmuswechsel ohne erneute mehrjährige Krisenreaktion bewältigen kann.

Fazit

Die Abschaffung von 3DES ist kein zukünftiges Ereignis, sondern bereits vollzogen. Das NIST hat die Entwicklung neuer 3DES-Verschlüsselungen nach dem 31. Dezember 2023 untersagt und die zugehörige Spezifikation am 1. Januar 2024 zurückgezogen. Dies geschah nach fast einem Jahrzehnt kryptanalytischen Drucks, der im erfolgreichen Sweet32-Angriff gipfelte. AES-256 ist der direkte und gut unterstützte Ersatz für praktisch alle Anwendungsfälle, die 3DES je abgedeckt hat. Die verbleibende Herausforderung besteht nicht in der Auswahl eines Algorithmus, sondern darin, alle Systeme zu finden, die noch den alten Algorithmus verwenden, und die damit verbundenen Schlüsselverwaltungsstrukturen zu entschlüsseln. Beginnen Sie mit einer ehrlichen Bestandsaufnahme, priorisieren Sie die Migration anhand der Systeme, bei denen das Bedrohungsmodell von Sweet32 realistisch ist, und entwickeln Sie den Ersatz so, dass der nächste Algorithmuswechsel nicht denselben Aufwand erfordert.

Häufig gestellte Fragen

Wann genau hat das NIST 3DES verboten?
NIST SP 800-131A Revision 2 hat die Verwendung der Drei-Schlüssel-TDEA-Verschlüsselung (3DES) für neue Anwendungen bis zum 31. Dezember 2023 als veraltet erklärt und sie danach untersagt. NIST bekräftigte dies durch die formelle Rücknahme von SP 800-67 Revision 2, der Spezifikation, die TDEA definiert, mit Wirkung zum 1. Januar 2024. Nach diesem Datum ist 3DES kein zugelassenes Verschlüsselungsverfahren mehr, die Entschlüsselung bereits damit geschützter Daten ist jedoch weiterhin möglich.

Was ist Sweet32 und hat es Auswirkungen auf jede 3DES-Anwendung?
Sweet32 (CVE-2016-2183 für TLS, CVE-2016-6329 für OpenVPN) ist ein Angriff, der auf Kollisionen durch den Geburtstag des Angreifers bei 64-Bit-Blockchiffren basiert und von Bhargavan und Leurent auf der ACM CCS 2016 veröffentlicht wurde. Er eignet sich besonders für Verbindungen mit hohem Datenaufkommen, langer Laufzeit und Netzwerküberwachung, die Dutzende von Gigabytes mit einem einzigen Schlüssel verschlüsseln, wie beispielsweise eine TLS-Sitzung, die lange genug offen bleibt, damit ein Angreifer diese Datenmenge generieren kann. Bei geringem Datenaufkommen oder Offline-Nutzung von 3DES liegt die für den Angriff erforderliche Datenmenge deutlich unter dem Schwellenwert. Die Verbotsrichtlinie des NIST gilt jedoch für neue Verschlüsselungsalgorithmen unabhängig vom Datenaufkommen.

Kann man 3DES noch zur Entschlüsselung alter Daten verwenden?
Ja. Die aktuellen NIST-Richtlinien erlauben die Verwendung von 3DES zur Entschlüsselung, zum Schlüssel-Unwrapping und zur Überprüfung von Message Authentication Codes (MACs) für Daten, die bereits vor Inkrafttreten des Verbots geschützt waren. Verboten ist lediglich die zukünftige Anwendung neuer 3DES-Verschlüsselung, nicht aber der Zugriff auf bereits damit verschlüsselte historische Daten.

Was sollte 3DES ersetzen?
AES-256 ist der Standardersatz: AES-256-GCM für Daten während der Übertragung und für Datensätze, die eine authentifizierte Verschlüsselung erfordern, AES-256-XTS für die Blockspeicherverschlüsselung. Wo keine AES-NI-Hardwarebeschleunigung verfügbar ist, stellt ChaCha20-Poly1305 eine starke, rein softwarebasierte Alternative dar. Formatbewahrende Verschlüsselung (FF1 oder FF3-1) ist die Option, die sich eignet, wenn ein Zahlungs- oder Tokenisierungssystem eine feste Feldlänge oder ein festes Format beibehalten muss.

Was ist die größte Herausforderung bei der Migration von Legacy-Zahlungssystemen oder Mainframe-Systemen von 3DES?
Das Schlüsselmanagement, nicht der Algorithmuswechsel selbst, ist entscheidend. Insbesondere Zahlungsnetzwerke haben Schlüsselhierarchien, HSM-Schlüsselzeremonien und PIN-Blockformate auf Basis der doppelten und dreifachen Schlüsselstrukturen von 3DES entwickelt. Diese müssen neu gestaltet und nicht einfach ersetzt werden. Hardwarebeschränkungen, zertifizierte Kassenterminals, ältere HSM-Firmware und nicht aktualisierbare eingebettete Geräte stellen in der Regel die zweitgrößte Herausforderung dar. Daher dauern Migrationen von Legacy-Systemen typischerweise Jahre und nicht nur einen einzigen Projektsprint.

Referenzen

• NIST SP 800-131A Revision 2, Übergang bei der Verwendung kryptografischer Algorithmen und Schlüssellängen
• NIST CSRC: NIST zieht Sonderveröffentlichung 800-67 Revision 2 (2023) zurück
• NIST SP 800-67 Revision 2 (zurückgezogen), Empfehlung für den Triple Data Encryption Algorithm (TDEA) Blockchiffre
• Sweet32: Geburtstagsangriffe auf 64-Bit-Blockchiffren in TLS und OpenVPN, Bhargavan und Leurent, ACM CCS 2016
• CVE-2016-2183, Nationale Schwachstellendatenbank