2015-07-04 35 views
9

Esistono diverse smart card che supportano ISO 14443-4. Ad esempio, Mifare Plus con il suo set di comandi nativi. O altre carte con set di comandi diversi (ad es. 7816-4 APDU).Come faccio a distinguere le diverse schede ISO 14443-4?

Sviluppo del software per un lettore di schede e devo identificare i comandi supportati dalla scheda (ad esempio, se supporta i comandi nella struttura ISO 7816-4 oppure no).

Qual è il modo consigliato per distinguerli? Dovrei semplicemente provare alcuni comandi dal set di comandi Mifare Plus e controllare se ottengo risposte corrette? O c'è un modo più intelligente per farlo?

risposta

8

Durante il protocollo di connessione vengono scambiati alcuni parametri che è possibile utilizzare per determinare le capacità della scheda. Ad esempio, il byte SAK informerà il lettore se la scheda è ISO 14443-4, e anche se è MIFARE Plus (c'è un documento NXP che spiega quali bit si devono leggere). Quindi hai ATS (Risposta per selezionare), che contiene molte informazioni utili sulla carta. Dai un'occhiata alla ISO 14443-4 e alla ISO 7816-4.

+1

Sì, lo so, ma ATS può essere modificato nelle carte Mifare Plus, quindi non è affidabile al 100%. E sospetto che possano esistere altre carte (non della famiglia Mifare) che hanno lo stesso SAK. NXP consiglia di valutare solo il bit 6 di SAK per verificare se la scheda supporta ISO 14443-4 e ignorare altri bit. –

+1

Probabilmente il miglior modo di agire sarà implementare un approccio "pragmatico": prima usare SAK e ATS (quindi coprirai la maggior parte delle carte) più alcuni comandi di prova per i casi d'angolo. Il tuo lettore software dovrà supportare tutte le schede generiche Mifare Plus o solo quelle personalizzate per una specifica applicazione o servizio? – mictter

+0

Penso che sarà sufficiente per gestire quelli personalizzati, oltre a nuove schede vuote per la personalizzazione. –

2

Non utilizzare mai ATQ! Usa SAK solo per carte non 14443-4 (ad esempio Mifare Classic)! L'ATS è anche una cattiva pratica in quanto il venditore di schede diverse può impostarlo in modo diverso.

Ora come farlo:

solo modo per pensare a carte e non si ottiene folle è immaginare le cose come stanno stack di comunicazione completo (vedi modello OSI).

Ricorda che il tuo obiettivo è connettere due applicazioni, una nella scheda e una nel computer. 14443-4 fornisce un meccanismo per l'invio di messaggi e non si preoccupa del suo contenuto.

Sopra di esso sono implementate interfacce di diverse carte e se entrambi i lati: card - carddriver sono compatibili, comunicano. In caso contrario, ci saranno errori a quel livello. Quindi sai che dovrai usare un driver di scheda diverso.

completo stack di comunicazione sarà simile a questa:

Your Application 
    | CardProtocol/7816-4 
    | | 14443-4 
    | | | 14443 
    | | | | radio waves 
    | | | 14443 (in card) 
    | | 14443-4 (in card) 
    | CardProtocol/7816-4 (in card) 
    Application/Appdata (in card) 

Naturalmente tra ogni strato deve essere una certa interfaccia.

Se si dispone di due applicazioni che vogliono comunicare, provare una e quindi provare secondo.

errore al livello di applicazione => non v'è alcuna applicazione compatibile sulla carta

errore al livello CardProtocol => non c'è scheda compatibile

Point è la tua comunicazione deve succed a tutti i livelli in modo da non preoccupati di provare a comunicare con la scheda tramite un protocollo non compatibile - se tu (per miracolo) non ottieni errori a livello di CardProtocol ne otterrai sicuramente una a livello di applicazione e il risultato sarà lo stesso. Buona fortuna!

P.S. Ci sono alcune situazioni più complesse come "un'app su due protocolli/tipi di schede" ma possono essere gestite facilmente.