Come fa un computer a parlare con un lettore NFC USB?

Dove sta il codice

Un programma non parla mai all'apparecchio USB. Parla al gestore delle risorse che il sistema operativo fornisce, che parla al lettore, che parla alla scheda o al tag. Le specifiche PC/SC definiscono quella catena pezzo per pezzo e sono pubblicate liberamente; la parte 3 è quella del lettore in sé, ed è dove un programmatore finisce quando un tag si comporta diversamente da una scheda.

Quello che viaggia fra il programma e la scheda è un'APDU, l'unità che la pagina delle APDU descrive. Un lettore contactless la porta a un tag di tipo 4 o a una scheda senza cambiare nulla; tutto il resto di questa pagina esiste perché gli altri tipi di tag non parlano quella lingua.

Lo stesso scambio, due sistemi

Su Windows le chiamate appartengono a winscard: un contesto, l'elenco dei lettori, poi SCardConnect, che prende una modalità di condivisione, condivisa, esclusiva o diretta, e i protocolli che il programma accetta, T=0 o T=1. SCardTransmit manda il comando con la struttura di controllo del protocollo corrispondente e rende la risposta.

Su macOS e su iOS lo stesso scambio passa da CryptoTokenKit. TKSmartCardSlotManager elenca gli slot e richiede l'abilitazione com.apple.security.smartcard; TKSmartCard apre una sessione, trasmette e la chiude, ed espone send(ins:p1:p2:data:le:), che costruisce l'APDU per te, con cla, useExtendedLength e useCommandChaining lì accanto.

Da iOS 26, lo stesso framework può aprire uno slot sulla radio del telefono: createNFCSlot(message:completion:) crea uno slot per smart card NFC e presenta un'interfaccia di sistema, che mette un tag dietro l'API che avrebbe usato un lettore. Core NFC resta il framework per i tag che non sono schede, come descrive la pagina delle sessioni.

I tag senza applicazione di scheda

Un tag di tipo 2 o di tipo 5 non ha alcuna applicazione da selezionare e nessuna APDU a cui rispondere. La parte 3 della specifica li tratta facendo fare il lavoro al lettore: un lettore conforme deve sostenere Read Binary, Update Binary, Load Keys, General Authenticate, Verify per le schede con un codice di sicurezza, e Get Data. La specifica dice esplicitamente che questi comandi vengono dal settore e non dall'ISO, e che i costruttori di lettori raccolgono i dettagli dai fabbricanti di chip.

Get Data è quello che ogni progetto usa: classe FF, istruzione CA, parametri 00 00, e una lunghezza attesa di 00 per l'identificatore intero. La specifica fissa cosa torna: 4, 7 o 10 byte per un tag ISO 14443 A, i 4 byte del PUPI per una scheda 14443 B, 8 byte per l'ISO 15693, nell'ordine ricevuto durante l'anticollisione, completati con riempimento invece che convertiti, e 6A 81 quando la scheda non ha alcun identificatore.

Quindi un lettore che legge un tag che il tuo codice non legge è di solito un lettore che realizza un comando che il tuo non manda, non una radio migliore.

Cosa dice il lettore che un tag sia

Un tag contactless non ha alcuna risposta al reset, e i programmi scritti per le schede se ne aspettano una. Il lettore ne costruisce quindi una sintetica, i cui campi definisce il supplemento alla parte 3: l'identificatore registrato del PC/SC Workgroup, A0 00 00 03 06, un byte che nomina la norma, ISO 14443 A parte 3, ISO 15693 parte 1, FeliCa e così via, poi due byte che nominano il chip da un registro che il gruppo mantiene su richiesta.

Leggilo prima di mandare qualsiasi cosa. Dice al tuo codice quale famiglia sta tenendo in mano, e un chip sconosciuto compare come nessuna informazione fornita invece che come un guasto, che è la differenza fra un programma che si adatta e uno che segnala un lettore rotto.