2015-10-07 17 views
5

Qual è la dimensione del campo dati consigliata in un APDU della scheda Java? Da Java Card Technology for Smart Cards: Architecture and Programmer's Guide libro di Zhiqun Chen, si informa che Le campo consente un massimo di 255.Scheda Java sicura Max. Comando dati APDU e dimensioni di risposta

dobbiamo interpretare come seguire per il comando APDU:

|<----------------------- 255 Bytes total ------------------------>| 
|<- CLA -><- INS -><- P1 -><- P2 -><- Lc -><---- DATA ----><- Le ->| 

Così, se CLA, INS, P1, P2 , Lc, Le sono tutti 1 byte ciascuno, dovremmo assumere che possiamo tranquillamente impostare solo 249 byte nella regione DATA?

Per la risposta APDU dobbiamo interpretare:

|<----------------------- 258 Bytes total ------------------------>| 
|<-------------------------- DATA ------------------------><- SW ->| 

I dati di risposta possono tranquillamente essere impostati a 256 byte di 2 byte di SO e totale di una risposta consistente di risposta dati e SW è 258 byte?

Quali altre considerazioni per inviare e ricevere in modo sicuro i dati in blocchi considerando che dobbiamo affrontare situazioni in cui il concatenamento potrebbe non essere possibile e noi stessi dobbiamo gestire manualmente il flusso di dati?

risposta

1

Lc e Le byte possono segnalare di sospendere/richiedere fino a byte 0xFF. Quindi per un APDU del comando Caso 4 hai 6 (intestazione + lc + le) + 0xFF = 261 byte. Per una risposta maxium hai 256 byte + 2 (Statusword) = 258 byte. Questo è ciò che lo standard suggerirebbe. Tuttavia, i token hardware diffrent potrebbero avere implementazioni diverse, quindi questo potrebbe non essere accurato al 100%. Se hai bisogno di più dati devi implementare ExtendedLength.

+0

Ci sono comunque per misurare con precisione la dimensione dell'APDU dall'API della Java Card oltre a chiedere al fornitore della scheda? – thotheolh

+0

Metti alla prova la tua carta. Qual è il tuo obiettivo specifico? –

+0

Voglio creare un protocollo generico tra host e scheda che può essere utilizzato su tante piattaforme di carte e utilizzabile su schede che non supportano il concatenamento. – thotheolh

6

AFAIK campo Le permette 1-256 byte (il limite 255 è per Lc) citando ISO 7816-3:

cassa 2S ⎯ La breve Le campo è costituito da C (5) codificante Ne da 1 a 256 ('00' significa il massimo, 256) ....
....
Caso 4S ⎯ ... Il campo corto Le è costituito da C (6 + Nc) codifica Ne da 1 a 256 ('00' significa il massimo , 256) ....

(ed è in linea con la vostra lunghezza di "risposta APDU" di 256 + 2, forse è solo un errore di battitura)

Il limite di 255 byte è per la parte di dati di "comando APDU". Quindi per l'intera lunghezza non estesa "Comando APDU" il limite dovrebbe essere 5+255+1.

Tutti questi limiti sono definiti con precisione in ISO 7816-3 - dai un'occhiata qui.


Attenzione, che APDU buffer della JavaCard potrebbe essere più piccoli. Dal javadoc della classe APDU:

L'(tampone APDU significato) lunghezza del buffer deve essere almeno 133 byte (5 byte di intestazione e 128 byte di dati)

Così per leggere entrante dati più lunghi di 128 byte potrebbe essere necessario chiamare APDU.receiveBytes() per recuperare il resto dei byte che non si adattano.

Lo stesso potrebbe domanda per l'invio dei dati (cioè APDU.sendBytes()potrebbe essere necessari per inviare i dati più a lungo).


Per livello di applicazione inquadratura, io sono a conoscenza di questi metodi (potrebbe essere fonte di ispirazione):

  • ISO 7816-4 (usando bit 5 in CLA)

  • piattaforma globale (utilizzando il bit più significativo di P1 per indicare più blocchi/ultimo blocco per alcuni comandi)

  • EMV CPS (comando MEMORIZZA DATI utilizzando expl lunghezze interne all'interno dei dati)

+0

hai assolutamente ragione su Le è 1-256 byte. Bella risposta! –