Javacard applet RPDU does not contain any data when accessed from seek-for-android

Question

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...

When I change Le byte from 0 to 0xFF, I get 0x6881. This is really confusing - I thought SEEK manages all the logical channels stuff. How could different Le byte change status word from 0x9000 to 0x6881? Any clue? Please, help... — vojta, Sep 23 '14 at 08:15
I think it might be a seek-for-android error while handling 61XX or 6CXX response. Is there any way to trace APDUs (TPDUs) that were really sent to UICC? — vojta, Sep 23 '14 at 08:38
I tried all possible options of Le, Lc etc., the result is always the same :-( : 1. `LC = 1 Data = {0x00} Le = null --> 90 00` 2. `LC = 1 Data = {0x00} Le = 0 --> 90 00` 3. `LC = 1 Data = {0x00} Le = 255 --> 90 00` 4. `LC = null Data = null Le = null --> 90 00` 5. `LC = null Data = null Le = 0 --> 90 00` 6. `LC = null Data = null Le = 255 --> 68 81` — vojta, Sep 23 '14 at 13:04
Please do not use the comments for additional information. In such a case edit your question and add the additional information there. — Robert, Sep 23 '14 at 14:34
To send apdu to uicc via android you need ARA applet which defines rules to send apdu to uicc.did you installed this applet or you have ARF? — Anurag Sharma, Sep 23 '14 at 14:46
Hi, thanks, this is a good idea. There is an applet with aid A000000x015141434C00, I will try to select it and get rules affecting my applet... I will write the output tomorrow, thanks! — vojta, Sep 23 '14 at 17:46
In your ARA rules i cant see any rule with Aid F06D617073616D2E617070. Please remove all rules and define only 1 rule with all aid and all apps with apdu always. — Anurag Sharma, Sep 24 '14 at 02:22
Hi, I made some progress! Firstly, it was all my mistake. Sorry. My APDUs for Omnikey and for the phone were not exactly the same... But SEEK responded 9000 instead of the status word I really sent! So: The missing data part is the correct behaviour. But it responses with different SW as it should: my applet responses 0x911C and provides no output data, but I get 0x9000 and no output data via SEEK api. — vojta, Sep 25 '14 at 05:44
@vojta It might be useful to others if you posted the solution as an answer instead of editing it in your question. — Michael Roland, Sep 30 '14 at 06:58
@vojta ,I'm facing a problem with transaction event in android device with payment applet in uicc.I have posted the problem in seek for android group.It will be very helpful if you share some knowledge about it. here is the post link https://groups.google.com/forum/#!topic/seek-for-android/q4_1RSEqME0 — Rabby Alam, Mar 24 '15 at 11:14

score 3 · Accepted Answer · answered Sep 30 '14 at 07:15

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."

Ouch, thanks for reporting that back. I would not have guessed it went that deep. — Maarten Bodewes, Sep 30 '14 at 07:43

Vinod Gangal · Answer 2 · 2015-04-12T18:51:39.037

-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.

edited Apr 12 '15 at 18:51

answered Sep 23 '14 at 08:22

Vinod Gangal

23
1
6

When I change my Le byte to anything > 0, I get 0x6881 - SW_LOGICAL_CHANNEL_NOT_SUPPORTED. – vojta Sep 23 '14 at 08:30
2

voted Down:As Le 00 doesn't mean no data is expected. – Anurag Sharma Sep 23 '14 at 15:14
@AnuragSharma We cannot downvote comments, but it doesn't mean "all bytes available" either. It means that the maximum response size is 256 bytes. – Maarten Bodewes Sep 24 '14 at 15:22
@owlstead i haven't down voted the comment it was my explanation why i voted down the answer.i dont want to just vote down and left,i explained that yes i have voted down the answer with reason. – Anurag Sharma Sep 24 '14 at 16:55
1

@AnuragSharma I wasn't criticizing you, I just wanted to mention to you as well that the initial comment of vojta is incorrect too. – Maarten Bodewes Sep 24 '14 at 18:43
@owlstead Thanks... sometimes i feel stackoverflow is only for criticizing pepole ;) and sorry for my reply :) – Anurag Sharma Sep 25 '14 at 04:30

Javacard applet RPDU does not contain any data when accessed from seek-for-android

2 Answers2

Linked