Was ist eine APDU, und wann braucht Ihr Code eine?

Befehl und Antwort

Eine Befehls-APDU beginnt mit vier Bytes. CLA gibt die Klasse der Anweisung an, INS die Anweisung selbst, P1 und P2 ihre Parameter. Daten folgen, wenn der Befehl welche sendet, mit ihrer Länge davor, Lc, und der Befehl kann mit Le enden, der Länge der erwarteten Antwort. Apples Initialisierer für NFCISO7816APDU baut eine aus genau diesen Feldern.

Längen gibt es in zwei Größen. Eine gewöhnliche APDU trägt höchstens 255 Datenbytes, 261 Bytes im Ganzen, eine erweiterte bis zu 65535, so die Referenz zu IsoDep, und manche Android-Controller verweigern die erweiterte Form, wie die Seite zu den Grenzen des Controllers erklärt. Apples Initialisierer kodiert Le aus einer Zahl: 256 sendet 00 in der kurzen Form, 65536 sendet 0000 in der erweiterten, und -1 erklärt, dass keine Antwortdaten erwartet werden.

Die Antwort sind Daten gefolgt von zwei Statusbytes, SW1 und SW2. Die Daten können leer sein, und Apple merkt an, dass sie es auch dann sein können, wenn der Befehl gelang.

Wann Code eine braucht

Immer dann, wenn der Tag ISO/IEC 7816-4 spricht: Type-4-Tags, die NDEF in Dateien ablegen, die über APDU erreicht werden, und Karten auf Grundlage der ISO/IEC 14443-4, die Android über IsoDep bereitstellt. Ein Type-2-Tag tut es nicht; er antwortet auf die NFC-A-Befehle, die die Seite zum Speicher eines Type-2-Tags beschreibt.

Unter Android sendet IsoDep.transceive() die APDU und gibt die Antwort mit ihren zwei Statusbytes am Ende zurück. Unter iOS übergibt eine Tag-Sitzung NFCISO7816Tag und dessen sendCommand(apdu:); für MIFARE-Plus- und DESFire-Tags, die als NFCMiFareTag ankommen, bietet Apple sendMiFareISO7816Command zum selben Zweck.

NDEF auf einem Type-4-Tag zu lesen oder zu schreiben verlangt keine von Hand gebaute APDU: Androids Klasse Ndef und die NDEF-Aufrufe von Core NFC tun es. Code baut APDU für das, was NDEF nicht abdeckt, etwa eine andere Datei als die NDEF-Datei, eine Zugriffsbedingung, oder eine eigene Anwendung. Die Seite zur NDEF-Datei eines Type-4-Tags folgt der Abfolge, die die Plattformen durchlaufen.

Die Auswahl kommt zuerst

Eine Karte nach ISO/IEC 7816-4 hält Anwendungen und Dateien, und ein Befehl wirkt auf das, was gerade ausgewählt ist. SELECT, Anweisung 0xA4, wählt nach Namen, wenn P1 auf 0x04 steht, wobei der Name eine Anwendungskennung ist, und nach Dateikennung, wenn P1 auf 0x00 steht. Das sind die Werte, die der quelloffene NFC-Stack von Android benutzt, um NDEF auf einem Type-4-Tag zu erreichen.

iOS schränkt die erste Art ein. Ein SELECT mit P1 auf 0x04 muss eine Anwendung nennen, die in der Info.plist der Anwendung aufgeführt ist, sonst scheitert der Aufruf mit readerErrorSecurityViolation, so die Referenz zu sendCommand. Die Sitzung wählt außerdem eine der aufgeführten Anwendungen aus, wenn sie den Tag erkennt, und meldet in initialSelectedAID, welche; die Seite zu den Deklarationen behandelt die Liste.

Eine Auswahl dauert nicht länger als die Versorgung des Tags. Ein Tag, der das Feld verlässt, verliert beides, Code, der sich neu verbindet, wählt die Anwendung also vor seinem nächsten Befehl erneut aus.

Die Statusbytes lesen

90 00 heißt, dass der Befehl durchlief. Die anderen Werte stammen aus der ISO/IEC 7816-4 oder aus der Anwendung der Karte, und der Stack von Android benennt die, denen ein Lesegerät für Type 4 am häufigsten begegnet:

Jede Plattform verbirgt sie auf ihre Weise. Unter Android sind es die letzten zwei Bytes des Feldes, das transceive() zurückgibt, und Code, der das ganze Feld als Daten behandelt, hält sie für Inhalt. Unter iOS deckt der Fehler nur die Übertragung ab, und eine Anwendung, die den Fehler prüft und nicht sw1 und sw2, nimmt eine Weigerung für einen Erfolg.