Kreditkartendaten entschlüsseln, Teil I

Eine häufig gestellte Frage lautet: Die Track-Daten, die ich von meinem ID TECH Kreditkartenlesegerät erhalte, sind verschlüsselt. Wie entschlüssele ich sie?

Die Antwort lautet: Sie müssen den passenden Session-Key für die Transaktion ermitteln und anschließend damit die Daten-Payload per Triple-DES (oder AES, je nach Anforderung) entschlüsseln.

Der Entschlüsselungsvorgang selbst ist erfreulich unspektakulär. Sie werden wahrscheinlich eine von mehreren verfügbaren Open-Source-Implementierungen von TDES oder AES nutzen – eigene Implementierungen der kryptografischen Kernroutinen sind nicht erforderlich –, die im CBC-Modus (Cipher Block Chaining) mit einem standardmäßigen Initialisierungsvektor aus reinen Nullbytes arbeiten. Sofern Sie den korrekten 16-Byte-Entschlüsselungsschlüssel besitzen, ist der Vorgang unkompliziert.

Die eigentliche Herausforderung liegt in der Schlüsselableitung. Dafür müssen Sie ANSI X9.24-1 verstehen, auch bekannt als DUKPT.

Willkommen in der Welt von DUKPT

Es ist wichtig zu verstehen, dass Kartenlesegeräte bei jeder Transaktion Daten erzeugen, die mit einem jeweils anderen Schlüssel verschlüsselt werden. Dieser Schlüssel ist einmalig für eine bestimmte Transaktion (daher das Akronym DUKPT: Derived Unique Key Per Transaction). Kein Schlüssel wird je zweimal verwendet. Dadurch sind Replay-Angriffe praktisch ausgeschlossen.

Um zu verstehen, wie DUKPT funktioniert, muss man das Konzept der Key Serial Number, kurz KSN, kennen. Das Wichtigste dabei: Die KSN ist ein 10-Byte-Wert, der sich bei jeder Transaktion ändert, da die unteren 21 Bits einen Zähler bilden.

Aufbau der Key Serial Number.

Zur Erinnerung: Jede verschlüsselte Kartentransaktion enthält eine KSN. Die KSN ist stets 10 Bytes lang und wird immer im Klartext übertragen, da sie für sich genommen keine sensiblen Informationen preisgibt – jedoch unverzichtbar für die Ableitung eines Sitzungsschlüssels ist.

Wenn ein Kartenlesegerät im Werk für die Verschlüsselung konfiguriert wird, erhält es einen 16-Byte-Schlüssel sowie eine 10-Byte-Anfangs-KSN injiziert. Der eingespritzte Schlüssel wird aus einem streng geheimen Schlüssel abgeleitet – der selbst nie injiziert wird –, dem sogenannten BDK (Base Derivation Key). Da aus einem einzigen BDK viele Schlüssel abgeleitet werden können, ist es möglich und in der Praxis üblich, Hunderte oder sogar Tausende von Kartenlesegeräten mit einzigartigen Schlüsseln zu versehen, die alle auf einem einzigen BDK basieren. Der Ableitungsprozess selbst erfordert die Verwendung einer KSN. Da die KSN Informationen über die Seriennummer des Geräts sowie weitere diverse „Namespace"-Angaben enthält, ist ein aus einer bestimmten BDK+KSN-Kombination erzeugter Hash (bzw. Schlüssel) im Wesentlichen gerätespezifisch. Darüber hinaus lässt sich der ursprüngliche BDK aus dem Hash niemals rückrechnen – selbst wenn die KSN bekannt ist –, da es sich um einen kryptografisch sicheren Einweg-Hash handelt.

Bei jeder Transaktion erzeugt das Kartenlesegerät – sofern es DUKPT unterstützt, was bei nahezu allen modernen Kartenlesegeräten der Fall ist – einen einzigartigen Schlüssel aus dem aktuellen KSN-Wert und dem sogenannten IPEK (Initial PIN Encryption Key). Der daraus resultierende, nur einmal verwendbare Sitzungsschlüssel wird anschließend genutzt, um die sensiblen Teile der Transaktionsdaten zu verschlüsseln.

Nach der Verschlüsselung werden die Transaktionsdaten erst wieder entschlüsselt, wenn sie den autorisierten Empfänger erreichen – etwa den Kartenaussteller. Die empfangende Partei (z. B. der Aussteller) verwendet ihre eigene Kopie des BDK zusammen mit der Transaktions-KSN, um den Sitzungsschlüssel für die Transaktion neu abzuleiten und die ursprünglichen (entschlüsselten) Transaktionsdaten wiederherzustellen. Dabei handelt es sich um ein sogenanntes symmetrisches Verfahren, da sowohl die verschlüsselnde als auch die entschlüsselnde Partei dasselbe Geheimnis – den BDK – kennen müssen. Es wird vorausgesetzt, dass Sie der empfangenden Partei das erforderliche „Geheimnis" bereits mitgeteilt haben, damit beide Seiten Nachrichten entschlüsseln können.

Der IPEK

Der Ausgangspunkt für die Ableitung eines DUKPT-Sitzungsschlüssels ist stets die Ableitung des IPEK – also des Anfangsschlüssels. Dies ist nur möglich, wenn der ursprüngliche BDK sowie die KSN bekannt sind. (Hier genügt jede beliebige KSN des betreffenden Geräts, da der Zähler für diesen Schritt auf null gesetzt wird.)

Um einen Initial PIN Encryption Key (IPEK) abzuleiten, sind folgende Schritte erforderlich:

1. Wenn Ihr BDK 16 Bytes groß ist, erweitern Sie ihn mit der sogenannten EDE3-Methode auf 24 Bytes. Das bedeutet einfach: Kopieren Sie die ersten 8 Bytes des Schlüssels an das Ende des Schlüssels, sodass ein 24-Byte-Schlüssel entsteht, bei dem die ersten und letzten 8 Bytes identisch sind.

Wenn Ihr ursprünglicher Schlüssel (in Hex) so aussieht:

Soll er anschließend so aussehen:

2. Maskieren Sie Ihren 10-Byte-Initial-KSN, indem Sie ihn mit dem Hex-Wert 0xFFFFFFFFFFFFFFE00000 per AND-Operation verknüpfen. Das Ergebnis bezeichnen wir als „maskierten KSN".

3. Erstellen Sie einen 8-Byte-Wert aus dem maskierten KSN, indem Sie nur die ersten (d. h. linksseitigen) 8 Bytes des 10-Byte-maskierten KSN behalten. Mit anderen Worten: Entfernen Sie die beiden rechtsseitigen Bytes.

4. Verwenden Sie Ihren erweiterten 24-Byte-BDK als Schlüssel und verschlüsseln Sie die 8 Bytes des maskierten KSN, den Sie in Schritt 3 ermittelt haben, mit TDES. Als Initialisierungsvektor verwenden Sie dabei ausschließlich Nullen. (Da die Datenmenge in diesem Fall nur einen einzigen Block von 8 Bytes umfasst, ist Cipher Block Chaining hier nicht relevant.) Behalten Sie den resultierenden 8-Byte-Chiffriertext, da er zur linken Hälfte des 16-Byte-IPEK wird.

5. Um die rechte Hälfte des IPEK zu ermitteln, verknüpfen Sie zunächst Ihren ursprünglichen 16-Byte-BDK per XOR-Operation mit dem Hex-Wert 0xC0C0C0C000000000C0C0C0C000000000. (In einer Programmiersprache mit Unterstützung für große Ganzzahlen lässt sich dies in einer einzigen Codezeile erledigen. Andernfalls müssen Sie die beiden Werte schrittweise, Stück für Stück, per XOR verknüpfen.)

6. Erweitern Sie den in Schritt 5 ermittelten 16-Byte-Wert per EDE3-Expansion auf einen 24-Byte-Schlüsselwert.

7. Verschlüsseln Sie mit dem 24-Byte-Schlüsselwert aus Schritt 6 die 8 Bytes des maskierten KSN aus Schritt 3 mittels TDES. Dies ergibt die rechte Hälfte des IPEK.

8. Fügen Sie die linke und rechte Hälfte des IPEK zusammen. Sie verfügen nun über den fertigen 16-Byte-IPEK.

Wenn Sie dies selbst in Code implementieren, versuchen Sie, einen IPEK aus dem Testschlüsselwert 0123456789ABCDEFFEDCBA9876543210 und einem KSN von 62994900000000000001 zu erzeugen. Der resultierende IPEK sollte B5610650EBC24CA3CACDD08DDAFE8CE3 lauten.

Schlüsselverwaltung vs. Verschlüsselungsalgorithmen

Ihnen wird auffallen, dass Triple-DES (TDES) in DUKPT häufig zum Einsatz kommt. AES wird dabei zu keinem Zeitpunkt verwendet – selbst wenn Ihr Kartenlesegerät für die AES-Verschlüsselung konfiguriert ist. Der X9.24-Standard schreibt TDES vor, in manchen Fällen auch einfaches DES. Machen Sie sich bewusst, dass der DUKPT-Schlüsselableitungsprozess vollständig vom Prozess der Transaktionsdatenverschlüsselung bzw. -entschlüsselung getrennt ist. Im einen Fall leiten Sie einen Schlüssel ab, im anderen verwenden Sie diesen Schlüssel zur TDES- oder AES-Codierung. Kein Verschlüsselungsverfahren weiß oder kümmert sich darum, woher Ihr Schlüssel stammt oder welche Algorithmen bei seiner Erstellung verwendet wurden – entscheidend ist allein, dass der Schlüssel selbst funktioniert. Auch wenn die Daten, die Sie entschlüsseln möchten, mit AES verschlüsselt wurden, wird der dazu verwendete Schlüssel über DUKPT abgeleitet, das intern auf TDES zurückgreift.

Wo ist der Quellcode?

In Teil II dieses Beitrags werden wir ausführlich erläutern, wie sich mithilfe eines IPEK und eines KSN ein tatsächlicher DUKPT-Sitzungsschlüssel ableiten lässt. Wir werden konkreten Quellcode vorstellen, damit Sie den gesamten Vorgang selbst nachvollziehen können. Wer nicht bis zum nächsten Teil warten möchte, kann sich schon jetzt unser beliebtes Encrypt/Decrypt Toolansehen. Es enthält eine vollständig funktionsfähige JavaScript-Implementierung der DUKPT-Algorithmen, die in Teil II behandelt werden – einschließlich Open-Source-Implementierungen von TDES und AES. Mit dem Encrypt/Decrypt Tool können Sie DUKPT-Schlüssel in allen drei Varianten ableiten (PIN, Data und MAC), Daten mit TDES oder AES ver- und entschlüsseln, verschiedene Hash-Typen generieren und vieles mehr. Da das Tool lediglich eine Webseite ist, funktioniert es in jedem Browser auf jeder Plattform, die JavaScript unterstützt.

Möchten Sie einen datenvarianten DUKPT-Sitzungsschlüssel aus einem KSN und einem IPEK ableiten? Weiter zu Teil II dieses Artikels.