论文部分内容阅读
摘要：本文从对Java卡进行漏洞分析并尝试对其发起攻击的角度来讨论Java卡的安全性；首先介绍了Java卡的大致系统结构及其一些基本的安全机制原理和其基于Java语言为系统平台所具有的安全属性；阐述了如何收集Java卡上的应用信息和所支持的加密服务，分别讨论Java卡的对象共享机制、类型转换所可能引起的漏洞，描述了针对这些漏洞发起的伪造AID、数据泄漏、非法对象转换的攻击手段，以及通过硬件渠道监测Java卡运行模式和加入包络代码提高监测精确性的做法；最后总结了防止所述攻击可采用的相应做法。
关键词：Java卡；安全性分析；漏洞攻击
中图分类号：TP309文献标识码：A文章编号：1007-9599 (2013) 05-0000-03
1引言
Java卡是由Sun公司基于Java提出的一种可以加载多应用的智能卡。在智能卡的硬件系统基础之上在卡片内通过软件构建的一个支持Java程序下载、安装、运行和卸载的软、硬件系统。它在有限资源的智能卡环境中支持Java语言的一个子集，成为Java嵌入式的一种新应用。Java智能卡充分利用了Java的平台无关性，使得Java技术“一次编写，到处运行”的思想在智能卡上得以实现；另外，Java卡技术解决了以往智能卡只能在发卡前装载应用的问题，允许用户能够在发卡后也能自主的下载和安装应用，提高了智能卡的灵活性并拓展了业务应用的范围。
2Java卡软件架构
Java卡的软件基本系统架构由以下部分组成：底层操作系统（OS）、Java卡虚拟机（JCVM）、Java卡运行时环境（JCRE）、Java卡API和装载的应用[1]（Applet），见图1。其中JCVM负责进行对字节码（Byte code）的翻译和解释；JCRE层承载了卡上所有Applet（应用）和对象之间的通信，担任了对象通信过程中的超级管理员职责；Java卡API是一套供应用开发人员调用的开放API，它使程序员在开发Applet过程中只需关心其功能的实现，与芯片底层硬件相关的各属性分离，可跨平台使用，开发者只需熟练掌握相关编程接口即可[1]。
本文中，我们将分析Java卡的逻辑漏洞和硬件上可攻击的部件，并举例分析对这些漏洞发起攻击的可行性，最后针对这些攻击提出了预防和解决方案。
图1Java卡系统架构
3收集卡上信息
在攻击Java卡之前，可先进行对Java卡上信息的收集工作，其中包括：对卡片支持的加密算法等服务的遍历以及对卡片上已安装的应用信息的统计。对于可开放下载应用的Java卡来说，向卡上装载一个带有恶意代码的应用并运行它，虽然普通的攻击行为会被Java卡拒绝，但通过收集被拒绝或者报错信息，该应用能完成以下所述的工作。
3.1对卡片加密算法的遍历
官方应用（或其他授权应用）只能使用智能卡上存在并支持的加密算法[2]，根据这一特性，恶意代码可以通过对所有Java卡规范上所定义的加密算法进行遍历，记录可使用的加密算法，从而获得卡片支持的加密算法列表，缩小范围，并推测出授权应用可能的合法行为。
3.2已安装应用的统计
完成这项工作可为之后的漏洞攻击做铺垫，恶意应用被裝载到Java卡上后，可以收集卡上其他已装载的应用及其相关信息。
4软件攻击方式
4.1伪造AID
这是一种针对Java卡对象共享机制提出的攻击方式。Java是一种强类型的面向对象程序语言，不同Context之中的对象有防火墙隔离，保护了各对象中的隐私数据[3]（包括对象中的方法、数据域等）。Context是一种对象空间，它与相同包中的对象绑定，也就是说，同一个包里的对象处于一个Context中，一般情况下，一个生成的对象只能被它所在的Context访问，这种机制防止了未授权的访问（需要说明的是，Java卡的运行时环境（JCRE）可以看作是卡上具有特殊权限的一个Context，它能够调用卡上任何其他Context中的对象）。
对象共享机制是Java卡技术中的一种共享接口概念，它实现了不同Context中的对象的相互调用和访问。若对象中有某方法是希望穿过防火墙被共享的，就把定义在共享接口上，当该方法被调用时，在JCRE的控制下切换到其所属Context并激活，通过这样的手段实现不同Context应用间的交互。
举个例子：应用A希望共享某些数据，它就需定义共享接口，该接口继承Java Card framework-Shareable，再定义一个类X来使该接口生效，这样从X类中实例化（instance）出的对象，就是一个共享接口对象（SIO）供被允许访问这些数据的应用访问；当应用B想要调用A的共享数据时，可使用JCSystem.getAppletShareableInterfaceObject方法，把调用请求和B的AID交给JCRE处理，JCRE把该请求送至应用A，待A确认调用请求以及AID合法后，便可实现该请求。
从以上机制我们可以看出，在应用A核实调用请求来源的身份时，基本上仅仅检查了应用B的AID，而没有其他进一步的措施，这意味着可能实现以下行为的攻击：设计一个含有恶意代码的应用，并把其AID设置成某合法应用的AID，当这个恶意应用被装载的卡上后，它就成为一个假冒的“访客”向SIO提出调用数据的请求，而此时应用A无法通过它的AID来识别出此应用的非法行为，造成数据被恶意程序访问。这种攻击方式就是“伪造AID”。
针对这种攻击方式，可在生成SIO对象的前，在X类中多定义若干种身份验证的方法，例如数字签名核对、应用HASH值验证等，这样由该类实例出的SIO具有多重验证方式，能识别出仅仅伪造AID的恶意应用。
4.2数据泄漏
这是一种由通过类型混淆（Type Confusion）可导致的安全问题[4]。Java语言作为一种面向对象的语言，它与C语言定义数组的机制有所不同，在Java卡上，若一个数组被定义后，并不是直接在存储器上开辟若干空间供该数组赋值，而是生成了一个类，当需要对数组进行赋值时，是在EEPROM上对该类进行实例化产生对象的过程，对象包含type、owner、reference等信息以及需要赋值的数据域，并在ROM中存放该对象的地址，所以，当Java卡上的数组被读取时，是通过ROM上的地址找到该对象，然后再读取对象的数据域。基于这种机制，在Java卡上读取数据时，如果找到了一种数据类型的对象，而用读取另一种数据类型对象的方式来读取其数据域，可能会由两种数据类型长度不同，导致数据泄漏。
例如：分别定义一个byte array和一个short array（1 short=2 byte），假设所定义的byte array声明了n个byte，并且其中存在一个short array的reference，然后由此byte array实例化出数据域类型为byte的对象，此时，如果把访问这些对象的指令，也就是读byte array的指令以读short array的指令形式发送，指令找到的仍是这些byte类型的对象，但读1 short等效为读2 byte，这样就读取了n×2 byte，基于这种原理，我们就可以非法读取Java卡存储空间上的数据。
4.3非法强制类型转换
这也是一种可以通过Type Confusion来实现的攻击。在Java卡上对某对象进行类型转换时，JCRE会调用checkcast指令对动态地检测指令中转换前后的两种类型是否兼容（转换是否合法）。本文将介绍Barbu et al.[4]攻击方式，它尝试了通过使用激光改变checkcast指令中的运行时type检测以达到type confusion的目的，从而伪造对象的reference及其他内容。
例如：定义3种不同type的类A（byte）、B（short）和C（继承A类）；此时若把B类的对象b轉换成一个类C的实例化对象c，并且把b.addr设为某特定值，就可以通过对象c.a来更改被参考的地址，正常情况下JCRE会抛出ClassCastException异常来阻止这种非法的类型转换，在运行该应用的过程中，可以通过示波器等特殊工具捕捉到被抛出的异常所产生的波形，在Barbu et al.攻击方式中，精确地捕捉异常被抛出的时刻并在该时刻上进行基于激光的干扰，阻止了checkcast指令的执行，以达到实现非法强制类型转换的目的。当这一非法类型转换完成后，对象c.a和b.addr的reference指向了同一个值，这一漏洞将导致对Java卡数据的非法读写。
4.4硬件攻击
根据Kocher的研究[2]，在不损坏Java卡的前提下通过硬件渠道对卡片进行攻击并获取卡片信息的方式，是监测芯片周围泄漏的物理信号，通过能耗分析或电磁波分析的手段可以确定和识别对Java卡内部操作流程相对应的模式。
主要可被监测或计算的物理信号有：功耗、电磁辐射、指令执行时间。例如，我们可以运行某种加密算法并观察算法执行时卡片所泄漏的物理信号（耗时、功耗、电磁辐射区域等）的特征，掌握这些特征后就可在以后的攻击中反推出卡片所执行何种算法。这种基于特征描述的方法可被用于掌握Java卡上执行特定服务的整个流程或其中某个基本操作。
在进行这种攻击时，对Java卡结构可简化得分为三层：外围物理通信接口（ISO7816协议）层、智能卡操作系统（OS）层、应用层，在物理通信接口层监测整个卡上的活动，需要识别接口上产生的脉冲来推测指令的起止，例如APDU送至卡上及其返回数据的响应，都会经过Java卡通信接口形成脉冲，如下图所示：
图2
显然，这样的观察方式只能监测到该APDU指令所指定服务的整个流程，无法观察其中某个基本操作。
针对流程中某个基本操作的监测，可以通过在所需观察的操作模式代码前后分别人为加入成对的、相同的、涉及到通信层工作的代码，引起接口处产生脉冲（事先熟悉此类脉冲的特征，可被观察作为标志使用），形成包络，精确的定位所需观察的操作模式，原理如下图所示：
图3
经过以上处理，一方面对所需观察模式的定位更加精确，另一方面也减少了所观察的信号量。具体做法可参照以下两个例子。
（1）时延请求包络
根据Java卡通信接口所采用的ISO7816-3协议，允许智能卡向读卡器发送时延请求，告诉读卡器卡片正在工作并需要延长返回数据的时间。在Java卡上，可以通过调用apdu.waitExtension()方法来实现时延请求。以下示例就是以一对时延请求作为包络来定位所需观察的加密模式：
apdu.waitExtension()；//包络：向I/O请求时延
cipherLength=cipher.doFinal(clearData，(short)0，
clearData.length，
cipherData，(short)0)；
apdu.waitExtension()；//包络：再次向I/O请求时延
当两次运行至apdu.waitExtension()方法时会触发卡片通信接口的脉冲，观察者可根据这一成对脉冲信号定位所观察的加密模式。
（2）伪造响应数据
另一种包络方式是调用标准的卡片通信方式，但改变卡片返回数据的发送方式来形成包络。多数情况下，读卡器与Java卡的通信模式是在执行完一条指令后一次性返回所有响应数据，但我们可以通过人为的伪造两次响应数据作为所观察模式的包络。
5结论
本文以讨论Java卡攻击手段可行性的角度来分析了Java卡安全性，介绍了若干种Java卡攻击方式，逻辑上的伪造AID、强制类型转换、数据泄漏方式以及硬件上的监测电磁信号泄漏方式，同时分析了应对这些攻击的保护措施；在Java卡开发过程中，针对伪造AID攻击，可以在使用共享对象机制的应用中添加访问者身份核实的方法，或者通过彻底禁用对象共享接口的做法保证Java卡安全性，并加强硬件外设的保护来防止攻击者从硬件上监测Java卡的运行模式。
Java卡系统架构相对复杂，本文中只能针对其一部分进行分析，不能面面俱到，加上Java卡作为智能卡市场未来的发展趋势，卡片网络化等可能的发展方向将对Java卡安全系统提出更高的要求。
参考文献：
[1]Yuchuan Wu,Yaqin Sun.Analysis and Research of Securing from Attack for Java Card International Conference on E-Business and E-Government,2010.
[2]Serge Chaumette,Damien Sauveron.An efficient and simple way to test the security of Java Cards.LaBri Laboratoire Bordelais de Recherche en Informatique
[3]王明飞.Java智能卡的安全性[J].电脑知识与技术,2011,8.
[4]Guillaume Bouffard,Julien Iguchi-Cartigny,Jean-Louis Lanet.Combined Software and Hardware Attacks on the Java Card Control Flow.Smart Secure Devices Team–XLIM Labs,Université de Limoges.
[5]Jean-Louis Lanet.Attacks against Smart Cards：Hands On Session.International Conference on Risks and Security of Internet and Systems,2012,7th
[作者简介]孙立元（1988-），男，上海，东华大学信息科学与技术学院电子通信工程专业，在读硕士研究生，主要研究方向为Java智能卡安全性分析。
关键词：Java卡；安全性分析；漏洞攻击
中图分类号：TP309文献标识码：A文章编号：1007-9599 (2013) 05-0000-03
1引言
Java卡是由Sun公司基于Java提出的一种可以加载多应用的智能卡。在智能卡的硬件系统基础之上在卡片内通过软件构建的一个支持Java程序下载、安装、运行和卸载的软、硬件系统。它在有限资源的智能卡环境中支持Java语言的一个子集，成为Java嵌入式的一种新应用。Java智能卡充分利用了Java的平台无关性，使得Java技术“一次编写，到处运行”的思想在智能卡上得以实现；另外，Java卡技术解决了以往智能卡只能在发卡前装载应用的问题，允许用户能够在发卡后也能自主的下载和安装应用，提高了智能卡的灵活性并拓展了业务应用的范围。
2Java卡软件架构
Java卡的软件基本系统架构由以下部分组成：底层操作系统（OS）、Java卡虚拟机（JCVM）、Java卡运行时环境（JCRE）、Java卡API和装载的应用[1]（Applet），见图1。其中JCVM负责进行对字节码（Byte code）的翻译和解释；JCRE层承载了卡上所有Applet（应用）和对象之间的通信，担任了对象通信过程中的超级管理员职责；Java卡API是一套供应用开发人员调用的开放API，它使程序员在开发Applet过程中只需关心其功能的实现，与芯片底层硬件相关的各属性分离，可跨平台使用，开发者只需熟练掌握相关编程接口即可[1]。
本文中，我们将分析Java卡的逻辑漏洞和硬件上可攻击的部件，并举例分析对这些漏洞发起攻击的可行性，最后针对这些攻击提出了预防和解决方案。
图1Java卡系统架构
3收集卡上信息
在攻击Java卡之前，可先进行对Java卡上信息的收集工作，其中包括：对卡片支持的加密算法等服务的遍历以及对卡片上已安装的应用信息的统计。对于可开放下载应用的Java卡来说，向卡上装载一个带有恶意代码的应用并运行它，虽然普通的攻击行为会被Java卡拒绝，但通过收集被拒绝或者报错信息，该应用能完成以下所述的工作。
3.1对卡片加密算法的遍历
官方应用（或其他授权应用）只能使用智能卡上存在并支持的加密算法[2]，根据这一特性，恶意代码可以通过对所有Java卡规范上所定义的加密算法进行遍历，记录可使用的加密算法，从而获得卡片支持的加密算法列表，缩小范围，并推测出授权应用可能的合法行为。
3.2已安装应用的统计
完成这项工作可为之后的漏洞攻击做铺垫，恶意应用被裝载到Java卡上后，可以收集卡上其他已装载的应用及其相关信息。
4软件攻击方式
4.1伪造AID
这是一种针对Java卡对象共享机制提出的攻击方式。Java是一种强类型的面向对象程序语言，不同Context之中的对象有防火墙隔离，保护了各对象中的隐私数据[3]（包括对象中的方法、数据域等）。Context是一种对象空间，它与相同包中的对象绑定，也就是说，同一个包里的对象处于一个Context中，一般情况下，一个生成的对象只能被它所在的Context访问，这种机制防止了未授权的访问（需要说明的是，Java卡的运行时环境（JCRE）可以看作是卡上具有特殊权限的一个Context，它能够调用卡上任何其他Context中的对象）。
对象共享机制是Java卡技术中的一种共享接口概念，它实现了不同Context中的对象的相互调用和访问。若对象中有某方法是希望穿过防火墙被共享的，就把定义在共享接口上，当该方法被调用时，在JCRE的控制下切换到其所属Context并激活，通过这样的手段实现不同Context应用间的交互。
举个例子：应用A希望共享某些数据，它就需定义共享接口，该接口继承Java Card framework-Shareable，再定义一个类X来使该接口生效，这样从X类中实例化（instance）出的对象，就是一个共享接口对象（SIO）供被允许访问这些数据的应用访问；当应用B想要调用A的共享数据时，可使用JCSystem.getAppletShareableInterfaceObject方法，把调用请求和B的AID交给JCRE处理，JCRE把该请求送至应用A，待A确认调用请求以及AID合法后，便可实现该请求。
从以上机制我们可以看出，在应用A核实调用请求来源的身份时，基本上仅仅检查了应用B的AID，而没有其他进一步的措施，这意味着可能实现以下行为的攻击：设计一个含有恶意代码的应用，并把其AID设置成某合法应用的AID，当这个恶意应用被装载的卡上后，它就成为一个假冒的“访客”向SIO提出调用数据的请求，而此时应用A无法通过它的AID来识别出此应用的非法行为，造成数据被恶意程序访问。这种攻击方式就是“伪造AID”。
针对这种攻击方式，可在生成SIO对象的前，在X类中多定义若干种身份验证的方法，例如数字签名核对、应用HASH值验证等，这样由该类实例出的SIO具有多重验证方式，能识别出仅仅伪造AID的恶意应用。
4.2数据泄漏
这是一种由通过类型混淆（Type Confusion）可导致的安全问题[4]。Java语言作为一种面向对象的语言，它与C语言定义数组的机制有所不同，在Java卡上，若一个数组被定义后，并不是直接在存储器上开辟若干空间供该数组赋值，而是生成了一个类，当需要对数组进行赋值时，是在EEPROM上对该类进行实例化产生对象的过程，对象包含type、owner、reference等信息以及需要赋值的数据域，并在ROM中存放该对象的地址，所以，当Java卡上的数组被读取时，是通过ROM上的地址找到该对象，然后再读取对象的数据域。基于这种机制，在Java卡上读取数据时，如果找到了一种数据类型的对象，而用读取另一种数据类型对象的方式来读取其数据域，可能会由两种数据类型长度不同，导致数据泄漏。
例如：分别定义一个byte array和一个short array（1 short=2 byte），假设所定义的byte array声明了n个byte，并且其中存在一个short array的reference，然后由此byte array实例化出数据域类型为byte的对象，此时，如果把访问这些对象的指令，也就是读byte array的指令以读short array的指令形式发送，指令找到的仍是这些byte类型的对象，但读1 short等效为读2 byte，这样就读取了n×2 byte，基于这种原理，我们就可以非法读取Java卡存储空间上的数据。
4.3非法强制类型转换
这也是一种可以通过Type Confusion来实现的攻击。在Java卡上对某对象进行类型转换时，JCRE会调用checkcast指令对动态地检测指令中转换前后的两种类型是否兼容（转换是否合法）。本文将介绍Barbu et al.[4]攻击方式，它尝试了通过使用激光改变checkcast指令中的运行时type检测以达到type confusion的目的，从而伪造对象的reference及其他内容。
例如：定义3种不同type的类A（byte）、B（short）和C（继承A类）；此时若把B类的对象b轉换成一个类C的实例化对象c，并且把b.addr设为某特定值，就可以通过对象c.a来更改被参考的地址，正常情况下JCRE会抛出ClassCastException异常来阻止这种非法的类型转换，在运行该应用的过程中，可以通过示波器等特殊工具捕捉到被抛出的异常所产生的波形，在Barbu et al.攻击方式中，精确地捕捉异常被抛出的时刻并在该时刻上进行基于激光的干扰，阻止了checkcast指令的执行，以达到实现非法强制类型转换的目的。当这一非法类型转换完成后，对象c.a和b.addr的reference指向了同一个值，这一漏洞将导致对Java卡数据的非法读写。
4.4硬件攻击
根据Kocher的研究[2]，在不损坏Java卡的前提下通过硬件渠道对卡片进行攻击并获取卡片信息的方式，是监测芯片周围泄漏的物理信号，通过能耗分析或电磁波分析的手段可以确定和识别对Java卡内部操作流程相对应的模式。
主要可被监测或计算的物理信号有：功耗、电磁辐射、指令执行时间。例如，我们可以运行某种加密算法并观察算法执行时卡片所泄漏的物理信号（耗时、功耗、电磁辐射区域等）的特征，掌握这些特征后就可在以后的攻击中反推出卡片所执行何种算法。这种基于特征描述的方法可被用于掌握Java卡上执行特定服务的整个流程或其中某个基本操作。
在进行这种攻击时，对Java卡结构可简化得分为三层：外围物理通信接口（ISO7816协议）层、智能卡操作系统（OS）层、应用层，在物理通信接口层监测整个卡上的活动，需要识别接口上产生的脉冲来推测指令的起止，例如APDU送至卡上及其返回数据的响应，都会经过Java卡通信接口形成脉冲，如下图所示：
图2
显然，这样的观察方式只能监测到该APDU指令所指定服务的整个流程，无法观察其中某个基本操作。
针对流程中某个基本操作的监测，可以通过在所需观察的操作模式代码前后分别人为加入成对的、相同的、涉及到通信层工作的代码，引起接口处产生脉冲（事先熟悉此类脉冲的特征，可被观察作为标志使用），形成包络，精确的定位所需观察的操作模式，原理如下图所示：
图3
经过以上处理，一方面对所需观察模式的定位更加精确，另一方面也减少了所观察的信号量。具体做法可参照以下两个例子。
（1）时延请求包络
根据Java卡通信接口所采用的ISO7816-3协议，允许智能卡向读卡器发送时延请求，告诉读卡器卡片正在工作并需要延长返回数据的时间。在Java卡上，可以通过调用apdu.waitExtension()方法来实现时延请求。以下示例就是以一对时延请求作为包络来定位所需观察的加密模式：
apdu.waitExtension()；//包络：向I/O请求时延
cipherLength=cipher.doFinal(clearData，(short)0，
clearData.length，
cipherData，(short)0)；
apdu.waitExtension()；//包络：再次向I/O请求时延
当两次运行至apdu.waitExtension()方法时会触发卡片通信接口的脉冲，观察者可根据这一成对脉冲信号定位所观察的加密模式。
（2）伪造响应数据
另一种包络方式是调用标准的卡片通信方式，但改变卡片返回数据的发送方式来形成包络。多数情况下，读卡器与Java卡的通信模式是在执行完一条指令后一次性返回所有响应数据，但我们可以通过人为的伪造两次响应数据作为所观察模式的包络。
5结论
本文以讨论Java卡攻击手段可行性的角度来分析了Java卡安全性，介绍了若干种Java卡攻击方式，逻辑上的伪造AID、强制类型转换、数据泄漏方式以及硬件上的监测电磁信号泄漏方式，同时分析了应对这些攻击的保护措施；在Java卡开发过程中，针对伪造AID攻击，可以在使用共享对象机制的应用中添加访问者身份核实的方法，或者通过彻底禁用对象共享接口的做法保证Java卡安全性，并加强硬件外设的保护来防止攻击者从硬件上监测Java卡的运行模式。
Java卡系统架构相对复杂，本文中只能针对其一部分进行分析，不能面面俱到，加上Java卡作为智能卡市场未来的发展趋势，卡片网络化等可能的发展方向将对Java卡安全系统提出更高的要求。
参考文献：
[1]Yuchuan Wu,Yaqin Sun.Analysis and Research of Securing from Attack for Java Card International Conference on E-Business and E-Government,2010.
[2]Serge Chaumette,Damien Sauveron.An efficient and simple way to test the security of Java Cards.LaBri Laboratoire Bordelais de Recherche en Informatique
[3]王明飞.Java智能卡的安全性[J].电脑知识与技术,2011,8.
[4]Guillaume Bouffard,Julien Iguchi-Cartigny,Jean-Louis Lanet.Combined Software and Hardware Attacks on the Java Card Control Flow.Smart Secure Devices Team–XLIM Labs,Université de Limoges.
[5]Jean-Louis Lanet.Attacks against Smart Cards：Hands On Session.International Conference on Risks and Security of Internet and Systems,2012,7th
[作者简介]孙立元（1988-），男，上海，东华大学信息科学与技术学院电子通信工程专业，在读硕士研究生，主要研究方向为Java智能卡安全性分析。