2015-10-07 4 views
5

Welche Datenfeldgröße wird in einer Java Card APDU empfohlen? Von Zhiqun Java Card Technology for Smart Cards: Architecture and Programmer's Guide Buch Chen, erwähnt sie, dass Le Feld ein Maximum von 255Safe Max Java-Karte APDU-Daten Befehl und Antwortgröße

sind erlaubt wir es interpretieren, wie sie für die APDU-Befehl folgen:

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

Wenn also CLA, INS, P1, P2 , Lc, Le sind jeweils 1 Byte, wir sollten davon ausgehen, dass wir sicher nur 249 Bytes in die DATA-Region setzen können?

Für die APDU Antwort sind wir zu interpretieren:

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

Die Antwortdaten sicher mit 2 Byte von SW und insgesamt eine Antwort auf 256 Byte festgelegt werden, die aus Daten Ansprech- und SW ist 258 Bytes?

Welche anderen Überlegungen zum gesicherten Senden und Empfangen von Daten in Chunks sind zu beachten, wenn wir uns Situationen stellen müssen, in denen eine Verkettung nicht möglich ist und wir den Datenfluss selbst manuell handhaben müssen?

Antwort

1

Lc und Le Byte kann signalisieren, bis zu 0xFF Bytes zu halten/anfordern. Für eine Case-4-Befehl-APDU haben Sie also 6 (header + lc + le) + 0xFF = 261 bytes. Für eine maximale Antwort haben Sie 256 Bytes + 2 (Statusword) = 258 Bytes. Dies ist, was der Standard vorschlagen würde. Unterschiedliche Hardwaretoken können jedoch unterschiedliche Implementierungen aufweisen, sodass diese möglicherweise nicht zu 100% korrekt sind. Wenn Sie mehr Daten benötigen, müssen Sie ExtendedLength implementieren.

+0

Gibt es neben der Frage des Kartenlieferanten auch eine genaue Abschätzung der Größe der APDU von der Java Card API? – thotheolh

+0

Testen Sie Ihre Karte. Was ist dein spezifisches Ziel? –

+0

Ich möchte ein generisches Protokoll zwischen Host und Karte erstellen, das auf so vielen Kartenplattformen verwendet werden kann und auf Karten verwendet werden kann, die keine Verkettung unterstützen. – thotheolh

6

AFAIK der Le Feld ermöglicht 1-256 Bytes (die Grenze für Lc 255 ist) unter Berufung auf ISO 7816-3:

Kasten 2S ⎯ Die kurze Le Feld besteht aus C (5) Ne kodierend von 1 bis 256 ('00' bedeutet das Maximum, 256) .... ...
Fall 4S ⎯ ... Das kurze Le Feld besteht aus C (6 + Nc), das für Ne von 1 kodiert bis 256 ('00' bedeutet Maximum, 256) ....

(Und es ist im Einklang mit Ihrer „Antwort APDU“ Länge von 256 + 2, vielleicht ist es nur ein Tippfehler)

Die 255-Byte-Grenze für den Datenteil von „Befehl APDU“ ist. Für die gesamte nicht erweiterte Länge "Command APDU" sollte das Limit sein.

All diese Grenzen sind genau definiert in ISO 7816-3 - schauen Sie hier.


Vorsicht, dass der APDU-Puffer des Javacard könnte kleiner sein. Von der javadoc der APDU Klasse:

Die Pufferlänge (dh APDU-Puffer) muss mindestens 133 Bytes (5 Byte Header und 128 Byte Daten) sein

So eingehenden zu lesen Daten, die länger als 128 Bytes sind, müssen Sie möglicherweise APDU.receiveBytes() aufrufen, um den Rest der Bytes abzurufen, die nicht passten.

Das gleiche könnte gelten für das Senden von Daten (d APDU.sendBytes()könnte mehr Daten zu senden ist erforderlich).


Für Anwendungsebene Framing, bin ich diese Methoden bewusst (vielleicht inspirierend sein):

  • ISO 7816-4 (mit Bit 5 in CLA)

  • Globale Plattform (Verwenden des höchstwertigen Bits von P1, um für einige Befehle mehr Blöcke/letzten Block anzuzeigen)

  • EMV CPS (Befehl STORE DATA mit Hilfe von expl icit lengths inside)

+0

Sie haben absolut Recht über Le ist 1-256 Bytes. gute Antwort! –