chipTAN Flickercodes

Created:2010-02-07
Date: 2012-06-04

„chipTAN“ ist ein Verfahren, das Online-Banking unanfälliger gegen zum Beispiel Man-In-The-Middle-Angriffe machen soll. Dabei bekommt jeder Bankkunde ein Gerät, das zusammen mit seiner Kreditkarte auftragsgebundene TANs generieren kann. Vor der Generierung einer TAN werden Zielkontonummer und Betrag (je nach Überweisungstyp auch andere Werte, wie IBAN oder Anzahl) angezeigt und können vom Kunden verifiziert werden. Diese Daten können manuell eingegeben werden oder (darum soll es im Folgenden gehen) über eine optische Schnittstelle übertragen werden.

Diese optische Schnittstelle ist in der HHD-Spezifikation (Version 1.3) des ZKA beschrieben. Das Problem dabei: Die Spezifikation ist nur teilweise öffentlich zugänglich. Es bleibt also nur der Weg über reverse engineering.

Aufbau

Im Folgenden werde ich den Aufbau der sogenannten „Flickercodes“ an dem Beispielcode 11048714955205123456789F14302C303107 erläutern. Diese Flickercodes sind die Daten, die auch an den externen TAN-Generator weitergegeben werden.

Code Bedeutung
11 Länge des Codes
0 Flag: BCD-kodiert
4 4 Bytes lang
871 Maske: 8 = Freie Gestaltung, 7 = Kontonummer, 1 = Betrag, siehe Masken
49552 Zufallszahl oder Transaktionsnummer
0 Flag: BCD-kodiert
5 5 Bytes
123456789F Kontonummer, BCD-kodiert, Füllzeichen F am Ende
1 Flag: ASCII-kodiert
4 4 Bytes
302C3031 ASCII-String: 0,01
0 Luhn-Prüfsumme
7 XOR-Prüfsumme

Wie man gut erkennen kann, ist jeder Code in mehrere Bereiche unterteilt, die jeweils mit einem Kodierungsflag (BCD = 0 oder ASCII = 1) und einer Länge (0–F) beginnen und dann einen (in der Theorie) maximal 16 Byte langen Payload enthalten.

Prüfsummen

Die einzelnen Stellen (Halbbytes) werden hier mit x1 bis xn bezeichnet, wobei n die Länge des Flickercodes ist. p1 bis pm ist der Payload ohne Längen- oder Kodierungshalbbytes. Der Payload des obigen Beispiels ist 871 49552 123456789F 302C3031 (ohne Leerzeichen).

Die Luhn-Prüfsumme wird nur über den Payload berechnet: \((10 - ((p_1 + q(2 p_2) + p_3 + q(2 p_4) + \ldots) \bmod 10)) \bmod 10\). q(n) berechnet die Quersumme der Dezimalzahl n, die Eingabezeichen A–F werden als Hexadezimalzahlen interpretiert und erhalten damit die Wertigkeit 10–16.

Die XOR-Prüfsumme wird über alle Zeichen, bis auf die Prüfsumme selbst, berechnet: \(x_1 \oplus x_2 \oplus \ldots \oplus x_{n-2}\)

Masken

Im ersten Datenbereich wird unter anderem festgelegt, wie sich das Gerät des Benutzers verhalten soll. Es gibt die, auch im obigen Beispiel benutzte, frei belegbare Maske 8xy, mit x und y aus dieser Tabelle:

Nummer Transaktionsdaten Displaytext
1 Betrag Betrag
2 Kontonummer Konto/IBAN
3 Online-Banking-PIN OBanking-PIN
4 Telefonnummer Telefon
5 Bankdaten Zusatzdaten
6 Anzahl Anzahl
7 Kontonummer Kontonummer
8 Kontonummer IBAN

Es existieren weitere Masken, die in den Belegungsrichtlinien (siehe Literatur) beschrieben sind.

Optische Schnittstelle

flicker.png

Belegung der blinkenden Grafik

Auf der Rückseite des Geräts befinden sich fünf Fotosensoren, die zur Übertragung über eine blinkende Grafik gehalten werden müssen. Es werden jeweils vier Bits und ein Taktsignal übertragen. Die blinkenden Bereiche sind wie folgt belegt: Takt, Bit 20, Bit 21, Bit 22, Bit 23. Der oben beschriebene Flickercode wird mit dem vorangestellten Code 0FFF in einer Endlosschleife übertragen. Die Übertragungsreihenfolge der einzelnen Halbbytes wird dabei umgekehrt. Beispiel: Aus 11048714955205123456789F14302C303107 wird zur Übertragung F0 FF 11 40 78 41 59 …

Javascript-Flickercode

Um einfacher verschiedene Belegungen ausprobieren zu können, habe ich einen Flickercode-Generator mit JavaScript und dem HTML-canvas-Element implementiert, der die Prüfsummen automatisch berechnet und einsetzt.

Zum Beispiel: 11 04 871 49552 05 123456789F 14 302C3031 07. Die Prüfsummen (letzte beiden Ziffern) und die Gesamtlänge des Codes (erste zwei Stellen) werden automatisch berechnet, können also auch als 00 angegeben (aber nicht weggelassen!) werden.

Literatur