ChipTAN: Difference between revisions
No edit summary |
|||
(19 intermediate revisions by 3 users not shown) | |||
Line 4: | Line 4: | ||
== Herangehensweise == |
== Herangehensweise == |
||
*>hier Bild vom Aufbau< |
|||
*'''Die ersten Schritte''' |
|||
*Beschreibung des Aufbaus |
|||
*wie wollten wir das ganze machen also seriell zu byte mit dem plugin vom logic analyzer etc. |
|||
Der erste Schritt war der Zusammenbau unser Hardwareunterstüzung, welche uns das Mithören der Kommunikation zwischen Karte und Tan Generator ermöglichen sollte. Die eigentlich Arbeit, das Löten der Komponenten, hat freundlicherweise ?Frank? übernommen. Desweiteren haben wir von unserem Mentor einen Logic Analyzer(inklusiv Software) zur Verfügung gestellt bekommen. Dieser ermöglichte uns das Bitweise mitschneiden des Datenstroms. |
|||
Als nächste haben wir unseren Versuch aufgebaut: |
|||
[[Image:aufbau1.jpg|800x220px|Aufbau]] |
|||
Ein bild fehlt(konnte es nicht hochladen) |
|||
Unser Aufbau an sich ist relativ einfach. Wie man auf den Fotos sieht haben wir unsere Hardwarekomponente zwischen Karte und Generator montiert. Diese Komponente besteht einerseits aus einem Kartenhalter, welcher aus einem Kartenleser stammt und den Kontakt zur Karte herstellt. Dieser Halter ist über einen Bus mit unserem Board verbunden welches als Karte dient und den Kontakt zum TanGenerator herstellt. Darüberhinaus hat das Board einige Anschlüssen an welche wir den Logic Analyzer anschließen können. |
|||
*'''Analyse Methode''' |
|||
Unsere erste Analyse bestand darin, statt einem TanGenereator einen Komfortleser zu benutzen und mitzuhören was übertragen wird, wenn man die Karte in den Leser steckt. Der Logic Analyzer stellt, in der mitgelieferten Software, den Datenstrom als High/Low Flanken, in Abhängigkeit von der vergangen Zeit, zur Verfügung. Nun haben wir angefangen das Signal mittels Literatur/ISO-Standard zu analysieren. Die Software bietet hierführ die Möglichkeit eine Art Parser auf das Signal "anzusetzen" um die zusammengehörenden Bits, im Datenstrom, als Byte darzustellen. Diesen Bytestrom konnte man sich in einem Exportfile ausgeben lassen. |
|||
Nun haben wir parallel an zwei Programmen gearbeitet. Zum einem Bestand die Möglichkeit das Exportfile zu modifizieren und mit den Bytes gleich die Bedeutung dieses mitauszugeben. Zum anderen haben wir ein Programm geschrieben welches den Bytestrom als Input bekommt und darauf die gewonnen Steuer-Informationen/Daten ausgibt. Nun hatten wir ein Werkzeug in der Hand welches die Analyse des Datenaustausches zwischen Karte und Terminal stark vereinfacht, da wir uns alle relevanten Daten für die weiter Analyse ausgeben lassen konnten. |
|||
Für unsere Analyse haben wir eine komplette Online Überweisung mitgehört und aufgezeichnet. |
|||
Im folgenden finden sich die genauen Ergebnisse unser Analyse. |
|||
== Asychronous Character Transfer == |
== Asychronous Character Transfer == |
||
Die elementare Übertragungseinheit ist ein Character. |
|||
* 1 Byte wird mit 10 Bit übertragen |
* 1 Byte wird mit 10 Bit übertragen |
||
* 1. Bit = Startbit |
* 1. Bit = Startbit |
||
* 2.-9. Bit = Daten |
* 2.-9. Bit = Daten |
||
* 10. Bit = Paritybit |
* 10. Bit = Paritybit |
||
Zwischen der Übertragung zweier Bytes wird eine vorher ausgehandelte Zeit gewartet (I/O Kanal auf High gesetzt) um der Gegenseite die möglichkeit zu geben |
Zwischen der Übertragung zweier Bytes wird eine vorher ausgehandelte Zeit gewartet (I/O Kanal auf High gesetzt) um der Gegenseite die möglichkeit zu geben |
||
das letzte Byte nochmal anzufordern (falls Paritybit falsch war). |
das letzte Byte nochmal anzufordern (falls Paritybit falsch war). |
||
Line 28: | Line 51: | ||
*2. Byte ('''T0''') gibt Anzahl der nachfolgenden Interface Character (TA,TB,TC,TD) und Anzahl der Historical Characters an |
*2. Byte ('''T0''') gibt Anzahl der nachfolgenden Interface Character (TA,TB,TC,TD) und Anzahl der Historical Characters an |
||
*3. Byte ('''TA1''') codiert Übertragungsfrequenz und Teiler die die Karte maximal unterstützt |
*3. Byte ('''TA1''') codiert Übertragungsfrequenz und Teiler die die Karte maximal unterstützt |
||
*'''TA,TB,TC'''-Bytes enthalten Informationen über die Fähigkeiten der Karte in Abhängigkeit vom jeweiligen Übertragungsprotokoll (unterstützte Frequenzen etc.) |
*'''TA<sub>i</sub>,TB<sub>i</sub>,TC<sub>i</sub>'''-Bytes enthalten Informationen über die Fähigkeiten der Karte in Abhängigkeit vom jeweiligen Übertragungsprotokoll (unterstützte Frequenzen etc.) |
||
*'''TD'''-Bytes geben an ob und welche TA,TB,TC,TD im Anschluß gesendet werden (verkettung möglich), das Übertragungsprotokoll wird auch angegeben (in 0x08) |
*'''TD<sub>i</sub>'''-Bytes geben an ob und welche TA,TB,TC,TD im Anschluß gesendet werden (verkettung möglich), das Übertragungsprotokoll wird auch angegeben (in 0x08) |
||
Im Anschluss an die '''TA,TB,TC,TD'''-Bytes folgen die historical Character und ein Checksummen-Byte TCK (XOR-Prüfsumme von T0 bis zum Byte vor TCK) |
Im Anschluss an die '''TA,TB,TC,TD'''-Bytes folgen die historical Character und ein Checksummen-Byte TCK (XOR-Prüfsumme von T0 bis zum Byte vor TCK) |
||
Line 42: | Line 65: | ||
*letztes Byte '''PCK''' XOR-Prüfsumme ab '''PPSS''' |
*letztes Byte '''PCK''' XOR-Prüfsumme ab '''PPSS''' |
||
Das Terminal schickt an die Karte eine solche PPS Datenstruktur. Zur Bestätigung schickt die Karte die gleiche PPS Datenstruktur zurück. |
|||
== Übertragungsprotokoll T=1 == |
|||
Bei der Kommunikation zwischen Chipkarte und ChipTAN-Generator wird (in unserem Fall) das Blockprotokoll T=1 Verwendet. |
|||
Es handelt sich um ein asynchrones Halbduplexprotokoll welches als kleineste Dateneinheit Blöcke überträgt. |
|||
=== Blöcke === |
=== Blöcke === |
||
* Block Typen: |
|||
**Informationsblöcke ('''I-Block''') |
|||
***Austausch von Daten/Kommandos |
|||
**Empfangsbestätigungsblöcke ('''R-Block''') |
|||
***enthalten kein Informationsfeld |
|||
***dienen zur positiven/negativen Empfangsbestätigung |
|||
**Systemblöcke ('''S-Block''') |
|||
***Modifikation von protokollspezifischen Steuerinformationen |
|||
==== Aufbau eines Blocks ==== |
|||
[[Image:Block.png|800x220px|Aufbau eines T=1 Übertragungsblocks]] |
|||
Der Header eines jeden Blocks besteht aus den '''NAD''', '''PCB''', '''LEN'''-Feldern. |
|||
*'''NAD''' Knotenaddresse (ist in unserem Fall, sowie in den meisten anderen auch 0x00) |
|||
*'''PCB''' (Protocol Control Byte) codiert Blocktyp und benötigte Informationen (z.B. Sendefolgenummer) |
|||
*'''LEN''' (Length Field) gibt die Länge des Informationsfeldes in Bytes an |
|||
*'''Informationsfeld''': |
|||
:im Falle eines S-Blocks werden Daten für das Übertragungsprotokoll übertragen |
|||
:im Falle eines I-Blocks wird ein APDU-Kommando übertragen |
|||
Die maximale Länge des Informationsfeldes ist initial im ATR angegeben und kann durch einen S-Block zu Beginn einer Unterhaltung auf einen Wert zwischen 0x00 und 0xFE festgelegt werden. |
|||
*'''EDC''' Fehelererkennungscode über alle vorherigen Bytes des Blockes |
|||
:*1 Byte lang für LRC (Längsprüfcode) |
|||
:*2 Byte lang für CRC (zyklischer Redundanz Prüfcode) |
|||
:Welches Verfahren verwendet wird lässt sich in den Interface Charactern (TC<sub>i</sub> für i>2) des ATR ablesen. Default ist LRC. |
|||
== APDU-Kommandos == |
|||
Das Terminal und die Chipkarte kommunizieren immer abwechselnd. Somit ist klar, wer wann das APDU-Kommando sendet. Die APDU des Terminals besteht aus einem Header (Class-Byte, Instruction-Byte, zwei Parameter-Bytes) und einer variablen Länge an Datenbytes. Sind Daten vorhanden, dann wird zusätzlich davor ein Byte Lc für die Länge eingefügt. Am Ende kann optional noch ein Byte Le folgen. Dieses gibt die maximale Länge für die Antwort der Chipkarte an (0x00 sind 256 Byte). |
|||
[[Image:apdu.png|800x420px|Aufbau der APDU-Kommandos]] |
|||
=== Befehle === |
|||
*SELECT Ordner, File oder Applikation |
|||
Wählt einen Ordner, eine Datei oder eine Applikation aus |
|||
*READ RECORD |
|||
Liest den mit SELECT vorher ausgewählten Record |
|||
*SEARCH RECORD |
|||
Sucht nach einem bestimmten Record auf der Karte |
|||
=== Kartenspezielle Befehle === |
|||
*VERIFY |
|||
Führt eine PIN-Verifikation durch (wichtig, muss dem GENERATE AC-Befehl vorausgehen) |
|||
*HASH |
|||
Die Karte berechnet aus den Transaktionsdaten wie Kontonummer und Betrag einen Hashwert |
|||
*GENERATE AC |
|||
Erzeugung des Application Cryptograms. Aus der Antwort der Karte berechnet das Terminal dann die TAN |
|||
Kommunikation zwischen ChipTAN-Generator und EC-Karte |
|||
Zu Beginn wird nach dem ATR ein S-Block vom Terminal geschickt, um die maximale Empfangspuffers IFSD auf 254 Bytes (FE) zu erhöhen. Die Chipkarte bestätigt dies durch das Rücksenden des gleichen "FE"-Wertes. Hiernach wird zwischen dem Terminal und der Chipkarte nur noch über Informations-Blöcke kommuniziert. Der erste I-Block wird |
|||
Die [https://wiki.ccc-ffm.de/projekte:tangenerator:start#t_1_ifsd genaue Aufschlüsselung der Kommunikation ChipTAN und Card kann hier nachgelesen werden.] |
|||
[https://wiki.ccc-ffm.de/projekte:tangenerator:start link title] |
|||
== Verwendete Hardware == |
== Verwendete Hardware == |
Latest revision as of 11:25, 28 November 2012
Ziel
- Analyse der Kommunikation zwischen Karte und Terminal
- Untersuchung einer möglichen Softwareemulation des ChipTAN-Generators
Herangehensweise
- Die ersten Schritte
Der erste Schritt war der Zusammenbau unser Hardwareunterstüzung, welche uns das Mithören der Kommunikation zwischen Karte und Tan Generator ermöglichen sollte. Die eigentlich Arbeit, das Löten der Komponenten, hat freundlicherweise ?Frank? übernommen. Desweiteren haben wir von unserem Mentor einen Logic Analyzer(inklusiv Software) zur Verfügung gestellt bekommen. Dieser ermöglichte uns das Bitweise mitschneiden des Datenstroms.
Als nächste haben wir unseren Versuch aufgebaut:
Ein bild fehlt(konnte es nicht hochladen)
Unser Aufbau an sich ist relativ einfach. Wie man auf den Fotos sieht haben wir unsere Hardwarekomponente zwischen Karte und Generator montiert. Diese Komponente besteht einerseits aus einem Kartenhalter, welcher aus einem Kartenleser stammt und den Kontakt zur Karte herstellt. Dieser Halter ist über einen Bus mit unserem Board verbunden welches als Karte dient und den Kontakt zum TanGenerator herstellt. Darüberhinaus hat das Board einige Anschlüssen an welche wir den Logic Analyzer anschließen können.
- Analyse Methode
Unsere erste Analyse bestand darin, statt einem TanGenereator einen Komfortleser zu benutzen und mitzuhören was übertragen wird, wenn man die Karte in den Leser steckt. Der Logic Analyzer stellt, in der mitgelieferten Software, den Datenstrom als High/Low Flanken, in Abhängigkeit von der vergangen Zeit, zur Verfügung. Nun haben wir angefangen das Signal mittels Literatur/ISO-Standard zu analysieren. Die Software bietet hierführ die Möglichkeit eine Art Parser auf das Signal "anzusetzen" um die zusammengehörenden Bits, im Datenstrom, als Byte darzustellen. Diesen Bytestrom konnte man sich in einem Exportfile ausgeben lassen.
Nun haben wir parallel an zwei Programmen gearbeitet. Zum einem Bestand die Möglichkeit das Exportfile zu modifizieren und mit den Bytes gleich die Bedeutung dieses mitauszugeben. Zum anderen haben wir ein Programm geschrieben welches den Bytestrom als Input bekommt und darauf die gewonnen Steuer-Informationen/Daten ausgibt. Nun hatten wir ein Werkzeug in der Hand welches die Analyse des Datenaustausches zwischen Karte und Terminal stark vereinfacht, da wir uns alle relevanten Daten für die weiter Analyse ausgeben lassen konnten.
Für unsere Analyse haben wir eine komplette Online Überweisung mitgehört und aufgezeichnet.
Im folgenden finden sich die genauen Ergebnisse unser Analyse.
Asychronous Character Transfer
Die elementare Übertragungseinheit ist ein Character.
- 1 Byte wird mit 10 Bit übertragen
- 1. Bit = Startbit
- 2.-9. Bit = Daten
- 10. Bit = Paritybit
Zwischen der Übertragung zweier Bytes wird eine vorher ausgehandelte Zeit gewartet (I/O Kanal auf High gesetzt) um der Gegenseite die möglichkeit zu geben das letzte Byte nochmal anzufordern (falls Paritybit falsch war). Wählt man die ersten fallende Flanke des I/O Kanals nach dem schalten des Reset-Signals auf High als Startpunkt kann man somit direkt Bytesvom I/O-Kanal ablesen.
Analyse des Bytestroms
Bei Inbetriebnahme einer Chipkarte wird diese durch das Terminal mit Strom und einem Takt versorgt. Als erstes setzt das Terminal den Reset-Kanal auf High, woraufhin die Chipkarte das Senden einer ATR("Answer To Reset") beginnt.
ATR
- max. 33 Byte lang
- 1. Byte (TS) gibt Coding Convention an
- Wert '3B' = Startbit = 0 Daten= °1101 1100° Parity = 1 -> direct convention (least significant bit -> most significant bit)
- Wert '3F' = Startbit = 0 Daten= °0011 1111° Parity = 1 -> inverse convention (most significant bit -> least significant bit)
- 2. Byte (T0) gibt Anzahl der nachfolgenden Interface Character (TA,TB,TC,TD) und Anzahl der Historical Characters an
- 3. Byte (TA1) codiert Übertragungsfrequenz und Teiler die die Karte maximal unterstützt
- TAi,TBi,TCi-Bytes enthalten Informationen über die Fähigkeiten der Karte in Abhängigkeit vom jeweiligen Übertragungsprotokoll (unterstützte Frequenzen etc.)
- TDi-Bytes geben an ob und welche TA,TB,TC,TD im Anschluß gesendet werden (verkettung möglich), das Übertragungsprotokoll wird auch angegeben (in 0x08)
Im Anschluss an die TA,TB,TC,TD-Bytes folgen die historical Character und ein Checksummen-Byte TCK (XOR-Prüfsumme von T0 bis zum Byte vor TCK)
Die ATR enthält somit Informationen über die Karte (z.B. unterstützte Übertragungsprotokolle und Geschwindigkeiten etc.)
Protocol Parameter Selection (PPS)
Durch die übermittelte ATR und die darin enthaltenen Informationen über die Fähigkeiten der Karte hat das Terminal nun die Möglichkeit (optional) neue Übertragungsparameter auszuhandeln. Eine PPS ist optional und besteht mindestens aus 3 Byte und höchstrens aus 6 Byte.
- 1. Byte PPSS = 0xFF
- 2. Byte PPS0 codiert das zu verwendende Übertragungsprotokoll und die vorhandenen optionalen Parameter PPS1-3
- 0-3 Byte Parameter PPS1-3
- letztes Byte PCK XOR-Prüfsumme ab PPSS
Das Terminal schickt an die Karte eine solche PPS Datenstruktur. Zur Bestätigung schickt die Karte die gleiche PPS Datenstruktur zurück.
Übertragungsprotokoll T=1
Bei der Kommunikation zwischen Chipkarte und ChipTAN-Generator wird (in unserem Fall) das Blockprotokoll T=1 Verwendet. Es handelt sich um ein asynchrones Halbduplexprotokoll welches als kleineste Dateneinheit Blöcke überträgt.
Blöcke
- Block Typen:
- Informationsblöcke (I-Block)
- Austausch von Daten/Kommandos
- Empfangsbestätigungsblöcke (R-Block)
- enthalten kein Informationsfeld
- dienen zur positiven/negativen Empfangsbestätigung
- Systemblöcke (S-Block)
- Modifikation von protokollspezifischen Steuerinformationen
- Informationsblöcke (I-Block)
Aufbau eines Blocks
Der Header eines jeden Blocks besteht aus den NAD, PCB, LEN-Feldern.
- NAD Knotenaddresse (ist in unserem Fall, sowie in den meisten anderen auch 0x00)
- PCB (Protocol Control Byte) codiert Blocktyp und benötigte Informationen (z.B. Sendefolgenummer)
- LEN (Length Field) gibt die Länge des Informationsfeldes in Bytes an
- Informationsfeld:
- im Falle eines S-Blocks werden Daten für das Übertragungsprotokoll übertragen
- im Falle eines I-Blocks wird ein APDU-Kommando übertragen
Die maximale Länge des Informationsfeldes ist initial im ATR angegeben und kann durch einen S-Block zu Beginn einer Unterhaltung auf einen Wert zwischen 0x00 und 0xFE festgelegt werden.
- EDC Fehelererkennungscode über alle vorherigen Bytes des Blockes
- 1 Byte lang für LRC (Längsprüfcode)
- 2 Byte lang für CRC (zyklischer Redundanz Prüfcode)
- Welches Verfahren verwendet wird lässt sich in den Interface Charactern (TCi für i>2) des ATR ablesen. Default ist LRC.
APDU-Kommandos
Das Terminal und die Chipkarte kommunizieren immer abwechselnd. Somit ist klar, wer wann das APDU-Kommando sendet. Die APDU des Terminals besteht aus einem Header (Class-Byte, Instruction-Byte, zwei Parameter-Bytes) und einer variablen Länge an Datenbytes. Sind Daten vorhanden, dann wird zusätzlich davor ein Byte Lc für die Länge eingefügt. Am Ende kann optional noch ein Byte Le folgen. Dieses gibt die maximale Länge für die Antwort der Chipkarte an (0x00 sind 256 Byte).
Befehle
- SELECT Ordner, File oder Applikation
Wählt einen Ordner, eine Datei oder eine Applikation aus
- READ RECORD
Liest den mit SELECT vorher ausgewählten Record
- SEARCH RECORD
Sucht nach einem bestimmten Record auf der Karte
Kartenspezielle Befehle
- VERIFY
Führt eine PIN-Verifikation durch (wichtig, muss dem GENERATE AC-Befehl vorausgehen)
- HASH
Die Karte berechnet aus den Transaktionsdaten wie Kontonummer und Betrag einen Hashwert
- GENERATE AC
Erzeugung des Application Cryptograms. Aus der Antwort der Karte berechnet das Terminal dann die TAN
Kommunikation zwischen ChipTAN-Generator und EC-Karte
Zu Beginn wird nach dem ATR ein S-Block vom Terminal geschickt, um die maximale Empfangspuffers IFSD auf 254 Bytes (FE) zu erhöhen. Die Chipkarte bestätigt dies durch das Rücksenden des gleichen "FE"-Wertes. Hiernach wird zwischen dem Terminal und der Chipkarte nur noch über Informations-Blöcke kommuniziert. Der erste I-Block wird
Die genaue Aufschlüsselung der Kommunikation ChipTAN und Card kann hier nachgelesen werden.
Verwendete Hardware
- Smartcard-Adapter
- ChipTAN Generator & EC-Karte
- Logic Analyzer (http://www.saleae.com/logic)
Verwendete Software
- "Logic Software 1.1.15" + SDK (http://www.saleae.com/downloads)
Literatur
- ISO/IEC 7816-3
- Handbuch der Chipkarten