这个验证 APDU 命令有什么问题？答案

【问题标题】：What's wrong with this Verify APDU command?这个验证 APDU 命令有什么问题？
【发布时间】：2017-03-27 11:15:47
【问题描述】：

我有以下验证 (PIN) APDU 命令，我们将其发送到金雅拓 SafeNet 阅读器 K1100：

00 20 00 81 08 26 12 34 56 ff ff ff ff

我总是收到回复67 00（长度错误）。据我所知，这意味着 LC 或 LE 都不正确。

【问题讨论】：

【解决方案1】：

假设 APDU 看起来是正确的：

您可以尝试使用 01 而不是 81，以确保在 MF 中搜索 PIN，或者假设卡隐式知道 PIN id，则使用 00。如果两次尝试均失败，您必须收集有关卡初始化/个性化的更多信息。

由于Verify命令没有结果，LE不可能出错。但请注意，使用 Java 类构建 APDU 时，会自动添加 LC，不能指定。

我唯一的另一个想法是，省略相应地调整 LC 的 FF 字节。

【讨论】：

该卡在另一个读卡器中工作，命令完全相同。我一直认为读卡器只是将这些命令转发给智能卡。有什么想法吗？
@ChristophWimberger：原则上是的，但是对于哑卡（例如存储卡）或非常智能的读卡器（例如用读卡器的 PIN 键盘上输入的内容替换 PIN 数据），读卡器的修改是必要。对于某些 CLA/INS 组合，它们的阅读器可能会认为自己是寻址单元，因此根本不会将其传递给卡。

【解决方案2】：

您在使用 Athena 吗？

如果是这种情况，请尝试 p2= A0

【讨论】：

请解释为什么（仅）在这种情况下会有所帮助。
这是特定于供应商的，如果您从 P2 从 00 映射到 FF，您将看到 SW1 和 SW2 仅在 P2= 时才具有有效值 //A0 有 7 次尝试 //82 有 3 次尝试 // 81 有 0 次尝试，这对我有用 [0x00, 0x20, 0, 0xa0, 4, 0x31, 0x30, 0x36, 0x31] 引脚是 1061
请edit 通过添加该解释来改进您的答案。考虑咨询How to Answer。