运营商发展国密UIM卡技术探讨

基础进行构建，引入了Java Card虚拟机（JCVM）[6]、Java Card运行时环境（JCRE）[7]、Global Platform运行环境（OPEN）[8]、非接触框架（Contactless Framework）等多类应用的运行环境，从而实现了多个维度的“一卡多应用”。具体来说，运营商现有移动支付UIM卡可以在一张UICC上同时支持接触式应用、非接触应用、电信应用（NAA，如UIM、USIM）、非电信应用（如安全域、金融支付类应用、身份识别类应用、门禁考勤类应用、公交一卡通类应用、医疗卫生类应用、社保健康卡应用等），实现多类应用并存的业务需求，所有应用均采用Java Applet方式实现，是一种可以应用于跨领域业务的电信智能卡。

运营商现有移动支付UIM卡架构如图1所示，主要由底层架构和应用层组成，其中底层架构主要由四部分组成：

（1）硬件层：UIM卡用于同外部设备进行通信的物理接口，包括ISO7816接口[9]、SWP接口[10]、蓝牙接口等。

（2）COS层：提供内存和文件等基础管理，实现虚拟机和安全机制，实现底层传输协议及命令分发、APDU指令处理，并实现多个应用间防火墙等，为上层提供基础的逻辑处理机制。

（3）应用基础能力层：负责为UIM卡应用层的各种卡应用程序提供在卡内容下载、安装、删除的管理和存储等服务，并实现用户卡与外部设备通信的指令报文，以及包含鉴权和加密机制的安全信道会话机制。实现GP应用管理、空间管理、生命周期管理，为UIM卡提供了与终端进行交互的应用工具箱能力（包括Setup Menu（菜单显示）、Display（信息显示）、Get Input（信息输入）、Send Short Message（发送短信）、Set Up Call（拨打电话）等）。

（4）应用API层：为UIM卡应用层的各种卡应用程序提供基本调用接口，包括Java Card API、UICC/USIM API、GP API、HCI API等。

应用层则包括基础功能需求应用（电信应用、CRS、CREL、JCPM等）、安全域（为安全隔离发卡方和应用提供方而创建的具有密钥和卡内容管理功能的特殊应用）以及各类可动态加载或预置的具有复杂处理逻辑的用户卡应用（如金融支付类应用、身份识别类应用、门禁考勤类应用、公交一卡通类应用、医疗卫生类应用、社保健康卡应用、EID应用等）。

本文提到的国密UIM卡产品实现方法，主要是针对COS底层架构中的应用API层进行改造，实现国密算法API供应用层调用。

3 国密UIM卡产品实现方式

目前国密UIM卡产品主要有如下几种实现方式：

（1）在现有的移动支付UIM卡上加载国密芯片；

（2）在现有的移动支付UIM卡上加载国密芯片和蓝牙芯片；

（3）将现有移动支付UIM卡采用芯片替换为国密芯片；

（4）将现有移动支付UIM卡采用芯片替换为国密芯片，同时增加蓝牙芯片。

3.1 现有移动支付UIM卡上加载国密芯片

该方案主要是为了解决运营商现有移动支付UIM卡产品不支持国密算法的问题，基于现有移动支付UIM卡增加国密芯片。现有移动支付UIM卡底层COS调用国密芯片提供的国密算法接口，提供给应用层供Java Applet使用，这样加载在移动支付UIM卡上金融支付类、身份识别类、门禁考勤类、公交一卡通类、医疗卫生类、社保健康卡等领域的Java Applet应用就可以支持国密算法。

基于该方案现有移动支付UIM卡需进行如下改造：

（1）卡片需重新设计封装；

（2）现有移动支付UIM卡COS底层需修改，增加与国密芯片交互接口，同时增加对外提供给Java Applet的国密算法接口。

该方案的优缺点：

（1）原有移动支付UIM卡COS成熟度较高，对原有移动支付UIM卡COS底层改造较小，COS开发和测试难度较小；

（2）现有移动支付UIM卡COS底层与国密芯片交互为私有接口，存在一定的安全隐患，且性能比直接调用国密芯片底层算法接口慢；

（3）卡片重新设计封装额外增加成本，且周期较长；

（4）未解决目前不支持Open Mobile API终端无法通过客户端访问UIM卡上的Java Applet问题。

3.2 现有移动支付UIM卡上加载国密芯片和蓝牙

芯片

该方案基于3.1节的方案额外增加蓝牙芯片，为了解决部分终端不支持Open Mobile API，无法通过客户端访问移动支付UIM卡上的Java Applet的问题。增加蓝牙芯片后，手机终端可通过蓝牙接口与移动支付UIM卡进行通信。

基于该方案现有移动支付UIM卡需进行如下改造：

（1）卡片需重新设计封装；

（2）现有移动支付UIM卡COS底层需修改，增加与国密芯片交互接口，同时增加对外提供给Java Applet的国密算法接口。

该方案的优缺点：

（1）原有移动支付UIM卡COS成熟度较高，对于原有移动支付UIM卡COS底层改造较小，COS开发和测试难度较小；

（2）现有移动支付UIM卡COS底层与国密芯片交互为私有接口，存在一定的安全隐患，且性能比直接调用国密芯片底层算法接口慢；

（3）卡片重新设计封装，额外增加成本，且周期较长；

（4）增加两颗芯片后卡片封装受限，无法封装成Mini-UICC（4FF）形态，在目前卡槽设計为Mini-UICC形态的终端上无法使用；

（5）终端与UIM卡进行蓝牙交互目前暂无标准协议接口，且目前终端与卡片进行蓝牙交互成熟度不高，可能存在兼容性问题。

3.3 现有移动支付UIM卡芯片替换为国密芯片

该方案主要是将现有移动支付UIM卡采用的国外芯片替换为国密芯片，UIM卡底层COS可以直接调用国密芯片提供的国密算法接口，提供国密算法API给应用层供Java Applet使用，这样加载在移动支付UIM卡上的金融支付类、身份识别类、门禁考勤类、公交一卡通类、医疗卫生类、社保健康卡等领域的Java Applet应用就可以支持国密算法。

基于该方案，现有移动支付UIM卡需进行如下改造：

需基于国密芯片实现原移动支付UIM卡产品所有功能，同时将国密芯片提供的国密算法接口改造成可供应用层调用的国密算法API接口，其中国密算法API调用流程如图2所示。

安全应用调用国密算法API的流程说明如下：

（1）获得移动支付UIM卡算法能力：调用安全应用的客户端软件使用移动支付UIM卡的基本命令，获取移动支付UIM卡上的算法能力，该命令和移动支付UIM卡上的安全应用无关。

（2）返回算法标识：移动支付UIM卡操作系统通过算法标识返回移动支付UIM卡支持的算法能力。如果载体不支持国密算法，流程结束；如果支持国密算法，转步骤（3）。

（3）调用安全应用接口：如果移动支付UIM卡支持国密算法，调用安全应用的客户端软件调用移动支付UIM卡安全应用的命令接口。移动支付UIM卡安全应用收到调用命令后，根据命令进行处理。

（4）调用国密算法API：如果该命令的处理需要使用国密算法，通过移动支付UIM卡操作系统的商用密码算法API进行调用。

（5）返回算法调用结果：国密算法API被调用后，进行算法处理并向移动支付UIM卡上的安全应用返回算法处理结果。

（6）返回应用调用结果：移动支付UIM卡上的安全应用处理算法结束后，向客户端返回调用结果，流程结束。

该方案的优缺点：

（1）COS开发测试难度较大，需在新的芯片平台进行功能移植（包含移动支付UIM卡架构中所有功能）以及完整的产品化测试；

（2）卡片无需重新设计封装；

（3）未解决目前不支持Open Mobile API终端无法通过客户端访问UIM卡上的Java Applet问题。

3.4 现有移动支付UIM卡采用芯片替换为国密芯

片，同时增加蓝牙芯片

该方案基于3.3节方案增加蓝牙芯片，手机终端可通过蓝牙接口与移动支付UIM卡进行通信。

基于该方案现有移动支付UIM卡需进行如下改造：

（1）需基于国密芯片实现原移动支付UIM卡产品所有功能；

（2）卡片需重新设计封装。

该方案的优缺点：

（1）COS开发测试难度较大，需在新的芯片平台进行功能移植、功能及产品化完整测试；

（2）卡片重新设计封装，额外增加成本，且周期较长；

（3）终端与UIM卡进行蓝牙交互目前暂无标准协议接口，且目前终端与卡片进行蓝牙交互成熟度不高，可能存在兼容性问题。

4 國密UIM卡产品实现方式对照

目前国密UIM卡产品实现方式对照结果如表1所示。

5 结束语

运营商发展国密UIM卡产品需根据实际需求，综合考虑实现方式。在目前终端与UIM卡交互成熟度不高的情况下，建议采用方案三，将现有移动支付UIM卡芯片替换为国密芯片。

参考文献：

[1] 全国信息安全标准化技术委员会. GB/T 20276-2016 信息安全技术具有中央处理器的IC卡嵌入式软件安全技术要求[S]. 2016.

[2] 全国信息安全标准化技术委员会. GB/T 22186-2016 信息安全技术具有中央处理器的IC卡芯片安全技术要求[S]. 2016.

[3] 全国信息安全标准化技术委员会. GB/T 32918-2016 信息安全技术SM2椭圆曲线公钥密码算法[S]. 2016.

[4] 全国信息安全标准化技术委员会. GB/T 32905-2016 信息安全技术SM3密码杂凑算法[S]. 2016.

[5] 全国信息安全标准化技术委员会. GB/T 32907-2016 信息安全技术SM4分组密码算法[S]. 2016.

[6] Oracle. E25256-01 Java Card 3 Platform Virtual Machine Specification， Classic Edition Version 3.0.4[S]. 2011.

[7] Oracle. E18985-01 Java Card 3 Platform Runtime Environment Specification， Classic Edition Version 3.0.4[S]. 2011.

[8] Global Platform. GPC_SPE_034 Card Specification Version 2.2.1[S]. 2011.

[9] ISO/IEC. Identification cards—Integrated circuit cards—Part 4： Organization， security and commands for interchange[S]. 2005.

[10] ETSI TS 102. 613. Smart Cards； UICC-Contactless Front-end （CLF） Interface； Part 1： Physical and data link layer characteristics[S]. 2012.★

推荐访问: 运营商 探讨 发展 技术 UIM