不同 SC 系列的智能卡探测：清除 SC 状态的命令

Posted 2023-02-22

【中文标题】不同 SC 系列的智能卡探测：清除 SC 状态的命令

【英文标题】：smartcard probing with different SC families : command to clean the SC state

【发布时间】：2017-05-29 22:33:05

【问题描述】：

我希望从一堆来自不同供应商、不同用途、不同 APDU 的智能卡中读取一些基本信息。 例如：国家识别智能卡、EMV（支付）、手机 SIM、javacard 等...

我编写了一个 Java 应用程序。 让我将 SC 系列称为 A B C D E 并使用相同名称的 5 个子程序，每个子程序都有正确的 APDU 来读取特定 SC 系列的基本信息。

不幸的是，我发出例程的顺序会影响成功的结果。

示例：使用子程序命令 A B C D E，我可以读取 A B C D 类型的 SC，而不是 E。

如果我将执行顺序更改为 E A B C D，我可以读取 E，但现在我因 SC 类型 C 失败。

我了解：一些 SC 丢弃了外部 APDU ...其他 SC“挂起”。

是否有清除智能卡（和读卡器）状态的基本命令？

所以子程序的执行顺序不会改变输出？

A 重置 B 重置 C 重置 D 重置等...

是 ATR 吗？每种 SC 都必须强制执行吗？

【问题讨论】：

这不应该发生。你用的是什么读卡器？您是否在使用不同的读卡器时观察到相同的行为？

是的，两个不同的读卡器。忽略具体测试：重置读卡器和卡状态的通用方法是什么？

【参考方案1】：

您可以使用Card.disconnect()方法重置卡（注意this）。

但是（恕我直言）最好的方法是使用卡片 ATR（由 Card.getATR() 给出）来猜测正确的卡片系列（如果可能的话）。这种方式也快得多。我将这种方法用于处理几种不同的非接触式卡产品的演示，效果非常好。

---

一些额外的（随机的）注释：

研究所有家庭的文档——这种行为肯定是有原因的。尝试跳过一些子程序和/或它们的 APDU 命令来固定它。

此外，某些 APDU 在意外发送时可能会导致问题（例如锁定的密码或锁定的身份验证尝试）。你应该知道自己在做什么。

大多数产品系列都可以通过某种方式进行可靠检测——如果有，请参阅文档。

如果任何先前调用的子例程使用SELECT 更改选定的应用程序/文件并成功，它会保持选定状态。考虑在每个子例程的开头使用显式 SELECT（例如，选择预期的 AID 或主文件）。

DESFire 卡在接收到非本机命令 APDU 时离开本机模式并进入包装模式（这可能不是您的情况，因为您通常在使用 javax.smartcardio 时使用 ISO 包装命令）。

祝你好运！

【参考方案2】：

你描述的行为听起来很奇怪，因为智能卡读卡器不应该在不同的智能卡之间保持状态。

但是，我不知道任何重启智能卡读卡器的通用命令。例如HID OMNIKEY 阅读器，您可以使用专有的 APDU FF 70 07 6B 08 A2 06 A1 04 A9 02 83 00 00 重新启动（请参阅here [7.6.3]，虽然本指南说它适用于 OMNIKEY 5022 阅读器，但它适用于更多 OMNIKEY 阅读器）。因此，对于您的读者，您必须在互联网上搜索类似的专有 APDU。

请记住，读取器重新启动也很可能会导致 USB 读取器重新枚举。