Fatal编程技术网
  • android/
  • Android KitKat：如何将APDU路由到SIM卡

Android KitKat：如何将APDU路由到SIM卡

android

Android KitKat：如何将APDU路由到SIM卡,android,nfc,android-4.4-kitkat,apdu,hce,Android,Nfc,Android 4.4 Kitkat,Apdu,Hce,我想将我从NFC阅读器获得的APDU路由到SIM卡。根据我的想法，只需创建一个带有相应路由条目的offhostapdus服务（我做到了），这是可能的 可悲的是，SIM卡似乎没有任何APDU。选择当SIM卡通过带有6a82的SIM卡读卡器直接连接到我的工作站时有效的命令（未找到文件） 在LogCat中，我发现了两个有趣的信息： 每次我发出一个应发送至SIM卡的select命令时，我都会收到以下条目： 01-14 10:44:18.501: D/BrcmNfcJni(1009): RoutingMa

我想将我从NFC阅读器获得的APDU路由到SIM卡。根据我的想法，只需创建一个带有相应路由条目的offhostapdus服务（我做到了），这是可能的

可悲的是，SIM卡似乎没有任何APDU。选择当SIM卡通过带有6a82的SIM卡读卡器直接连接到我的工作站时有效的命令（未找到文件）

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

每次我发出一个应发送至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
我认为这是路由设置不正确的一个线索，因为我认为Android操作系统不应该知道到SIM卡的路由处于活动状态，并且会向SIM卡发送select或其他命令

每次我从读卡器的NFC字段中取出手机时，我都会收到以下错误：

01-14 10:46:48.791: E/BrcmNfcNfa(1009): UICC[0x0] is not activated
我试图找出这个错误的原因，找到了文件
external/libnfc-nci/src/nfa/ce/nfa\u-ce\u-act.chere
，它似乎属于Broadcom的NFC驱动程序

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

我使用Nexus5进行测试。有人有过APDU可以路由到SIM卡而不是CPU的经验和/或工作示例吗？

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

消息是谷歌对KitKat和its采取了一种不同的方法，基本上是在没有硬件安全元素的情况下实现NFC卡仿真模式。IMHO这基本上破坏了有趣的卡模拟模式应用程序所需的安全性：电子支付、票务、身份验证等。我怀疑谷歌会通过放松SIM卡内部安全元素的访问来迎合运营商，所以我猜仍然不可能使用库存固件将APDU发送到SIM卡。

快速检查（分析插入设备的UICC的SWP引脚上的信号）发现Nexus 5未将SIM卡作为NFC安全元件激活（无论是在开机时还是将手机置于智能卡读卡器上）

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

  • /system/etc/libnfc-brcm-20791b05.conf
    和
  • /system/etc/libnfc brcm.conf
这两个文件似乎为NFC控制器提供了配置（第一个文件是芯片专用配置，第二个文件是芯片系列专用配置？）

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

结果是，我设法让设备激活UICC（UICC被激活并通过SWP注册其CE门？），设备有时甚至会通知UICC有关字段状态的更改。但是，由于没有任何修改的配置，我能够让读卡器顺利发现卡模拟（在设备上只有HCE可用的情况下，这在以前是可行的），也无法与UICC通信

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

  • NFA\u MAX\u EE\u SUPPORTED
    ：当前设置为0。我尝试了一个值3，这似乎是默认值
  • ACTIVE\u SE
    ：当前设置为0（无活动SE）。我试图取消注释该行，以便设备使用检测到的第一个SE
  • NFA\u HCI\u STATIC\u PIPE\u ID\u？？？：不需要，但在输出GS4时，对于？？？=F3和F4，此设置为0x71
  • UICC\u LISTEN\u TECH\u MASK
    ：在我们的GS4上设置为0x00
  • REGISTER\u VIRTUAL\u SE
    ：我把它原封不动（=注释掉）
  • SCREEN\u OFF\u POWER\u STATE
    ：我没有尝试过这个，但在我们的GS4上，它被设置为3（SCREEN OFF CE）
/system/etc/libnfc-brcm-20791b05.conf
中有趣的参数似乎是：

  • NFA\u DM\u START\u UP\u CFG
    ：我尝试了UICC的注释参数，并尝试使用GS4中的配置。该值以长度字节开始，并以TLV格式构造（一个标记字节、一个长度字节、参数数据）.UICC激活的相关标签似乎是
    C2
    ，其中第二个参数字节中的上两位禁用NFC控制器的SWP接口（如果设置）
  • NFA\u DM\u PRE\u DISCOVERY\u CFG
    ：评论建议需要取消注释以支持UICC
如果将以下内容添加到
/etc/libnfc brcm.conf

DEFAULT_ISODEP_ROUTE=0xF3
UICC将接收APDU

您还需要在
libnfc-brcm.conf
和
libnfc-brcm-20791b05.conf

DEFAULT_ISODEP_ROUTE=0xF3
在Jelly Bean 4.3之前，通常的方法是使用
nfc_extras
及其方法
CardSimulationRoute（，）
将UICC路由到RF。
但在KITKAT上，通过默认ISODEP路由进行的这种野蛮修改足以启用UICC卡仿真。

非常感谢！再问一个问题：在GS4上，UICC可以用来回答NFC命令？我认为答案中暗示了这一点。是的，至少在我们的GS4上（来自奥地利A1 Telekom）UICC可以通过NFC空中接口和应用处理器（通过SEEK/Open Mobile API）访问