从寻求换安卓访问时，Java卡小应用程序RPDU不包含任何数据 [英] Javacard applet RPDU does not contain any data when accessed from seek-for-android

问题描述

我有一个复杂的Java卡小应用程序，它的开发和测试用于普通智能卡（例如NXP J3E145，T = 1）。现在我使用它在UICC的手机和我的Andr​​oid应用程序访问它。该UICC采用T = 0协议。

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.

当我从一个普通的读卡器（支持Omnikey 5321）进行通信SIM卡，小应用程序工作正常。

When I communicate to the SIM card from an ordinary card reader (Omnikey 5321), the applet works fine.

不过，当我移动到我的手机（索尼Xperia S）和APDU发送通过寻求换的Andr​​oid API，一些RPDUs不包含任何数据的一部分，只有状态字0×9000和数据部分失踪了！

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!

这些APDU的是失败的：

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)

这些APDU的是确定：

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)

这可能是一个超时问题（处理时间总是与LT; 1秒）？或者一些T = 0的怪事？

Could it be a timeout issue (processing time is always < 1s)? Or some T=0 weirdness?

我的Andr​​oid应用程序，code是非常简单的：

My Android app code is really simple:

Channel channel = session.openLogicalChannel(aid);
byte[] resp = channel.transmit(new byte[] {(byte) 0x80, 0x04, 0x00, 0x00, 0x00});

开放移动API，4.4.2（19）。

Open Mobile API, 4.4.2 (19).

任何帮助将是不错的，我花了两天时间解决这个问题。 请救救我吧。

Any help would be nice, I spent two days solving this problem. Please, save me.

Vojta开发

修改 我的访问规则：

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

在上面的列表中我只过滤规则APDU（和NFC规则没有写下来的话）。

In the list above I filtered APDU rules only (and NFC rules did not write down at all).

我的小程序AID F06D617073616D2E617070 我的发卡行安全域是A0000000871002FF33FFFF8901010100。

My applet has AID F06D617073616D2E617070 My Issuer Security Domain is A0000000871002FF33FFFF8901010100.

我不认为这些规则会影响我的APDU，还有用头和口罩没有真正的过滤器...

I do not think these rules can affect my APDUs, there are no real filters with header and mask...

编辑2

我在我的小程序，这实际上造成了整个问题找到了一个错误。我的小程序回应，状态字0x911C并没有数据。现在的问题是在SEEK回应，状态字0×9000，而不是0x911C为什么channel.transmit方法。当我解决了我的小程序中的问题，所有RPDUs是正确的。

I found an error in my applet, which really caused the whole issue. My applet responded with status word 0x911C and no data. The question is why channel.transmit method in SEEK responded with status word 0x9000 instead of 0x911C. When I solved the problem in my applet, all RPDUs are correct.

所以，唯一悬而未决的问题是：为什么我得到0×9000使用SEEK而不是0x911C我的小程序作出了回应

So the only open question is: Why did I get 0x9000 using SEEK and not 0x911C as my applet had responded?

修改3 - 解决方案：

我解决这个问题的休息。经由SEEK访问时状态字0x91XX不能使用。下一段是EduardEtc来自SEEK的论坛，它说明了一切：

I solved the rest of this issue. Status words 0x91XX cannot be used when accessing via SEEK. Next paragraph is by EduardEtc from the SEEK forum and it explains everything:

ETSI定义（在TS 102 221）状态字91XX与SIMToolKit（CAT）应用。任何卡的应用程序，否则将发送9000作为SW1SW2可以返回91XX，而不是它的手机必须跨preT处理CAT APDU的，所以手机的应用程序将永远不会看到的91XX，它被替换手机的CAT处理一层9000。 ISO / IEC 7816-4定义SW1SW2 = 61XX类似用途。在当时，这包括在标准中，以满足需要从ETSI，但是，ETSI没有等待ISO流程来​​完成，并指定了不同的编码。

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

推荐答案

我在我的小程序，这实际上造成了整个问题找到了一个错误。我的小程序回应，状态字0x911C并没有数据。然而，SEEK总是返回0×9000，代替0x911C，因为经由SEEK访问时状态字0x91XX不能使用。下一段是EduardEtc来自SEEK的论坛，它说明了一切：

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定义（在TS 102 221）状态字91XX与SIMToolKit（CAT）应用。任何卡的应用程序，否则将发送9000作为SW1SW2可以返回91XX，而不是它的手机必须跨preT处理CAT APDU的，所以手机的应用程序将永远不会看到的91XX，它被替换手机的CAT处理层由9000 ISO / IEC 7816-4定义SW1SW2 = 61XX类似用途。在当时，这包括标准，以满足在需要从ETSI，但是，ETSI没有等待ISO流程来​​完成，并指定了不同的编码。

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

这篇关于从寻求换安卓访问时，Java卡小应用程序RPDU不包含任何数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！