提高JAVA卡互操作性的研究

2014-10-21王俊清郭娜

电子世界 2014年12期

王俊清郭娜

【摘要】目前栖息于JAVA USIM卡上的应用主要分三大类：银行类、公交类、校企类。本文主要以银行类应用为例，分析目前联通java卡的互操作性现状，并提出了改进互操作性的建议，为实现第三方应用开发作好技术准备。

【关键词】UICC；USIM；SWP；PBOC；JAVA；互操作性

一、背景

联通金融USIM卡是符合3GPP相关规范和GP规范的含有USIM应用和PBOC应用的有SWP功能的JAVA卡。主要遵循七部分规范： UICC规范、USIM规范、JAVA卡规范、GP规范、SWP卡规范、HCI规范和PBOC3.0规范。理论上讲，联通金融USIM卡据有良好的安全性和互操作性，可以采用预置和后期两种方式加载。然而，现实中其互操作性很差。本文建立在联通11家供卡商的卡与4家应用的实际互测试基础上，分析了引起互操作性的因素，对未来实现第三方应用开发提供了有价值的参考。

二、联通JAVA USIM卡架构简介：

联通JAVA USIM卡架构图如下：

三、理想的JAVA卡应用编写状态

如果运营商采购的java卡遵循的各规范版本一致，各家卡商开发的PBOC检测用应用经过了银检中心的检测，那么上层的给各家银行编写的应用理论上应该可以由第三方统一开。

四、实际的JAVA卡应用编写现状

最近，联通兴业组织了一次4家应用开发商的应用在11家联通供卡商的卡上进行的兼容性测试，结果如表1所示。

本次测试由于时间问题准备的较为仓促，测试设备和测试项没有事先统一规定，有的应用商测试项较多，覆盖面较广，有的检测却相对简单。另外，有的测试使用手机终端进行，有的使用非接读卡器进行，因此，本次测试只具有参考价值。通过4家应用测试的卡未必是没有问题的，本次在其他家卡上兼容性表现不好的应用也未必是不好的应用。虽然只是一个不全面的测试，也已经发现了严重的兼容性问题：卡与应用的兼容性问题，卡和应用与终端的兼容性问题。此次兼容性问题可基本排除“规范版本众多，彼此不统一”和“使用私有指令”等因素。本文只讨论分析本次测试同一个金融应用不能在各家卡上兼容的原因：

（1）PBOC规范中一些参数的设定很灵活，没有相应的生产规范进行明确，致使各家定义不同；

（2）各家对规范理解存在一定差异，而测试又没有全覆盖；

（3）各家对规范中可选项的处理存在差异；

（4）COS内存管理水平的优劣差别致使程序健壮性不同；

（5）程序指令优先顺序和占用的资源状况影响卡与应用的适配性；

（6）硬件性能差异造成应用程序兼容性差：由于芯片内存大小、CPU运算速度差异、协处理器存在与否等造成了同样的JAVA卡应用程序在性能差的芯片上难以正常运行；

（7）应用编程水平和卡与应用的适配性对兼容性存在影响，同款芯片同样COS的卡，运行同样功能的不同应用，速度差距也较大。

（8）COS编程人员的经验与处理能力存在差异：目前联通的SWP卡芯片商主要有3家，这3家芯片水平基本相当，但同样应用下载、安装、删除、运行在11家卡商COS的速度卻存在明显差别，如表2所示。

五、java卡的生产控制过程

1.新产品开发

2.新产品研发到发布

由于银检中心的检测只针对功能测试，而不负责互操作性和与终端的兼容性测试。而从图5的流程图也可以看出，由于卡、应用的互操作性问题，致使到“第三方开发的银行应用2”这一步很难做到理想状态，如果再考虑兼容性问题，情况就变得更为复杂，只好谁家的卡谁来开发应用，否则，在产品成熟之前反复去银检中心检测和反复备案将成为常态，极大地加大卡商的研发成本，延长了产品开发周期，使得第三方开发成为噩梦。那么，如何改进流程呢？一个可行的过程就是在卡商去银检中心检测应用前进行把关，以助其提高成功率。

六、增强java卡的互操作性建议

1.加强企业规范制定

加强企业规范制定的前瞻性、国际性、实用性、严谨性、完整性，避免歧义的发生。

（1）综合考虑卡商的相关产品的技术稳定性和版本的先进性，如果稳定性大同小异，版本就高不就低。不到万不得已，不宜轻易升级卡的软件版本。当用户的需求超过了现有标准卡的处理能力，而一些卡商的卡所具备的非标准能力可以实现用户需求时，要综合考虑商业利益和互操作性之间的平衡。

（2）制定科学合理的测试和生产规范，一些灵活的参数，可选项、条件项，不适合在技术规范中明确，要在测试和生产规范中明确，使得每次采购均有相应的生产测试规范支撑对应，以保证至少同批次卡拥有良好的互操作性。

2.增加互测试以增强卡的互操作性和降低检测成本

目前，每一家卡商在去银检中心检测前的一项重要工作就是编写涵盖PBOC规范功能的应用程序，然后下载到自家的卡上，再到银检中心进行认证。

那么是否过了银检中心认证的卡就能彼此可以互操作呢？理论上可以，但银检中心的检测涵盖点也有一个不断完善的过程，而卡的硬件性能、内存管理水平、实现方式、实现效率和对危机的处理经验不同，使得面对编写习惯差异不同的应用时表现不一，甚至会暴露一些隐秘错误甚至程序崩溃。

为了避免第三方检测机构认证后再发现错误而重新进行所有检测流程，建议联通兴业在应用送检前组织卡商进行互测试。首先，规定统一的测试环境、测试条件、测试功能项、测试性能点。然后在测试中发现总结问题，对因歧义和参数定义不明确造成的问题在测试规范和生产规范中进行确定和完善，以规避潜在问题。其次，虽然互测试是组织方为了降低卡商开发成本所作，但卡商的参与度和热情未必高，尤其测试技术相对强大的卡商不愿参加，组织者除了明确第三方应用开发的决心外，还应该在规则制定上有所考虑，那么不参加的卡商不仅会减少一次交流和自我完善的机会，在日后应用和卡片的招投标中也会受到影响。再次，要制定合理的规程，提高测试的有效性、公平性、规范性，避免强者成为弱者的测试人员，比如：规定测试次数，将测试错误多少作为产品优劣的一项指标，作为未来产品采购的一项参考。而对于能够更多的检测出其他卡商产品错误的卡商，在技术支撑方面加分，也一并在招投标中给与考虑。最后，由于送检之前的产品可能故意开有漏洞，使得个别卡商能够无偿拿到别家的应用，可以规定，每家提供的卡样由应用测试者持有，不需要归还。

3.对于第三方应用进行限制和要求

与芯片采购备案一样，第三方应用也需要备案，合同里明确中标者需提供源码，以备将来出现问题时的分析和问责。对第三方应用能力进行评估，实行第三方应用入围，综合考虑以下因素，并将结果在招投标中给于考虑：

（1）应用的功能性；

（2）应用的易用性；

（3）应用与各家卡的兼容性；

（4）应用代码运行速度；

（5）应用代码效率；

（6）第三方应用开发商后期服务水平和态度。

图7 第三方应用开发商入围及应用开发

4.加强产品检测

（1）除对卡片进行基本指令（包括API）测试外还要进行指令组合交叉测试、压力测试，速度性能测试等。

（2）加强与第三方检测机构的合作，如银行卡检测中心和中国信息安全认证中心等权威检测机构的合作，并强化第三方认证测试作用，使其严格遵循标准规范流程。