Wsrtjtyk

I want to send a long response (1000+ bytes) from the card to the host. The reader only has T=0. I have a few questions wondering if anyone knows:

1. My understanding is ExtendedLength only works on T=1, is this true?


2. If so, is there best practice on sending long response on T=0?


3. One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard

All the best!

Johnny

My understanding is ExtendedLength only works on T=1, is this true?

That is not true. No such limitation is specified in ISO/IEC 7816-4 anyway. However, the card should indicate support for extended length in the ATR / the EF.ATR. Readers may not just assume that extended length is present (but you could ignore this if you're the only one handling the application anyway).

If so, is there best practice on sending long response on T=0?

There are many issues with extended length, not all readers support it, Global Platform doesn't support it (the latest version might, I haven't checked) and Java Card only supports up to 32Ki - 1 bytes. Android only has enabled extended length support by default in the latest versions, but you'd better expect NFC enabled phones not to handle it correctly. ISO/IEC 7816-4 made a mess out of the extended length specification, especially in the later versions (2015 onwards).

Unfortunately you are often constrained to using command chaining or simply by executing multiple READ BINARY commands. The latter is definitely the least error prone - but it is slow and end-of-file handling can be tricky.

One potential solution is to send out data by chunks, with status code 61xx. Basically, I would call APDU.sendBytesLong, then throw an exception with 61xx to indicate there's more data. But it seems weird to throw an exception to indicate there's more data, even this seem to conform to the standard.

This is the command chaining solution, correct.

Yes, it is rather idiotic that you cannot indicate warnings without throwing an exception. Well found. But you can just send data and generate the status word by throwing the exception. Probably best to save the status word and generate the exception at the end of your process method.

1 - extended length works in T=0 as explained by @Maarten in his answer.

2 - I am not aware of any best practice. But you can try to implement as described in my next answer.

3 - I partially agree with this, you can use response chaining to get all the response data. Good news is, depending on circumstances, you don't need to implement different protocol handling on applet level. My suggestion is just to do the same processing as you did in T=1, which I imagine is that you just call APDU.sendBytesLong. Then let the platform do the rest like magic.

In javacard platforms that I have worked before, doing so will lead to the following behavior:

Suppose you want to send a get Data command to retrieve 1000 bytes of data:

• Send Get Data which will return 256 bytes of data followed by 61xx


• Send Get Response APDU (00 C0 00 00 plus desired Le) as much as needed until the returned status word is 9000 which means that all data are returned.

Take note that the 61xx and processing of Get Response command are handled on platform level and you don't need to do anything in the applet.

You can give it a try and let me know if it works.