KitKat:如何把APDUs运送到SIM卡

I want to route APDUs I get from an NFC Reader to the SIM Card. According to the HCE documentation I thought it would be possible simply by creating an OffHostApduService with the according routing-entries (which I did).

我想从NFC阅读器到SIM卡的路径。根据HCE文档，我认为可以通过使用According routing-entries创建一个OffHostApduService来实现(我确实这么做了)。

Sadly, the SIM does not seem to get any APDUs. SELECT-Commands that work when the SIM is directly attached to my workstation by a SIM-Reader return with 6a82 (File not found).

不幸的是，SIM卡似乎没有任何解决方案。当SIM与我的工作站直接连接到我的工作站时，由一个SIM- reader返回，并带有6a82(文件未找到)。

In LogCat I found two interesting bits of information:

在LogCat我发现了两个有趣的信息:

Every time I shoot a select command which should be routed to the SIM, I get these entries:

每次我发射一个要路由到SIM的select命令时，我都会得到以下条目:

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

I think that this is a clue that the routing is not set correctly, since I think the Android OS should not be aware when the routing to the SIM is active, and a select or another command is sent to the SIM.

我认为这是路由设置不正确的提示，因为我认为Android OS不应该知道到SIM的路由何时是活动的，并向SIM发送一个select或另一个命令。

Every time I remove the phone from the NFC field of the reader, I receive the following error:

每次我从阅读器的NFC字段中删除手机时，都会收到以下错误信息:

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

I tried to track the cause of this error down and found the file external/libnfc-nci/src/nfa/ce/nfa_ce_act.chere which seems to belong to the Broadcom NFC Driver.

我试图找到这个错误的原因，并找到了文件的外部/libnfc-nci/src/nfa/ce/nfa_ce_act。chere似乎属于Broadcom NFC司机。

I think that the mistake is that the application cannot set the correct routing for the APDUs since the driver thinks that the SIM is not activated. In the moment I send the commands, the SIM is unlocked (PIN-Entry), but I doubt that this has anything to do with it since I don't have to unlock the SIM before using it in the card reader.

我认为错误在于应用程序不能为APDUs设置正确的路由，因为驱动程序认为SIM没有被激活。当我发送命令时，SIM卡是解锁的(输入)，但我怀疑这与它没有任何关系，因为我在使用读卡器之前不需要解锁SIM卡。

I use a Nexus 5 for testing. Does anybody have experience and / or a working example where the APDUs can be routed to the SIM instead of the CPU?

我使用Nexus 5进行测试。是否有人有经验和/或一个工作示例，其中APDUs可以路由到SIM，而不是CPU?

3 个解决方案

#1

A quick check (analyzing the signals on the SWP pin of a UICC inserted into the device) revealed that the Nexus 5 is not activating the SIM as an NFC secure element (neither at boot nor when putting the phone on a smartcard reader).

快速检查(分析插入到设备中的UICC的SWP pin上的信号)发现，Nexus 5并没有将SIM卡激活为NFC安全元素(无论是在引导时还是将手机放入智能卡阅读器时)。

However, I found two interesting files on the device's system partition:

然而，我在设备的系统分区上发现了两个有趣的文件:

/system/etc/libnfc-brcm-20791b05.conf and
/系统/ etc / libnfc - brcm b05——20791。配置和
/system/etc/libnfc-brcm.conf.
/系统/ etc / libnfc-brcm.conf。

These two files seem to provide the configuration for the NFC controller (the first one a chip-sepecific configuration and the second one a chip-family specific one?).

这两个文件似乎提供了NFC控制器的配置(第一个是chip-sepecific配置，第二个是chip-family特有的配置)。

After unlocking the bootloader, I was able to modify those files through adb by booting a clockworkmod recovery image, so I did some experimenting with the configuration parameters.

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

The result is that I managed to let the device activate the UICC (UICC was activated and registered its CE gates through SWP?), the device sometimes even notified the UICC about field status changes. However, with none of my modified configurations, I was able to get the reader to smoothly discover card emulation (this was working before, when only HCE was available on the device) nor to communicate with the UICC.

结果是我设法让设备激活UICC (UICC被激活并通过SWP注册它的CE gates ?)，设备有时甚至会通知UICC关于字段状态的更改。然而，没有修改过任何配置，我就能够让阅读器顺利地发现卡片模拟(这在以前是有效的，当时设备上只有HCE可用)，也不能与UICC通信。

The interesting parameters in /system/etc/libnfc-brcm.conf seem to be:

有趣的参数在/系统/etc/libnfc-brcm。会议似乎是:

NFA_MAX_EE_SUPPORTED: This is currently set to 0. I tried a value of 3, which seems to be the default.
NFA_MAX_EE_SUPPORTED:当前设置为0。我尝试了一个3的值，这似乎是默认值。
ACTIVE_SE: This is currently set to 0 (no active SE). I tried to uncomment that line to let the device use the first SE detected.
ACTIVE_SE:当前设置为0(不活动SE)。我试图取消对这一行的注释，以便让设备使用检测到的第一个SE。
NFA_HCI_STATIC_PIPE_ID_??: Should not be necessary but on out GS4 this is set to 0x71 for ?? = F3 and F4.
NFA_HCI_STATIC_PIPE_ID_ ? ?:不应该是必要的，但在GS4上这是设置为0x71的??= F3,F4。
UICC_LISTEN_TECH_MASK: This is set to 0x00 on our GS4.
UICC_LISTEN_TECH_MASK:在GS4中将它设置为0x00。
REGISTER_VIRTUAL_SE: I left this as it was (== commented out).
REGISTER_VIRTUAL_SE:我保留了它的原样(==注释掉了)。
SCREEN_OFF_POWER_STATE: I did not experiment with this, but on our GS4 this is set to 3 (screen-off CE).
SCREEN_OFF_POWER_STATE:我没有对此进行实验，但是在GS4上，它被设置为3(屏幕关闭CE)。

The interesting parameters in /system/etc/libnfc-brcm-20791b05.conf seem to be:

在/system/etc/libnfc-brcm-20791b05中有趣的参数。会议似乎是:

NFA_DM_START_UP_CFG: I've tried the commented-out parameters for UICC and I tried to use the configuration from our GS4. The value starts with a length byte and is structured in TLV format (one tag byte, one length byte, parameter data). The relevant tag for UICC activation seems to be C2, where the upper two bits in the second parameter byte disable the SWP interfaces of the NFC controller if set.
NFA_DM_START_UP_CFG:我尝试了UICC的注释参数，并尝试使用GS4中的配置。值以长度字节开始，结构为TLV格式(一个标记字节、一个长度字节、参数数据)。UICC激活的相关标记似乎是C2，其中第二个参数字节的上两个位在设置时禁用NFC控制器的SWP接口。
NFA_DM_PRE_DISCOVERY_CFG: The comments suggest that this need to be uncommented for UICC support.
NFA_DM_PRE_DISCOVERY_CFG:这些注释表明需要对UICC支持进行未注释。

#2

It's been a while since I last played with card emulation on Android but AFAIK (I could be wrong), secure element access (internal or inside SIM) has not yet been opened to all developers (without some hacking). There are many non-technical issues regarding SE control which seem not yet solved (who keeps the biggest slice of the cake the Telcos or service providers?).

我已经有一段时间没有使用Android上的纸牌模拟了，但是AFAIK(我可能是错的)，安全元素访问(内部的或者内部的SIM)还没有向所有的开发者开放(没有一些黑客)。有许多关于SE控制的非技术问题似乎还没有解决(谁将最大的一块蛋糕留给电信公司或服务提供商?)

The news is that Google has taken a different approach with KitKat and its HCE, which basically consists on implementing a NFC card emulation mode without hardware secure element. IMHO this basically breaks the security required for the interesting card emulation mode applications: e-payment, ticketing, authentication, etc. Nexus 5 lacks such secure element and I doubt Google will pander to carriers by easing the access to secure element inside SIM, so I guess it still will not be possible to send APDUs to the SIM with stock firmware.

最新消息是，谷歌对KitKat及其HCE采取了不同的做法，基本上是在没有硬件安全元素的情况下实现NFC卡仿真模式。IMHO这基本上打破了有趣的卡片模拟模式应用程序所需的安全:网络支付、票务、身份验证、等联系5缺少这样安全元素和我怀疑谷歌将迎合运营商通过宽松的访问安全元素在SIM卡,所以我猜它仍然是不可能发送APDUs SIM的股票固件。

#3

If you add the following to /etc/libnfc-brcm.conf

如果您向/etc/libnfc-brc .conf添加以下内容

DEFAULT_ISODEP_ROUTE=0xF3

the UICC will receive APDUs

UICC将收到APDUs

You also need all modifications above in libnfc-brcm.conf and libnfc-brcm-20791b05.conf

您还需要在libnfc-brcm中进行以上所有修改。配置和libnfc b05.conf——brcm - 20791

Up to Jelly Bean 4.3, normal way is to use nfc_extras and its method CardEmulationRoute (<route>, <nfcEe>) to route the UICC to the RF. But on KITKAT, this brutal modification through DEFAULT_ISODEP_ROUTE is enough to have UICC Card Emulation enabled.

通常的方法是使用nfc_extras及其方法CardEmulationRoute ( ， )将UICC路由到RF。但是在KITKAT上，通过DEFAULT_ISODEP_ROUTE进行的粗暴修改就足以启用UICC卡片模拟。

#1