Welche Herausforderungen gibt es bei der symmetrischen Kryptografie?

Veröffentlicht: Dezember 2022. Aktualisiert: August 2026. Geprüft vom HSM- und Schlüsselmanagement-Beratungsteam von Encryption Consulting.

Einführung

Symmetrische Kryptographie verwendet einen gemeinsamen geheimen Schlüssel zum Ver- und Entschlüsseln von Daten und wird daher auch als Kryptographie mit geheimem Schlüssel bezeichnet . Die algorithmische Seite ist weitgehend geklärt: AES-256 ist praktisch nicht kryptanalytisch angreifbar und auch ein Quantencomputer kann keinen solchen Angriff ausführen. Grovers Algorithmus halbiert die effektive Sicherheitsmarge lediglich, sodass immer noch robuste 128 Bit verbleiben. Die operative Seite bereitet der symmetrischen Kryptographie jedoch Schwierigkeiten. Jede Organisation, die sie einsetzt – vom Datenbankadministrator, der einen Tabellenschlüssel rotiert, bis hin zur Bank, die Millionen von Kassenterminals verwaltet –, stößt auf dieselben vier Probleme: den geheimen Schlüssel an die richtige Stelle weiterzugeben, ohne ihn preiszugeben; diesen geheimen Schlüssel in großem Umfang zu verfolgen; den Schaden bei einem Schlüsselleck zu begrenzen; und nachzuweisen, wer die Verschlüsselung tatsächlich durchgeführt hat. Dieser Leitfaden behandelt jede Herausforderung, nutzt die Zahlungs- und Bankenbranche als anschaulichstes Beispiel aus der Praxis (da Zahlungs-HSMs und Schlüsselblockstandards speziell zur Lösung dieser Probleme entwickelt wurden) und schließt mit der Darstellung, wie ein verteidigungsfähiges symmetrisches Schlüsselmanagementprogramm in der Praxis aussieht.

Was sind die zentralen operativen Herausforderungen der symmetrischen Kryptographie?

Die operativen Herausforderungen der symmetrischen Kryptographie lassen sich in vier Kategorien einteilen: die sichere Übermittlung des Schlüssels an beide Parteien, die Verwaltung dieses Schlüssels in großem Umfang, die Kontrolle der Folgen einer Schlüsselkompromittierung und die Tatsache, dass ein gemeinsames Geheimnis allein keine Identität beweisen kann. Keine dieser Herausforderungen lässt sich durch die Wahl eines stärkeren Verschlüsselungsverfahrens lösen; vielmehr liegt die Lösung in der Art und Weise, wie der Schlüssel generiert, verteilt, gespeichert, rotiert und außer Betrieb genommen wird.

Das Problem der Schlüsselverteilung. Bevor zwei Parteien Daten symmetrisch austauschen können, benötigen sie beide denselben geheimen Schlüssel. Dieser Schlüssel muss unabgefangen von einer Partei zur anderen übertragen werden. Ihn unverschlüsselt zu senden, ist kontraproduktiv, und die manuelle Übertragung ist für weniger Verbindungen nicht praktikabel. Aus diesem Grund verwenden nahezu alle Produktionssysteme – TLS, SSH, IPsec – asymmetrische Kryptografie, um den symmetrischen Sitzungsschlüssel zu generieren, anstatt die Verteilung ausschließlich mit symmetrischen Methoden zu lösen.

Schlüsselverwaltung im großen Stil. Einige wenige symmetrische Schlüssel lassen sich manuell in einer Tabelle verwalten. Für Unternehmen mit Tausenden von Datenbankschlüsseln, verschlüsselten Backups, VPN-Tunneln und Zahlungsterminals ist dies jedoch nicht möglich. Gemäß NIST SP 800-57 Part 1 Revision 5 durchläuft jeder Schlüssel einen definierten Lebenszyklus: Voraktivierung, aktiv, deaktiviert, kompromittiert und gelöscht. Jeder Schlüssel muss in diesem Lebenszyklus seinen Status verfolgen, seine Gültigkeitsdauer einhalten und seine Rotation planen. NIST empfiehlt eine Gültigkeitsdauer von ein bis zwei Jahren für symmetrische Datenverschlüsselungsschlüssel und bis zu zwei Jahren für HMAC-Schlüssel zur Nachrichtenauthentifizierung. Nach Ablauf dieser Frist steigen sowohl das Risiko einer Kompromittierung als auch das Ausmaß der dadurch offengelegten Daten. Ab einigen Hundert Schlüsseln ist dies ohne ein zentrales Schlüsselverwaltungssystem oder eine HSM-gestützte Plattform, die die Nachverfolgung automatisch übernimmt, nicht mehr praktikabel.

Die Folgen eines Schlüsselkompromittierungsfalls sind gravierend. Da derselbe Schlüssel sowohl zum Ver- als auch zum Entschlüsseln verwendet wird, kann jeder, der ihn erlangt, alle jemals mit diesem Schlüssel geschützten Daten lesen. Jede Verwendung des Schlüssels unter einer festen Verschlüsselung gibt zudem eine geringe Menge an Informationen preis, die ein Angreifer potenziell zur Rekonstruktion nutzen kann. Ein einzelner, langlebiger Schlüssel, der jahrelange Transaktionen schützt, stellt somit einen zentralen Schwachpunkt für alle diese Transaktionen dar. Die übliche Schutzmaßnahme ist eine Schlüsselhierarchie, in der ein selten verwendeter Hauptschlüssel kurzlebigere Sitzungs- oder Arbeitsschlüssel enthält. Dadurch gibt ein kompromittierter Arbeitsschlüssel nur die Daten preis, die er jeweils berührt hat, und nicht den gesamten Datenbestand.

Keine Nichtabstreitbarkeit. Ein symmetrischer Schlüssel kann zwar mittels HMAC bestätigen, dass eine Nachricht von jemandem stammt, der den Schlüssel besitzt, aber er kann nicht beweisen, welcher spezifische Inhaber sie gesendet hat, da jeder Bevollmächtigte eine identische Kopie besitzt. Entsteht ein Streit darüber, wer eine Transaktion autorisiert hat, kann symmetrische Kryptografie allein diesen nicht klären. Diese Garantie, die Nichtabstreitbarkeit, erfordert eine asymmetrische digitale Signatur, die an einen privaten Schlüssel einer einzigen Identität gebunden ist. Aus diesem Grund werden bei regulierten Transaktionen (Finanztransfers, Verträge, Code-Releases) PKI-basierte Signaturen zusätzlich zur symmetrischen Verschlüsselung eingesetzt, anstatt sich auf gemeinsame Geheimnisse zur Nachvollziehbarkeit zu verlassen.

Wie veranschaulicht eine Zahlungsschlüsselhierarchie diese Herausforderungen?

Zahlungs- und Bankensysteme verdeutlichen die Herausforderungen der symmetrischen Kryptographie, da sie vollständig auf symmetrischen Schlüsseln basieren. PINs, Kartendaten und Magnetstreifen- oder EMV-Kryptogramme sind alle durch AES- oder 3DES-basierte symmetrische Operationen innerhalb eines zertifizierten Zahlungs-HSM geschützt, und das hohe Transaktionsvolumen macht jede Schwachstelle schnell sichtbar. Eine typische Zahlungsschlüsselhierarchie besteht aus drei Ebenen:

• Hauptschlüssel (Zonenhauptschlüssel / Lokale Hauptschlüssel): Die Top-Tier-Schlüssel, die innerhalb eines HSM generiert werden, dienen ausschließlich der Verschlüsselung anderer Schlüssel, niemals direkt von Kundendaten, und sind durch Vier-Augen-Prinzip und geteiltes Wissen geschützt, sodass keine einzelne Person jemals den vollständigen Schlüssel besitzt.
• Sitzungs- oder Arbeitsschlüssel: Sie werden von einem Hauptschlüssel abgeleitet oder unter diesem ausgetauscht und für einen begrenzten Zeitraum oder eine einzelne Sitzung verwendet, um tatsächliche PIN-Blöcke, Kartendaten oder MAC-Werte zu verschlüsseln. Die Begrenzung ihrer Lebensdauer begrenzt direkt den oben beschriebenen Gefahrenradius.
• PIN-Verschlüsselungsschlüssel (PEKs): Eine spezielle Kategorie von Arbeitsschlüsseln, die ausschließlich zum Schutz von PIN-Blöcken während der Übertragung zwischen Kassenterminal, Acquirer und Issuer dient; eine der am strengsten regulierten Schlüsselarten in der gesamten Zahlungskette.

Kassenterminals lösen das Problem der Schlüsselverwaltung im großen Maßstab mit DUKPT (Derived Unique Key Per Transaction), standardisiert in ANSI X9.24-3-2017 . Anstatt eines statischen Schlüssels pro Terminal wird ein Gerät einmalig mit einem Initial PIN Encryption Key (IPEK) geladen, der von einem Base Derivation Key (BDK) abgeleitet wird, den ausschließlich das HSM verwaltet. Jede Transaktion generiert und verwendet einen neuen Schlüssel, der durch eine 80-Bit-Schlüsselseriennummer (KSN) verfolgt wird. Dieser Schlüssel wird nach Gebrauch sofort verworfen. Gelingt es einem Angreifer, den aktuellen Schlüssel eines Geräts zu extrahieren, kann er die Daten genau einer Transaktion wiederherstellen. Vergangene und zukünftige Transaktionen bleiben geschützt, da frühere Schlüssel nicht wiederhergestellt und zukünftige Schlüssel nicht ohne den BDK abgeleitet werden können. Dies ist die direkte, standardbasierte Antwort der Zahlungsbranche auf das Problem der weitreichenden Folgen eines Schlüsselkompromittierungsangriffs und ein bewährtes Verfahren, das überall dort Anwendung finden sollte, wo Geräte wiederholte symmetrische Operationen in großem Umfang verarbeiten.

Wie lösen die Schlüsselblock-Workflows TR-31 und TR-34 das Problem des sicheren Schlüsselaustauschs?

Ein symmetrischer Schlüssel besteht lediglich aus Bytes; er enthält keinerlei Informationen darüber, zu welchem ​​Algorithmus er gehört, wofür er verwendet werden darf oder wann er abläuft. Dieses Fehlen eingebetteter Nutzungsmetadaten stellt an sich ein Betriebsrisiko dar: Ein für die MAC-Authentifizierung generierter Schlüssel könnte versehentlich geladen und für die PIN-Verschlüsselung verwendet werden, ohne dass es einen Schutzmechanismus gibt. ASC X9 hat dieses Problem mit zwei verwandten Standards adressiert.

ASC X9 TR-31 , die Spezifikation für interoperable sichere Schlüsselaustausch-Schlüsselblöcke, kapselt einen symmetrischen Schlüssel zusammen mit seinen Nutzungsattributen, dem Schlüsselalgorithmus, dem Nutzungsmodus, der Exportierbarkeit und der Version in einem einzigen authentifizierten Block. Dieser Block ist verschlüsselt und mit einem MAC (Member Action Identifier) ​​integritätsgeschützt, sodass ein empfangendes System kryptografisch überprüfen kann, ob der Schlüssel manipuliert wurde und ob er ausschließlich für seinen autorisierten Zweck verwendet wird. TR-31 ist der Workflow, der es zwei Systemen mit bereits bestehendem Vertrauensverhältnis – beispielsweise einem Acquirer und einem Processor – ermöglicht, Arbeits- und Sitzungsschlüssel kontinuierlich auszutauschen, ohne die Schlüssel als reine Hexadezimalzeichenketten zu übertragen.

ASC X9 TR-34 , ein interoperables Verfahren zur Verteilung symmetrischer Schlüssel mittels asymmetrischer Techniken, löst das komplexere Problem: Wie lädt man den ersten Schlüssel auf ein Gerät oder System, das noch keinerlei Geheimnisse mit einem teilt? TR-34 verwendet asymmetrische (Public-Key-)Kryptographie, um diesen initialen symmetrischen Schlüssel zu verschlüsseln und zu authentifizieren. Dadurch kann ein Host einen Basisschlüssel oder lokalen Masterschlüssel sicher und remote auf ein neues Terminal oder HSM laden, ohne dass ein Kurier physisch einen gedruckten Schlüssel transportieren muss. In der Praxis löst TR-34 das Problem des Bootstrappings (das Laden von Schlüsseln aus der Ferne), während TR-31 das Problem des fortlaufenden Schlüsselaustauschs (die übliche Schlüsselrotation und -verteilung) nach dem Aufbau einer Vertrauensbeziehung löst.

Welche Anforderungen stellen PCI-PIN-Kontrollen an die symmetrische Schlüsselverwaltung?

Die PCI-PIN-Sicherheitsanforderungen , aktuell in Version 3.1 des PCI Security Standards Council, sind das verbindliche Regelwerk für alle Organisationen, die PINs verwalten, verarbeiten oder übermitteln. Die Anforderungen übersetzen die oben genannten allgemeinen Herausforderungen in spezifische, überprüfbare Kontrollen:

• Doppelte Kontrolle: Eine sensible Schlüsselverwaltungsoperation, -generierung, -ladung oder -vernichtung kann nicht von einer einzelnen Person allein durchgeführt werden; es sind mindestens zwei autorisierte Personen erforderlich.
• Geteiltes Wissen: Wo Schlüsselkomponenten verwendet werden, kennt keine einzelne Person jemals den vollständigen Schlüsselwert; jede Person besitzt nur eine Komponente, die für sich genommen bedeutungslos ist.
• Tastenblöcke über bloßen Tasten: PCI PIN schreibt die Verwendung von TR-31-Schlüsselblöcken für die Speicherung und Übertragung von Schlüsseln vor, wodurch die oben beschriebene Metadatenlücke geschlossen und veraltete Formate, die Schlüssel ohne gebundene Nutzungsattribute übertragen, schrittweise abgeschafft werden.
• Dokumentierte, nachvollziehbare Schlüsselzeremonien: Die Generierung und das Laden des Generalschlüssels müssen einem festgelegten, bezeugten Verfahren mit unterzeichneten Nachweisen folgen.
• HSM-exklusive Schlüsselerzeugung und -speicherung: Die für die PIN-Verschlüsselung verwendeten Schlüssel müssen innerhalb eines PCI-konformen, manipulationssicheren HSM generiert und verwendet werden, niemals auf Allzweckservern.

Dies sind die gleichen Prinzipien, die NIST SP 800-57 allgemein beschreibt – Kryptoperioden, definierte Zustände, kontrollierte Zerstörung –, die jedoch für einen symmetrischen Anwendungsfall mit hohem Einsatz spezifisch und obligatorisch gemacht werden.

Wie konzipiert man Hochverfügbarkeit und Disaster Recovery für symmetrische Schlüsselinfrastrukturen?

Eine symmetrische Schlüsselinfrastruktur, die einen Hardwareausfall nicht übersteht, macht die Schlüsselverwaltung im großen Maßstab zu einem Verfügbarkeitsproblem statt zu einem Sicherheitsproblem. Drei Designentscheidungen sind dabei besonders wichtig:

1. Clustered HSMs, not single units. Die Hauptschlüssel sollten in mindestens zwei geografisch getrennten, geclusterten HSMs vorhanden sein, die das Schlüsselmaterial über eine authentifizierte, verschlüsselte Verbindung replizieren, damit ein Ausfall eines einzelnen Standorts die Schlüsseloperationen nicht beeinträchtigt.
2. Sichere, dokumentierte Datensicherung wichtiger Unterlagen. HSM-Anbieter stellen verschlüsselte Backup-Mechanismen (Smartcards, Backup-HSMs) bereit, damit Master-Schlüssel wiederhergestellt werden können, ohne sie jemals im Klartext zu exportieren; dieser Backup-Prozess selbst erfordert die gleiche doppelte Kontrolle und das gleiche geteilte Wissen wie die ursprüngliche Schlüsselzeremonie.
3. Ein getestetes Failover-Runbook. Die Zuverlässigkeit von HA-Hardware hängt von der Leistungsfähigkeit beim letzten Failover ab. Zahlungsdienstleister testen den HSM-Failover üblicherweise nach einem festgelegten Zeitplan und speichern die Testhistorie als Prüfnachweis – dieselbe Art von Nachweis, die Aufsichtsbehörden und QSAs im Rahmen einer PCI-PIN-Prüfung verlangen.

Was geschieht während einer Schlüsselzeremonie?

Eine Schlüsselzeremonie ist das formale, bezeugte Verfahren zur Erzeugung, zum Laden oder zur Vernichtung eines hochrangigen symmetrischen Schlüssels, typischerweise eines Hauptschlüssels oder eines Basisschlüssels, der die Anforderungen der Vier-Augen-Kontrolle und der Wissensteilung gleichzeitig erfüllt. Eine typische Zeremonie läuft in folgenden Schritten ab: Teilnehmer mit definierten Rollen (Schlüsselverwalter, Zeremonienleiter und unabhängiger Zeuge) treffen sich in einem kontrollierten Raum; das HSM erzeugt das Schlüsselmaterial direkt innerhalb seiner kryptografischen Grenzen, sodass es niemals im Klartext außerhalb des Geräts existiert; der Schlüssel wird in Komponenten aufgeteilt, die jeweils auf einem manipulationssicheren Formular erfasst und einem separaten Verwalter übergeben werden, der sie sofort versiegelt; jede Aktion, die anwesenden Personen, die erzeugten Daten und die Zuteilung der Komponenten an die jeweiligen Empfänger werden protokolliert und in einem Zeremonienprotokoll signiert; das vollständige Protokoll dient als Prüfnachweis und wird für die gesamte Lebensdauer des Schlüssels aufbewahrt. Zahlungs-HSM-Systeme führen dieses Verfahren für jeden Hauptschlüssel und jeden Basisschlüssel durch; es ist das physische Gegenstück zu den kryptografischen Kontrollen, die TR-31 und TR-34 elektronisch durchsetzen.

Wie integriert man symmetrisches Schlüsselmanagement in bestehende Systeme?

Die nachträgliche Integration eines disziplinierten symmetrischen Schlüsselmanagements in eine bestehende Umgebung, sei es im Zahlungsverkehr oder anderweitig, folgt im Allgemeinen der gleichen Abfolge:

1. Erstellen Sie eine Liste aller verwendeten symmetrischen Schlüssel.Einschließlich eingebetteter Schlüssel im Anwendungscode, Datenbankkonfigurationsdateien und Terminal-Firmware geht der größte Teil der Gefährdung von Schlüsseln aus, deren Existenz niemand mehr in Erinnerung hatte.
2. Ordnen Sie jeden Schlüssel seiner Rolle zu., Master, Session, Working, PIN-Verschlüsselung, und ordnen Sie es der Kryptoperiode zu, die NIST SP 800-57 für diese Rolle empfiehlt.
3. Verlagern Sie die Schlüsselgenerierung und -speicherung in ein zertifiziertes HSM. Das private Schlüsselmaterial gelangt daher niemals unverschlüsselt in den Anwendungsspeicher oder auf die Festplatte.
4. TR-31-Schlüsselblöcke übernehmen für jeden Schlüssel, der zwischen Systemen übertragen werden muss, und ersetzt die reine Schlüsselübertragung, wo immer diese noch existiert.
5. Führen Sie eine dokumentierte Schlüsselzeremonie durch. für jeden neuen Hauptschlüssel oder BDK, mit doppelter Kontrolle und geteiltem Wissen von Anfang an und nicht erst nachträglich.
6. Automatische Rotation innerhalb der definierten Kryptoperiode anstatt sich auf die manuelle Nachverfolgung zu verlassen, sobald die Anzahl der Schlüssel den Rahmen einer Tabellenkalkulation übersteigt.
7. HA/DR in die HSM-Schicht integrieren vor der Inbetriebnahme, nicht nach dem ersten Ausfall.
8. Vernetzen Sie die gesamte Pipeline mit Überwachungs- und Berichtsfunktionen. So erzeugen wichtige Zustandsänderungen wie Aktivierung, Deaktivierung, Kompromittierung und Zerstörung die Prüfnachweise, die die Gutachter anfordern werden.

Welche Prüfungsnachweise erwarten die Prüfer für symmetrisches Schlüsselmanagement?

Eine PCI-PIN-Prüfung oder ein umfassenderes Sicherheitsaudit verlangt branchenunabhängig in der Regel dieselben Nachweise: Signierte Schlüsselzeremonienprotokolle, die belegen, dass das Vier-Augen-Prinzip und die Aufteilung des Wissens tatsächlich eingehalten und nicht nur als Richtlinie dokumentiert wurden; HSM-Konfigurationsauszüge, die belegen, dass Schlüssel innerhalb der kryptografischen Grenzen und nicht in Software generiert und gespeichert werden; Schlüsselinventarberichte, die den aktuellen Status (aktiv, deaktiviert, kompromittiert, zerstört) im Verhältnis zur definierten Kryptoperiode für jeden Schlüssel aufzeigen; TR-31-Schlüsselblock-Nutzungsprotokolle, die belegen, dass Schlüssel mit gebundenen Nutzungsattributen und nicht als reine Werte ausgetauscht wurden; Zugriffsprotokolle für jede Person, die jemals Schlüsselverwalterrechte besessen hat; und HA/DR-Testprotokolle, die belegen, dass das Failover tatsächlich durchgeführt und nicht nur architektonisch geplant wurde. Organisationen, die diese Ergebnisse in den Schlüsselmanagement-Workflow integrieren, anstatt sie zum Zeitpunkt des Audits zu rekonstruieren, durchlaufen PCI-PIN- und SOC-2-Prüfungen deutlich schneller.

Herausforderungen der symmetrischen Kryptographie: Auswirkungen und Gegenmaßnahmen

Die nachstehende Tabelle ordnet jeder operativen Herausforderung, die spezifisch für die symmetrische Kryptographie ist (und nicht bei asymmetrischen Verfahren auftritt), ihre praktische Auswirkung und die übliche Gegenmaßnahme zu.

Herausforderung	Nur symmetrischer Einschlag	Mitigation
Schlüsselverteilungsproblem	Beide Parteien benötigen das gleiche Geheimnis, bevor ein Austausch beginnen kann; es gibt keine integrierte Möglichkeit, dies über einen nicht vertrauenswürdigen Kanal zu gewährleisten.	Asymmetrisches Schlüssel-Wrapping für Bootstrapping (TR-34) oder hybrider TLS-basierter Schlüsselaustausch
Schlüsselmanagement im großen Maßstab	Die manuelle Nachverfolgung stößt schon weit vor einigen hundert Schlüsseln an ihre Grenzen; abgelaufene oder ausgetauschte Schlüssel werden nicht mehr erfasst.	Zentralisierte, HSM-gestützte Schlüsselverwaltungsplattform mit automatisierter Lebenszyklusüberwachung
Keine Nichtabstreitbarkeit	Ein gemeinsamer Schlüssel beweist, dass jemand mit Zugriff die Daten verschlüsselt hat, aber niemals, welcher spezifische Inhaber dies getan hat.	Für die Nachvollziehbarkeit können PKI-basierte digitale Signaturen verwendet oder die gerätespezifische Ableitung (DUKPT) genutzt werden, um den Kreis der möglichen Akteure einzugrenzen.
Wichtigster Kompromiss: Explosionsradius	Ein einziger offengelegter gemeinsamer Schlüssel kann alles entschlüsseln, was jemals damit geschützt war.	Schlüsselhierarchien (Master-/Sitzungs-/Arbeitsschlüssel), kurze Kryptoperioden, Ableitung pro Transaktion (DUKPT)
Keine eingebetteten Nutzungsmetadaten	Ein Rohschlüssel enthält keinerlei Informationen über Zweck, Algorithmus oder Ablaufdatum und kann daher unbemerkt missbraucht werden.	TR-31-Schlüsselblöcke binden Nutzungsattribute und eine Integritätsprüfung an das Schlüsselmaterial.
Sicherer Datenaustausch über nicht vertrauenswürdige Kanäle	Die Übertragung eines unformatierten Schlüssels birgt das Risiko des Abfangens während der Übertragung.	TR-34 asymmetrisches Fernladen von Schlüsseln; bezeugte physische Schlüsselzeremonien für Hauptschlüssel

Einschränkungen

Symmetrische Kryptografie kann ihr eigenes Schlüsselverteilungsproblem nicht lösen; sie benötigt stets entweder einen bereits bestehenden sicheren Kanal, einen Kurierdienst für den physischen Austausch oder asymmetrische Kryptografie als zusätzliche Sicherheitsebene, um Vertrauen aufzubauen. Auch die Nichtabstreitbarkeit kann sie nicht allein gewährleisten, da jede Partei mit Zugriff auf einen gemeinsamen Schlüssel gleichermaßen in der Lage ist, jeden beliebigen Chiffretext oder MAC zu erzeugen. DUKPT und Schlüsselhierarchien reduzieren zwar den Umfang einer Kompromittierung, eliminieren ihn aber nicht vollständig: Ein kompromittierter Basisschlüssel oder ein Master-Schlüssel der obersten Ebene legt weiterhin alle jemals davon abgeleiteten Schlüssel offen. Genau deshalb unterliegen Basisschlüssel und Master-Schlüssel den strengsten Kontrollen hinsichtlich Aufbewahrung, Zugriff und Verwaltung aller Schlüssel im System. Keiner der hier behandelten Standards – DUKPT, TR-31, TR-34, PCI PIN – ersetzt ein kryptografisches Inventar; eine Organisation muss weiterhin wissen, wo sich jeder symmetrische Schlüssel befindet, bevor diese Kontrollen angewendet werden können.

Was würde Encryption Consulting empfehlen?

Beginnen Sie damit, den Schlüssel – und nicht die Verschlüsselung – als das zu betrachten, was tatsächlich ein darauf basierendes Programm benötigt. Encryption Consultings HSM-as-a-Service stellt symmetrische Hauptschlüssel und Arbeitsschlüssel in FIPS 140-3-validierter Hardware mit geclusterter Hochverfügbarkeit und dokumentierter Datensicherung bereit, ohne dass die Investitionskosten für den Aufbau dieser Infrastruktur im eigenen Haus anfallen.

Für Organisationen, die speziell Karten-, PIN- oder PCI-PIN-bezogene Operationen durchführen, übernimmt unser Payment HSM -Services- und HSM-Services -Team die Schlüsselzeremonien, die TR-31/TR-34-Schlüsselblockimplementierung und die DUKPT-Schlüsseleinspeisungs-Workflows, die PCI PIN v3.1 erfordert, und erstellt den von den Prüfern geforderten Prüfnachweis als Nebenprodukt des Auftrags und nicht erst im Vorfeld.

Und da in den meisten Umgebungen symmetrische und asymmetrische Kryptographie parallel eingesetzt werden, behandelt unser Leitfaden „Symmetrische vs. asymmetrische Verschlüsselung“, wo die jeweilige Kategorie ihren Platz hat und wie die aktuellen Algorithmenrichtlinien des NIST auf beide anwendbar sind.

Fazit

Die Herausforderungen der symmetrischen Kryptographie sind fast ausschließlich operativer Natur: die sichere Übermittlung eines gemeinsamen Geheimnisses an die richtige Partei, ohne dass dieses Geheimnis offengelegt wird; die Nachverfolgung dieses Geheimnisses in einem wachsenden Schlüsselbestand; die Begrenzung der Folgen eines einzelnen Kompromittierungsfalls; und die Akzeptanz der Tatsache, dass ein gemeinsamer Schlüssel allein keine Identität beweisen kann. Zahlungs- und Bankensysteme zeigen, wie eine ausgereifte Lösung in der Praxis aussieht: eine Hierarchie aus Hauptschlüssel, Sitzungsschlüssel und PIN für die Verschlüsselung; DUKPT zur kryptografischen Isolation jeder Transaktion; TR-31 und TR-34 für den sicheren Schlüsselaustausch; sowie die Anforderungen von PCI PIN hinsichtlich Vier-Augen-Prinzip, geteiltem Wissen und Schlüsselzeremonien, um die Auditierbarkeit des gesamten Systems zu gewährleisten. Dieselben Prinzipien – Schlüsselhierarchie, kurze Kryptoperioden, HSM-gestützte Speicherung und dokumentierte Zeremonien – gelten ebenso direkt für Datenbankverschlüsselungsschlüssel, VPN-Tunnelschlüssel oder jede andere symmetrische Implementierung, auch außerhalb des Zahlungsverkehrs.

Häufig gestellte Fragen

Was ist die größte Schwäche der symmetrischen Kryptographie?
Das Schlüsselmanagement, nicht der Algorithmus. AES-256 weist keine praktische kryptografische Schwachstelle auf, aber die sichere Verteilung, Nachverfolgung und Stilllegung des gemeinsamen Schlüssels in großem Umfang ist der Punkt, an dem symmetrische Systeme in der Praxis versagen, zusammen mit der Tatsache, dass ein gemeinsamer Schlüssel allein keine Nichtabstreitbarkeit gewährleisten kann.

Wie löst DUKPT das Schlüsselmanagementproblem in Zahlungsterminals?
DUKPT, standardisiert in ANSI X9.24-3, generiert für jede Transaktion einen neuen, eindeutigen Schlüssel aus einem Basisschlüssel, den ausschließlich das ausstellende HSM besitzt. Wird der aktuelle Schlüssel eines Terminals extrahiert, ist nur diese eine Transaktion offengelegt; vergangene und zukünftige Transaktionen bleiben geschützt, da frühere Schlüssel nicht wiederhergestellt und zukünftige Schlüssel ohne den Basisschlüssel nicht abgeleitet werden können.

Worin besteht der Unterschied zwischen TR-31 und TR-34?
TR-31 verschlüsselt einen symmetrischen Schlüssel mit seinen Nutzungsattributen für den fortlaufenden Austausch zwischen Systemen, die bereits einander vertrauen. TR-34 verwendet asymmetrische Kryptografie, um das komplexere Bootstrapping-Problem zu lösen, indem der allererste Schlüssel remote auf ein Gerät oder System geladen wird, ohne dass zuvor ein gemeinsames Geheimnis besteht.

Benötigt PCI DSS TR-31-Schlüsselblöcke?
Die PCI PIN-Sicherheitsanforderungen (derzeit Version 3.1 des PCI Security Standards Council), die für alle Stellen gelten, die mit Karteninhaber-PINs umgehen, schreiben die Verwendung des TR-31-Schlüsselblocks für die Speicherung und Übertragung von Schlüsseln sowie die Vier-Augen-Kontrolle, die Aufteilung des Wissens und dokumentierte Schlüsselzeremonien vor.

Kann symmetrische Kryptographie Nichtabstreitbarkeit gewährleisten?
Nein. Da jeder autorisierte Inhaber eines symmetrischen Schlüssels einen identischen Chiffretext oder MAC erzeugen kann, lässt sich mit symmetrischer Kryptographie nicht beweisen, welche Partei eine bestimmte Operation durchgeführt hat. Nichtabstreitbarkeit erfordert eine asymmetrische digitale Signatur, die an einen privaten Schlüssel einer bestimmten Identität gebunden ist.

Referenzen

• NIST SP 800-57 Teil 1 Revision 5, Empfehlung für das Schlüsselmanagement: Allgemeines
• ANSI X9.24-3-2017, Symmetrisches Schlüsselmanagement im Finanzdienstleistungssektor, Teil 3: Abgeleiteter eindeutiger Schlüssel pro Transaktion
• ASC X9 TR-31-2018, Interoperable Secure Key Exchange Key Block Specification for Symmetric Algorithms
• ASC X9 TR-34-2019, Interoperables Verfahren zur Verteilung symmetrischer Schlüssel unter Verwendung asymmetrischer Techniken
• PCI Security Standards Council, PIN-Sicherheitsanforderungen
• PCI SSC, soeben veröffentlicht: Version 3.1 des PCI-PIN-Sicherheitsstandards