ISO7816 APDU 的最大长度和寻址偏移量？答案

【问题标题】：Max length of ISO7816 APDU and addressing offsets?ISO7816 APDU 的最大长度和寻址偏移量？
【发布时间】：2013-10-01 13:55:20
【问题描述】：

我对符合 ISO7816-4 的第一个行业间 APDU 很感兴趣。这种 APDU 可以/允许的最大长度是多少？

我能想到的最长的 APDU 应该是扩展长度的 ISO case 4 APDU。这意味着我们有 4 个字节的标题，3 个字节用于扩展 Lc，2 个字节用于扩展 Le。此外，Lc 字段允许寻址总共 2^16 个字节。考虑到这种最坏情况的 APDU，一个 2 字节的大短值显然不足以解决最后一个字节的偏移量。

是否有解决此问题的最佳实践或我遗漏了什么？

【问题讨论】：

标签： iso javacard

【解决方案1】：

您的计算是正确的（除了 Nc 的最大大小是 64Ki - 1 以字节为单位，而不是 64Ki。所以最大命令 APDU 将是 4 + 3 + (64Ki - 1) + 2 = 64Ki + 8。请注意，可以返回的数据量是 64Ki，状态字为两个字节，响应 APDU 的最大大小为64Ki + 2。然而，许多智能卡会限制智能卡可以发送和返回的数据量。ISO 7816- 4 2013 规范包含指示智能卡和智能卡应用程序“缓冲区大小”的方法。

在 Java Card 中，限制设置为 32 Ki - 1，原因很简单，较大的值不能存储在带符号的 short 中。需要从 EEPROM 流式传输字节以获得接近该大小的任何位置，APDU 缓冲区将比这小得多。

现在关于“最后一个字节的偏移量”，我假设您正在谈论从智能卡读取文件结构。这些是使用 READ BINARY APDU (B0) 命令读取的，该命令实际上包含 P1/P2 中的偏移量。带有奇数 INS (B1) 的 READ BINARY 可用于高于 32Ki 的偏移量。使用这些命令，您可以处理大于大多数智能卡最大内存量的文件。

当然，UPDATE BINARY 命令也是如此。因此，超过 64Ki 限制的读/写字节不是问题。然而，确定文件大小并读取文件的确切结尾比您想象的更“有趣”。

【讨论】：

我能够遵循您的 (64Ki - 1)-参数 - 不允许将 Lc 设置为全零。
至于“最后一个字节的偏移量”，我只是想知道如何解决例如如此大的 APDU 的 Le 字段或最后 Nc 个字节。但是，如果卡可以限制/确定接受的 APDU 的大小，甚至能够指示这一点，那么这应该不是问题。我的部分困惑是由于 ISO7816 将 Lc 指定为短值，但根据 ISO7816，在数据字段中传输的 BER-TLV 结构的长度也可能很好地进入整数大小类。显然，似乎还有另一种处理大型 BER-TLV 结构的方法。
TLV 结构通常只对卡上的 record 结构感兴趣，表示对象。此外，它们用于处理命令和响应结构本身中的参数（DO）。这些通常不是那么大。文件中的 TLV 结构并不重要。直到我认为 ISO 7816-4 2005 长度的最大大小为 64Ki - 1。这可能已经改变以允许更灵活地处理长度参数（在 BER 中，即使是小的长度也可以由最多 5 个字节表示，例如 8400000001 完全有效），使用什么取决于实现。