问题
I have a complex Javacard applet, which is developed and tested for ordinary Smart Card (e. g. NXP J3E145, T=1). Now I have to use it in UICC in a mobile phone and access it from my Android app. The UICC uses T=0 protocol.
When I communicate to the SIM card from an ordinary card reader (Omnikey 5321), the applet works fine.
However, when I move it into my mobile phone (Sony Xperia S) and send APDUs via seek-for-android API, some RPDUs do not contain any data part, there is only the status word 0x9000 and the data part is missing!
These APDUs are failing:
80 04 00 00 00 --> 90 00 (although there should be some data, 200 bytes approx.)
80 01 00 00 00 --> 90 00 (although I expect 18 bytes)
These APDUs are OK:
80 05 00 00 00 --> 00 90 00 (one byte as I expected)
80 06 00 00 00 --> <... data of length 20 ...> 90 00 (as I expected)
Could it be a timeout issue (processing time is always < 1s)? Or some T=0 weirdness?
My Android app code is really simple:
Channel channel = session.openLogicalChannel(aid);
byte[] resp = channel.transmit(new byte[] {(byte) 0x80, 0x04, 0x00, 0x00, 0x00});
Open Mobile API, 4.4.2 (19).
Any help would be nice, I spent two days solving this problem. Please, save me.
Vojta
EDIT My Access Rules:
AID: A000000018308005006563686F00 ___ AllApps:Never
AID: A0000000183080055A6563686F5A ___ Hash:ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always
AID: A000000018308005596563686F59 ___ Hash: ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always
AID: A000000018308005586563686F58 ___ AllApps:Always
AID: NO_AID ___ AllApps:Always
AID: A000000018308005006563686F00 ___ AllApps:Never
AID: A0000000183080055A6563686F5A ___ Hash: ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always
AID: A000000018308005596563686F59 ___ Hash: ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always
AID: A000000018308005586563686F58 ___ AllApps:Always
AID: NO_AID ___ AllApps:Always
In the list above I filtered APDU rules only (and NFC rules did not write down at all).
My applet has AID F06D617073616D2E617070 My Issuer Security Domain is A0000000871002FF33FFFF8901010100.
I do not think these rules can affect my APDUs, there are no real filters with header and mask...
回答1:
I found an error in my applet, which really caused the whole issue. My applet responded with status word 0x911C and no data. However, SEEK returned always 0x9000 instead of 0x911C, because status words 0x91XX cannot be used when accessing via SEEK. Next paragraph is by EduardEtc from the SEEK forum and it explains everything:
"ETSI defines (in TS 102 221) status word 91XX for use with SIMToolKit (CAT) applications . Any card application that would otherwise send 9000 as SW1SW2 can return 91xx instead which the phone must interpret to handle CAT APDUs. So the phone application will never see the 91xx, it is replaced by the phone’s CAT handling layer by 9000. ISO/IEC 7816-4 defines SW1SW2=61xx for a similar purpose. At the time this included in the standard to meet a need from ETSI, however, ETSI didn’t wait for the ISO process to finish and specified a different encoding."
回答2:
The main problem is with the Open Logical channel i suppose. may be the card is not supporting logical channel. Try Open Basic channel.
and u are not getting any response data because, the Le part is not set. CLA, INS, P1, P2, (Le), Data ..If you are setting your Le field to 00 you should get full back response as the total number of bytes available. Again if you send the number of bytes you need suppose XX then pass it and you should be able to get that response, if its more than 256 then it will be 61 XX, XX indicating the number of bytes of response.
来源：https://stackoverflow.com/questions/25982327/javacard-applet-rpdu-does-not-contain-any-data-when-accessed-from-seek-for-andro