KitKat：如何将 APDU 路由到 SIM答案

【问题标题】：KitKat: How to route APDUs to the SIMKitKat：如何将 APDU 路由到 SIM
【发布时间】：2014-01-14 09:52:27
【问题描述】：

我想将从 NFC 读取器获取的 APDU 路由到 SIM 卡。根据HCE documentation，我认为只需使用相应的路由条目创建一个 OffHostApduService （我做了）就可以了。

遗憾的是，SIM 卡似乎没有获得任何 APDU。当 SIM 卡通过 SIM 读取器直接连接到我的工作站时起作用的 SELECT 命令返回 6a82（找不到文件）。

在 LogCat 中我发现了两条有趣的信息：

每次我发出一个应该路由到 SIM 卡的选择命令时，我都会得到这些条目：

01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingManager::stackCallback: event=0x17
01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingManager::stackCallback: NFA_CE_DATA_EVT; h=0x302; data len=12
01-14 10:44:18.501: D/HostEmulationManager(1009): notifyHostEmulationData

我认为这是路由设置不正确的线索，因为我认为 Android 操作系统不应该知道何时路由到 SIM 卡是活动的，并且选择或其他命令被发送到 SIM 卡。

每次我将手机从阅读器的 NFC 区域中取出时，我都会收到以下错误：

01-14 10:46:48.791: E/BrcmNfcNfa(1009): UICC[0x0] is not activated

我试图追踪这个错误的原因并找到了文件external/libnfc-nci/src/nfa/ce/nfa_ce_act.chere，它似乎属于 Broadcom NFC 驱动程序。

我认为错误在于应用程序无法为 APDU 设置正确的路由，因为驱动程序认为 SIM 未激活。在我发送命令的那一刻，SIM 被解锁（PIN 输入），但我怀疑这与它有什么关系，因为在读卡器中使用它之前我不必解锁 SIM。

我使用 Nexus 5 进行测试。有没有人有经验和/或一个可以将 APDU 路由到 SIM 而不是 CPU 的工作示例？

【问题讨论】：

您好，我正在解决同样的问题，但是我不知道如何将 apdu 路由到 sim 可以解释您在我提出的问题上使用的方法。我正在搜索如何覆盖 offHostApduService 的 onBind 方法。非常感谢

标签： android nfc android-4.4-kitkat apdu hce

【解决方案1】：

快速检查（分析插入设备的 UICC 的 SWP 引脚上的信号）显示 Nexus 5没有将 SIM 作为 NFC 安全元件激活（无论是在启动时还是在启动时）将手机放在智能卡读卡器上）。

但是，我在设备的系统分区上发现了两个有趣的文件：

/system/etc/libnfc-brcm-20791b05.conf 和
/system/etc/libnfc-brcm.conf。

这两个文件似乎提供了 NFC 控制器的配置（第一个是特定于芯片的配置，第二个是特定于芯片系列的配置？）。

解锁引导加载程序后，我可以通过启动clockworkmod恢复映像通过adb修改这些文件，因此我对配置参数进行了一些试验。

结果是我设法让设备激活 UICC（UICC 已激活并通过 SWP 注册其 CE 门？），设备有时甚至通知 UICC 字段状态更改。然而，在我没有修改任何配置的情况下，我能够让读卡器顺利发现卡仿真（这在以前可以工作，当时设备上只有 HCE 可用），也不能与 UICC 通信。

/system/etc/libnfc-brcm.conf 中有趣的参数似乎是：

NFA_MAX_EE_SUPPORTED：目前设置为 0。我尝试了一个值 3，这似乎是默认值。
ACTIVE_SE：当前设置为 0（无活动 SE）。我尝试取消注释该行以让设备使用检测到的第一个 SE。
NFA_HCI_STATIC_PIPE_ID_??：应该没有必要，但在 GS4 上，这设置为 0x71 吗？ = F3 和 F4。
UICC_LISTEN_TECH_MASK：在我们的 GS4 上设置为 0x00。
REGISTER_VIRTUAL_SE：我保持原样（== 已注释掉）。
SCREEN_OFF_POWER_STATE：我没有对此进行实验，但在我们的 GS4 上，此设置为 3（屏幕关闭 CE）。

/system/etc/libnfc-brcm-20791b05.conf 中有趣的参数似乎是：

NFA_DM_START_UP_CFG：我尝试了 UICC 的注释掉参数，并尝试使用我们 GS4 中的配置。该值以一个长度字节开始，并以 TLV 格式（一个标签字节、一个长度字节、参数数据）构成。 UICC 激活的相关标签似乎是C2，其中第二个参数字节中的高两位禁用 NFC 控制器的 SWP 接口（如果设置）。
NFA_DM_PRE_DISCOVERY_CFG：cmets 建议取消对 UICC 支持的注释。

【讨论】：

非常感谢！还有一个问题：在 GS4 上，UICC 可以用来回答 NFC 命令吗？我认为答案中暗示了这一点。
是的，至少在我们的 GS4（来自 A1 Telekom Austria）上，UICC 可以通过 NFC 空中接口和应用处理器（通过 SEEK/Open Mobile API）访问。跨度>
我刚刚玩了一点，发现UICC在设备放在阅读器上时会收到场开/关和激活事件。然而，这些事件到达 UICC 的 B 类仿真门，而读卡器只检测到 A 类卡（向此卡发送 APDU 会导致它们被转发到主机——无论任何 OffHostApduService 配置如何）。

【解决方案2】：

自从我上次在 Android 上玩卡模拟已经有一段时间了，但 AFAIK（我可能是错的），安全元素访问（内部或内部 SIM）尚未向所有开发人员开放 (without some hacking)。有许多关于 SE 控制的非技术问题似乎还没有解决（谁是电信公司或服务提供商的最大份额？）。

消息是，Google 对 KitKat 及其HCE 采取了不同的方法，主要包括实现 NFC 卡模拟模式没有硬件安全元件。恕我直言，这基本上打破了有趣的卡模拟模式应用程序所需的安全性：电子支付、票务、身份验证等。Nexus 5 lacks such secure element 我怀疑谷歌会通过放宽对 SIM 内安全元素的访问来迎合运营商，所以我猜它仍然无法使用库存固件将 APDU 发送到 SIM。

【讨论】：

【解决方案3】：

如果将以下内容添加到/etc/libnfc-brcm.conf

DEFAULT_ISODEP_ROUTE=0xF3

UICC 将接收 APDU

您还需要在libnfc-brcm.conf 和libnfc-brcm-20791b05.conf 中对above 进行所有修改

直到Jelly Bean 4.3，正常的方法是使用nfc_extras及其方法CardEmulationRoute (<route>, <nfcEe>)将UICC路由到RF。但在 KITKAT 上，这种通过 DEFAULT_ISODEP_ROUTE 进行的粗暴修改足以启用 UICC Card Emulation。

【讨论】：

谢谢。我还没有测试它，但相信你。这是单向更改（破坏 HCI），还是路由是否根据文档工作？
您好，请告诉我这是否有效？这也适用于其他手机吗？