====== 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" ({{:projekte:tangenerator:createflickerimage.gif?linkonly|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.
=== 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 [[http://de.wikipedia.org/wiki/Luhn-Algorithmus|Luhn-Prüfsumme]] über Start-Code S und Maskeninhalte M1 & M2:
Vorgehen:
-jedes linke Halbbyte zählt einfach, jedes rechte Halbbyte zählt doppelt
-aus allen einzelnen Werten von 1. werden jeweils Quersummen gebildet und diese summiert
-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 ====
{{:projekte:tangenerator:tanjack_hinten.png?100|}}
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 ^
|1|0|0|0|0|
|0|0|0|0|0|
|1|1|1|1|1|
|0|1|1|1|1|
|1|1|1|1|1|
|0|1|1|1|1|
|1|1|1|1|1|
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) ^
|F|1|1|1|1|1|
| |0|1|1|1|1|
|0|1|0|0|0|0|
| |0|0|0|0|0|
|4|1|0|0|1|0|
| |0|0|0|1|0|
|0|1|1|0|0|0|
| |0|1|0|0|0|
|7|1|1|1|1|0|
| |0|1|1|1|0|
|8|1|0|0|0|1|
| |0|0|0|0|1|
=== Flicker zum "Mitschreiben" ===
-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'
-herunterladen
-mit "gimp" öffnen und Layer-Ansicht anzeigen ({{:projekte:tangenerator:gimpflicker.png?linkonly|Beispiel}})
=== Links ===
Flickercode-Generator in bash [[https://chaos.expert/ccc-ffm/smartkram/-/blob/master/chiptan/flicker/flicker.sh|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 [[http://www.reiner-sct.com/index.php?option=content&task=view&id=188|REINER SCT tanJack® optic SR]].
{{:projekte:tangenerator:tanjack.png?nolink&100|}}
[[http://www.reiner-sct.com/content/view/189/143/|Bild Quelle: REINER SCT]]
Die Schritte im Einzelnen:
==== Initialisierung ====
Nach dem Einstecken der Bankkarte ist mit einem Logic Analyzer [[http://www.saleae.com/logic|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
{{:projekte:tangenerator:500px-smartcardpinout.svg.png?200|}}
[[http://commons.wikimedia.org/wiki/File:SmartCardPinout.svg|Bild Quelle: Wikimedia Commons]]
Die Kommunikation im Weiteren auf der I/O-Leitung zwischen Terminal und Karte wurde mittels [[http://dangerousprototypes.com/bus-pirate-manual/|Bus Pirate v2go]] mitgeschnitten.
=== Testaufbau ===
{{:projekte:tangenerator:pbsetup.jpg?200|}}
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. [[http://wiki.yobi.be/wiki/Bus_Pirate#7816-3_T.3D0_at_arbitrary_baudrate|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 ([[http://de.wikipedia.org/wiki/Answer_to_Reset|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→C|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|
Der ATR kann mit dem Script ATR_analysis aus den [[pcsc-tools|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:
*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)
^b8^b7^b6^b5^b4^b3^b2^b1^
|0|Sende Sequenz (abwechselnd 0 und 1)|1: weiterer verketteter Datenblock folgt, sonst 0|0 (RFU)|0 (RFU)|0 (RFU)|0 (RFU)|0 (RFU)|
R Block (Status)
^b8^b7^b6^b5^b4^b3^b2^b1^
|1|0|0 (RFU)|Empfangs Sequenz (abwechselnd 0 und 1)|0 (RFU)|0 (RFU)|0|0: kein Fehler|
| | | | | | |0|1: Checksummen- oder Parityfehler|
| | | | | | |1: anderer Fehler|0|
S Block (Protokollsteuerung)
^b8^b7^b6^b5^b4^b3^b2^b1^
|1|1|0: Request, 1: Response|0|0|0|0|1: Resync|
| | | | | | |1: Information Field Size (IFS)|0|
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]]
=== 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 ([[http://ftp.ccc.de/docs/cards/geldkarte.pdf|Quelle]])
^Feld (1 Byte)^Wert^
|fix|65|
|fix|63|
|IC manufacturer ID|11|
|Manufacturer’s IC type ID|08|
|Manufacturer’s ROM mask ID|43|
|Embedder country code|02|
|Embedder country code|50|
|Embedder national registration ID|00|
|Embedder national registration ID|10|
|Chip series number|SS|
|Chip series number|SS|
|Chip series number|SS|
|Chip series number|SS|
|Manufacturer OS Version (major version number)|05|
|Manufacturer OS Version (minor version number)|30|
Die [[http://www.seccos.info/|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→C|00 C1 01 FE 3E|
Die Karte bestätigt dies per S-Block Response (111. ....).
|T←C|00 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 [[http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_6_basic_interindustry_commands.aspx#chap6_11|SELECT FILE]] die Datenstruktur des TAN-Generator ausgewählt.
AID ermittelt in [[http://chipcardmaster.de/|Chipcard Master]]:
{{:projekte:tangenerator:chipcardmaster.png?200|}}
^↔^T=1 Header^APDU^T=1 XOR^
|T→C|00 00 0E|00 A4 04 0C 09 D2 76 00 00 25 54 44 01 00|3B|
|T←C|00 00 02|90 00|92|
=== 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. [[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte03/0386a_pdf.pdf|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 Header^APDU^T=1 XOR^
|T→C|00 40 08|80 A8 00 00 02 83 00 00|E1|
|T←C|00 40 0E|77 0A 82 02 18 00 94 04 08 02 04 00 90 00|A5|
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 Header^APDU^T=1 XOR^
|T→C|00 00 05|00 B2 01 BC 00|0A|
|T←C|00 00 1A|67 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. [[http://ftp.ccc.de/docs/cards/geldkarte.pdf|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: [[http://www.3gpp.org/ftp/Specs/html-info/31101-CRs.htm|CR #0019]]
Suche nach Tag "9F56" (issuer proprietary bitmap, "Bitfilter" (vgl. [[http://www.cl.cam.ac.uk/~sjm217/talks/ccc09optimised.pdf|Optimised to Fail: Card Readers for Online Banking]], Seite 30)
SECCOS vor 6.0
^↔^T=1 Header^APDU^T=1 XOR^
|T→C|00 40 0F|00 A2 01 0F 09 04 00 CE 9F 56 00 00 00 FF 00|16|
|T←C|00 40 1E|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 90 00|07|
SECCOS ab 6.0
^↔^T=1 Header^APDU^T=1 XOR^
|T→C|00 40 0F|00 A2 01 0F 09 04 00 CE 9F 56 00 00 00 FF 00|16|
|T←C|00 40 1E|03 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 00|3F|
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 Header^APDU^T=1 XOR^
|T→C|00 .. 0E|00 A2 01 0F 08 04 00 CE 8C 00 00 00 FF 00|..|
|T←C|00 .. 33|02 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 [[https://de.wikipedia.org/wiki/DIN_66003|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. [[https://web.archive.org/web/20130903015705/https://www.hbci-zka.de/dokumente/spezifikation_deutsch/FinTS_3.0_Security_Alternative_Sicherheitsverfahren_Rel_20091215_final_version.pdf|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 Header^APDU^T=1 XOR^
|T→C|00 00 31|80 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 00|7B|
|T←C|00 00 22|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 90 00|67|
SECCOS ab 6.0
^↔^T=1 Header^APDU^T=1 XOR^
|T→C|00 .. 31|80 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←C|00 .. 22|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 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 [[http://www.cl.cam.ac.uk/~osc22/scd/|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.