Inhaltsverzeichnis

Vom Überweisungsauftrag zur TAN

In den letzten Jahren sind viele Banken und Sparkassen dazu übergegangen, iTAN-Listen auf Papier durch transaktionsgebundene mTAN (TAN per SMS auf das Handy) oder TAN-Generatoren abzulösen. Diese werden je nach Institut unter den Bezeichnungen Sm@artTAN, chipTAN, oder auch „Flicker TAN“ beworben. Stets wird dabei pro Auftrag eine „flackernde“ Grafik zum Einlesen mit dem bereitgestellten TAN-Generator dargestellt. Dieser zeigt nach dem erfolgreichen Einlesen die Transaktionsdaten an und liefert nach deren Bestätigung durch den Benutzer eine TAN. Die Spezifikation der dahinter stehenden Vorgänge ist nicht allgemein einsehbar. Dieser Artikel beschreibt gemachte Beobachtungen dieses Verfahrens hinsichtlich der optischen Schnittstelle zwischen Flickergrafik und Lesegerät sowie die Smartcardkommunikation. Denkbar wäre, diese Technik (insbesondere die damit, zumindest deutschlandweit, gut verbreiteten Generatoren anderweitig zu nutzen. Über Ergänzungen, Anmerkungen oder Korrekturen freuen wir uns.

Ausgangspunkt

Es wird eine Überweisung von 1,23 EUR an die Kontonummer 335554 im Onlinebanking beauftragt. Es muss der angezeigte „Flickercode“ mit dem TAN-Generator bei eingelegter Bankkarte und nach Betätigung der Taste F eingelesen und die im Display angezeigten Transaktionsparameter, Kontonummer und Betrag, bestätigt werden. Schlussendlich zeigt der TAN-Generator die TAN 251067 zur Eingabe im Onlinebanking. Es ist zu beobachten, dass bei wiederholter Einlese- & Bestätiungs- prozedur unterschiedliche TANs erzeugt werden. Werden auf diese Weise zuviele TANs erzeugt, jedoch nicht im Online-Banking verwendet, fordert das Bankssystem eine Neusyncronisation mit der Karte an.

Frage: Wie kommt der TAN-Generator zur Anzeige der TAN 251067?

Onlinebanking Interface

Flickercode Anzeige

Das Onlinebanking zeigt einen „Flickercode“ (Beispiel). Dies kann über unterschiedliche Techniken erfolgen:

Die Auswahl der Darstellungstechnik richtet sich den verfügbaren Browsererweiterungen und Clienttechnologien (z.B. Terminalserver). Wenn möglich wird dem Flash Film der Vorzug gegeben.

Verbrauchertipp :-)

Gelingt das Einlesen der Grafik mit dem TAN-Generator nicht oder nur sehr unzuverlässig kann es helfen die Anzeigehelligkeit am Monitor/Display und Flickergeschwindigkeit der Grafik zu variieren. Ist die Anzeigehelligkeit zu hoch erkennt der Generator selbst schwarze Bereiche als „hell“; ist sie zu niedrig können entsprechend helle Balken nicht mehr differenziert werden. Einzelne Anzeigetechniken des Flickercodes (z.B. das üblicherweise verwendete Flash) erlauben desweiteren die Flickergeschwindkeit anzupassen. Ein Klick auf den ganz linken der fünf „flackernden“ Balken verlangsamt den Ablauf der Sequenz. Dem gegenüber beschleunigen Klicks auf den Balken ganz rechts. So kann ein Kompromiss zwischen schnellem Einlesen der Daten und der Toleranz gegenüber Anzeigeproblemen (Browser, Grafiksystem, Monitor. etc) gefunden werden.

Flickercode Aufbau

Der Flicker-Code wird aus folgenden Eingabedaten generiert (im Folgenden „Flickerdaten“ genannt):

0F 04 87 11 00 03 03 33 55 54 14 31 2C 32 33 1D

Diese, bzw. eine entsprechende, Zahlenreihe findet sich auch im Quelltext der Onlinebanking-Seite als Parameter für den Flash Film oder die Javascript- & DOM-Routine.

Die Flickerdaten werden beispielsweise wie folgt zusammengestellt:

0F: Anzahl nachfolgender Bytes (15 Bytes)

0 : Kennzeichen der Kodierung für die nachfolgenden Daten in BCD (0=BCD, 1=DIN-66003)
 4: Länge des sog. Start-Codes in Bytes (der Start-Code definiert die vom TAN-Generator angezeigten Masken)

87 11 00 03: 4 byte Start-Code in BCD-Notation - S
8          : signalisiert freie Maskengestaltung anhand nachfolgender Codes (hier 7 und 1)
 7         : signalisiert Maske "Kontonummer"
   1       : signalisiert Maske "Betrag"
    1 00 03: Übergabe einer vom Bankensystem vorgegebenen Zufallszahl (ändert mit jeder Online-Transaktion)
  
0 : Kodierung der nachfolgenden Daten in BCD
 3: Länge des ersten Maskeninhalts in Byte

33 55 54: 3 Byte: erster Maskeninhalt (Kontonummer) in BCD-Notation - M1

1 : Kodierung der nachfolgenden Daten in DIN-66003 (wg. Komma in 1,23)
 4: Länge des zweiten Maskeninhalt in Bytes

302C3031: zweiter Maskeninhalt (hier: Betrag) in DIN-66003-Kodierung 1,23 - M2
31      : DIN-66003 (hex): 1
  2C    : DIN-66003 (hex): , (Komma)
    32  : DIN-66003 (hex): 2
      33: DIN-66003 (hex): 3

1 : Luhn Prüfsumme über Start-Code und Maskeninhalte
 D: XOR Prüfsumme über die gesamten Flickerdaten ohne diese beiden Prüfsummenhalbbytes

Hinweise

Eine ungerade Anzahl an BCD-Stellen (1/2 Byte) in Maskenwerten wird mit einem „F“ als Füllzeichen zu einem vollen Byte aufgefüllt. Eine gute Übersicht verfügbarer Masken findet sich in http://files.messe.de/cmsdb/D/007/22435.pdf, Seite 12ff.

Luhn-Prüfsumme

Bildung der Luhn-Prüfsumme über Start-Code S und Maskeninhalte M1 & M2:

Vorgehen:

  1. jedes linke Halbbyte zählt einfach, jedes rechte Halbbyte zählt doppelt
  2. aus allen einzelnen Werten von 1. werden jeweils Quersummen gebildet und diese summiert
  3. Die Prüfsumme ist 10-(Summe aus 2. modulo 10)
                S----------|M1------|M2---------
Am Beispiel  :  87 11 00 03 33 55 54 31 2C 32 33:
1xl          :  8 +1 +0 +0 +3 +5 +5 +3 +2 +3 +3
Quersumme 1xl:  8 +1 +0 +0 +3 +5 +5 +3 +2 +3 +3 =33
2xr          :  14+ 2+ 0+ 6+ 6+10+ 8+ 2+24+ 4+ 6
Quersumme 2xr:   5+ 2+ 0+ 6+ 6+ 1+ 8+ 2+ 6+ 4+ 6=46
---------------------------------------------------
Summe:                                           79
10-(Summe modulo 10):                             1
===================================================

XOR

Bildung der XOR-Prüfsumme am Beispiel:

0F 04 87 11 00 03 03 33 55 54 14 31 2C 32 33

Die Operation erfolgt in Übertragungsreihenfolge (erst niederwertiges Halbbyte, dann höherwertiges, 0F⇒F0, 04⇒40, …)

F0 40 78 11 00 30 30 33 55 45 41 13 C2 23 33

Berechnung

0x0 ⊕ 0x4 ⊕ 0x0 ⊕ 0x7 ⊕ 0x8 ⊕ 0x1 ⊕ 0x1 ⊕ 0x0 ⊕ 0x0 ⊕ 0x3 ⊕
0x0 ⊕ 0x3 ⊕ 0x0 ⊕ 0x3 ⊕ 0x3 ⊕ 0x5 ⊕ 0x5 ⊕ 0x4 ⊕ 0x5 ⊕ 0x4 ⊕
0x1 ⊕ 0x1 ⊕ 0x3 ⊕ 0xC ⊕ 0x2 ⊕ 0x2 ⊕ 0x3 ⊕ 0x3 ⊕ 0x3
= 0xD

Flickercode Übertragung

Die optischen Eingänge des TAN-Generators nehmen ein Taktsignal und je ein Halbbyte (4 bit, auch genannt Nibble) an Daten entgegen. Die Abfolge der Signalfelder ist wie folgt (auf dem Bildschirm).

Feld 1 Feld 2 Feld 3 Feld 4 Feld 5
Takt 2^0 2^1 2^2 2^3

Der eigentlichen Übertragung wird eine statische Synchronisationssequenz vorgelagert:

Feld 1 Feld 2 Feld 3 Feld 4 Feld 5
10000
00000
11111
01111
11111
01111
11111

Funfact/Eselsbrücke: Betrachtet man nur die Felder 2-5 bei wechselndem Takt: 0x0 0xf 0xf ⇒ hex-speak: „Off“, gefolgt von Takt=0b1, Rest=0xf.

Im Anschluss werden die Flickerdaten, jeweils beginnend mit dem niederwertigsten Halbbyte, übertragen. Mit der steigenden Flanke des Takts beginnt ein neues Halbbyte.

Am Beispiel von 0F0487…:

Wert Takt 2^0 (1) 2^1 (2) 2^2 (4) 2^3 (8)
F11111
01111
010000
00000
410010
00010
011000
01000
711110
01110
810001
00001

Flicker zum "Mitschreiben"

  1. Flicker-GIF von Onlinebanking-Service erzeugen lassen
    • wget --no-check-certificate -Oflicker.gif 'https://Homebankingserver/InternetPortalStruts/CreateFlickerImage?data=...&fps=10'
    • z.B.
      wget --no-check-certificate -Oflicker.gif 'https://bankingportal.frankfurter-sparkasse.de/InternetPortalStruts/CreateFlickerImage?data=0F04871100030333555414312C32331D&fps=10'
  2. herunterladen
  3. mit „gimp“ öffnen und Layer-Ansicht anzeigen (Beispiel)

Flickercode-Generator in bash flicker.sh

JS Flickercode-Generator mit Checksummenberechnung: http://6xq.net/blog/2010/flickercodes/flickercode.html

TAN-Generator

Zur TAN-Erzeugung wird die Bankkarte in den TAN-Generator gesteckt und mit der Funktionstaste „F“ das Einlesen gestartet. Der Flickercode wird über die Fototransistoren auf der Rückseite eingelesen.

Die Tests erfolgten größtenteils mit einem REINER SCT tanJack® optic SR.

Bild Quelle: REINER SCT

Die Schritte im Einzelnen:

Initialisierung

Nach dem Einstecken der Bankkarte ist mit einem Logic Analyzer Saleae Logic folgendes an Kontakten der Smartcard zu beobachten:

Bild Quelle: Wikimedia Commons

Die Kommunikation im Weiteren auf der I/O-Leitung zwischen Terminal und Karte wurde mittels Bus Pirate v2go mitgeschnitten.

Testaufbau

Die Signalleitungen VCC, RST, CLK, GND, I/O müssen zwischen Terminalinterface (im Bild unter Zuhilfenahme eines passenden dünnen Platine) und der Chipkarte 1:1 verbunden werden. Die Signalleitungen GND, CLK und I/O werden des weiteren dem Bus Pirate zugeführt:

Signalleitung Bus Pirate Pin
GND GND
CLK AUX
I/O MISO

Folgende Firmwareversion des Bus Pirate kam zum Einsatz:

HiZ>i
Bus Pirate v3.a
Firmware v6.1 r1676  Bootloader v4.1
DEVID:0x0447 REVID:0x3042 (24FJ64GA002 B4)
http://dangerousprototypes.com
HiZ>

Parametrisierung des Bus Pirate

Um die Kommunikation mitschneiden zu können muss Anfangs muss die vom TAN-Generator der Karte vorgegebene Taktfrequenz ermittelt werden. Zu diesem Zweck bietet der Bus Pirate eine Frequenzmessung auf dem AUX PIN an; welche mit dem Befehl „f“ aufgerufen wird. Es ist empfehlenswert, diesen Vorgang mehrmals zu wiederholen. Die Messung ist nur nach dem Einführen der Karte in den Generator und während der Kommunikation mit der Karte möglich. Der Bus Pirate benötigt ein über eine Sekunde dauerhaft anliegendes Takt-Signal.

HiZ>ffffff
AUX Frequency:  autorange 0 Hz
AUX Frequency:  autorange 392,394 Hz
AUX Frequency: 450,304 Hz
AUX Frequency: 1,644,800 Hz
AUX Frequency:  autorange 392,394 Hz
AUX Frequency:  autorange 0 Hz
HiZ>

Mit Hilfe der Taktrate kann der Wert des BRG errechnet werden (vgl. Berechnung BRG):

(4000000/1644800*372)-1 = 903,66926 => 904

Damit kann nun der UART-Modus des Bus Pirate parametrisiert werden:

HiZ>m3
Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value

(1)>10
Raw value for BRG (MIDI=127)

(34)>904
Data bits and parity:
1. 8, NONE *default 
2. 8, EVEN 
3. 8, ODD 
4. 9, NONE
(1)>2
Stop bits:
1. 1 *default
2. 2
(1)>2
Receive polarity:
1. Idle 1 *default
2. Idle 0
(1)>
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)

(1)>
Ready

Mit „{“ wird die Ausgabe gestartet:

UART>{
UART LIVE DISPLAY, } TO STOP
UART>
READ: -f 0x00
UART>

Damit gibt der Bus Pirate die einzelnen Bytes in folgendem Format aus:

UART>
READ: 0x3B
UART>
READ: 0xFF
UART>
READ: 0x18
UART>
READ: 0x00
UART> ...

In den nachfolgenden Schritten werden die Byte mit Leerzeichen getrennt und, der Übersicht zuliebe, ohne 0x-Präfix dargestellt. Mit „T→C“ ist im Folgenden die Kommunikation vom TAN-Generator/Terminal zur Karte markiert, von der Karte zum Terminal mit „T←C“.

ATR

Nach dem Anlegen der RST-Signals liefert die Karte den ATR (Answer to Reset) aus und der TAN-Generator überprüft, ob die ZKA TAN-Generatoranwendung angewählt werden kann. Im Anschluss beendet der Generator wieder die Kommunikation mit der Karte (alle Kontakte LOW) bis der Benutzer die Taste „TAN“ oder „F“ betätigt. Es startet die Initialisierungssequenz wie oben und der ATR wird erneut gesendet. In den Beispielen ist der Seriennummer des Chips im ATR mit „SS SS SS SS“ überschrieben.

T→C3B FF 18 00 FF 81 31 FE 45 65 63 11 08 43 02 50 00 10 SS SS SS SS 05 30 6C

Der ATR kann mit dem Script ATR_analysis aus den http://ludovic.rousseau.free.fr/softwares/pcsc-tools/ bequem aufbereitet werden:

(pcsc-tools-1.4.18)$ ./ATR_analysis  3B FF 18 00 FF 81 31 FE 45 65 63 11 08 43 02 50 00 10 SS SS SS SS 05 30 6C
ATR: 3B FF 18 00 FF 81 31 FE 45 65 63 11 08 43 02 50 00 10 SS SS SS SS 05 30 6C
+ TS = 3B --> Direct Convention
+ T0 = FF, Y(1): 1111, K: 15 (historical bytes)
  TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
    129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
  TB(1) = 00 --> VPP is not electrically connected
  TC(1) = FF --> Extra guard time: 255 (special value)
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 
-----
  TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 
-----
  TA(3) = FE --> IFSC: 254
  TB(3) = 45 --> Block Waiting Integer: 4 - Character Waiting Integer: 5
+ Historical bytes: 65 63 11 08 43 02 50 00 10 SS SS SS SS 05 30
  Category indicator byte: 65 (proprietary format)
+ TCK = 6C (correct checksum)

Demnach hat der Datenaustausch mit der Karte nach dem T=1 Protokoll zu erfolgen (auch ersichtlich an TCK. TCK wird nur bei T=1 gesendet).

T=0 vs. T=1

T=0

Byteorientiertes Protokoll. Jedem übertragenem Byte wird ein Parity-Bit angehängt. Ist die Parity nicht korrekt zieht der Empfänger die Leitung I/O auf HIGH und der Sender wiederholt anschließend das Byte.

T=1

Blockorientiertes Protokoll. Die Kommandos und Antworten werden mit einem Header eingeleitet, am Stück übertragen und eine XOR-Prüfsumme angehängt. Bei einem Übertragungsfehler wird vom Empfänger der Block erneut angefordert (mit einer Steuernachricht).

Aufbau der Nachrichten:

I Block (normale Datenübertragung)

b8b7b6b5b4b3b2b1
0Sende Sequenz (abwechselnd 0 und 1)1: weiterer verketteter Datenblock folgt, sonst 00 (RFU)0 (RFU)0 (RFU)0 (RFU)0 (RFU)

R Block (Status)

b8b7b6b5b4b3b2b1
100 (RFU)Empfangs Sequenz (abwechselnd 0 und 1)0 (RFU)0 (RFU)00: kein Fehler
01: Checksummen- oder Parityfehler
1: anderer Fehler0

S Block (Protokollsteuerung)

b8b7b6b5b4b3b2b1
110: Request, 1: Response00001: Resync
1: Information Field Size (IFS)0

IFS gibt die Puffergröße an, es wird hierbei zwischen Terminal und Karte unterschieden

Quelle, abseits eingeschränkt verfügbarer ISO-Standards: http://www.panstruga.de/ct-api/spec/mktp2v09.ps.gz

Historical Bytes

Die „Historical Bytes“ (im Beispiel „65 63 11 08 43 02 50 00 10 SS SS SS SS 05 30“, siehe oben) des ATR haben bei SECCOS Karten folgende Bedeutung (Quelle)

Feld (1 Byte)Wert
fix65
fix63
IC manufacturer ID11
Manufacturer’s IC type ID08
Manufacturer’s ROM mask ID43
Embedder country code02
Embedder country code50
Embedder national registration ID00
Embedder national registration ID10
Chip series numberSS
Chip series numberSS
Chip series numberSS
Chip series numberSS
Manufacturer OS Version (major version number)05
Manufacturer OS Version (minor version number)30

Die SECCOS-Version, hier „05.30“, ist von besonderer Bedeutung, da ab Version 6.0 der Ablauf geringfügig abweicht.

T=1 IFSD

Nachdem die Karte dem Terminal im ATR mitgeteilt hat, dass die Datenübertragung via T=1 erfolgt, wird ein S-Block Request geschickt um den IFSD zu erhöhen.

Das Terminal (T) teilt der Karte (C) per S-Block Request (110. ….) die Größe (FE = 254 byte) des Empfangspuffers IFSD (…. …1) mit:

T→C00 C1 01 FE 3E

Die Karte bestätigt dies per S-Block Response (111. ….).

T←C00 E1 01 FE 1E

Ab diesem Zeitpunkt folgen nur noch I Blöcke zwischen Terminal und Karte - die eigentliche Kommunikation.

Innerhalb einer PCSC-Applikation können diese nachfolgenden APDUs direkt verwendet werden (ohne die vorderen drei T=1-Header- und das abschließende Prüfsummen-Byte)

SELECT FILE

Im ersten Schritt wird mittels SELECT FILE die Datenstruktur des TAN-Generator ausgewählt. AID ermittelt in Chipcard Master:

T=1 HeaderAPDUT=1 XOR
T→C00 00 0E00 A4 04 0C 09 D2 76 00 00 25 54 44 01 003B
T←C00 00 0290 0092

AID

Aufbau des AID (Application Identifier) aus RID (Registered Application Identifier) und PIX (Proprietary Application Identifier Extension) am Beispiel von „D2 76 00 00 25 54 44 01 00“:

AID: D2 76 00 00 25 54 44 01 00
RID: D2 76 00 00 25
     D: "national registration"
      2 76: ISO 3166 Country Code Deutschland
           00 00 25: ZKA?
PIX:                54 44 01 00: TAN Anwendung DF_TAN

PIX 54440100 vgl. TAN Anwendung DF_TAN

GET PROCESSING OPTIONS

Nachfolgend wird das EMV Kommando GET PROCESSING OPTIONS (vgl. z.B. http://blog.saush.com/2006/09/08/getting-information-from-an-emv-chip-card/) abgesetzt; damit wird eine neue Transaktion gestartet.

GET PROCESSING OPTS ohne Parameter 83 00:

T=1 HeaderAPDUT=1 XOR
T→C00 40 0880 A8 00 00 02 83 00 00E1
T←C00 40 0E77 0A 82 02 18 00 94 04 08 02 04 00 90 00A5

Aufbau der Antwort (EMV TLV, http://www.emvlab.org/emvtags/all/):

77 0A 82 02 18 00 94 04 08 02 04 00
      82 Application Interchange Profile: 18 00
         Byte 1: bit 8: 1 = Initiate (not supported)
                 bit 7: 1 = Offline static data authentication is supported
                 bit 6: 1 = Standard offline dynamic data authentication is supported
                 bit 5: 1 = Cardholder verification is supported
                 bit 4: 1 = Terminal Risk Management is to be performed
                 bit 3: 1 = Issuer Authentication is supported
                 bit 2: 1 = Combined DDA/AC Generation is supported
                 bit 1: RFU (0)
         Byte 2: RFU (“00”)
                  94 Application File Locator (AFL): 08 02 04 00
                     Indicates the location (SFI, range of records) of
                     the AEFs related to a given application

READ RECORD

Kartendaten einlesen, u.A. Kartennummer (wie Geldkarte, http://ftp.ccc.de/docs/cards/geldkarte.pdf)

T=1 HeaderAPDUT=1 XOR
T→C00 00 0500 B2 01 BC 000A
T←C00 00 1A67 mm mm MM NN NN NN NN NN 9D 10 12 06 07 10 02 80 45 55 52 01 3F 00 01 90 00..

Antwort der Karte gem. geldkarte.pdf:

67 mm mm MM NN NN NN NN NN 9D 10 12 06 07 10 02 80 45 55 52 01 3F 00 01
67: Branchenhauptschlüssel
   mm mm MM: "Kurz-BLZ" kartenausgebendes Institut
            NN NN NN NN NN: individuelle Kartennummer
                           9D: Prüfziffer über 67 MM MM MM NN NN NN NN NN
                              10 12: Verfalldatum der ec-Karte
                                    06 07 10: Aktivierungsdatum der ec-Karte
                                             02 80: Ländercode
                                                   45 55 52: Währungskennzeichen 'EUR'
                                                            01: Wertigkeit der Währung
                                                               3F: Freier Zähler für die Schlüsselerzeugung
                                                                  00 01

SEARCH RECORD IPB

Eine Art Volltextsuche in den Dateien der Karte. Es können keine Spezifikationen dieses Befehls gefunden werden. er ist vermutlich angelehnt an SEARCH RECORD (00 A2) aus der nicht offen gelegten Spezifikation ISO/IEC 7816-9, jedoch sind Informationen aus GSM-Standard ableitbar: CR #0019

Suche nach Tag „9F56“ (issuer proprietary bitmap, „Bitfilter“ (vgl. Optimised to Fail: Card Readers for Online Banking, Seite 30)

SECCOS vor 6.0

T=1 HeaderAPDUT=1 XOR
T→C00 40 0F00 A2 01 0F 09 04 00 CE 9F 56 00 00 00 FF 0016
T←C00 40 1E03 70 19 9F 55 01 38 9F 56 12 00 00 03 FF FF 80 00 00 00 00 00 00 00 00 00 08 00 00 90 0007

SECCOS ab 6.0

T=1 HeaderAPDUT=1 XOR
T→C00 40 0F00 A2 01 0F 09 04 00 CE 9F 56 00 00 00 FF 0016
T←C00 40 1E03 70 19 9F 55 01 *00* 9F 56 12 00 00 03 FF FF 80 00 00 00 00 00 00 00 00 00 08 00 00 90 003F

Antwort der Karte gem. EMV TLV:

03 70 19 9F 55 01 38 9F 56 12 00 00 03 FF FF 80 00 00 00 00 00 00 00 00 00 08 00 00
         9F 55 01: issuer authentication flag (vermutlich ebenfalls Teil der Speicherstelle?), Länge
                  38: Wert (00 bei SECCOS ab Version 6.0)
                     9F 56 12: issuer proprietary bitmap, Länge
                              00 00 03 FF FF 80 00 00 00 00 00 00 00 00 00 08 00 00: Wert

SEARCH RECORD CDOL (SECCOS ab 6.0)

Ab SECCOS Version 06.00 setzt der TAN-Generator einen weiteren SEARCH RECORD-Aufruf für die Suche nach „8C“ ab. Das Feld „8C“ wird im EMV Standard CDOL1 bezeichnet und legt normalerweise fest, welche Daten dem später folgendem GENERATE AC Kommando übergeben werden sollen.

T=1 HeaderAPDUT=1 XOR
T→C00 .. 0E00 A2 01 0F 08 04 00 CE 8C 00 00 00 FF 00..
T←C00 .. 3302 70 2E 8C 21 9F 02 06 9F 03 06 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 9F 4C 08 9F 45 02 9F 33 03 9F 1A 02 9F 35 01 8D 09 91 10 8A 02 95 05 9F 37 04 90 00..

Die Antwort enthalt sowohl CDOL1 als auch CDOL2 (letzteres wird üblicherweise für einen zweiten GENERATE AC Aufruf verwendet, dieser entfällt jedoch bei der TAN-Generierung). Aufgeschlüsselt gemäß http://www.emvlab.org/emvtags/all/ ergibt sich folgende Aufstellung. In der Darstellung findet sich vor dem Bindestrich das Feldkennzeichen (Tag), dahinter die Längenangabe.

CDOL1 8C 21 9F02-06 Amount, Authorised (Numeric)    1A 29 37 0D 90 46
            9F03-06 Amount, Other (Numeric)         F7 A6 6C F7 62 5C
            95-05   Terminal Verification Results   53 25 51 78 4E
            5F2A-02 Transaction Currency Code       5E 09
            9A-03   Transaction Date                64 00 00
            9C-01   Transaction Type                00
            9F37-04 Unpredictable Number            00 00 00 00
            9F4C-08 ICC Dynamic Number              00 00 00 00 00 00 00 00
            9F45-02 Data Authentication Code        00 00
            9F33-03 Terminal Capabilities           00 00 00
            9F1A-02 Terminal Country Code           00 00
            9F35-01 Terminal Type                   00

CDOL2 8D 09 91-10   Issuer Authentication Data
            8A-02   Authorisation Response Code
            95-05   Terminal Verification Results
            9F37-04 Unpredictable Number

Den Beobachtungen nach ist nur die Summe der Längenangaben (hier 0x2B) für das spätere GENERATE AC der TAN-Generierung relevant.

VERIFY

Der nachfolgende Befehl VERIFY führt i.d.R. eine PIN-Verifikation durch. Bei deutschen Karten wird jedoch darauf verzichtet. Da einem späterem GENERATE AC ein VERIFY-Aufruf vorausgehen muss, wird stellvertretend das letzte Byte der Kurz-BLZ und die Kartennummer (MM NN NN NN NN NN) übergeben (siehe oben aus READ RECORD).

T=1 Header APDU T=1 XOR
T→C 00 00 0D 00 20 00 81 08 2C MM NN NN NN NN NN FF ..
T←C 00 00 02 90 00 92

HASH (PERFORM SECURITY OPERATION, 00 2A)

Nach dem Scan und Bestätigung oder Eingabe der Transaktionsdaten (Kontonummer, Betrag) wird in zwei Schritten die eigentliche TAN ermittelt.

Die Transaktionsdaten werden mit ihren Maskenbezeichnungen vorweg aufbereitet und der der Karte übergeben, welche daraus einen Hash (SHA1) errechnet. Auch hier gibt es, ähnlich wie beim Flickercode eine Markierung ob es sich um DIN-66003 (0xE1) und BCD (0xE0) handelt.

T=1 Header APDU T=1 XOR
T→C 00 40 3C 00 2A 90 A0 36 90 00 80 81 31 E1 53 74 61 72 74 2D 43 6F 64 65 3A E0 87 11 00 03 E1 4B 6F 6E 74 6F 6E 75 6D 6D 65 72 E1 33 33 35 35 35 34 E1 42 65 74 72 61 67 E1 31 2C 32 33 B6 00 CF
T←C 00 40 16 4B 4E 0A C4 13 E1 9D 4F A9 CA 17 7B 76 D4 AA 0B 5E 42 09 1C 90 00 28

Bezeichnung der „Nutz-Daten“ u.U. „VisDataSig“? (vgl. FinTS 3.0 Security Alternative Sicherheitsverfahren, B.5.1): Aufbau:

HASH  P1 P2 Le              1 a   S  t  a  r  t  -  C  o  d  e  : b  87 11 00 03 a   K  o  n  t  o  n  u  m  m  e  r  a  3  3  5  5  5  4 ..
00 2A 90 A0 36 90 00 80 81 31 E1 53 74 61 72 74 2D 43 6F 64 65 3A E0 87 11 00 03 E1 4B 6F 6E 74 6F 6E 75 6D 6D 65 72 E1 33 33 35 35 35 34 ..

  ..  a  B  e  t  r  a  g  a  1  ,  2  3  ¶x
  .. E1 42 65 74 72 61 67 E1 31 2C 32 33 B6 00

¶, hier B6 = B0 + Anzahl der Felder (hier 6)

PERFORM SECURITY OPERATION, Schachtelung der Daten für 00 2A 90 A0

 90 00    -> Tag/Len für bereits vorberechneten Hash (0, nicht vorhanden)
 80 81 31 -> Tag/Len für die Daten der Hashberechnung (Länge 0x31)
 E1 53 74 61 72 74 2D 43 6F 64 65 3A E0 87 11 00
 03 E1 4B 6F 6E 74 6F 6E 75 6D 6D 65 72 E1 33 33
 35 35 35 34 E1 42 65 74 72 61 67 E1 31 2C 32 33
 B6

Verifikation

$ xxd -r -p <<<"E1 53 74 61 72 74 2D 43 6F 64 65 3A E0 87 11 00 03 E1 4B 6F 6E 74 6F 6E 75 6D 6D 65 72 E1 33 33 35 35 35 34 E1 42 65 74 72 61 67 E1 31 2C 32 33 B6" | sha1sum 
4b4e0ac413e19d4fa9ca177b76d4aa0b5e42091c  -
$

GENERATE AC

Erzeugung des Application Cryptograms. Bei SECCOS vor 6.0 werden 4 Byte des Hashes in eine ansonsten statische Struktur eingebettet übergeben. Ab SECCOS 6.0 wird der komplette Hashwert von 20 Byte verwendet und mit 23 Null-Bytes (0x00) auf insgesamt 0x2B (vgl. oben: SEARCH RECORD CDOL) Bytes aufgefüllt. In das Cryptogram fließen zudem karteninterne Daten/Schlüsselmaterial ein. Die Antwort der Karte ist nicht abhängig von der eingesetzten SECCOS Version.

SECCOS vor 6.0

T=1 HeaderAPDUT=1 XOR
T→C00 00 3180 AE 00 00 2B 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00 09 99 00 00 00 00 4B 4E 0A C4 00 00 00 00 00 00 00 00 00 00 20 80 00 00 00 34 007B
T←C00 00 2277 1E 9F 27 01 00 9F 36 02 01 02 9F 26 08 EC F5 0D 2C 1E AF 4E E2 9F 10 07 03 82 01 00 31 00 00 90 0067

SECCOS ab 6.0

T=1 HeaderAPDUT=1 XOR
T→C00 .. 3180 AE 00 00 2B 4B 4E 0A C4 13 E1 9D 4F A9 CA 17 7B 76 D4 AA 0B 5E 42 09 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00..
T←C00 .. 2277 1E 9F 27 01 00 9F 36 02 01 02 9F 26 08 EC F5 0D 2C 1E AF 4E E2 9F 10 07 03 82 01 00 31 00 00 90 00..

Antwort der Karte (EMV TLV):

77 1E 9F 27 01 00 9F 36 02 01 02 9F 26 08 EC F5 0D 2C 1E AF 4E E2 9F 10 07 03 82 01 00 31 00 00
77 Response Message Template Format 2 
      9F 27 Cryptogram Information Data (cid)
               00
                  9F 36 Application Transaction Counter (ATC)
                           01 02
                                 9F 26 Application Cryptogram (ac)
                                          EC F5 0D 2C 1E AF 4E E2
                                                                  9F 10 Issuer Application Data
                                                                           03 82 01 00 31 00 00

Ableitung der TAN

Aus der Antwort der Karte wird nun final die TAN gebildet. Dazu werden die Nutzdaten der GENERATE_AC-Antworten aneinandergereit und mit dem Bitfilter (IPB) ver-AND-ed:

Daten: 000102ECF50D2C1EAF4EE203820100310000
IPB  : 000003FFFF80000000000000000000080000

Daten: 000000000000000100000010111011001111010100001101001011000001111010101111010011...
IPB  : 000000000000000000000011111111111111111110000000000000000000000000000000000000...
AND  :                       1011101100111101010

Daten: ...101110001000000011100000100000000100000000001100010000000000000000
IPB  : ...000000000000000000000000000000000000000000000010000000000000000000
AND  : ...                                              0
Im Weiteren werden nur noch die Bit-Stellen aus den Daten verwendet, welche im Bit-Filter an korrespondierender Stellen mit 1 gekennzeichnet sind. Es entsteht eine komprimierte Darstellung.
Komprimiert: 10111011 0011 11010100
Im letzen Schritt werden die letzten acht Bit (LSBs) an den Anfang der Bitfolge gestellt (LEFT ROTATE 8) und die Zahl in Dezimalschreibweise dargestellt.
LEFT ROTATE um acht Bit:
                        11 11010100
             10111011
         =>  10111011   11 11010100
         => 251067

Damit ist die passende TAN 251067 zur Überweisung gefunden. Das Banksystem kann unter Anwendung der selben Eingangsdaten die TAN verifizieren.

Ist ein siebenstelliger TAN das Ergebnis, wird dieses verworfen und der Generator wiederholt die Schritte SELECT FILE, GET PROCESSING OPTIONS, READ RECORD und GENERATE AC mit dem bereits im ersten Durchgang erzeugten Hash. Durch den dann erhöhten ATC kommt ein neuer Wert zustande.

Für Tests und die Verifikation von Vermutungen kam der Smart Card Detective zum Einsatz. Dieser unterstützt leider nur das Protokoll T=0; kann jedoch mit Quellcodemodfikationen zum „blinden“ Senden von Kartenantworten an den TAN-Generator verwendet werden. Mit Hilfe des SCD konnte der „Bit-Mix“ (IPB-anding, LEFT ROTATE, etc.) aus der Antwort auf GENERATE AC erkannt und rekonstruiert werden.