Hi, APDU cases are deeply linked to T=0. In T=1, you don't need anything like this, because the block length is sent in the block header, before the block data, so the peers know the data length.
So I think the exchange transparency should be done at a higher level. In case 2, just send the 5-bytes apdu you get, do not change Le (P3) In this case, P3=Le=00 accounts for 256 bytes to be responded. Then, switch to receive mode. If the length is correct and accepted by the card, the card will answer INS then the proper number of data bytes and SW. you do not need a timeout. if the procedure byte is INS, the length you requested is valid and you will get that many bytes - plus final SW. If the length is not correct, the card will ALWAYS reply an error or warning, be it 61XX, 6CXX, or anything else. you also know that you just have 2 bytes to read, and the correct length. just go ahead with get response or command re-emission, now you know the correct length that will be accepted by the card. Normal cards indicate the correct length, so you can receive the exact number of bytes. If the card is dumb and replies a foolish 61XX length, this is not your driver's fault :-) This will timeout and the card is bad. Other cases are undefined and do not need to be taken into account, because this is a card problem (like the french navigo cards who replies 9000 instead of 61XX - pardon them, they are old cards). There are some differences among cards when you send a GET RESPONSE with a length that is shorter that what the card did -some cards complains with an error -some cards insists with a 61XX/6CXX and the correct length -some cards send what you requested, and terminates with a 61YY where YY is the remaining length. This can be used to read a very long apdu in blocks - but not all cards supports this. Final word, your driver should not care about emitting the get responses. This is the responsibility of the application. The only available software I know that does that is javax.smartcardio, but this is not a driver. It's an application. Winscard and PCSC do not automatically send the GET RESPONSE commands. Regards Sebastien On Wed, Jul 7, 2010 at 11:32 AM, Drasko DRASKOVIC < [email protected]> wrote: > Hi all, > I am currently implementing one SC driver and I have run into a > problem with T=0 Case 2 command response length. > > Standard says that this response can be : > 1) 6C Luicc (i.e. 2 bytes); or > 2) INS [Data(Luicc)] 90 00 (i.e. Luicc + 3 bytes) > > There are other variations with "61" and "6C" PBs, but in any case it > turns out that for the same command [CLA INS P1 P2 P3=00], > response can vary in length and is not known in advance. > > I can not read byte by byte and analyse it because : > 1) It should be done in a transport layer, so I have to exit my driver > RX function > 2) When I do this, there is a danger of RX FIFO overflow while I am in > transport layer processing, > because now driver is not popping bytes from RX FIFO (which is only 8 > bytes). And if a card is sending long answer and > I exited my driver code to analyse first byte, havoc might happen. > > As a result, before calling my drivers RX function I have to know in > advance how much bytes I have to receive, > and stay in my driver's RX function until I received this number of > bytes, while popping RX FIFO to some location in memory. > > What is the best way to implement Case 2 response END detection : > 1) To demand always 256 (maximum) length from UICC and have timeout > which will say : no more characters arriving, so it must be the end of > message. > 2) To insert some kind of T=0 dependence in the driver itself > (datalink layer) which will take a look at every byte arriving (which > I did not want to do. I wanted to keep byte sending/receiving > transparent for the driver, and do analysis in the transport layer. I > do not want to pollute my driver with T=0 dependencies). > 3) Something other that I am missing right now ? > > > BTW. > Luicc is defined like : > > Luicc: exact length of data available in the UICC to be returned in > response to the case 2 or 4 Command received by > the UICC > > Is it always not known by the terminal before issuing first Case 2 > command, or there is a way to know this value in advance (I guess no, > and I guess it changes dynamically depending on the command and the > card state.) > > BR, > Drasko > _______________________________________________ > Muscle mailing list > [email protected] > http://lists.drizzle.com/mailman/listinfo/muscle >
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
