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.

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?

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

• Adobe Flash Film
• Javascript & DOM
• animiertes GIF
• Java-Applet
• innerhalb einer nativen Applikation (z.B. StarMoney)

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.

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.

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

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.

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
===================================================

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

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).

Der eigentlichen Übertragung wird eine statische Synchronisationssequenz vorgelagert:

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…:

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

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:

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

• Spannungsversorgung via VCC startet
• I/O wird auf HIGH gesetzt
• das CLK-Signal startet
• RST wird auf HIGH gesetzt

Bild Quelle: Wikimedia Commons

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

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:

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>

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“.

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.

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).

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.

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:

• 1 Byte NAD (Node Address Byte)
• 1 Byte PCB (Protocol Control Byte)
  • I Information Block
  • R Receive Ready Block
  • S Supervisory Block
• 1 Byte Länge 0..254 (FE)
• 0..254 Byte Daten
• 1 Byte XOR Prüfsumme ab und inkl. NAD

• NAD ist immer 0x00 (vorgesehen für zukünftige Verwendung)
• PCB siehe Tabellen unten

I Block (normale Datenübertragung)

R Block (Status)

S Block (Protokollsteuerung)

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

• IFSD: Empfangspuffer des Terminals; Startwert 32 Byte
• IFSC: Empfangspuffer der Karte wird im ATR mitgeteilt (siehe oben: 0xFE, 254)

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

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)

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

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:

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

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)

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

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

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:

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

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

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

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

SECCOS ab 6.0

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

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.

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.

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).

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.

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)

 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

$ 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  -
$

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

SECCOS ab 6.0

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

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.