Che cos'è un'APDU, e quando serve al tuo codice?

Comando e risposta

Un'APDU di comando comincia con quattro byte. CLA dà la classe dell'istruzione, INS l'istruzione stessa, P1 e P2 i suoi parametri. I dati seguono quando il comando ne invia, preceduti dalla loro lunghezza, Lc, e il comando può finire con Le, la lunghezza della risposta che si aspetta. L'inizializzatore di NFCISO7816APDU di Apple ne costruisce una esattamente da questi campi.

Le lunghezze hanno due misure. Un'APDU normale porta al massimo 255 byte di dati, 261 byte in tutto, e una estesa fino a 65535, secondo il riferimento di IsoDep, e certi controller Android rifiutano la forma estesa, come spiega la pagina dei limiti del controller. L'inizializzatore di Apple codifica Le da un numero: 256 invia 00 nella forma corta, 65536 invia 0000 nella forma estesa, e -1 dichiara che non si aspetta alcun dato di risposta.

La risposta è fatta di dati seguiti da due byte di stato, SW1 e SW2. I dati possono essere vuoti, e Apple nota che possono esserlo anche quando il comando è riuscito.

Quando serve al codice

Ogni volta che il tag parla ISO/IEC 7816-4: i tag di tipo 4, che conservano il NDEF in file raggiunti da APDU, e le schede costruite su ISO/IEC 14443-4, che Android espone tramite IsoDep. Un tag di tipo 2 no; risponde ai comandi NFC-A descritti nella pagina della memoria di tipo 2.

Su Android, IsoDep.transceive() invia l'APDU e rende la risposta con i suoi due byte di stato in fondo. Su iOS, una sessione di tag consegna NFCISO7816Tag e il suo sendCommand(apdu:); per i tag MIFARE Plus e DESFire consegnati come NFCMiFareTag, Apple fornisce sendMiFareISO7816Command per lo stesso scopo.

Leggere o scrivere NDEF su un tag di tipo 4 non chiede alcuna APDU costruita a mano: la classe Ndef di Android e le chiamate NDEF di Core NFC lo fanno. Il codice costruisce APDU per quello che il NDEF non copre, come un file diverso dal file NDEF, una condizione di accesso, o un'applicazione propria. La pagina del file NDEF di tipo 4 segue la sequenza che le piattaforme eseguono.

La selezione viene per prima

Una scheda ISO/IEC 7816-4 porta applicazioni e file, e un comando agisce su quello che è selezionato al momento. SELECT, istruzione 0xA4, sceglie per nome quando P1 è 0x04, dove il nome è un identificatore di applicazione, e per identificatore di file quando P1 è 0x00. Sono i valori che la pila NFC libera di Android usa per raggiungere il NDEF su un tag di tipo 4.

iOS restringe il primo genere. Una SELECT con P1 a 0x04 deve nominare un'applicazione elencata nell'Info.plist dell'applicazione, altrimenti la chiamata fallisce con readerErrorSecurityViolation, secondo il riferimento di sendCommand. La sessione seleziona anche una delle applicazioni elencate quando rileva il tag, e segnala quale in initialSelectedAID; la pagina delle dichiarazioni copre l'elenco.

Una selezione non dura più dell'alimentazione del tag. Un tag che lascia il campo perde tutt'e due, quindi il codice che si riconnette seleziona di nuovo l'applicazione prima del comando successivo.

Leggere i byte di stato

90 00 vuol dire che il comando è andato a termine. Gli altri valori vengono dalla ISO/IEC 7816-4 o dall'applicazione della scheda, e la pila di Android nomina quelli che un lettore di tag di tipo 4 incontra più spesso:

Ciascuna piattaforma li nasconde a modo suo. Su Android sono gli ultimi due byte dell'array che transceive() rende, e il codice che tratta tutto l'array come dati li scambia per contenuto. Su iOS l'errore copre la sola comunicazione, e un'applicazione che guarda l'errore e non sw1 e sw2 prende un rifiuto per un successo.