Zum Inhalt springen

„Application Protocol Data Unit“ – Versionsunterschied

aus Wikipedia, der freien Enzyklopädie
Versionsgeschichte interaktiv durchsuchen
[gesichtete Version][gesichtete Version]
← Zum vorherigen Versionsunterschied
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
WP:OMA (Bitte zumindest die Einleitung so formulieren, dass man halbwegs weiß, worum es hier geht)
 
(27 dazwischenliegende Versionen von 12 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
'''''{{lang|en|Application Protocol Data Unit}}''''' ('''{{lang|en|APDU}}'''; [[englische Sprache|englisch]] für „Datenelement des Anwendungsprotokolls“) bezeichnet einen kombinierten Kommando-/Datenblock des [[Kommunikationsprotokoll|Kommunikationsprotokolls]] zwischen einem [[Chipkartenleser]] und einer [[Chipkarte]]. Für den Datenaustausch wird ein kombinierter [[Anweisung (Programmierung)|Befehl]]s- (oder ''Kommando-'') und Datenblock verwendet. Die Struktur der APDU ist definiert in der Norm [[ISO 7816]].<ref>{{Internetquelle | url=http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=36134 | titel=ISO/IEC 7816-4:2005 Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange | hrsg=Iso.org | datum=2008-10-03 | zugriff=2016-12-18}} (englisch)</ref>
{{Allgemeinverständlichkeit}}
'''Application Protocol Data Unit''' ('''APDU'''; {{deS|''"Datenelement des Anwendungsprotokolls"''}}) bezeichnet einen kombinierten Kommando-/Datenblock, der zwischen Anschlussschnittstelle und [[Chipkarte]] nach dem [[ISO 7816]]-Standard ausgetauscht wird.


'''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.
''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|ISO 7816-4]] festgelegt. ''APDUs'' stellen ein Informationselement der Anwendungsebene dar. Im [[OSI-Modell|OSI-Schichtenmodel]] entspricht das der Schicht 7.
Die Strukturen von ''command APDU'' und ''response APDU'' sind in der Norm [[ISO 7816|ISO 7816-4]] festgelegt. ''APDUs'' stellen ein Informationselement der Anwendungsebene dar. Im [[OSI-Modell|OSI-Schichtenmodel]] entspricht das der Schicht 7.
Zeile 8: Zeile 7:
== Ablauf der Kommunikation ==
== Ablauf der Kommunikation ==


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


== ''command APDU'' ==
== ''command APDU'' ==
Die Kommando-APDU besteht aus einem Kopf (Header) und einem optionalen Rumpf (Body).


Die Kommando-APDU besteht aus einem Kopf ({{enS|header}}) und einem optionalen Rumpf (engl. ''{{lang|en|body}}'').
{| border=1 cellspacing="0"

{| class="wikitable"
!width="10%"|CLA
!width="10%"|CLA
!width="10%"|INS
!width="10%"|INS
Zeile 21: Zeile 21:
!width="40%"|Data
!width="40%"|Data
!width="10%"|Le
!width="10%"|Le
|-
|-
|colspan="4" align="center" |Header
|colspan="4" align="center"| Header
|colspan="3" align="center" |Body
|colspan="3" align="center"| Body
|}
|}


Die einzelnen Bytes haben folgende Bedeutung:
Die einzelnen Bytes haben folgende Bedeutung:


{| class="prettytable"
{| class="wikitable"
!Bezeichner
! Bezeichner
!Name
! Name
!Länge
! Länge in Byte
!Bedeutung
! Bedeutung
|-
|-
| CLA
|CLA||Class||1 Byte||Gibt die Befehlsklasse an. Zusätzlich wird signalisiert, ob das Kommando Secure Messaging nutzt.
|-
| Class
| 1
|INS||Instruction||1 Byte||Gibt das Kommando an. Wegen Einschränkungen im byteorientierten Protokoll [[T=0]] dürfen nur geradzahlige Instruction-Bytes verwendet werden.
| Gibt die Befehlsklasse an. Zusätzlich wird signalisiert, ob das Kommando Secure Messaging nutzt.
|-
|-
|P1||Parameter&nbsp;1||1 Byte||Parameter für das Kommando
|-
| INS
| Instruction
|P2||Parameter&nbsp;2||1 Byte||Parameter für das Kommando
|-
| 1
| Gibt das Kommando an. Wegen Einschränkungen im byteorientierten Protokoll [[T=0]] dürfen nur geradzahlige Instruction-Bytes verwendet werden.
|Lc||Length&nbsp;command||0&nbsp;bis&nbsp;3&nbsp;Bytes||Länge der Kommandodaten (siehe auch [[Application Protocol Data Unit#Kodierung der Längenfelder Lc und Le|Kodierung der Längenfelder]]).
|-
|-
| P1
|Data||Data||Lc&nbsp;Bytes||Kommandodaten
| Parameter&nbsp;1
|-
| 1
|Le||Length&nbsp;expected||0&nbsp;bis&nbsp;3&nbsp;Bytes||Länge der erwarteten Antwortdaten (siehe auch [[Application Protocol Data Unit#Kodierung der Längenfelder Lc und Le|Kodierung der Längenfelder]]).
| Parameter für das Kommando
|}
|-
| P2
| Parameter&nbsp;2
| 1
| Parameter für das Kommando
|-
| Lc
| Length&nbsp;command
| 0, 1 oder 3
| Länge der Kommandodaten (siehe auch Abschnitt „[[#Kodierung der Längenfelder Lc und Le|Kodierung der Längenfelder]]“)
|-
| Data
| Data
| ''Lc''
| Kommandodaten
|-
| Le
| Length&nbsp;expected
| 0 bis 3
| Länge der erwarteten Antwortdaten (siehe auch Abschnitt „[[#Kodierung der Längenfelder Lc und Le|Kodierung der Längenfelder]]“)
|}


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.
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 ''{{lang|en|case 1}}'' bis ''{{lang|en|case 4}}'' (engl. für ''Fall 1 bis 4'') bezeichnet.


=== ''Case 1''-Kommando ===
=== ''Case 1''-Kommando ===

''Case 1'' ist ein einfaches Kommando ohne Kommandodaten und ohne Antwortdaten. Deshalb kann auf den gesamten ''Body'' des Kommandos verzichtet werden:
''Case 1'' ist ein einfaches Kommando ohne Kommandodaten und ohne Antwortdaten. Deshalb kann auf den gesamten ''Body'' des Kommandos verzichtet werden:
{| class="wikitable"
{| border=1 cellspacing="0"
|Header
| Header
|}
|}


=== ''Case 2''-Kommando ===
=== ''Case 2''-Kommando ===

Im ''Case 2'' hat das Kommando keine Kommandodaten, erwartet aber Antwortdaten. Daraus ergibt sich folgender Kommandoaufbau:
Im ''Case 2'' hat das Kommando keine Kommandodaten, erwartet aber Antwortdaten. Daraus ergibt sich folgender Kommandoaufbau:
{| class="wikitable"
{| border=1 cellspacing="0"
|Header||Le
| Header || Le
|}
|}


=== ''Case 3''-Kommando ===
=== ''Case 3''-Kommando ===

''Case 3'' beschreibt ein Kommando mit Kommandodaten, das keine Antwortdaten erwartet und demnach folgendermaßen aussieht:
''Case 3'' beschreibt ein Kommando mit Kommandodaten, das keine Antwortdaten erwartet und demnach folgendermaßen aussieht:
{| class="wikitable"
{| border=1 cellspacing="0"
|Header||Lc||Data
| Header || Lc || Data
|}
|}


=== ''Case 4''-Kommando ===
=== ''Case 4''-Kommando ===

Ein ''Case 4''-Kommando hat sowohl Kommando- als auch Antwortdaten und deswegen den vollständigen Kommando-''Body'':
Ein ''Case 4''-Kommando hat sowohl Kommando- als auch Antwortdaten und deswegen den vollständigen Kommando-''Body'':
{| class="wikitable"
{| border=1 cellspacing="0"
|Header||Lc||Data||Le
| Header || Lc || Data || Le
|}
|}


=== Kodierung der Längenfelder Lc und Le ===
=== 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 (Sedezimal 0x01 bis 0xFF). Der Sonderfall Le = 0x00 bedeutet hierbei eine erwartete Länge ("expected length") von 256 Bytes. Somit können maximal 255 Bytes geschrieben (Lc) und 256 Bytes gelesen (Le) werden.


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 ({{enS|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 ''[[Answer to Reset#Die Historical Characters|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 65536 annehmen. 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).


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 ''{{lang|en|extended APDUs}}'' eingeführt. Anhand der ''{{lang|en|[[Answer to Reset#Die Historical Characters|Historical Characters]]}}'' im ATR kann festgestellt werden, ob eine Smartcard diese größeren APDUs unterstützt. Bei der ''{{lang|en|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 (wenn B2 und B3 auf '0000' gesetzt werden, ist dies gleichbedeutend mit 65536) und das zweite (sofern vorhanden) nach dem gleichen Schema ohne das führende Null-Byte.

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'' ==
== ''response APDU'' ==
Die ''response APDU'' besteht aus einem optionalen Rumpf (Body) und einem obligatorischen Abschluss (Trailer).


Die sogenannte ''{{lang|en|response APDU}}'' ([[englische Sprache|engl.]] für ''Antwort-APDU'') besteht aus einem optionalen Rumpf (engl. ''{{lang|en|body}}'') und einem obligatorischen Abschluss (engl. ''{{lang|en|trailer}}'').
{| border=1 cellspacing="0"

!width="80%"|Data
{| class="wikitable"
!width="20%"|SW1 SW2
!width="80%"| Data
|-
!width="20%"| SW1 SW2
|align="center" |Body
|-
|align="center" |Trailer
|align="center"| Body
|}
|align="center"| Trailer
|}


Der Trailer enthält die beiden Status-Bytes SW1 und SW2, die zusammen das Statuswort (SW) bilden. Das Statuswort (engl. "[[Return Code|return code]]") gibt Auskunft über die erfolgreiche Abarbeitung des Kommandos oder die Art des Fehlers, der die Abarbeitung verhindert oder unterbrochen hat.
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'':
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
* Le nicht Null, und Kommando erfolgreich

{| border=1 cellspacing="0"
{| class="wikitable"
|width="80%"|Data
|width="80%"|Data
|width="20%"|SW1 SW2
|width="20%"|SW1 SW2
|}
|}
* Le ist Null, oder Kommando nicht erfolgreich
* Le ist Null, oder Kommando nicht erfolgreich

{| border=1 cellspacing="0"
{| class="wikitable"
|SW1 SW2
|SW1 SW2
|}
|}


=== Statuswörter ===
=== 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.


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.
{| border=1 cellspacing="0"

!align="center"|61xx&nbsp;und&nbsp;9000
{| class="wikitable"
!align="center"|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;62xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!align="center"|63xx
!align="center"| 61xx&nbsp;und&nbsp;9000
!align="center"| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;62xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!align="center"|65xx
!align="center"|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;64xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!align="center"| 63xx
!align="center"| 65xx
!align="center"| &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;64xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!align="center"|67xx&nbsp;bis&nbsp;6Fxx
!align="center"| 67xx&nbsp;bis&nbsp;6Fxx
|-
|-
|colspan="3" align="center"|Prozess abgeschlossen
|colspan="3" align="center"| Prozess abgeschlossen
|colspan="3" align="center"|Prozess abgebrochen
|colspan="3" align="center"| Prozess abgebrochen
|-
|-
|align="center"|Normal
|align="center"| Normal
|colspan="2" align="center"|Warnung
|colspan="2" align="center"| Warnung
|colspan="2" align="center"|Ausführungsfehler
|colspan="2" align="center"| Ausführungsfehler
|align="center"|Prüfungsfehler
|align="center"| Prüfungsfehler
|-
|-
|&nbsp;
|&nbsp;
|align="center"|Keine Daten verändert
|align="center"|Keine Daten verändert
|colspan="2" align="center"|Daten im EEPROM verändert
|colspan="2" align="center"| Daten im EEPROM verändert
|colspan="2" align="center"|Keine Daten verändert
|colspan="2" align="center"| Keine Daten verändert
|}
|}


Die folgende Tabelle zeigt die wichtigsten Statuswörter und ihre Bedeutung:
Die folgende Tabelle zeigt die wichtigsten Statuswörter und ihre Bedeutung:
{| class="prettytable"
{| class="wikitable"
!Statuswort
! Statuswort
!Bedeutung
! Bedeutung
!Anmerkung
! Anmerkung
|-
|61xx||Kommando erfolgreich ausgeführt. xx Datenbytes können mit dem GET RESPONSE-Kommando abgeholt werden.||Statuswort zur Steuerung des T=0-Protokolls
|-
|-
| 61xx
|6281||Die zurückgegebenen Daten können fehlerhaft sein||&nbsp;
| Kommando erfolgreich ausgeführt. xx Datenbytes können mit dem ‚<code>{{lang|en|GET RESPONSE}}</code>‘-Kommando abgeholt werden.
| Statuswort zur Steuerung des T=0-Protokolls
|-
|-
| 6281
|6282||Da das Dateiende vorher erreicht wurde, konnten nur weniger als Le Bytes gelesen werden||&nbsp;
| Die zurückgegebenen Daten können fehlerhaft sein.
| &nbsp;
|-
|-
| 6282
|6283||Die ausgewählte Datei ist gesperrt (invalidated)||&nbsp;
| Da das Dateiende vorher erreicht wurde, konnten nur weniger als ''Le'' Bytes gelesen werden.
| &nbsp;
|-
|-
| 6283
|6284||Die File Control Information (FCI) ist nicht [[ISO 7816|ISO 7816-4]]-konform||&nbsp;
| Die ausgewählte Datei ist gesperrt ({{enS|invalidated}}, wörtlich „ungültig“).
| &nbsp;
|-
|-
| 6284
|62xx||Warnung; Zustand des nichtflüchtigen Speichers nicht verändert||&nbsp;
| Die ''{{lang|en|File Control Information}}'' (''{{lang|en|FCI}}'') ist inkonform zu ''[[ISO 7816|ISO 7816-4]]''.
| &nbsp;
|-
|-
| 62xx
|63Cx||Zähler hat den Wert x erreicht (die genaue Bedeutung ist vom Kommando abhängig)||&nbsp;
| Warnung; Zustand des nichtflüchtigen Speichers nicht verändert
| &nbsp;
|-
|-
| 63Cx
|63xx||Warnung; Zustand des nichtflüchtigen Speichers verändert||&nbsp;
| Zähler hat den Wert x erreicht (die genaue Bedeutung ist vom Kommando abhängig)
| &nbsp;
|-
|-
| 63xx
|64xx||Ausführungsfehler; Zustand des nichtflüchtigen Speichers nicht verändert||&nbsp;
| Warnung; Zustand des nichtflüchtigen Speichers verändert
| &nbsp;
|-
|-
| 64xx
|6581||Speicherfehler||&nbsp;
| Ausführungsfehler; Zustand des nichtflüchtigen Speichers nicht verändert
| &nbsp;
|-
|-
| 6581
|65xx||Ausführungsfehler; Zustand des nichtflüchtigen Speichers verändert||&nbsp;
| Speicherfehler
| &nbsp;
|-
|-
| 65xx
|6700||Länge (Lc oder Le) falsch||&nbsp;
| Ausführungsfehler; Zustand des nichtflüchtigen Speichers verändert
| &nbsp;
|-
|-
| 6700
|6800||Funktionen im Class-Byte werden nicht unterstützt||&nbsp;
| Befehlslänge (''Lc'') oder erwartete Antwortlänge (''Le'') falsch
| &nbsp;
|-
|-
| 6800
|6881||Logische Kanäle werden nicht unterstützt||&nbsp;
| Funktionen im Class-Byte werden nicht unterstützt
| &nbsp;
|-
|-
| 6881
|6882||Secure Messaging wird nicht unterstützt||&nbsp;
| Logische Kanäle werden nicht unterstützt
| &nbsp;
|-
|-
| 6882
|6900||Kommando nicht erlaubt||&nbsp;
| ''{{lang|en|Secure Messaging}}'' wird nicht unterstützt
| &nbsp;
|-
|-
| 6900
|6981||Kommando inkompatibel zur Dateistruktur||&nbsp;
| Kommando nicht erlaubt
| &nbsp;
|-
|-
| 6981
|6982||Sicherheitszustand nicht erfüllt||&nbsp;
| Kommando inkompatibel zur Dateistruktur
| &nbsp;
|-
|-
| 6982
|6983||Authentisierungsmethode ist gesperrt||&nbsp;
| Sicherheitszustand nicht erfüllt
| &nbsp;
|-
|-
| 6983
|6984||Referenzierte Daten sind gesperrt||&nbsp;
| Authentisierungsmethode ist gesperrt
| &nbsp;
|-
|-
| 6984
|6985||Nutzungsbedingungen sind nicht erfüllt||&nbsp;
| Referenzierte Daten sind gesperrt
| &nbsp;
|-
|-
| 6985
|6986||Kommando nicht erlaubt (kein EF selektiert)||&nbsp;
| Nutzungsbedingungen sind nicht erfüllt
| &nbsp;
|-
|-
| 6986
|6987||Erwartete Secure-Messaging-Objekte nicht gefunden||&nbsp;
| Kommando nicht erlaubt (kein EF selektiert)
| &nbsp;
|-
|-
| 6987
|6988||Secure-Messaging-Datenobjekte sind inkorrekt||&nbsp;
| Erwartete Secure-Messaging-Objekte nicht gefunden
| &nbsp;
|-
|-
| 6988
|6A00||Falsche Parameter P1/P2||&nbsp;
| Secure-Messaging-Datenobjekte sind inkorrekt
| &nbsp;
|-
|-
| 6A00
|6A80||Falsche Daten||&nbsp;
| Falsche Parameter P1/P2
| &nbsp;
|-
|-
| 6A80
|6A81||Funktion wird nicht unterstützt||&nbsp;
| Falsche Daten
| &nbsp;
|-
|-
| 6A81
|6A82||Datei wurde nicht gefunden||&nbsp;
| Funktion wird nicht unterstützt
| &nbsp;
|-
|-
| 6A82
|6A83||Datensatz ("record") der Datei nicht gefunden||&nbsp;
| Datei wurde nicht gefunden
| &nbsp;
|-
|-
| 6A83
|6A84||Nicht genügend Speicherplatz in der Datei||&nbsp;
| Datensatz (engl. ''{{lang|en|record}}'') der Datei nicht gefunden
| &nbsp;
|-
|-
| 6A84
|6A85||Lc nicht konsistent mit der [[Type-Length-Value|TLV]]-Struktur||&nbsp;
| Nicht genügend Speicherplatz in der Datei
| &nbsp;
|-
|-
| 6A85
|6A86||Inkorrekte Parameter P1/P2||&nbsp;
| Lc nicht konsistent mit der [[Type-Length-Value|TLV]]-Struktur
| &nbsp;
|-
|-
| 6A86
|6A87||Lc inkonsistent mit P1/P2||&nbsp;
| Inkorrekte Parameter P1/P2
| &nbsp;
|-
|-
| 6A87
|6A88||Referenzierte Daten nicht gefunden||&nbsp;
| Lc inkonsistent mit P1/P2
| &nbsp;
|-
|-
| 6A88
|6B00||Parameter P1/P2 falsch||&nbsp;
| Referenzierte Daten nicht gefunden
| &nbsp;
|-
|-
| 6B00
|6Cxx||Falsche Länge Le; xx gibt die korrekte Länge an||Statuswort zur Steuerung des T=0-Protokolls
| Parameter P1/P2 falsch
| &nbsp;
|-
|-
| 6Cxx
|6D00||Das Kommando (INS) wird nicht unterstützt||&nbsp;
| Falsche Länge Le; xx gibt die korrekte Länge an
| Statuswort zur Steuerung des T=0-Protokolls
|-
|-
| 6D00
|6E00||Die Kommandoklasse (CLA) wird nicht unterstützt||&nbsp;
| Das Kommando (INS) wird nicht unterstützt
| &nbsp;
|-
|-
| 6E00
|6F00||Kommando wurde mit unbekanntem Fehler abgebrochen||&nbsp;
| Die Kommandoklasse (CLA) wird nicht unterstützt
| &nbsp;
|-
|-
| 6F00
|9000||Kommando erfolgreich ausgeführt||&nbsp;
| Kommando wurde mit unbekanntem Fehler abgebrochen
| &nbsp;
|-
| 9000
| Kommando erfolgreich ausgeführt
| &nbsp;
|}
|}


== Weblinks ==
== Einzelnachweise ==
<references />

* [http://www.cryptoshop.com/de/knowledgebase/technology/smartcard/smartcardcom.php Smart Card Kommunikation]


[[Kategorie:Chipkarten]]
[[Kategorie:Chipkarten]]

Aktuelle Version vom 26. Juli 2023, 01:28 Uhr

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

[Bearbeiten | Quelltext bearbeiten]

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

command APDU

[Bearbeiten | Quelltext bearbeiten]

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

CLA INS P1 P2 Lc Data Le
Header Body

Die einzelnen Bytes haben folgende Bedeutung:

Bezeichner Name Länge in Byte Bedeutung
CLA Class 1 Gibt die Befehlsklasse an. Zusätzlich wird signalisiert, ob das Kommando Secure Messaging nutzt.
INS Instruction 1 Gibt das Kommando an. Wegen Einschränkungen im byteorientierten Protokoll T=0 dürfen nur geradzahlige Instruction-Bytes verwendet werden.
P1 Parameter 1 1 Parameter für das Kommando
P2 Parameter 2 1 Parameter für das Kommando
Lc Length command 0, 1 oder 3 Länge der Kommandodaten (siehe auch Abschnitt „Kodierung der Längenfelder“)
Data Data Lc Kommandodaten
Le Length expected 0 bis 3 Lä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

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

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

Header Le

Case 3-Kommando

[Bearbeiten | Quelltext bearbeiten]

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

Header Lc Data

Case 4-Kommando

[Bearbeiten | Quelltext bearbeiten]

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

Header Lc Data Le

Kodierung der Längenfelder Lc und Le

[Bearbeiten | Quelltext bearbeiten]

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

[Bearbeiten | Quelltext bearbeiten]

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

Data SW1 SW2
Body Trailer

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
Data SW1 SW2
  • Le ist Null, oder Kommando nicht erfolgreich
SW1 SW2

Statuswörter

[Bearbeiten | Quelltext bearbeiten]

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      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 (englisch invalidated, wörtlich „ungültig“).  
6284 Die File Control Information (FCI) ist inkonform zu ISO 7816-4.  
62xx Warnung; Zustand des nichtflü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 nichtflüchtigen Speichers verändert  
64xx Ausführungsfehler; Zustand des nichtflüchtigen Speichers nicht verändert  
6581 Speicherfehler  
65xx Ausführungsfehler; Zustand des nichtflüchtigen Speichers verändert  
6700 Befehlslänge (Lc) oder erwartete Antwortlänge (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 Datensatz (engl. 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  

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  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)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Application_Protocol_Data_Unit&oldid=235819517“