Jakob Bohm a écrit :
From what I have read in recent days, could the difference be in
the low level protocol between card and reader?, specifically, I
suspecte that some variants (maybe those based on T=0, maybe
others) might not make the Lc field (and its size: 1 vs. 3)
available in the APDU buffer until after setIncomingAndReceive()
waits for that field to arrive from the reader.
I didn't double-check but extended length are may be not supported
at all in T=0 protocol, OOH T=0 protocol was fine for "old" chips
(says 5+ years) that have very limited resources, most of nowadays
chips have an efficiency UART (I/O controler) and much more RAM.
I so anticipate that most of modern chips are used under T=1
protocol.
your question is actually independant of the used protocol (even
if the block transfer on T=1 protocol makes low level transport
quite different), practically one can consider that the terminal
sends only the 5 first bytes of the APDU, it is up to the card
(so the applet) to know if it wants to receive more data or not,
basically it's an applet concern to use setIncomingAndReceive or
not, and the applet (usinh high level API) would NOT care about
low level transport constraint, so if it considers that data shall
be transmitted, it can invoke setIncomingAndReceive or (it should
be able to call) getIncomingLength.
for both functions, it require the JCRE (and other low level stuff)
to request more data from the terminal, if getIncomingLength is
called first, the JCRE can extract that length from the fifth byte
or from bytes 5-8 and keep the remaining bytes (the actual data)
for later request (ie setIncomingAndReceive call); doing that
the JCRE can not assumed that by applet won't use the APDU buffer
for its own purpose and thus may discard data if the JCRE does
store tham into that buffer - of course this risk doesn't exist
if setIncomingAndReceive must be called first; I think RAM
constraint is the main reason to disallow getIncomingLength
(which is so not a protocol constraint).
There is also the issue that the APDU format begins identically
for an APDU with Lc!=0 and for an APDU with Lc=0 Le!=0.
for a short APDU, with a "P3" parameter different than 0, the UART
does not know if it means that the terminal is ready to send P3
bytes or if the terminal is expecting a P3-byte length response;
again only the application will decide to request data (P3 will
so mean Lc) or to send data (and P3 was a Le parameter).
if P3 is '00', the same is true, "Lc" exists only if the applet
request data (and it shall be 00xxxx) or ask for the requested
length of data (also coded 00xxxx).
Some APDU
documents even suggest that the APDU ends before the Lc/Le field
if both are semantically 0 (not to be confused with 256d encoded
as 00 or 65536d encoded as 00 00 00)
not sure to guess which "APDU documents" we're dealing with nor to
understand their goal; in the "pre-extended length" age, one may decide
to directly read the P3 parameter and when '00' is present decide that
no data were transmitted (if they are optional) or that 256 bytes must
be returned, basically there are dangerous assumption, dealing with
JavaCard, one shall NEVER compute a length by reading the byte 4 of
the APDU buffer, as the CardEdge muscle applet does.
Sylvain.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
