问题描述
我有一个复杂的 Javacard 小程序，它是为普通智能卡(例如 NXP J3E145，T=1)开发和测试的.现在我必须在手机的 UICC 中使用它并从我的 Android 应用程序访问它.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.
然而，当我把它移到我的手机(Sony Xperia S)并通过seek-for-android API发送APDU时，一些RPDU不包含任何数据部分，只有状态字0x9000，数据部分是不见了！
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)
会不会是超时问题(处理时间总是小于 1 秒)?或者一些 T=0 的怪癖?
Could it be a timeout issue (processing time is always < 1s)? Or some T=0 weirdness?
我的 Android 应用代码非常简单:
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.
沃伊塔
编辑我的访问规则:
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 F06D617073616D2E617070My 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...
推荐答案
我在我的小程序中发现了一个错误，这确实导致了整个问题.我的小程序响应状态字 0x911C 并且没有数据.但是，SEEK 总是返回 0x9000 而不是 0x911C，因为通过 SEEK 访问时不能使用状态字 0x91XX.下一段来自 SEEK 论坛的 EduardEtc，它解释了一切:
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 而不是电话必须解释以处理 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."
这篇关于从seek-for-android 访问时，Javacard 小程序RPDU 不包含任何数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！