java卡互操作性研究白

提高JAVA卡互操作性的研究联通兴业通信技术有限公司王俊清郭娜【摘要】：目前栖息于JAVAUSIM卡上的应用主要分三大类：银行类、公交类、校企类。本文主要以银行类应用为例，分析目前联通java卡的互操作性现状，并提出了改进互操作性的建议，为实现第三方应用开发作好技术准备。【关键词】：UICC、USIM、SWP、PBOC、JAVA、互操作性一、背景：联通金融USIM卡是符合3GPP相关规范和GP规范的含有USIM应用和PBOC应用的有SWP功能的JAVA卡。主要遵循七部分规范：UICC规范、USIM规范、JAVA卡规范、GP规范、SWP卡规范、HCI规范和PBOC3.0规范。理论上讲，联通金融USIM卡据有良好的安全性和互操作性，可以采用预置和后期两种方式加载。然而，现实中其互操作性很差。本文建立在联通11家供卡商的卡与4家应用的实际互测试基础上，分析了引起互操作性的因素，对未来实现第三方应用开发提供了有价值的参考。二、联通JAVAUSIM卡架构简介：联通JAVAUSIM卡架构图如下：图1、电信JAVAUSIM卡架构图（FromObethur）由上图看出，电信JAVA卡的电信应用在靠近底层实现，运行速度和效率较高，其他Applet开发不需改动COS，直接利用JAVA的API开发。三、理想的JAVA卡应用编写状态如果运营商采购的java卡遵循的各规范版本一致,各家卡商开发的PBOC检测用应用经过了银检中心的检测,那么上层的给各家银行编写的应用理论上应该可以由第三方统一开发。图2.理想的JAVA卡应用编写状态示意图四、实际的JAVA卡应用编写现状联通java卡互操作性较差，一个应用，如果采用m家卡商的卡需要m家根据各自的卡编写m个应用程序，编程、测试及管理维护的使用效率大大降低，项目开展速度缓慢，无法实现第三方应用编程和统一管理,联通JAVA卡应用编写现状示意图见图3。图3.实际的JAVA卡应用编写现状图3.JAVA卡应用编写现状示意图最近，联通兴业组织了一次4家应用开发商的应用在11家联通供卡商的卡上进行的兼容性测试，结果如下：表1.卡1卡2卡3卡4卡5卡6卡7卡8卡9卡10应用1VVXVXXVVXV应用2VVVVVVXXVX应用3XVXXXVXXXX应用4VVXVXXXXXX注：V：通过，X：未通过。本次测试由于时间问题准备的较为仓促，测试设备和测试项没有事先统一规定，有的应用商测试项较多，覆盖面较广，有的检测却相对简单。另外，有的测试使用手机终端进行，运营商卡商1USIM卡卡商2USIM卡卡商mUSIM卡银行1应用银行n应用银行2应用…….银行1应用银行n应用银行2应用…….银行1应用银行n应用银行2应用…….运营商卡商1USIM卡卡商2USIM卡卡商3USIM卡银行1应用银行2应用…….银行n应用第三方应用开发商卡商1卡商2卡商m…….有的使用非接读卡器进行，因此，本次测试只具有参考价值。通过4家应用测试的卡未必是没有问题的,本次在其他家卡上兼容性表现不好的应用也未必是不好的应用。虽然只是一个不全面的测试，也已经发现了严重的兼容性问题：卡与应用的兼容性问题，卡和应用与终端的兼容性问题。此次兼容性问题可基本排除“规范版本众多，彼此不统一”和“使用私有指令”等因素。本文只讨论分析本次测试同一个金融应用不能在各家卡上兼容的原因：1)PBOC规范中一些参数的设定很灵活，没有相应的生产规范进行明确，致使各家定义不同；2)各家对规范理解存在一定差异，而测试又没有全覆盖；3)各家对规范中可选项的处理存在差异；4)COS内存管理水平的优劣差别致使程序健壮性不同；5)程序指令优先顺序和占用的资源状况影响卡与应用的适配性；6)硬件性能差异造成应用程序兼容性差：由于芯片内存大小、CPU运算速度差异、协处理器存在与否等造成了同样的JAVA卡应用程序在性能差的芯片上难以正常运行；7)应用编程水平和卡与应用的适配性对兼容性存在影响，同款芯片同样COS的卡，运行同样功能的不同应用，速度差距也较大。8)COS编程人员的经验与处理能力存在差异：目前联通的SWP卡芯片商主要有3家，这3家芯片水平基本相当，但同样应用下载、安装、删除、运行在11家卡商COS的速度却存在明显差别，见下表：表2（武汉天喻信息产业股份有限公司提供,单位:毫秒）下载cap1下载cap2实例化cap2应用安装全流程个人化删除cap2删除cap1应用删除全流程（cap1+cap2）总的交易时间(SDI)卡商139577436818945460494057294231152314.91卡商2594526755145183157452211174021519386.45卡商33541239461241614645504577284861卡商4430405195364958505408515295562085卡商55313447423528950167377518268786卡商6401704992304053985056012133771590380.27卡商75251063343621705265896264310673710卡商8383455397183070355077726674043071405.99五、java卡的生产控制过程1、新产品开发图4.新产品开发2、新产品研发到发布在通过EAL4+的硬件芯片上开发产品卡商通过TCK测试的USIM卡新产品研发立项规范制定新产品研发到发布图6.新产品研发到发布由于银检中心的检测只针对功能测试，而不负责互操作性和与终端的兼容性测试。而从图6的流程图也可以看出，由于卡、应用的互操作性问题，致使到“第三方开发的银行应用2”这一步很难做到理想状态，如果再考虑兼容性问题，情况就变得更为复杂，只好谁家的卡谁来开发应用，否则，在产品成熟之前反复去银检中心检测和反复备案将成为常态，极大地加大卡商的研发成本，延长了产品开发周期，使得第三方开发成为噩梦。那么，如何改进流程呢？一个可行的过程就是在卡商去银检中心检测应用前进行把关，以助其提高成功率。六、增强java卡的互操作性建议1、加强企业规范制定加强企业规范制定的前瞻性、国际性、实用性、严谨性、完整性，避免歧义的发生。1)综合考虑卡商的相关产品的技术稳定性和版本的先进性，如果稳定性大同小异，版本就高不就低。不到万不得已，不宜轻易升级卡的软件版本。当用户的需求超过了现有标准卡的处理能力，而一些卡商的卡所具备的非标准能力可以实现用户需求时，要综合考虑商业利益和互操作性之间的平衡。2)制定科学合理的测试和生产规范，一些灵活的参数，可选项、条件项，不适合在技术规范中明确，要在测试和生产规范中明确，使得每次采购均有相应的生产测试规范支撑对应，以保证至少同批次卡拥有良好的互操作性。2、增加互测试以增强卡的互操作性和降低检测成本目前，每一家卡商在去银检中心检测前的一项重要工作就是编写涵盖PBOC规范功能的下载下载下载第三方开发的PBOC测试应用1（见图7）卡商1USIM卡片卡商3USIM卡片银检中心预测试PBOC正式测试符合PBOC规范的证书通过GP测试合格厂商入围，相关产品备案第三方开发的银行应用2（见图7）卡商1USIM卡片卡商1USIM卡片卡商1USIM卡片卡商2USIM卡片应用程序，然后下载到自家的卡上，再到银检中心进行认证。那么是否过了银检中心认证的卡就能彼此可以互操作呢？理论上可以，但银检中心的检测涵盖点也有一个不断完善的过程，而卡的硬件性能、内存管理水平、实现方式、实现效率和对危机的处理经验不同，使得面对编写习惯差异不同的应用时表现不一，甚至会暴露一些隐秘错误甚至程序崩溃。为了避免第三方检测机构认证后再发现错误而重新进行所有检测流程，建议联通兴业在应用送检前组织卡商进行互测试。首先，规定统一的测试环境、测试条件、测试功能项、测试性能点。然后在测试中发现总结问题，对因歧义和参数定义不明确造成的问题在测试规范和生产规范中进行确定和完善，以规避潜在问题。其次，虽然互测试是组织方为了降低卡商开发成本所作，但卡商的参与度和热情未必高，尤其测试技术相对强大的卡商不愿参加，组织者除了明确第三方应用开发的决心外,还应该在规则制定上有所考虑，那么不参加的卡商不仅会减少一次交流和自我完善的机会，在日后应用和卡片的招投标中也会受到影响。再次，要制定合理的规程，提高测试的有效性、公平性、规范性，避免强者成为弱者的测试人员，比如：规定测试次数，将测试错误多少作为产品优劣的一项指标，作为未来产品采购的一项参考。而对于能够更多的检测出其他卡商产品错误的卡商，在技术支撑方面加分，也一并在招投标中给与考虑。最后，由于送检之前的产品可能故意开有漏洞，使得个别卡商能够无偿拿到别家的应用，可以规定，每家提供的卡样由应用测试者持有，不需要归还。3、对于第三方应用进行限制和要求与芯片采购备案一样，第三方应用也需要备案，合同里明确中标者需提供源码，以备将来出现问题时的分析和问责。对第三方应用能力进行评估，实行第三方应用入围，综合考虑以下因素，并将结果在招投标中给于考虑：1)应用的功能性；2)应用的易用性；3)应用与各家卡的兼容性；4)应用代码运行速度；5)应用代码效率；6)第三方应用开发商后期服务水平和态度。图7.第三方应用开发商入围及应用开发4、加强产品检测第三方应用开发商入围启动使用规范定义函数编写第三方应用第三方应用备案测试第三方应用在各家卡的运行情况1)除对卡片进行基本指令（包括API）测试外还要进行指令组合交叉测试、压力测试，速度性能测试等。2)加强与第三方检测机构的合作，如银行卡检测中心和中国信息安全认证中心等权威检测机构的合作，并强化第三方认证测试作用，使其严格遵循标准规范流程。5、加强管理1)建立通用开放、版本可管可控的智能卡平台。2)为保证卡商提交给银行卡检测中心的卡和最终提交给联通的卡为相同的卡，并且避免由于加载项增多后造成的问题，联通应计算和保留卡商送检COS代码的哈西值。3)同一批次卡（即符合联通相同版本规范的卡）的复位应答ATR历史字节中要有联通规定的统一的批次号。以便今后的统一管理。七、作者简介王俊清，高级工程师，主要从事智能卡COS及应用开发工作；郭娜，工程师，主要从事智能卡应用开发工作。八、引用[1]JR/T0025《中国金融集成电路（IC）卡规范》（系列规范）[2]《中国联通电信智能卡SWP卡技术规范v2.0》[3]JavaCard(TM)Specification.[4]GlobalPlatformCardSpecification.[5]《金融USIM卡多应用加载的安全性和互操作性研究》（《电子世界》2012年10月期）[6]欧贝特“UICC/USIM简介”薃肀莂蒃袂肀肂虿袈聿芄薂螄肈莇螇蚀肇葿薀罿肆腿莃袅肅芁薈螁膄莃莁蚇膄肃薇薃膃芅荿羁膂莈蚅袇膁蒀蒈螃膀膀蚃虿腿节蒆羈芈莄蚁袄芈蒆蒄螀芇膆蚀蚆袃莈蒃蚂袂蒁螈羀袁膀薁袆袁芃螆螂袀莅蕿蚈衿蒇莂羇羈膇薇袃羇艿莀蝿羆蒂薆螅羅膁蒈蚁羅芄蚄罿羄莆蒇袅羃蒈蚂螁羂膈蒅蚇肁芀蚁薃肀莂蒃袂肀肂虿袈聿芄薂螄肈莇螇蚀肇葿薀罿肆腿莃袅肅芁薈螁膄莃莁蚇膄肃薇薃膃芅荿羁膂莈蚅袇膁蒀蒈螃膀膀蚃虿腿节蒆羈芈莄蚁袄芈蒆蒄螀芇膆蚀蚆袃莈蒃蚂袂蒁螈羀袁膀薁袆袁芃螆螂袀莅蕿蚈衿蒇莂羇羈膇薇袃羇艿莀蝿羆蒂薆螅羅膁蒈蚁羅芄蚄罿羄莆蒇袅羃蒈蚂螁羂膈蒅蚇肁芀蚁薃肀莂蒃袂肀肂虿袈聿芄薂螄肈莇螇蚀肇葿薀罿肆腿莃袅肅芁薈螁膄莃莁蚇膄肃薇薃膃芅荿螀羀膆蒃蚆肀芈芆薂聿羈蒂蒈肈肀芅袆肇芃薀螂肆莅莃蚈肅肅薈薄蚂膇莁蒀蚁艿薇蝿螀罿荿蚅蝿肁薅薁螈膄莈薇螈莆膀袆螇肆蒆螁螆膈艿蚇螅芀蒄薃螄羀芇葿袃肂蒃螈袂膄芅蚄袂芇蒁蚀袁肆芄薆袀腿蕿蒂衿芁莂螁袈羁薇蚇袇肃莀薃羆膅薆葿羆芈荿螇羅羇膁螃羄膀莇虿羃节芀薅羂羂蒅蒁羁肄芈螀羀膆蒃蚆肀芈芆薂聿羈蒂蒈肈肀芅袆肇芃薀螂肆莅莃蚈肅肅薈薄蚂膇莁蒀蚁艿薇蝿螀罿荿蚅蝿肁薅薁螈膄莈薇螈莆膀袆螇肆蒆螁螆膈艿蚇螅芀蒄薃螄羀芇葿袃肂蒃螈袂膄芅蚄袂芇蒁蚀袁肆芄薆袀腿蕿蒂衿芁莂螁袈羁薇蚇袇肃莀薃羆膅薆葿羆芈荿螇羅羇膁螃羄膀莇虿羃节芀薅羂羂蒅蒁羁肄芈螀羀膆蒃蚆肀芈芆薂聿羈蒂蒈肈肀芅袆肇芃薀螂肆莅莃蚈肅肅薈薄蚂膇莁