AN12057-Making reader infrastructures ready for multi-application.pdf

1.1 动机和背景

如今，许多交通票务、门禁管理、钱包等系统在其基础设施中使用符合 ISO/IEC 14443 标准的非接触式卡。 终端通常被设计为操作一组明确的卡，保存特定的应用程序。 这也称为封闭系统方法。 有意或无意地，某些终端应用程序需要较低 RF 或 ISO 协议的特定参数设置来执行整个交易。 如果卡或模拟卡的NFC移动设备（NMD）未相应设置上述参数，终端应用程序可能会停止交易。 NMD 可以托管多个应用程序。 通常，这些应用程序可能依赖于不同甚至冲突的低级 ISO/IEC 14443 参数设置，这可能会导致互操作性问题。 为了避免多应用卡和 NMD 的互操作性问题，本文档旨在列出非接触式参数，并就其在读卡器基础设施系统中的相关性和设置提供指导。 此外，还提到了如果忽视准则可能产生的后果。

阅读器终端、终端应用程序、PTO、阅读器基础设施、非接触式、MIFARE、SmartMX、JCOP、NFC、NFC 移动设备、多应用环境 摘要 本文档就符合 ISO/IEC 标准的阅读器和终端实施提出建议。 它的重点是接受非接触式卡和托管多个应用程序的 NFC 移动设备。

1.2 范围

本应用说明面向系统运营商、系统集成商、基础设施供应商和终端开发商，旨在允许在其系统中使用多应用卡和 NMD。 因此，目标是从封闭的生态系统方法转变为开放的生态系统方法。 该文档试图允许多个应用程序共存，并在一个阅读器系统中使用。

1.3 重要说明

本应用说明是一份补充文件，重点介绍了 ISO/IEC 14443、ISO/IEC 7816、ISO/IEC 18092 参数的基本部分及其在阅读器系统中的用法。 为了全面了解上述标准和产品，请参阅匹配规范、白皮书和数据表。

2.1 目前存在的问题

已经安装的阅读器基础设施大多没有为第三方媒体做好准备。 ISO/IEC 14443 和 ISO/IEC 18092 提供了几种不同的方式来交换信息和提供可选功能。 不需要实现可选功能。

过去，该领域的 PCD 实施主要旨在允许单个应用程序 PICC 指示特定参数设置。 因此，这种基础设施的读者拒绝了所有其他使用不同 ISO/IEC 一致性参数设置并托管不同应用程序的 PICC。

最终客户正在努力应对他们钱包中的大量不同卡片，所有这些卡片都托管一个应用程序。 因此，PICC 和 NMD 正在进入能够承载多种应用程序的市场，这是一种强烈的趋势。 由于上述原因，现有基础设施的一部分不允许引入。

强烈建议更新当前的 PCD 基础设施以支持最终客户的需求。 特别是应该可以实现在同一设备上驻留不同类型的应用程序（例如公共交通、访问和支付应用程序）。 为了实现这一目标，本文档提供了如何设计基础设施的建议，主要侧重于 ISO/IEC 14443 参数设置和应用程序选择。

 

2.2 一般建议

建议终端实现不要混淆 13.56 MHz 无线电的传输层（A 类激活和协议）和应用层（应用数据）。 因此，终端的设计方式应接受 PICC 或 NMD 指示的整个范围的参数，并符合 ISO/IEC 14443 第 1 至 4 部分、ISO/IEC 18092 和 NFC 论坛规定的所有要求。 终端应允许该指示，并应尊重来自 PICC 的以下参数的所有响应：

• 所有 UID 和 UID 长度（4、7 和 10 字节，参见 [8]，第 6.5.4 节）
• 所有协议（参见 [9]，第 11.2.1 节）
• 所有比特率
• 所有帧大小和帧等待时间
• ATS 的所有信息（如果符合 ISO/IEC 14443 规范）
如果 ATS 的长度不符合预期，即不包含预期的历史字节长度，则不建议终端拒绝 PICC。

3 ISO/IEC 14443 终端实施指南

所有 MIFARE IC 的设计均符合 ISO/IEC 14443 第 2 部分和第 3 部分。MIFARE DESFire、NXP 双接口或三接口卡 IC（如 SmartMX）支持 ISO/IEC 14443-4 中定义的传输协议 ）和 MIFARE Plus。

对于所有读写器终端，我们建议严格遵循 ISO/IEC 14443 的要求和指南，并且不要对 PICC 提供的参数进行限制。 为了与不同类型的 PICC/NMD 及其应用顺利配合，读取设备应是开放的，并且不限制 PICC 提供的参数。

3.2 交换的 ISO/IEC 14443 参数的处理

在符合 ISO/IEC 14443 的防冲突环路和卡激活期间，PCD 和 PICC 之间会交换许多参数：表 1 列出了标准 ISO/IEC 14443、ISO/IEC 18092 和 NFC 论坛中定义的选定参数。 提供了有关 PCD 应如何处理每个参数的建议。 表格后面的部分还讨论了特别重要的参数。

为了识别所呈现的PICC的类型，需要评估交换的参数（主要是SAK的内容）。 类型识别机制的详细信息可以在[2]中找到。

在每个轮询周期后或 PICC 停用后，PCD 应关闭 RF 场至少 5.1 ms。

在发送第一个激活命令之前，PCD 应提供至少 5.1 毫秒的未调制射频场。

PCD 应接受 PICC 提供的任何 UID。 PCD不应依赖于UID的特定长度或UID的特定类型。 最重要的是，PCD 不应依赖特定范围的 UID 来实现专用应用。 如果多个应用程序同时在 PICC 上可用，则无法预测在激活期间将显示哪个 UID（由于隐式选择）。

PCD 不应检查或依赖于 PICC 在 ATQA 字节 1 的 b8 至 b7 和 b5 至 b1 以及字节 2 的 b4 至 b1 中返回的值。

在评估 SAK 的第 6 位和第 7 位之前，PCD 应检查基于 ISO/IEC 14443-3 的应用程序。 PCD 应接受 Bit7 的任何值。 在移动环境中，该位通常设置为 1 以指示 NFC-DEP 能力。 当接收到不为零的 Bit7 时，PCD 不应混淆，但应继续正常操作。

PCD 应指示其在 FSDI 中接收数据的最大可接受帧大小。 PCD 应接受从 PICC 接收到的有效范围内的任何 FSCI 值。

PCD 应评估 FWI 并允许任何接收到的值位于有效范围内。 默认 FWI 为 4。在 ISO/IEC 分配 RFU 值 15 之前，接收 FWI = 15 的 PCD 应将其解释为 FWI = 4。

PCD 应允许历史字节的任何可能值，并且不应将它们限制为某些预期值。

PCD 应接受支持 CID 的 PICC 以及不支持 CID 的 PICC。 无论 PICC 支持或不支持 CID，PCD 均应继续正常运行。

PCD 应允许 NAD 支持字段的任何可能值。 无论它接收到支持的 NAD 还是不支持的 NAD，都应该被接受。

PCD 应接受在 ATS 内接收到的任何指示比特率，但不一定需要使用最高比特率。

PCD 应评估 SFGI 并允许有效范围内的任何接收值。 默认 FWI 为 0。在 ISO/IEC 分配 RFU 值 15 之前，接收 SFGI = 15 的 PCD 应将其解释为 SFGI = 0。

PICC 可以自由使用历史字节，因为它们是可选的。 最大历史字节数可以根据ATS的最大长度来确定。

历史人物的内容并不固定。 它们可用于 PICC 提供商的任何特定信息。 仅接受 PCD 上某些定义的历史字节可能会导致互操作性问题。

PICC 应在接口字节 TA(1) 中或通过 S(PARAMETER) 协商指示最大支持比特率。

3.2.1 仅支持 ISO/IEC 14443-3 应用的终端实现

如果 PICC 指示 SAK 中存在 ISO/IEC 14443-4 应用程序，则 PCD 仍应发送针对基于 ISO/IEC 14443-3 的应用程序的命令。

3.2.2 支持 ISO/IEC 14443-3 应用和 ISO/IEC 14443-4 应用的终端实现

  如果 PICC 指示 SAK 中存在更高层协议，则 PCD 应通过发送相应的命令来检查是否存在 ISO/IEC 14443-3 应用程序。 如果未找到 ISO/IEC 14443-3 应用程序，则 PICC 可能已离开 ACTIVE 状态并进入 IDLE 状态。 在这种情况下，PCD 应执行卡激活并将 PICC 置于协议状态，然后 PCD 才能检查现有的 ISO/IEC 14443-4 应用程序。

3.3 克服 FWI 的潜在限制

特别是 NMD 可能具有多种应用，其中每种应用都可以通过不同的 RF 参数来表征。 某些应用程序要求 PICC 将 FWI 设置为特定值。 在 PCD 方面，互操作性不应受到此特定设置的影响，因为终端应遵守最高 FWI = 14 的任何 FWI 值。期望特定 FWI 值（例如 7 或 8）的 PCD 既不符合 ISO/IEC 14443 也不符合 EMVCo 合规。

4.1 主机卡仿真 (HCE) 和 ISO/IEC 7816 支持

特别是对于 HCE 实现的支持，未来终端实现的设计和实现方式应该是根据基于 ISO/IEC 14443-4 的底层（本地）PICC 命令集进行应用选择，以及根据 ISO/ IEC 7816，可以达到。 除了主机之外，NMD 还可能包含一个安全元件 (SE)，例如 SmartMX。 在这种情况下，NMD 上可以使用多个 NFCEE（NFC 执行环境）。 当一个 NMD 上存在多个 NFCEE 时，提供给终端的 RF 参数可以是任何可用 NFCEE 的参数，也可以来自管理实体。 根据所选的 NMD 默认应用程序及其位置（SE 或主机），UID 可能会发生变化。 因此，PCD目标应用程序可能与接收到的UID不匹配。 因此，PCD应当选择应用程序而不管接收到的UID。 示例：使用 HCE 可以通过 SmartMX 参数激活卡仿真，但最终驻留在主机上的应用程序由终端应用程序选择。 SmartMX 和主机可能具有不同的 UID，并且应用程序不知道 SmartMX 的 UID。 此示例中的预期行为是终端使用 SmartMX 提供的 RF 参数执行激活过程，并且在 NMD 上，NFC 控制器负责将请求路由到驻留在主机上的应用程序。 对于此路由，NFC 控制器使用路由表，其中映射了 SmartMX 和主机的所有 AID。

4.1.1 使用 SELECT FILE 命令选择应用程序

对于根据 ISO/IEC 7816-4 的应用程序选择，需要在终端实现中使用命令 SELECT FILE by DF Name（DF Name 代表应用程序的 AID），详见[4]，第 3.3 节。 此应用程序选择可用于与 HCE 以及 PICC 交互，这些 PICC 在 ISO/IEC 14443-4 上运行并支持 ISO/IEC 7816-4 行业间兼容命令集（至少是 SELECT FILE）命令。 当前未使用 SELECT FILE 命令的基础设施可以根据 NXP IID 分配方案 [3] 选择 DF 名称/AID。 已经在其终端实现中使用 SELECT FILE 命令的现有基础设施可以为 HCE 应用程序实现使用相同的 DF 名称。

4.1.2 UID检索

主要是在PICC内部使用多样化密钥时需要检索UID，并且密钥多样化是基于UID作为密钥多样化功能的基础输入。 此外，当使用特殊配置（例如随机 ID）时，需要从 PICC 检索真实的 UID。 NMD 在 ISO/IEC 14443-3 防碰撞过程中报告的 UID 由 NFC 控制器确定。 Android 主机卡仿真完全独立于 UID，并且没有可用的 API 允许对其进行设置。 UID 主要取决于 NFC 控制器（UICC 或 SmartMX）中定义的默认安全元件以及隐式选择，以防 SmartMX 上有多个可用应用程序。 如果卡激活的默认路由为 host。

4.1.3 随机ID的使用

如果使用随机 ID 激活卡，检索 UID 的实际机制取决于 MIFARE 产品系列的具体产品。 举一些例子： • 对于 MIFARE DESFire，可以执行专用命令 Cmd.GetVersion 或 Cmd.GetCardUID。 作为响应，将返回 PICC 的真实 UID。 • 对于 MIFARE Classic、MIFARE Ultralight 和 MIFARE Plus，需要执行扇区 0 中块 0 的读取命令（从制造商块读取），其中存储了制造商详细信息和 UID。

4.2 MIFARE4Mobile
[5] 中给出了有关如何在终端安装上处理 MIFARE4Mobile 的详细建议。

4.2.1 UID 在 MIFARE4Mobile 中的使用

根据 MIFARE4Mobile 的使用情况，如果通过隐式选择激活虚拟卡（例如 MIFARE Classic），则手机提供的 UID 可以是：
  • 随机 UID，在每次新激活时改变
  • 固定的 7 字节 UID，对应于安全元件的主 UID（如 P73）
• 伪随机UID（4 字节或7 字节）使用预定义范围内的随机ID，并在创建虚拟卡期间固定
• 如果应用程序可以完全访问安全元件，则分配 4 字节或 7 字节 UID

4.3 读写器/终端射频场

正如本文档前一节所述，卡激活和 PICC 选择期间所有与时序相关的参数都是必不可少的。 对于 RF 场的修改（场开/场关），在继续执行命令之前需要插入至少 5.1 ms 的等待时间。