Das Kefk Network Wiki befindet sich im Testbetrieb.

---

Aus Kefk.

Die Application Protocol Data Unit ist die Kommunikationseinheit zwischen Chipkarte und einer Chipkartenanwendung nach dem ISO 7816-Standard. Die APDU ist eine Kommunikationseinheit auf Anwendungsebene. Im OSI-Schichtenmodel entspricht das der Schicht 7.

Die APDU wird unterschieden in command APDUs, welche Kommandos an die Chipkarte übermitteln und response APDUs, die die Antwort der Karte auf ein Kommando übermittelt. Diese Kommunikation findet nach Etablierung der Kommunikation mittels Answer to Reset und optionaler Protocol Type Selection statt. Die Struktur von command APDU und response APDU sind in der Norm ISO 7816-4 festgelegt.

Inhaltsverzeichnis 1 command APDU 1.1 Case 1 Kommando 1.2 Case 2 Kommando 1.3 Case 3 Kommando 1.4 Case 4 Kommando 2 response APDU 2.1 Statuswörter 3 Weblinks

command APDU

Die Kommando-APDU besteht aus einem Kopf (Header) und einem optionalen Körper (Body).

CLA	INS	P1	P2	Lc	Data	Le
Header				Body

Die einzelnen Bytes haben folgende Bedeutung:

Bezeichner	Name	Länge	Bedeutung
CLA	Class	1 Byte	Gibt die Klasse des Befehls an. Zusätzlich wird signalisiert, ob das Kommando Secure Messaging nutzt.
INS	Instruction	1 Byte	Gibt das Kommando an. Wegen Einschränkungen im byteorientierten Protokoll T=0 dürfen nur geradzahlige Instruction-Bytes verwendet werden.
P1	Parameter 1	1 Byte	Parameter für das Kommando
P2	Parameter 2	1 Byte	Parameter für das Kommando
Lc	Length command	1 Byte	Länge der Kommandodaten.
Data	Data	Lc Bytes	Kommandodaten
Le	Length expected	1 Byte	Länge der erwarteten Antwortdaten.

Wenn keine Antwortdaten erwartet werden, wird das Le Byte des Body weggelassen. Genauso werden Lc Byte und die Daten weggelassen, wenn keine Kommandodaten nötig sind. Abhängig von Kommando- und Antwortdaten lassen sich vier Fälle mit unterschiedlicher Struktur des Kommandos unterscheiden. Sie werden mit case 1 bis case 4 bezeichnet.

Case 1 Kommando

Case 1 ist ein einfaches Kommando ohne Kommandodaten und ohne Antwortdaten. Deshalb kann auf den gesamten Body des Kommandos verzichtet werden:

Header

Case 2 Kommando

Im Case 2 hat das Kommando keine Kommandodaten, erwartet aber Antwortdaten. Daraus ergibt sich folgender Kommandoaufbau:

Header

Le

Case 3 Kommando

Case 3 beschreibt ein Kommando mit Kommandodaten, das keine Antwortdaten erwartet und demnach folgendermaßen aussieht:

Header

Lc

Data

Case 4 Kommando

Ein Case 4 Kommando hat sowohl Kommando- als auch Antwortdaten und deswegen den vollständigen Kommandobody:

Header

Lc

Data

Le

response APDU

Die response APDU besteht aus einem optionalen Körper (Body) und einem obligatorischen Abschluss (Trailer).

Data	SW1 SW2
Body	Trailer

Der Trailer enthält die beiden Status Bytes SW1 und SW2, die zusammen das Statuswort (SW) bilden. Das Statuswort - auch Returncode genannt - gibt Auskunft über die erfolgreiche Abarbeitung des Kommandos oder die Art des Fehlers, der die Abarbeitung verhindert oder unterbrochen hat.

Der Body enthält die Antwortdaten des Kommandos, dessen Länge im Le Byte der command APDU angegeben war. Wenn Le Null ist oder die Kommandoabarbeitung wegen eines Fehlers abgebrochen wurde, werden keine Antwortdaten verschickt. Damit ergeben sich zwei Varianten einer response APDU:

• Le nicht Null und Kommando erfolgreich

Data

SW1 SW2

• Le ist Null oder Kommando nicht erfolgreich

SW1 SW2

Statuswörter

Das Statuswort hat entweder den Wert 9000 und zeigt damit die fehlerfreie Abarbeitung des Kommandos an oder einen Wert 6xxx, der die Art der Abweichung vom normalen Ablauf angibt. Die Statuswörter unterliegen der in der Tabelle angegebenen Systematik.

61xx und 9000	62xx	63xx	65xx	64xx	67xx bis 6Fxx
Prozess abgeschlossen			Prozess abgebrochen
Normal	Warnung		Ausführungsfehler		Prüfungsfehler
	Keine Daten verändert	Daten im EEPROM verändert		Keine Daten verändert

Die folgende Tabelle zeigt die wichtigsten Statuswörter und ihre Bedeutung:

Statuswort	Bedeutung	Anmerkung
61xx	Kommando erfolgreich ausgeführt. xx Datenbytes können mit dem GET RESPONSE Kommando abgeholt werden.	Statuswort zur Steuerung des T=0 Protokolls
6281	Die zurückgegebenen Daten können fehlerhaft sein
6282	Da das Dateiende vorher erreicht wurde, konnten nur weniger als Le Bytes gelesen werden
6283	Die ausgewählte Datei ist gesperrt (invalidated)
6284	Die File Control Information (FCI) ist nicht ISO 7816-4 konform
62xx	Warnung; Zustand des nicht flüchtigen Speichers nicht verändert
63Cx	Zähler hat den Wert x erreicht (Die genaue Bedeutung ist vom Kommando abhängig)
63xx	Warnung; Zustand des nicht flüchtigen Speichers verändert
64xx	Ausführungsfehler; Zustand des nicht flüchtigen Speichers nicht verändert
6581	Speicherfehler
65xx	Ausführungsfehler; Zustand des nicht flüchtigen Speichers verändert
6700	Länge (Lc oder Le) falsch
6800	Funktionen im Class Byte werden nicht unterstützt
6881	Logische Kanäle werden nicht unterstützt
6882	Secure Messaging wird nicht unterstützt
6900	Kommando nicht erlaubt
6981	Kommando inkompatibel zur Dateistruktur
6982	Sicherheitszustand nicht erfüllt
6983	Authentisierungsmethode ist gesperrt
6984	Referenzierte Daten sind gesperrt
6985	Nutzungsbedingungen sind nicht erfüllt
6986	Kommando nicht erlaubt (kein EF selektiert)
6987	Erwartete Secure Messaging Objekte nicht gefunden
6988	Secure Messaging Datenobjekte sind inkorrekt
6A00	Falsche Parameter P1/P2
6A80	Falsche Daten
6A81	Funktion wird nicht unterstützt
6A82	Datei wurde nicht gefunden
6A83	Record der Datei nicht gefunden
6A84	Nicht genügend Speicherplatz in der Datei
6A85	Lc nicht konsistent mit der TLV Struktur
6A86	Inkorrekte Parameter P1/P2
6A87	Lc inkonsistent mit P1/P2
6A88	Referenzierte Daten nicht gefunden
6B00	Parameter P1/P2 falsch
6Cxx	Falsche Länge Le; xx gibt die korrekte Länge an	Statuswort zur Steuerung des T=0 Protokolls
6D00	Das Kommando (INS) wird nicht unterstützt
6E00	Die Kommandoklasse (CLA) wird nicht unterstützt
6F00	Kommando wurde mit unbekanntem Fehler abgebrochen
9000	Kommando erfolgreich ausgeführt

Weblinks

• Smart Card Kommunikation