Application Protocol Data Unit

Application Protocol Data Unit (APDU; englisch für „Datenelement des Anwendungsprotokolls“) bezeichnet einen kombinierten Kommando-/Datenblock des Kommunikationsprotokolls zwischen einem Chipkartenleser und einer Chipkarte. Für den Datenaustausch wird ein kombinierter Befehls- (oder Kommando-) und Datenblock verwendet. Die Struktur der APDU ist definiert in der Norm ISO 7816.[1]

APDUs werden unterschieden in command APDUs, welche Kommandos an die Chipkarte übermitteln, und response APDUs, die die jeweilige Antwort der Karte auf ein Kommando übermitteln. Eine Kommunikation wird immer von der Anschlussschnittstelle angestoßen. Auf eine command APDU der Anschlussschnittstelle erfolgt jeweils eine response APDU der Karte. Die Chipkarte selbst initiiert nie eine Kommunikation.

Die Strukturen von command APDU und response APDU sind in der Norm ISO 7816-4 festgelegt. APDUs stellen ein Informationselement der Anwendungsebene dar. Im OSI-Schichtenmodel entspricht das der Schicht 7.

Ablauf der Kommunikation

Zu Beginn einer Kommunikation wird das Anwendungsprotokoll üblicherweise mittels Answer-to-Reset- und optionaler Protocol-Type-Selection-ADPUs initialisiert.

command APDU

Die Kommando-APDU besteht aus einem Kopf (englisch header) und einem optionalen Rumpf (engl. body).

CLAINSP1P2LcDataLe
HeaderBody

Die einzelnen Bytes haben folgende Bedeutung:

BezeichnerNameLänge in ByteBedeutung
CLAClass1Gibt die Befehlsklasse an. Zusätzlich wird signalisiert, ob das Kommando Secure Messaging nutzt.
INSInstruction1Gibt das Kommando an. Wegen Einschränkungen im byteorientierten Protokoll T=0 dürfen nur geradzahlige Instruction-Bytes verwendet werden.
P1Parameter 11Parameter für das Kommando
P2Parameter 21Parameter für das Kommando
LcLength command0, 1 oder 3Länge der Kommandodaten (siehe auch Abschnitt „Kodierung der Längenfelder“)
DataDataLcKommandodaten
LeLength expected0 bis 3Länge der erwarteten Antwortdaten (siehe auch Abschnitt „Kodierung der Längenfelder“)

Wenn keine Antwortdaten erwartet werden, wird das Le-Byte des Rumpfes (oder Bodys) 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 (engl. für Fall 1 bis 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:

HeaderLe

Case 3-Kommando

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

HeaderLcData

Case 4-Kommando

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

HeaderLcDataLe

Kodierung der Längenfelder Lc und Le

Es gibt zwei unterschiedliche Kodierungen für die Längenfelder Lc und Le. Standardmäßig unterstützt werden die kurzen Längenfelder; hierbei ist die Längenangabe nur ein Byte lang und unterstützt somit Werte von 1 bis 255 Byte (Hexadezimal 0x01 bis 0xFF). Der Sonderfall Le = 0x00 bedeutet hierbei eine erwartete Länge (englisch expected length) von 256 Bytes. Somit können maximal 255 Bytes geschrieben (Lc) und 256 Bytes gelesen (Le) werden.

Wegen der immer größeren Datenmengen, die auf Smartcards (besonders im Bereich der Signaturen) gespeichert und gelesen werden können, wurde es notwendig, innerhalb einer APDU größere Datenmengen zu lesen oder zu schreiben. Dazu wurden die extended APDUs eingeführt. Anhand der Historical Characters im ATR kann festgestellt werden, ob eine Smartcard diese größeren APDUs unterstützt. Bei der extended APDU kann Lc bzw. Le einen Wert zwischen 1 und 65535 bzw. 65536 kodieren. Das erste auftretende Feld wird dabei mit 3 Bytes kodiert. Bei Case-2-Kommando-APDUS ist dies das Le-Feld, bei Case-3- und -4-Kommando-APDUS das Lc-Feld. Bei Case-4-Kommando-APDUS wird das Le-Feld mit 2 Bytes codiert (das führende Null-Byte entfällt).

Kodiert wird demnach das erste Lx-Feld mit 3 Bytes (B1)='00', (B2||B3)=beliebiger Wert, wobei für Lc hier '0000' nicht erlaubt ist (wenn B2 und B3 für Le auf '0000' gesetzt werden, ist dies gleichbedeutend mit 65536) und das zweite (sofern vorhanden ist es Le) nach dem gleichen Schema ohne das führende Null-Byte.

response APDU

Die sogenannte response APDU (engl. für Antwort-APDU) besteht aus einem optionalen Rumpf (engl. body) und einem obligatorischen Abschluss (engl. trailer).

DataSW1 SW2
BodyTrailer

Der Abschluss (oder Trailer) enthält die beiden Status-Bytes SW1 und SW2, die zusammen das Statuswort (kurz SW oder den auch sogenannten Return Code) bilden. Das Statuswort 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
DataSW1 SW2
  • Le ist Null, oder Kommando nicht erfolgreich
SW1 SW2

Statuswörter

Das Statuswort hat entweder die Werte 9000 oder 61xx und zeigt damit die fehlerfreie Abarbeitung des Kommandos an, oder die Werte 62xx bis 6Fxx, welche die Art der Abweichung vom normalen Ablauf angeben. Die Statuswörter unterliegen der in der Tabelle angegebenen Systematik.

61xx und 9000     62xx     63xx65xx     64xx     67xx bis 6Fxx
Prozess abgeschlossenProzess abgebrochen
NormalWarnungAusführungsfehlerPrüfungsfehler
 Keine Daten verändertDaten im EEPROM verändertKeine Daten verändert

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

StatuswortBedeutungAnmerkung
61xxKommando erfolgreich ausgeführt. xx Datenbytes können mit dem ‚GET RESPONSE‘-Kommando abgeholt werden.Statuswort zur Steuerung des T=0-Protokolls
6281Die zurückgegebenen Daten können fehlerhaft sein. 
6282Da das Dateiende vorher erreicht wurde, konnten nur weniger als Le Bytes gelesen werden. 
6283Die ausgewählte Datei ist gesperrt (englisch invalidated, wörtlich „ungültig“). 
6284Die File Control Information (FCI) ist inkonform zu ISO 7816-4. 
62xxWarnung; Zustand des nichtflüchtigen Speichers nicht verändert 
63CxZähler hat den Wert x erreicht (die genaue Bedeutung ist vom Kommando abhängig) 
63xxWarnung; Zustand des nichtflüchtigen Speichers verändert 
64xxAusführungsfehler; Zustand des nichtflüchtigen Speichers nicht verändert 
6581Speicherfehler 
65xxAusführungsfehler; Zustand des nichtflüchtigen Speichers verändert 
6700Befehlslänge (Lc) oder erwartete Antwortlänge (Le) falsch 
6800Funktionen im Class-Byte werden nicht unterstützt 
6881Logische Kanäle werden nicht unterstützt 
6882Secure Messaging wird nicht unterstützt 
6900Kommando nicht erlaubt 
6981Kommando inkompatibel zur Dateistruktur 
6982Sicherheitszustand nicht erfüllt 
6983Authentisierungsmethode ist gesperrt 
6984Referenzierte Daten sind gesperrt 
6985Nutzungsbedingungen sind nicht erfüllt 
6986Kommando nicht erlaubt (kein EF selektiert) 
6987Erwartete Secure-Messaging-Objekte nicht gefunden 
6988Secure-Messaging-Datenobjekte sind inkorrekt 
6A00Falsche Parameter P1/P2 
6A80Falsche Daten 
6A81Funktion wird nicht unterstützt 
6A82Datei wurde nicht gefunden 
6A83Datensatz (engl. record) der Datei nicht gefunden 
6A84Nicht genügend Speicherplatz in der Datei 
6A85Lc nicht konsistent mit der TLV-Struktur 
6A86Inkorrekte Parameter P1/P2 
6A87Lc inkonsistent mit P1/P2 
6A88Referenzierte Daten nicht gefunden 
6B00Parameter P1/P2 falsch 
6CxxFalsche Länge Le; xx gibt die korrekte Länge anStatuswort zur Steuerung des T=0-Protokolls
6D00Das Kommando (INS) wird nicht unterstützt 
6E00Die Kommandoklasse (CLA) wird nicht unterstützt 
6F00Kommando wurde mit unbekanntem Fehler abgebrochen 
9000Kommando erfolgreich ausgeführt 

Einzelnachweise

  1. ISO/IEC 7816-4:2005 Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange. Iso.org, 3. Oktober 2008, abgerufen am 18. Dezember 2016. (englisch)