Kreditkartendaten entschlüsseln, Teil I

Eine häufig gestellte Frage lautet: Die Trackdaten, 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 Sitzungsschlüssel für die Transaktion ermitteln und anschließend mit diesem Schlüssel die Datennutzlast über Triple-DES (oder AES, je nach Bedarf) entschlüsseln.

Der Entschlüsselungsprozess selbst ist erfreulicherweise weniger komplex als erwartet. Sie werden wahrscheinlich eine der zahlreichen verfügbaren Open-Source-Implementierungen von TDES oder AES nutzen – eine eigene Implementierung der kryptografischen Kernroutinen ist nicht erforderlich –, die im CBC-(Cipher Block Chaining)-Modus mit einem standardmäßigen Initialisierungsvektor aus ausschließlich Null-Bytes betrieben wird. Sofern Sie über den korrekten 16-Byte-Entschlüsselungsschlüssel verfügen, ist der Entschlüsselungsvorgang unkompliziert.

Der anspruchsvolle Teil ist die Ableitung des Schlüssels. Hierfü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 bei Kreditkartenlesern jede Transaktion Daten erzeugt, 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 jemals zweimal verwendet. Dadurch sind Replay-Angriffe praktisch ausgeschlossen.

Um zu verstehen, wie DUKPT funktioniert, muss man das Konzept der Key Serial Number (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.

Wichtig: 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 allein keine sensiblen Informationen preisgibt – jedoch unverzichtbar für die Ableitung eines Sitzungsschlüssels ist.

Wenn ein Kartenleser im Werk für die Verschlüsselung konfiguriert wird, erhält er einen injizierten 16-Byte-Schlüssel sowie eine initiale 10-Byte-KSN. Der injizierte 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 Kartenlesern 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 zahlreiche weitere 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 nicht zurückberechnen – selbst wenn die KSN bekannt ist –, da es sich um einen kryptografisch sicheren Einweg-Hash handelt.

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

Nach der Verschlüsselung werden Transaktionsdaten erst wieder entschlüsselt, wenn sie den autorisierten Empfänger – etwa den Kartenaussteller – erreicht haben. Die empfangende Partei (z. B. der Aussteller) verwendet ihre eigene Kopie Ihres BDK sowie die Transaktions-KSN, um den Sitzungsschlüssel der Transaktion erneut 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 – bereits kennen muss. Es wird vorausgesetzt, dass Sie der empfangenden Partei das erforderliche „Geheimnis" vorab mitgeteilt haben, damit beide Seiten Nachrichten entschlüsseln können.

Der IPEK

Der Ausgangspunkt zur Ermittlung eines DUKPT-Sitzungsschlüssels ist stets die Ableitung des IPEK – des initialen Schlüssels –, was nur möglich ist, wenn der ursprüngliche BDK und die KSN bekannt sind. (Hierbei kann jede KSN des betreffenden Geräts verwendet werden, 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 schlicht: Kopieren Sie die ersten 8 Bytes des Schlüssels an dessen Ende, sodass ein 24-Byte-Schlüssel entsteht, bei dem das erste und das letzte 8-Byte-Segment identisch sind.

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

Soll er am Ende so aussehen:

2. Maskieren Sie Ihren 10-Byte-Initial-KSN, indem Sie ihn mit dem Hex-Wert 0xFFFFFFFFFFFFFFE00000 per AND-Verknüpfung kombinieren. 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. Verschlüsseln Sie die 8 Bytes des maskierten KSN, die Sie in Schritt 3 ermittelt haben, mittels TDES und verwenden Sie dabei Ihren erweiterten 24-Byte-BDK als Schlüssel. Als Initialisierungsvektor verwenden Sie dabei ausschließlich Nullen. (Beachten Sie, dass Cipher Block Chaining hier nicht relevant ist, da die Daten in diesem Fall nur einen einzigen Block umfassen: 8 Bytes.) Speichern Sie den in diesem Schritt erhaltenen 8-Byte-Chiffretext, da er zur linken Hälfte des 16-Byte-IPEK wird.

5. Um die rechte Hälfte des IPEK zu erhalten, XOR-verknüpfen Sie zunächst Ihren ursprünglichen 16-Byte-BDK mit dem Hex-Wert 0xC0C0C0C000000000C0C0C0C000000000. (In einer Programmiersprache mit Unterstützung für Big-Integer-Arithmetik lässt sich dies in einer einzigen Codezeile umsetzen. 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 mittels EDE3-Expansion zu einem 24-Byte-Schlüsselwert.

7. Verschlüsseln Sie die 8 Bytes des maskierten KSN aus Schritt 3 mittels TDES und dem 24-Byte-Schlüsselwert aus Schritt 6. Dieser Wert bildet nun die rechte Hälfte des IPEK.

8. Verketten Sie die linke und die rechte Hälfte des IPEK. 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 ergeben.

Schlüsselverwaltung vs. Verschlüsselungsalgorithmen

Ihnen wird auffallen, dass Triple-DES (TDES) in DUKPT sehr 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 und in manchen Fällen auch einfaches DES vor. Vergegenwärtigen Sie sich, dass der DUKPT-Schlüsselableitungsprozess vollständig vom Verschlüsselungs- und Entschlüsselungsprozess der Transaktionsdaten getrennt ist. Im einen Fall leiten Sie einen Schlüssel ab; im anderen Fall verwenden Sie diesen Schlüssel für die TDES- oder AES-Kodierung. 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 zu entschlüsselnden Daten mit AES verschlüsselt wurden, wird der dazu benötigte Schlüssel mittels DUKPT abgeleitet, das intern TDES verwendet.

Wo ist der Code?

In Teil II dieses Beitrags werden wir sehr detailliert erläutern, wie man mit einem IPEK und einem KSN einen tatsächlichen DUKPT-Sitzungsschlüssel ableitet. Wir zeigen echten Quellcode, damit Sie den gesamten Vorgang selbst nachvollziehen können. Falls Sie nicht bis zum nächsten Teil warten möchten, um den Quellcode zu sehen, werfen Sie schon jetzt einen Blick auf unser beliebtes Encrypt/Decrypt Tool, das eine vollständig funktionsfähige JavaScript-Implementierung der DUKPT-Algorithmen enthält, auf die ich in Teil II eingehen werde (einschließlich Open-Source-Implementierungen von TDES und AES). Mit dem Encrypt/Decrypt Tool können Sie DUKPT-Schlüssel ableiten (in allen 3 Varianten: PIN, Daten und MAC), Daten verschlüsseln oder entschlüsseln (mit TDES oder AES), verschiedene Arten von Hashes generieren und vieles mehr. Das Beste daran: Da es sich bei dem Tool lediglich um eine Webseite handelt, funktioniert es in jedem Browser (auf jeder Plattform), der JavaScript unterstützt.

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