android - 从 seek-for-android 访问时，Javacard 小程序 RPDU 不包含任何数据

Question

我有一个复杂的 Javacard 小程序，它是为普通智能卡(例如 NXP J3E145，T=1)开发和测试的。现在我必须在手机的 UICC 中使用它并从我的 Android 应用程序访问它。 UICC使用T=0协议(protocol)。

当我从普通读卡器 (Omnikey 5321) 与 SIM 卡通信时，小程序工作正常。

然而，当我将它移入我的手机(Sony Xperia S)并通过 seek-for-android API 发送 APDU 时，一些 RPDU 不包含任何数据部分，只有状态字 0x9000，数据部分是不见了!

这些 APDU 失败了:

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 没问题:

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)

会不会是超时问题(处理时间总是<1s)？还是一些 T=0 的怪事？

我的 Android 应用程序代码非常简单:

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

打开移动 API，4.4.2 (19)。

任何帮助都会很好，我花了两天时间解决了这个问题。请救救我。

沃伊塔

编辑我的访问规则:

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规则根本没写下来)

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

我认为这些规则不会影响我的 APDU，没有带标题和掩码的真正过滤器...

Answer 1

我在我的小程序中发现了一个错误，这确实导致了整个问题。我的小程序以状态字 0x911C 响应并且没有数据。但是，SEEK 始终返回 0x9000 而不是 0x911C，因为在通过 SEEK 访问时不能使用状态字 0x91XX。下一段来自 SEEK 论坛的 EduardEtc，它解释了一切:

“ETSI 定义(在 TS 102 221 中)用于 SIMToolKit (CAT) 应用程序的状态字 91XX。任何将 9000 作为 SW1SW2 发送的卡应用程序都可以返回 91xx 而不是手机必须解释以处理 CAT APDU。因此电话应用程序永远不会看到 91xx，它被电话的 CAT 处理层替换为 9000。ISO/IEC 7816-4 出于类似目的定义 SW1SW2=61xx。当时这包含在标准中以满足 ETSI 的需求，然而，ETSI 没有等待 ISO 进程完成并指定了不同的编码。”