Für die Kommunikation zwischen Chipkarte und Terminal steht nur eine einzige Leitung zur Verfügung. Dadurch können Informationen nur wechselseitig ausgetauscht werden. Dieses abwechselnde Senden und Empfangen wird als Halbduplex-Verfahren bezeichnet.

Das Vollduplex-Verfahren, bei dem beide Teilnehmer gleichzeitig senden und empfangen können ist derzeit in der Chipkartenwelt noch nicht verwirklicht. Da jedoch die meisten Chipkarten-Mikrocontroller zwei I/O-Ports haben und zwei der acht Kontakte für zukünftige Anwendungen reserviert sind, wäre eine Vollduplex-Verbindung technisch möglich. Erste Vorschläge für eine Normierung liegen bereits vor.

Die Kommunikation mit der Chipkarte geht immer vom Terminal aus. Die Karte reagiert auf Befehle vom Terminal und sendet nie von sich aus Daten nach außen. Es ergibt sich ein Master-Slave-Verhältnis, mit dem Terminal als Master und der Karte als Slave.

6.1 Synchrone Karten

Karten mit synchroner Kommunikation sind als Speicherkarten ausgeführt. Bei Chipkarten mit Mikrocontrollern findet sie keine Anwendung, da diese nur asynchron mit dem Terminal kommunizieren. Durch die große Verbreitung von Speicherkarten als Telefon- oder Krankenversichertenkarten soll im folgenden kurz auf die Art der Datenübertragung eingegangen werden, auch wenn für die Anwendung als elektronische Geldbörse nur Chipkarten mit Mikrocontrollern aus Sicherheitsgründen denkbar sind.

Speicherkarten stellen nach außen ein getaktetes Schieberegister dar, d.h. mit jedem Impuls aus der Taktleitung schalten sie eine Adresse weiter und geben den Inhalt der adressierten Speicherzelle an den Ein-/Ausgabe-Port weiter. Die Adreßweiterschaltung ist also mit dem Taktsignal synchron. Der Takt bewegt sich im Bereich zwischen zehn und 50 Kilohertz. Jede Speicheradresse repräsentiert hierbei genau ein gespeichertes Bit. Bei den meisten Karten wird der Adreßzähler nach einer bestimmten Adresse, die über den nutzbaren Speicherbereich hinausgeht, durch den nachfolgenden Taktimpuls wieder auf die Adresse Null zurückgesetzt. Dies bezeichnet man auch als wrap-around-Prinzip. Der Adreßzähler kann auch mit einem Reset zurückgesetzt werden.

6.1.1 Answer-To-Reset (ATR)

Da eine Chipkarte in Abhängigkeit von ihrer Anwendung unterschiedliche Funktionen besitzen kann, ist es wichtig, sie unmittelbar nach der Aktivierung zu klassifizieren. Dies geschieht durch das Auslesen spezieller Daten - auch Answer-To-Reset (ATR) genannt - nach Anlegen der Versorgungsspannung, des Taktes und eines Resetimpulses. Bei synchronen Karten ist dieser ATR entweder zwei oder vier Bytes lang.

Die ältere Version ist die Telefonkarte der Telekom AG mit zwei Bytes, bezeichnet als H1 und H2. Zur Unterscheidung der beiden Schemata dient das Bit b1 (siehe unten) des H1-Bytes. Ist Bit b1=1, so bezeichnet es das 16-Bit-Schema der Telekom AG.

Abbildung 27: 16-Bit-Schema der ATR bei Telefonkarten der Telekom AG in Bitdarstellung

Das erweiterte 32-Bit-Schema ist für die Krankenversichertenkarte entwickelt wor-den und ist in der ISO 7816-3 Zusatz 2 enthalten. Es ist im folgenden dargestellt:

Abbildung 28: Erweitertes 32-Bit-Schema der ATR in Bitdarstellung

Die vier Bytes werden als H1 bis H4 bezeichnet, wobei die Bits b8 bis b5 im H1-Byte benutzt werden, um das Übertragungsverfahren festzustellen. Je nach verwendetem internen Datenbus ist dieses Verfahren unterschiedlich. Ein Terminal, das mit unterschiedlichen Speicherkarten kommunizieren will, braucht also mehrere verschiedene Implementierungen synchroner Übertragungsverfahren. Erst nach der empfangenen ATR schaltet das Terminal auf das kartenspezifische Verfahren um. Im zweiten Byte werden die Parameter beschrieben. Es werden die Speichergröße und die Seitengröße definiert. Die folgenden Daten des H3-Bytes beinhalten Informationen über den Chiphersteller, den Chiptyp und den Kartenhersteller. Als letztes wird im vierten Byte ein Zeiger übertragen. Dieser verweist auf eine Adresse, an der Ländercode und Anwendungsnummer, die RID, stehen.

Unterstützt die Speicherkarte kein ATR, so sendet sie viermal 'FF', den höchsten darzustellenden hexadezimalen Zahlenwert.

6.1.2 Synchrone Datenübertragung

Bei der synchronen Chipkarte ist das verwendete Übertragungsverfahren abhängig vom verwendeten internen Datenbus. Mit diesem Datenbus werden Informationen zwischen serieller Schnittstelle und dem EEPROM ausgetauscht. Jeder Datenbus ist mit zwei oder drei Kontakten des Kontaktfeldes verbunden, und wird dadurch gesteuert. Es haben sich drei Verfahren bzw. Datenbusse durchgesetzt: der I›C-Bus, der Zweidraht-Bus und der Dreidraht-Bus.

6.1.2.1 Der I›C-Bus

Seit längerer Zeit bekannt und weit verbreitet ist der I›C-Bus der Firma Philips. Er wird seit Jahren als Standardbaustein auch für andere Zwecke eingesetzt und ist für jedermann erhältlich. Steuerung und Datenaustausch laufen über zwei Leitungen. Eine ist an den Takt angeschlossen, die Zweite an die bidirektionale Datenleitung.

Abbildung 29: Ansteuerung eines I›C-Busses

Befehle an den Chip beginnen mit einer Startsequenz (siehe Abbildung 31), indem der Sender die Datenleitung während einer aktiven Taktphase auf Null setzt. Darauf folgen acht Datenbits, wobei das erste gesendete Bit das achte Bit ist. Mit dem neunten Takt wird ein Trennungsbit übertragen. Abgeschlossen wird die Übertragung mit einer Stopsequenz, bei der die Datenleitung bei aktivem Takt auf Null gesetzt wird.

I2C-Bus-Karten haben zwei verschiedene Codes, um zwischen Schreib- und Lesevorgängen zu unterscheiden.

Abbildung 30: Schreib- und Lesevorgang bei einem I›C-Bus

Um ein bestimmtes Byte aus einer I›C-Karte zu lesen, muß zunächst ihr Adreßzähler durch einen Schreibvorgang mit einem folgenden Adreß-Byte die Adresse im EEPROM gesetzt werden. Der nächste Lesevorgang liefert dann das gewünschte Daten-Byte.

Alle folgenden Daten-Bytes lassen sich durch wiederholte Lesevorgänge einfach auslesen, da der Adreßzähler automatisch hochgezählt wird, solange das Quittierungsbit auf Null bleibt und keine Stopsequenz gesendet wird.

Das Schreiben eines Daten-Bytes in das EEPROM ist noch einfacher. Zuerst sendet man die Adresse an welche die Daten auf der Chipkarte geschrieben werden sollen, gefolgt vom eigentlichen Daten-Byte.

Sollen mehrere Bytes geschrieben werden, so muß eine Programmierzeit von zehn Millisekunden für das EEPROM abgewartet werden, danach kann das nächste Daten-Byte gesendet werden, bis eine Stopsequenz folgt.

6.1.2.2 Der Zweidraht-Bus

Der Zweidraht-Bus von Siemens benutzt wie der I›C-Bus zwei Leitungen, die ebenfalls an Schnittstelle und Takt angeschlossen sind. Er verwendet die gleichen Start- und Stopsequenzen, hat aber ein vereinfachtes Verfahren ohne Quittierung und eine umgekehrte Bitreihenfolge; deshalb ist er zum I›C-Bus nicht kompatibel. Dahinter steckt durchaus eine Absicht, denn es soll nicht möglich sein, mit Hilfe eines handelsüblichen I›C-Bus-Bausteins diese Chipkarte zu simulieren.

Ein Zweidraht-Bus-Befehl besteht immer aus 24 Bits, also drei aufeinanderfolgenden Bytes: dem Kontroll-Byte, dem Adreß-Byte und dem Daten-Byte. Im Kontroll-Byte ist die Art des Befehls codiert, ähnlich ist es bei den I›C-Bussen.

Bei Lesevorgängen ist das Daten-Byte ohne Belang, das Ergebnis erhält man immer nach der Stopsequenz durch weitere Taktimpulse. Wurden genügend Daten-Bytes ausgelesen, muß ein Reset ausgelöst werden, um den Datenfluß von der Speicherkarte zu stoppen.

Schreibvorgänge können mit den 24-Bit-Befehlen einfach beschrieben werden. Die Zeit zum Programmieren des EEPROMs zeigt die Chipkarte auf der Datenleitung an. Solange diese auf dem low-Pegel bleibt, benötigt sie mehr Zeit zur Bearbeitung des Befehls, legt sie den Pegel auf high, kann ein weiterer Befehl folgen.

Das Datenübertragungsverfahren des Zweidraht-Busses wird bei der Krankenversichertenkarte angewendet.

6.1.2.3 Der Dreidraht-Bus

Die Bezeichnung Dreidraht-Bus bezieht sich auf die Art der Kartenansteuerung. Neben den Signalen von Taktleitung und I/O-Schnittstelle wird auch die Reset-Leitung für die Steuerung der Richtung einer Nachricht zwischen Karte und Terminal verwendet. Ein high auf der Reset-Leitung zeigt an, daß die folgenden Taktimpulse einen Befehl an die Karte übermitteln. Ist die Reset-Leitung low, so sendet die Karte die gewünschten Informationen.

Auch beim Dreidraht-Bus bestehen die Befehle aus 24 Bits. Da der Dreidraht-Bus bei Chipkarten mit größerer Speicherkapazität eingesetzt wird, mußte die Codierungsmöglichkeit des Adreß-Bytes von acht auf zehn Bits erhöht werden. Das Kontroll-Byte umfaßt jetzt nur noch sechs Bits, das Daten-Byte bleibt mit 8 Bits bestehen. Kontoll-Byte, Adreß-Byte und Daten-Byte behalten die Funktionalität, wie beim Zweidraht-Bus schon beschrieben.

6.2 Asynchrone Karten

Nachdem eine Chipkarte in ein Terminal gesteckt wurde, werden als erstes die Kontakte der Karte mit denen des Terminals verbunden. Danach wird die Karte elektrisch aktiviert und sendet einen Answer-To-Reset (ATR) aus, der diverse Kartenparameter für die Datenübertragung beinhaltet. In der Regel wartet die Karte dann auf den ersten Befehl, der mit dem im ATR vereinbarten Übertragungsprotokoll übermittelt wird. Zwischen ATR und dem ersten Befehl kann vom Terminal noch eine Protocol Type Selection (PTS) gesendet werden. Hiermit können, wenn die Karte dies zuläßt, verschiedene Übertragungsparameter des Übertragungsprotokolls eingestellt werden.

Die gesamte Datenübertragung von und zur asynchronen Chipkarte kann im Rahmen des OSI-Schichtenmodells dargestellt werden:

Abbildung 31: Das OSI-Schichtenmodell der Kommunikation zwischen Terminal und Chipkarte

Das OSI-Modell unterteilt sich in sieben Schichten. Es ist nicht notwendig, daß andere Schichten, außer der jeweils Betroffenen, den Inhalt der übertragenen Daten interpretiert oder verändert. Die fehlerfreie Übertragung der Nachrichten wird von tieferliegenden Schichten gewährleistet.

Die oberste Schicht ist die Anwendungsebene, die Schnittstelle zum Benutzer. In ihr werden Aufbau und Inhalt einer Nachricht definiert. Hierzu dient der Befehlssatz, der in der ISO 7816-4 vorgeschlagen wurde.

In der Präsentationsebene wird jeder Befehl, in üblicher Hexadezimal-Darstellung, in die binäre Darstellung umgewandelt, damit die Nachricht letztendlich digital übertragen werden kann.

Die Sitzungsebene steuert den Datenfluß. Jede Nachricht wird im übertragenen Sinne in Watte gepackt, damit sie unversehrt beim Empfänger ankommt. Diese Schutzmechanismen sind je nach Übertragungsprotokoll unterschiedlich.

Die Transportebene ist für den Leitungsaufbau zuständig. Es existiert bereits eine stabile Datenleitung, die durch die physikalische Verbindung der Kontaktnehmer mit den Kontakten der Chipkarte zustandekommt.

Sender und Empfänger einer Nachricht müssen für die Netzwerkebene eindeutig erkennbar sein. Da es nur eine serielle Schnittstelle gibt und in den Protokollen die Kommuniktion zwischen beiden Partnern genau festgelegt ist, müssen die Nachrichten an sich keine Kennzeichnung tragen.

Die Übertragungsprotokolle entsprechen der Leitungsebene. Sie sind insbesondere für die Fehlererkennung zuständig.

Auf der untersten Ebene findet die eigentliche physikalische Übertragung der digitalen Nachricht statt.

6.2.1 Physikalische Ebene

Die physikalische Übertragungsschicht ist in der ISO 7816-3 in allen Parametern festgelegt. Dies ist die grundlegende Norm für alle Aspekte der Kommunikation auf physikalischer Ebene.

Der gesamte Datenaustausch findet digital statt, d.h. mit der Benutzung der logischen Werte '0' und '1'. In der Digitalwelt sind die verwendeten Spannungswerte von null Volt und fünf Volt üblich. Welcher dieser beiden Pegel die logische '1' repräsentiert ist frei wählbar und wird im ersten Byte des ATR festgelegt. Es gibt zwei Konventionen ein Byte zu übertragen:

Bei der direkten Konvention entspricht die logische '1' dem 5-Volt-Pegel und umgekehrt bei der indirekten Konvention symbolisiert der 5-Volt-Pegel die logische '0'.

Jeweils eine logische '0' oder '1' wird als ein Bit bezeichnet. Eine Serie von acht Bits ergibt ein Byte und kann vom Prozessor verarbeitet werden. Bei direkter Konvention ist das erste gesendete Bit das niederwertigste. Im Falle der indirekten Konvention wird das höherwertigste Bit als erstes gesendet.

Abbildung 32: a) Datenübertragung mit direkter Konvention b) Datenübertragung mit indirekter Konvention

Asynchrone Karten erzeugen aus dem angelegten Takt über einen Frequenzteiler (F) ihren seriellen Schnittstellentakt. Die üblichen Standardtaktfrequenzen sind 3,57 Megahertz und 4,92 Megahertz. Als Frequenzteiler werden weltweit die Faktoren F=512 und F=372 benutzt. Sie ergeben in der unten abgebildeten Berechnungsformel als Übertragungsrate 9600 Baud.

Da die Datenübertragung asynchron zwischen Chipkarte und Terminal abläuft, muß jedes übertragene Byte zusätzlich mit Synchronisationsbits ausgestattet werden, um eine gleichzeitige Aktivität von Terminal und Chipkarte zu verhindern und somit eine sichere Übertragung zu gewährleisten.

Den Anfang macht ein Startbit, das dem Empfänger den Sendebeginn signalisiert. Nach jedem Byte fügt der Sender ein sogenanntes Paritätsbit zur Fehlererkennung sowie zwei Stopbits hinzu, um die Bytes voneinander zu trennen.

Die acht Nutzbits setzen sich aus Nullen und Einsen zusammen. Ist die Anzahl der Nullen gerade, wird als Paritätsbit '0' übertragen. Ist sie ungerade, ist das Paritätsbit '1'. Dadurch kann der Empfänger prüfen, ob ein Bit verloren gegangen ist.

Für eine Übertragung von acht Nutzbits werden also insgesamt zwölf Taktzyklen benötigt, die einzelnen Taktzyklen werden auch als ETU oder Elementary Time Units bezeichnet.

Abbildung 33: Aufbau einer Datenübertragung von einem Byte

6.2.2 Answer-To-Reset (ATR)

Nach Anlegen der Spannungsversorgung, des Taktes und des Resetsignals sendet die Chipkarte einen Answer-To-Reset (ATR) aus. Er enthält Informationen über die Datenübertragung und Chipkartenparameter. Der ATR ist maximal 33 Byte lang und wird laut ISO 7816-3 immer mit dem Teiler F=372 gesendet.

Übermittelt die Chipkarte innerhalb von 40.000 Taktzyklen nach einem Reset keine ATR, so muß der elektrische Einschaltvorgang wiederholt werden. Dies kann bis zu dreimal vorkommen, danach wird die Karte deaktiviert, da sie nicht funktionsfähig ist. Das Terminal kann sie unter Umständen noch als synchrone Karte ansprechen.

Der grundlegende Aufbau eines ATR setzt sich zusammen aus folgenden Elementen:

Abbildung 34: Aufbau eines asynchronen ATRs

Der Initial Character

Dieses mit TS bezeichnete Byte enthält die Konvention aller Daten des ATR und des nachfolgenden Kommunikationsablaufes. Die Codierung '3B' bedeutet direkte Konvention, '3F' entspricht indirekter Konvention. Das TS-Byte muß immer gesendet werden.

Der Format Character

Das zweite Byte T0 zeigt an, welche Interface Characters übertragen werden und wieviele Historical Characters folgen. Dieses Byte muß immer übertragen werden.

Die Interface Characters

Die Interface Characters spezifizieren alle Übertragungsparameter der verschiedenen Übertragungsprotokolle, z.B. den Frequenzteiler, diverse Schutz- und Wartezeiten und zeigen an, ob eine Programmierspannung benötigt wird. Die Angabe dieser Bytes ist optional.

Im TD1-Byte wird im niederwertigen Halbbyte das Übertragungsprotokoll (0 bis 15) festgelegt, im höherwertigen Halbbyte wird angezeigt, ob weitere Bytes von TAi+1 bis TDi+1 folgen.

Die Historical Characters

Die Größe der Historical Characters liegt zwischen null Byte und 15 Bytes. Der Inhalt ist zur Zeit in keiner Norm festgelegt, weshalb je nach Betriebssystemhersteller die verschiedensten Daten auftreten können, beispielsweise eine Seriennummer der ROM-Maske oder eine Bezeichnung des Betriebssystems. Im Allgemeinen beinhalten die Historical Characters Hinweise auf die Herkunft der Chipkarte. Die Existenz der Historical Characters im ATR ist nicht vorgeschrieben.

Der Checksum Character

Dieses letzte Byte ist eine Prüfsumme, mit der die Richtigkeit der ATR-Übertragung festgestellt werden kann. Beim Übertragungsprotokoll T=0 (siehe Kapitel 6.2.4) fehlt der Checksum Character völlig.

Um eine Chipkarte möglichst schnell befehlsbereit zu haben, wird der ATR eher kurz gehalten und optionale Elemente weggelassen.

6.2.3 Protokoll Type Selection (PTS)

Sind verschiedene Anwendungen auf einer Chipkarte untergebracht, so kann sie mehr als ein Übertragungsprotokoll anbieten. Zur Auswahl eines bestimmten Übertragungsprotokolls oder der Änderung bestimmter Protokollparameter gibt es die 'Protokoll Type Selection' (PTS).

Eine PTS-Anfrage vom Terminal zur Chipkarte muß unmittelbar nach dem Empfang des ATR durchgeführt werden. Erlaubt die Chipkarte die gewünschte Änderung, so sendet sie die empfangene PTS-Anfrage zum Terminal zurück. Im anderen Fall sendet sie nichts aus, und das Terminal muß nochmals einen Reset auslösen, um die Karte zu aktivieren. In der Praxis kommt ein PTS sehr selten vor.

6.2.4 Übertragungsprotokolle

Um Informationen zwischen Chipkarte und Terminal auszutauschen, gibt es verschiedene Verfahren. Diese werden als Übertragungsprotokolle bezeichnet. Ihre wesentlichen Aufgaben sind:

Erkennen von Datenverlusten auf der Übertragungsstrecke,
Erkennung von Datenverfälschungen auf der Übertragungsstrecke,
Synchronisation beider Kommunikationspartner nach Übertragungsstörung.

Das eigentliche Übertragen der Nachrichten übernimmt die physikalische Ebene im OSI-Schichtenprotokoll und ist somit keine Aufgabe eines Übertragungsprotokolls.

Es sind insgesamt 15 Übertragungsprotokolle in der ISO-Norm 7816-3 vorgesehen. Ihre Bezeichnung setzt sich aus dem Ausdruck 'T=' und einer nachfolgenden natürlichen Zahl zusammen. Die folgende Tabelle zeigt einen Überblick:

Von den verschiedenen Protokollen haben sich international zwei durchgesetzt. Zum einen ist dies das byteorientierte Protokoll T=0, das 1989 international genormt wurde, und zum anderen das blockorientierte T=1-Protokoll, das 1992 in den Anhang der ISO-Norm 7816-3 aufgenommen wurde. In den zwei folgenden Kapiteln werden beide Übertragungsprotokolle näher erläutert.

Noch eine kurze Erklärung zum nationalen Protokoll T=14. In Deutschland wird bei Mobiltelefonen der Telekom AG ein drittes Protokoll verwendet. Dieses blockorientierte Protokoll entstand, weil die Telekom schon sehr früh für das C-Netz ein leistungsfähiges Protokoll einsetzen wollte, das T=1-Protokoll welches allerdings erst in der Entwicklungsphase war. Es wurde ein Normenvorschlag eines DIN-Arbeitskreises verwendet, der später auch Grundlage des T=1-Protokolls war. Da das T=14 nur ein nationales Protokoll ist, geht die Telekom dazu über, ihre zukünftigen Chipkarten mit dem T=1 Protokoll auszustatten.

6.2.4.1 Übertragungsprotokoll T=0

Das T=0-Protokoll wurde schon in der Anfangsphase der Chipkartenentwicklung in Frankreich verwendet und war auch das erste international genormte Protokoll für Chipkarten. Es ist auf minimalen Speicherbedarf und maximale Einfachheit ausgelegt. Das Übertragungsprotokoll T=0 wird weltweit in der GSM-Karte verwendet und hat dadurch den größten Verbreitungsgrad aller Chipkartenprotokolle.

Das T=0-Protokoll ist byteorientiert, das bedeutet, die kleinste Dateneinheit, die das Übertragungsprotokoll bearbeitet, ist ein einzelnes Byte. Durch die Byteorientierung muß nach einem erkannten Übertragungsfehler nur das nicht korrekt empfangene Byte nochmals angefordert werden. Die Erkennung von Übertragungsfehlern erfolgt ausschließlich mit Hilfe des Paritätsbits, das jedem Byte nachgestellt ist. Es folgen die zwei Stopbits, die im T=0-Protokoll als Schutzzeit bezeichnet werden, in der immer ein high-Pegel gesendet wird.

Abbildung 35: Fehlerfrei übertragenes Byte beim T=0-Protokoll

Erkennt der Empfänger einen Übertragungsfehler, so muß er während der Schutzzeit einen low-Pegel senden. Damit signalisiert er dem anderen Kommunikationspartner, daß das letzte Byte nochmals gesendet werden muß.

Eine beispielhafte Befehls-Antwort-Sequenz ist die Leseanweisung 'READ BINARY' aus dem Befehlssatz der ISO 7816-4.

Das Terminal soll bei diesem Befehl aus einer schon selektierten Datei auf der Chipkarte Daten auslesen. Als Parameter braucht dieser Befehl die Anzahl der auszulesenden Bytes und die Stelle in der Datei, ab der gelesen werden soll, den sogenannten Offset. Als Antwort werden von der Karte eine Rückmeldung und die gewünschten Daten erwartet.

Abbildung 36: Kommunikationsablauf eines Befehls

Zuerst sendet das Terminal an die Chipkarte einen fünf Bytes langen Befehlskopf. Dieser besteht aus fünf Einzelbytes: [ CLA, INS, P1, P2, P3 ].

CLA ist die Klasse eines Befehls und definiert, ob und wie der Befehl verschlüsselt ist. Wird ein Befehl unverschlüsselt gesendet, so wird die Hexadezimal-Codierung '00' verwendet.

INS steht für Instruktion und beschreibt in einem Byte, um welchen Befehl es sich handelt. Eine Tabelle für Befehle und die dazugehörigen Hexadezimal-Codierungen befinden sich in der ISO 7816-4 und sind im Kapitel 8 ausführlich dargestellt. Beim Befehl READ BINARY ist die Codierung 'B0'.

Als Nächstes folgen die Parameter P1 bis P3. P1 beschreibt die Anzahl der auszulesenden Bytes. In diesem Beispiel sollen es 15 Bytes sein, das entspricht '0F', hexadezimal. P2 enthält den Offset. Setzen wir P2 auf '00' fest, dann bedeutet es, daß vom Anfang der Datei gelesen werden soll. P3 legt die Anzahl von Datenbytes fest, die zu einem Befehl gehören können, dem Befehlsrumpf. Zum Beispiel werden bei einem Schreibbefehl die Daten übergeben, die geschrieben werden sollen. Da aber bei einem Lesebefehl keine solchen Daten an die Chipkarte zu übergeben sind, ist P3='00'. Zusammenfassend sieht der Befehlskopf wie folgt aus:

[ '00' || 'B0' || '0F' || '00' || '00' ]

Dieser Befehlskopf wird nun byteweise, wie oben beschrieben, übertragen. Zum Zeichen, daß der Befehlskopf von der Chipkarte verstanden wurde, sendet sie ein sogenanntes Acknowledge-Byte zurück. Es besteht aus der Wiederholung des Instruktionsbytes, also 'B0'.

Das Terminal sendet daraufhin den Befehlsrumpf, soweit dieser vorhanden ist, und der Mikrocontroller beginnt mit der Bearbeitung des Befehls.

Sobald er fertig ist, sendet die Chipkarte eine Antwort von zwei Bytes. Diese Antwort beinhaltet eine Rückgabemeldung und die Länge der ausgelesenen Daten. Die Rückmeldung ist in über 50 verschiedene Möglichkeiten unterteilt, denen ebenfalls in der ISO 7816-4 Hexadezimal-Codierungen zugewiesen sind. Je nachdem, ob der Befehl fehlerfrei bearbeitet werden konnte, oder ob und welcher Fehler auftrat, wird in der Rückmeldung dargestellt.

Das Terminal schickt einen GET RESPONSE-Befehl, der nur aus einem Befehlskopf besteht, an die Karte:

[ '00' || 'C0' || '00' || '00' || '0F' ]

Es soll wieder unverschlüsselt gesendet werden, und der Befehl hat die Codierung 'C0'. Im dritten Parameter wird die Länge der Daten übergeben, die von der Chipkarte zum Terminal übertragen werden sollen. P1 und P2 werden nicht gebraucht.

Die Chipkarte sendet die angeforderten Daten und fügt eine neue Rückgabemeldung für den GET RESPONSE-Befehl dahinter ein. Damit ist die Befehlssequenz abgeschlossen.

Wird ein Befehl zur Karte gesendet, der nur eine Rückgabemeldung als Antwort verlangt, so entfällt der Teil mit GET RESPONSE.

Durch die Aktion des Abholens von Daten eines vorherigen Befehls mit einem zusätzlichen Befehl, verschwimmt die Trennung der Protokollschichten. Denn es muß ein Befehl der Anwendungsebene benutzt werden, um die Datenübertragung vollständig abzuschließen.

Ein weiteres Beispiel für das Aufweichen der Schichtentrennung ist das Acknowledge-Byte. Es besteht aus dem Instruktionsbyte, das ebenfalls ein Teil der Anwendungsebene ist, und dient zur Steuerung des Datenflusses.

Ein Nachteil des T=0-Protokolls ist die Fehlererkennung. Durch das Paritätsbit können 1-Bit-Fehler sicher erkannt werden. 2-Bit-Fehler lassen sich nicht mehr feststellen, und sobald ein ganzes Byte verloren geht, kommt es zu einer Endlosschleife in der Kommunikation, da unendlich lange auf dieses angekündigte Byte gewartet wird. Die einzige Lösung ist dann ein Reset.

Wegen der nicht vollständig vorhandenen Schichtentrennung und der Problematik bei der Fehlererkennung, wird das T=0-Protokoll oft als veraltet angesehen. Andererseits kommt es zwischen den Kommunikationspartnern nur selten zu Übertragungsfehlern.

Die wesentlichen Vorteile des T=0-Protokolls sind: Dieses Übertragungsprotokoll benötigt nur ca. 400 Bytes Speicherplatz, die durchschnittliche Datenübertragungsgeschwindigkeit ist hoch und, es ist weit verbreitet.

6.2.4.2 Übertragungsprotokoll T=1

Das Übertragungsprotokoll T=1 ist ein asynchrones blockorientiertes Halbduplexprotokoll. Es weist eine strenge Schichtentrennung auf. Gerade der Einsatz von verschlüsselter Datenübertragung erfordert es, daß die Schichtentrennung streng eingehalten wird. Das T=1-Protokoll ist momentan das einzige internationale Protokoll für Chipkarten, mit dem ohne Probleme und Kompromisse eine gesicherte Datenübertragung in allen Variationen möglich ist.

Ein Block bettet die zu übertragenden Informationen zwischen ein Prologfeld und ein Epilogfeld, um die Informationen sicher zu übertragen.

Abbildung 37: Aufbau eines T=1 Übertragungsblocks

Außerdem werden die Blöcke für Steuerdaten des Übertragungsprotokolls und zur Behandlung von Übertragungsfehlern verwendet.

Prologfeld

Das Prologfeld enthält grundlegende Steuerungs- und Anzeigeinformationen und setzt sich aus drei Unterfeldern zusammen: der Adresse, der Protokollkontrolle und der Länge.

Im ersten Byte, der Adresse, werden Absender und Adressat eines Blocks definiert. Das Byte für die Protokollkontrolle zeigt in den oberen zwei Bits an, um welchen Blocktyp es sich handelt. Unterschieden wird in Informationsblöcke, Empfangsbestätigungsblöcke und Systemblöcke.

Systemblöcke werden für Steuerinformationen, die das Protokoll selbst betreffen, benutzt. Zum Beispiel zur Verlängerung von Wartezeiten oder zur Größenänderung des Informationsfeldes.

Empfangsbestätigungsblöcke überwachen den Kommunikationsfluß. Sie besitzen kein Informationsfeld und dienen nur als positive oder negative Empfangsbestätigung bei Übertragungsfehlern.

Informationsblöcke werden zum Austausch von Informationen der Anwendungsebene verwendet. Sie enthalten ein wichtiges Sicherungsverfahren. Jeder Informationsblock ist mit einem Sendefolgezähler ausgestattet. Er ordnet jedem Block eine laufende Nummer zu. Sender und Empfänger verwalten ihren Folgezähler getrennt voneinander. Tritt eine Unstimmigkeit auf, so liegt ein Übertragungsfehler vor und der entsprechende Block kann mit seiner Nummer nochmals angefordert werden.

Das Längenfeld zeigt die Länge des nachfolgenden Informationsfeldes an. Sie kann zwischen Null und 254 Bytes liegen. Eine Länge von 32 Bytes ist voreingestellt, kann aber im ATR oder durch einen Steuerblock geändert werden.

Informationsfeld

Das Feld mit der zu übertragenden Information dient im Falle eines Informationsblockes als Container für die Daten der Anwendungsschicht. Diese Container werden als APDUs bezeichnet. Sie stellen international genormte Dateneinheiten der Anwendungsschicht dar. Unterschieden wird in Befehls-APDUs, die Befehle an die Chipkarte darstellen und Antwort-APDUs, welche die Antworten der Chipkarte enthalten.

Befehls-APDUs setzen sich aus einem obligatorischen Kopf und einem variablen Rumpf zusammen.

Abbildung 38: Struktur eines Befehls-APDU

Der Kopf entspricht genau dem des T=0-Protokolls, der im vorigen Kapitel 5 beschrieben wurde. Im Rumpf wird als erstes die Länge des Datenteils im Lc-Feld festgelegt, gefolgt vom eigentlichen Datenfeld.

Das Le-Feld spezifiziert die Länge des von der Chipkarte zurückzusendenden Datenteils. Falls das Le-Feld den Wert '00' hat, erwartet das Terminal das Maximum von Antwortdaten der Chipkarte. Dies ist die einzige Ausnahme in der numerischen Beschreibung der Längenangaben. Einen Befehls-APDU kann man in vier generelle Fälle unterscheiden:

Abbildung 39: Kombinationen bei Befehls-APDUs

Antwort-APDUs werden von der Chipkarte als Antwort auf einen Befehls-APDU gesendet und bestehen aus einem optionalen Rumpf und einer obligatorischen Rückmeldung.

Abbildung 40: Struktur einer Antwort-APDU

Der Rumpf besteht aus einem Datenfeld, dessen Länge in der vorangegangenen Befehls-APDU im Le-Feld festgelegt wird. Tritt während der Befehlsabarbeitung ein Fehler auf, wird kein Rumpf gesendet. In jedem Fall enthält die Rückmeldung Angaben über die Abarbeitung des Befehls. Ein Normenentwurf für mögliche Rückmeldungen ist für das T=1, sowie für das T=0-Protokoll, in der ISO 7816-4 nachzulesen.

Epilogfeld

Dieses, am Ende des Blocks, übertragene Feld enthält einen Fehlererkennungscode über alle vorangegangenen Bytes des Blocks. Mit diesem Byte kann man die Richtigkeit aller übertagenen Bytes prüfen. Wird ein Übertragungsfehler entdeckt, so kann der entsprechende Block durch den Folgezähler explizit ein zweites Mal angefordert werden.

Wartezeiten

Neben dem statischen Aufbau von T=1-Blöcken wurden auch einige Wartezeiten festgelegt, die zur Überwachung der Kommunikation dienen können. Zwei der wichtigsten sind die Zeichenwartezeit und die Blockwartezeit.

Die Zeichenwartezeit ist definiert als die maximale Zeitspanne zwischen den Startflanken zweier aufeinander folgender Zeichen innerhalb eines Blocks. Der Empfänger startet eine Stoppuhr. Diese Uhr hat als Startwert die Zeichenwartezeit. Läuft die Uhr ab und währenddessen wurde keine neue Startflanke eines Zeichens erkannt, so ist entweder der Block zu Ende oder es trat ein Fehler auf.

Normalerweise erkennt die Empfängerseite das Ende eines Blocks anhand der Blocklängenangabe im Längenfeld. Ist der Inhalt dieses Feldes jedoch fehlerhaft, wird zusätzlich die Zeichenwartezeit benutzt, um ein definiertes Ende beim Empfang zu erhalten.

Die Blockwartezeit ist die maximale Zeitspanne zwischen der Startflanke des letzten Zeichens eines Blocks, der zur Karte gesandt wurde, und der Startflanke des ersten Zeichens, das die Karte zurücksendet.

Läuft die Blockwartezeit ab, ohne daß die Karte eine Antwort sendet, muß das Terminal von einer Fehlfunktion der Karte ausgehen.

Fehlerbehandlung

Das T=1-Protokoll weist hochentwickelte Fehlererkennungs- und Behandlungsmechanismen auf. Werden ungültige Blöcke empfangen, so versucht das Protokoll anhand von festgelegten Abläufen die Kommunikation wieder auf ein fehlerfreies Niveau zurückzuführen.

Dabei gibt es aus der Sicht des Terminals drei Synchronisationsstufen:

In der ersten Stufe erhält der Sender eines fehlerhaften Blocks einen Empfangsbestätigungsblock, der einen Fehler anzeigt. Daraufhin muß der zuletzt gesendete Block wiederholt werden.

Ist es nicht möglich, mit dem Mechanismus der ersten Stufe eine fehlerfreie Verbindung wiederherzustellen, dann wird zur zweiten Stufe übergegangen. Dies bedeutet, daß die Chipkarte vom Terminal eine Resynchonisationsanfrage in einem Steuerblock erhält. Das Terminal erwartet daraufhin eine Resynchronisationsantwort. Gleichzeitig setzt sowohl das Terminal als auch die Chipkarte die Sendefolgezähler auf Null zurück. Dies entspricht dem Protokollzustand direkt nach dem ATR. Auf der Grundlage dieses Ursprungszustandes versucht nun das Terminal eine neue Verbindung herzustellen.

Kann das Terminal durch die Stufen eins und zwei keine fehlerfreie Verbindung aufbauen, so löst es einen Reset aus. Dabei gehen alle Informationen der aktuellen Sitzung verloren. Im Anschluß an diesen Reset muß die Kommunikation komplett neu aufgebaut werden. Führt auch dieses Verfahren nicht zum Erfolg, so deaktiviert das Terminal die Chipkarte.