OMA手机发展建议探讨

2017-01-12郭建昌

广东通信技术 2016年12期

［郭建昌］

OMA手机发展建议探讨

［郭建昌］

提出OMA手机概念(Open Mobile API移动开放互联)概念，介绍其技术背景、发展必要性、应用前景和目前实施方案介绍，为移动互联网用户和SP提供了融合智能终端便捷性和新型UICC架构(U)SIM卡高安全性的OMA手机实现思路和发展建议。

OMA 移动开放互联 SE 安全单元 GP

郭建昌

工程师，中山大学计算机硕士，中国电信基于用户卡移动融合安全认证体系能力和产品开发和实施项目经理，中国电信天翼通行证(CTPass)集团产品研究和开发项目经理，目前主要负责移动身份认证研究和开发工作。

1 背景介绍

随着移动互联网的蓬勃发展，智能手机的普及和成本的降低，越来越多的用户拥有至少一台智能手机，并且将智能手机与自己的工作、生活、娱乐、学习关联起来，贯穿自己每日的各种时间片段中。

而我们的手机用户卡（U）SIM卡也早已在2013年左右进行新的技术升级，由此前大家孰知的32K、64K或128K（见用户卡背面，表示用户卡容量）的ICC架构传统Native用户卡升级为512K的UICC新型架构Java用户卡，例如中国电信的NFC卡、天翼羊城通卡等。

2 必要性和前景分析

传统手机用户感知概念中，手机卡的作用就是进行电话、短信、上网等功能，最多是早期在里面还可以存联系人、存短信，或者通过用户卡菜单进去订购天气预报或订阅笑话等功能，其原因一方面是因为Native卡的性能和存储有限，另一方面是因为早期智能手机尚未普及和移动互联网尚未兴起。

新型UICC架构Java卡具有RSA硬件协处理器，具有较大的可用存储，并且具有Java虚拟机和符合GP（Global Platform）规范，是一个天然的安全单元SE(Secure Element)，也是一个可安全便捷开发部署各类Applet应用的安全环境，例如目前三大运营商已经在部署推广的SIM快捷身份认证应用、支付应用等。

如果能够将智能手机的便捷性和用户卡的高安全性结合起来，必定能促进移动互联网的发展，为SP、为用户提供更安全便捷可信的服务。SIMalliance OMA(Open Mobile API移动开放接口)手机已经实现了这个设想，并且已经在2014年起在国内大规模商用，也就是此前大家所熟悉了解的NFC手机。

3 OMA实施方案

下面以中国电信NFC手机和NFC卡为例介绍OMA接口和安全控制方案。

（1）OMA接口

图1 NFC-SWP终端硬件结构

本文所讨论的接口如图1所示的IF4，即运行于智能手机的APP应用和NFC用户卡（SWP-UIM卡）间接口。

图2 NFC-SWP终端软件架构

本文所讨论OMA方案即为图2右侧上部的Open Mobile API接口，安全控制方案即为Access Control Enforcer模块。

图3 SE访问接口总体架构

图3 中是Open Mobile API架构的概览。该体系架构被分为3个功能层次：

① 传输层是服务API的基础。当一个应用通过通用传输API访问SE时，它提供对SE的通用访问。传输层使用APDU命令来访问SE；

② 服务层提供接口访问SE上不同的功能。对应用开发商来说，这比通用传输API更加容易使用。例如，E-Mail应用程序可以调用Crypto API提供的加密函数sign()，由Crypto API完成与SE之间的APDU命令交互（而不是由E-Mail应用直接处理所有需要的APDU命令）；

③ 应用层代表使用Open Mobile API的各种不同应用客户端。

图4中传输API的作用是提供一个方法，使得应用可以访问设备上有效的SE。所提供的访问接口是基于ISO/IEC 7816-4定义的概念。

① APDU命令：与SE进行数据交换的消息格式，一般来说是送往SE（更准确的说是送往SE应用）的一个字节数组，然后SE再返回另外一个字节数组作为应答。消息格式参考ISO/IEC 7816-4；

图4 传输API概览

② 基本通道和逻辑通道：通道是传输APDU命令的路径，并且能同时打开多条通道（同一时刻只能发送一个APDU命令，需要等待应答返回后才能发送下一个APDU命令）。

这个API是基于“连接”模式的：客户端应用（运行在和SE建立连接的设备上，如手机）先和SE建立会话，然后再与SE应用建立一个基本通道或逻辑通道，访问模型如图4所示。

在此模式之上，系统有许多强制性的约束：

一个应用不能自己发送“通道管理”的APDU命令，因为这样会打破逻辑通道的独立性。一旦通道建立，它将被分配给SE上一个且仅有一个SE应用进行通信。同样的，终端应用不能发送选择专有文件（DF）的APDU命令。

这些系统的约束应该由直接处理SE通信的模块来实现，而不是API本身，从而保证攻击者不能穿透APDU过滤器。因此如果可能，应该由基带芯片或者至少是和基带芯片通信的无线接口层（RIL）来管理过滤器。

如图5所示，Open Mobile API在传输API之上定义了一个服务API，服务API依赖于传输API来完成与SE内部应用的通信。服务API由多个实现不同作用的专门的API组成(例如文件管理API实现文件操作)。一般来说每一个专门的API在SE中需要有一个与其相对应的部分(例如一个提供了特定APDU命令集的SE应用)。

对于应用开发者更关注的API类视图如图6所示：

（2）GPAC安全访问控制

SE访问接口打通之后，客户端软件在能够很方便的访问SE的同时，也会带来一定的安全隐患，一些非法客户端软件可能通过该接口对SE发动攻击，包括：

① 拒绝服务攻击，例如多次尝试错误的PIN码导致SE被锁，多次选择不能重复选择的SE应用等；

② 试图破解用户的敏感的应用数据，进行仿冒交易；

图5 服务API概述

③ 试图窃取用户的通信数据，进行“ 卡”。

为避免上述风险，确保用户数据的安全，必须制定必要的安全访问策略，限制客户端软件对于SE访问接口的访问，只有获得授权的客户端软件才能够进行访问

图7中的访问控制执行器负责智能手机应用客户端访问安全模块SE（如电信NFC用户卡）中的身份认证SE应用或支付SE应用时，根据访问控制数据中的访问规则如（应用客户端APPID，签名数字证书hash值）二元组来放行或组织对SE中应用的访问。

图7中的体系架构示例是访问规则仅存放在用户卡的主安全域中，其他可选架构包括：访问规则存放在主安全域和辅助安全域中或访问规则存放在访问规则文件中。

4 OMA手机发展建议

图6 OMA API类视图

通过上文对OMA实施方案的介绍可知，用户卡（SE）访问接口和访问控制技术是物理上和逻辑上都可以独立于NFC相关模块的，基于安全性考虑目前NFC手机都是建议在基带芯片或无线接口层(RIL)进行实现。同理，对于所有的智能手机（主要是Android），均可参照此模式为手机增加OMA功能，通过固件升级的方式实现，在不增加手机硬件成本的情况下，能够为手机APP应用增加访问手机（U）SIM卡SE单元的便捷能力，能够为手机用户和互联网应用提供更安全的解决方案和用户体验。

Google目前已经对OMA的接口发布了多个版本，保证对最新Android操作系统的支持，同时SIMalliance也发布了OMA的OEM手机厂家实施指南和应用开发者指南，并且提供丰富的测试案例和测试APP，大大降低OMA的推广普及门槛。