Quale comando APDU ottiene l'ID della carta

Question

Quale comando APDU ottiene 7 byte di ID della scheda? Uso il pritocol T = CL (ISO7816) con livello ISO14443. Sulla scheda di rilevamento posso vedere solo 4 byte di ID della carta. Ho cercato, questo è il comando APDU per ottenere l'ID della carta. Per esempio la sua:
0xFF, 0xCA, 0x00, 0x00, 0x00
ma frutto di thouse comando è: 6E 00, che sulle specifiche di risposta APDU dicono che "classe non supportato"

Poi trovo, che il suo comando APDU può essere come:
0x00, 0xCA, 0x00, 0x00, 0x00
questo comando ritorno 6A 88
dove 6A XX - "parametro errato (s) P1-P2" e 88 - "Dati di riferimento non trovati"

Cosa ne pensi?

Grazie!

p.s. Tutto comando come: CLA, INS, P1, P2, LenData, Data
Altro mio lavoro di comando normalmente (come aplet sellect e lavorare con esso), problema solo ad ottenere carta d'identità

Answer 1

0xca è il comando GET DATA. È necessario fornire un tag TLV in P1-P2.

ISO 7816 parte 6 "Elementi di dati interindustry per lo scambio" ha un elenco di questi tag, ma nessuno di essi corrisponde inequivocabilmente a "ID scheda". Ti suggerisco di provare tutti i valori di P2, con P1 uguale a 0x00, 0x5F o 0x7F, per scoprire quali elementi di dati sono supportati dalla tua scheda.

Answer 2

La risposta data prima è errata. Questo perché non stiamo parlando di un comando ISO 7816 qui ma di un comando interno dell'API PC/SC.

L'APDU "0xFF 0xCA 0x00 0x00 0x00" è infatti corretto e ho schede per le quali ottengo una risposta a 7 byte. Si noti che questo funziona solo con le schede contactless (RFID) poiché questo UID è parte del protocollo radio. Si noti inoltre che alcuni chip restituiranno un nuovo UID casuale dopo ogni accensione. Questo è ad esempio vero per il mio chip del passaporto e anche la mia carta d'identità nazionale tedesca e una contromisura per impedire il tracciamento dei titolari di carte. In teoria tali UID casuali inizieranno con 0x08 ma questo non è sempre il caso.

Poiché l'UID è un valore "interno" del protocollo, l'APDU in questione NON viene inviato alla scheda ma è solo un comando interno (dell'interfaccia PC/SC) per ottenere l'UID dal driver del lettore di schede . CLA 0xFF generalmente non è in uso normale poiché è utilizzato solo per la "Protocol Parameter Selection" (PPS) riservata. PC/SC abusa di questo CLA per i comandi interni.

Il comando qui è il comando interno "Ottieni dati" PC/SC, specificato nella Parte 3, Sezione 3.2.2.1.3 della specifica PC/SC. Qui P1 e P2 hanno significati predefiniti speciali, quindi non ha senso provare diversi valori. Lo standard definiva P1 = 0, P2 = 0 per ottenere l'UID e P1 = 1, P2 = 0 per "tutti i byte storici dell'ATS di una scheda ISO 14443 A senza CRC". Altri valori non sono supportati.

È interessante notare che la risposta 0x6A 0x88 non è definita nello standard. 0x6a 0x81 significherebbe "Funzione non supportata" quale sarebbe il caso che le carte che non hanno un UID (standard menziona 7816-10 scheda di contatto).Le altre due risposte definite (0x62 0x82 e 0x6C 0xXX) definiscono una mancata corrispondenza tra la lunghezza della risposta richiesta e la quantità effettiva di dati e non si verificheranno qui, perché richiediamo semplicemente dati di lunghezza specificando 0 nell'ultimo byte della richiesta .

Quindi, perché non funziona per il mittente non lo so. Per me funziona, alcune schede restituiscono 4 byte, altri restituiscono 7 byte.

Vedi lo standard PC/SC, parte 3 in particolare, qui: http://www.pcscworkgroup.com/specifications/specdownload.php

Answer 3

Credo che il tuo secondo comando è corretto, ma la scheda non è stata programmata con un ID applicazione.

Per 6A88 il manuale BasicCard dice: "Il comando incorporato OTTAVA ID APPLICAZIONE restituisce questo codice di errore se non è stato configurato alcun ID applicazione nella BasicCard".