CN110008134A - 一种Java卡标准API安全性测试方法 - Google Patents

Abstract

本发明公开一种Java卡标准API安全性测试方法。该测试包括：针对待测试的API，获取编写的测试Applet；对所述测试Applet的Cap文件进行修改；将修改后的Cap文件下载到Java卡中；试图获取所述Java卡的有效信息从而根据获取结果确定Java卡标准API的安全性。本发明的Java卡标准API安全性测试方法，通过对标准API的入参对象的合法性进行校验，全面检测Java卡标准API可能存在的漏洞。

Description

一种Java卡标准API安全性测试方法

技术领域

本发明涉及Java软件平台测试领域，特别是涉及一种Java卡标准API安全性测试方法。

背景技术

Java卡将标准应用程序编程接口(Application Programming Interface，API)的定义引入了嵌入式开发，这带来了平台和应用开发的分离，使得Java卡软件平台更为通用与开放，开发应用更为便利。但是，这样的通用与开放也带来了一定的隐患，攻击者可通过使用标准API来编写自己的Java编程语言的小应用程序(Applet)并下载到智能卡中的方式，尝试非法获取当前卡中其他Applet的信息。特别是当智能卡中有金融应用时，金融应用在卡中存储的持卡人验证方法(Cardholder Verification Method，CVM)信息(例如：PIN值)、签名用私钥信息等都存在被非法获取的风险，这就使得Java卡标准API的安全性显得尤为重要。

目前对于Java卡标准API的测试主要集中在对各个API接口的功能测试上，最常用也是行业通用的是Oracle公司的TCK(JavaCardTM Technology Compatibility Kit)测试套件。但是，若只仅仅通过TCK的功能测试，是不足以防范未来多应用智能卡可能受到的安全攻击的。

发明内容

本发明的目的是提供一种Java卡标准API安全性测试方法，通过对标准API的入参对象的合法性进行校验，全面检测Java卡标准API可能存在的漏洞。

一种Java卡标准API安全性测试方法，包括：

针对待测试的API，获取编写的测试Applet；

对所述测试Applet的Cap文件进行修改；

将修改后的Cap文件下载到Java卡中；

试图获取所述Java卡的有效信息从而根据获取结果确定Java卡标准API的安全性。

可选的，所述待测试的API为带有入参的API。

可选的，所述测试Applet的编写方法为：

定义一个全局static对象并初始化；

编写以所述全局static对象作为入参的调用所述待测试的API的语句；

对所述语句进行编译，得到编译结果；

若所述编译结果表示编译失败，则返回步骤“编写以所述全局static对象作为入参的调用所述待测试的API的语句”；

若所述编译结果表示编译成功，则生成Cap文件。

可选的，所述对所述测试Applet的Cap文件进行修改，具体包括：

对所述Cap文件进行解析，得到解析出的12个组件；所述12个组件包括：Header组件、Directory组件、Applet组件、Import组件、Constant pool组件、Reference Location组件、Export组件、Debug组件、Class组件、Method组件、StaticField组件和Descriptor组件；

修改所述Method组件；

修改所述Reference Location组件。

可选的，所述修改所述Method组件，具体包括：

将所述全局static对象对应的Java卡虚拟机指令修改为Java卡虚拟机压栈指令；

将所述全局static对象对应的索引依次修改为0到最大索引值之间的值，得到多个索引。

可选的，所述修改所述Reference Location组件，具体包括：

删除与所述Method组件中的所述全局static对象对应的索引偏移。

可选的，所述将修改后的Cap文件下载到Java卡中，具体包括：

将每个索引所对应的Cap文件依次下载到所述Java卡中。

可选的，所述试图获取所述Java卡的有效信息从而根据获取结果确定Java卡标准API的安全性，具体包括：

在任意一个索引所对应的Cap文件下载到所述Java卡中之后，通过APDU指令运行所述待测试的API，得到运行结果；

若所述运行结果表示有数据读出，则记录当前Cap文件对应的索引值和读出的数据并将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读出且引起死卡，则记录当前Cap文件对应的索引值，并将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读取且未引起死卡，则将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读取且所述Java卡无响应，则将下载到所述Java卡中的Cap文件删除；

根据记录的索引值和读出的数据确定安全性能。

根据本发明提供的具体实施例，本发明公开了以下技术效果：本发明所公开的一种Java卡标准API安全性测试方法，通过对标准API的入参对象的合法性进行校验，全面检测Java卡标准API可能存在的漏洞。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例的Java卡标准API安全性测试方法的方法流程图；

图2为本发明的具体实施例的方法流程图；

图3为本发明的具体实施例中编写测试用Applet的程序代码图；

图4为本发明的具体实施例中对Method组件进行修改的程序代码图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1为本发明实施例的Java卡标准API安全性测试方法的方法流程图。

参见图1，该Java卡标准API安全性测试方法主要是对带入参的Java卡标准API的入参对象的合法性进行安全性检测，包括：

步骤101：针对待测试的API，获取编写的测试Applet；所述待测试的API为带有入参的API。

所述测试Applet的编写方法为：

定义一个全局static对象(Object)并初始化；全局static对象在内存中只有一个副本，被其他对象所共享，不会在测试中过多占用EEPROM空间，并且作用域只限于本文件，在同一工程中的其他源文件不能使用它。

编写以所述全局static对象作为入参的调用所述待测试的API的语句；

对所述语句进行编译，得到编译结果；

若所述编译结果表示编译失败，则返回步骤“编写以所述全局static对象作为入参的调用所述待测试的API的语句”；

若所述编译结果表示编译成功，则生成Cap文件。

步骤102：对所述测试Applet的Cap文件进行修改。通过修改测试Applet的Cap文件的方式，将修改后的Cap文件下载到智能卡中。

步骤102具体包括：

对所述Cap文件进行解析，得到解析出的12个组件；所述12个组件包括：Header组件、Directory组件、Applet组件、Import组件、Constant pool组件、Reference Location组件、Export组件、Debug组件、Class组件、Method组件、StaticField组件和Descriptor组件；

在Bytecode层面对Method组件进行修改：将所述全局static对象对应的Java卡虚拟机指令修改为Java卡虚拟机压栈指令；将所述全局static对象对应的索引依次修改为0到最大索引值之间的值，得到多个索引。

修改所述Reference Location组件：删除与所述Method组件中的所述全局static对象对应的索引偏移，使得下载修改后的测试Applet的Cap文件到Java卡上时，使用到的是本次修改的索引值，而不会由于Reference Location组件的指示，修改为Constant pool组件中的对应值。

步骤103：将修改后的Cap文件下载到Java卡中。每一个索引值都对应生成一个修改后的测试Applet的Cap文件，将这些Cap文件逐一下载到智能卡中并实例化。

步骤103具体包括：

将每个索引所对应的Cap文件依次下载到所述Java卡中。

步骤104：试图获取所述Java卡的有效信息从而根据获取结果确定Java卡标准API的安全性。

步骤104具体包括：

在任意一个索引所对应的Cap文件下载到所述Java卡中之后，通过APDU指令运行所述待测试的API，得到运行结果；

若所述运行结果表示有数据读出，则保存log并将下载到所述Java卡中的Cap文件删除；log内容包括索引值以及读出的数据值；

若所述运行结果表示无数据读出且引起死卡，则保存log并将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读取且未引起死卡，则将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读取且所述Java卡无响应，则将下载到所述Java卡中的Cap文件删除；

根据log(记录的索引值和读出的数据值)确定安全性能。安全性能的具体分析方法为：

预期的测试结果有以下五种：

a.索引值所对应的EEPROM区域正好为全局的static对象所在区域，读出的数据为全局的static对象。

b.索引值所对应的EEPROM区域为公共区域，读出的数据公共区域值。

c.索引值所对应的EEPROM区域为非公共区域，但读出了数据。

d.无数据可被读出。

e.引起了死卡。死卡表示Java卡无法上电。

结合预期的测试结果，对log进行分析：

若对log的分析表明，实际的测试结果为预期结果a，则处理方式正确，安全性能良好。

若对log的分析表明，实际的测试结果为预期结果b，则处理方式正确，安全性能良好。

若对log的分析表明，实际的测试结果为预期结果c，则不论读出什么样的数据，即便是全0，也认为是可继续攻击并可获得有用数据的成功攻击，即未通过对入参对象的合法性检查，处理方式错误，存在安全隐患。

若实际的测试结果为预期结果d，则处理方式正确，安全性能良好。

若对log的分析表明，实际的测试结果为预期结果e，则需要进一步确定处理方式的合理性，大部分情况下，可能是由于被测方法涉及到写EEPROM操作，修改到了配置区的数据。

下面以Java卡标准API中的APDU类中的sendBytesLong()方法为例，对本实施例的安全性测试方法做进一步说明。

图2为本发明的具体实施例的方法流程图。

参见图2，该具体实施例的方法包括以下步骤：

(1)编写测试用Applet，参见图3：

第10行：定义一个全局的static的byte数组mulbuf；

第29行至第36行：对mulbuf数组进行初始化；

第42行：编写一条正常调用sendBytesLong()方法的语句，mulbuf数组为入参的第一个参数，源文件编译成功，生成Cap文件；

第25行：定义当接收到的APUD指令的INS值为0x00时，执行sendBytesLong()方法。

(2)对测试Applet的Cap文件进行解析，即解析出12个组件，解析工具可使用capdump。

(3)修改Method组件，参见图4：

mulbuf数组对应的Bytecode值为7b 00 02(十六进制)；

7b：代表JCVM指令getstatic_a，此处为获取mulbuf数组的静态域；将7b修改为11(十六进制)。11代表JCVM指令sspush，表示对short类型的数据进行压栈操作；

0002：代表Method组件中mulbuf数组对应的索引，索引的遍历取值从0到0xFFFF(2个字节的最大取值)。

(4)修改Reference Location组件，解析出的Reference Location组件值为：0900 13 00 00 00 0f 05 06 04 0a 07 07 05 10 11 09 08 12 05 19 08

09：代表Reference Location组件的ID；

0013：代表后续数据的长度；

0000：代表Reference Location组件中offsets_to_byte_indices数组中的元素数量，此处为0，所以该Reference Location组件中不含offsets_to_byte_indices数组；

000f：代表后续Method组件里索引偏移值的长度；

05 06 04 0a 07 07 05 10 11 09 08 12 05 19 08：这串值对应Method组件中的索引的偏移。找到我们要遍历的那个索引的偏移值并进行删除，做完删除操作后要注意相应长度字节以及后续偏移值的修改；

本实施例中，需要删除的偏移值为倒数第四个偏移值(即12)，则修改后的ReferenceLocation组件值为：09 00 12 00 00 00 0e 05 06 04 0a 07 07 05 10 11 0908 17 19 08。

(5)修改Method组件时的索引值取00 00，将修改后的Cap文件下载到智能卡中并实例化，发送APDU指令0000000001(INS值为0x00)执行sendBytesLong()方法。

若有数据可被读出，则保存log并分析入参对象的合法性，将Cap文件从智能卡平台上删除。然后，索引值+1，跳转到(3)；

若无数据可被读出，且未引起死卡，则将Cap文件从智能卡平台上删除。然后，索引值+1，跳转到(3)；

若无数据可被读出，且卡片无响应，则将Cap文件从智能卡平台上删除。然后，索引值+1，跳转到(3)；

若无数据可被读出，且引起死卡，则保存log并分析入参对象的合法性。

根据索引值遍历时取值的不同，会有以下五种测试结果的预期：

1.索引值所对应的EEPROM区域正好为mulbuf数组，则将mulbuf数组值读出。

2.索引值所对应的EEPROM区域为公共区域，例如：apdu buffer，则将apdu buffer值读出。

3.索引值所对应的EEPROM区域为非公共区域，但读出了数据。

4.无数据可被读出。

5.引起了死卡。

实际的测试结果出现了预期的测试结果中的1、2、3、4四种情况，则结合log进行分析，实际的测试结果如预期的测试结果1、2和4这三种情况时，软件的处理是正确的，当实际的测试结果如预期的测试结果3时，则不论读出什么样的数据，即便是全0，也认为是可继续攻击并可获得有用数据的成功攻击，即软件未检查出非法的入参对象，软件的处理是错误的。

根据本发明提供的具体实施例，本发明公开了以下技术效果：本发明所公开的一种Java卡标准API安全性测试方法，通过对标准API的入参对象的合法性进行校验，全面检测Java卡标准API可能存在的漏洞。在此基础上对标准API进行完善，减少了Java卡软件平台可能存在的安全漏洞，从而使平台的安全性得以提高。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (8)

1.一种Java卡标准API安全性测试方法，其特征在于，包括：

针对待测试的API，获取编写的测试Applet；

对所述测试Applet的Cap文件进行修改；

将修改后的Cap文件下载到Java卡中；

试图获取所述Java卡的有效信息从而根据获取结果确定Java卡标准API的安全性。

2.根据权利要求1所述的Java卡标准API安全性测试方法，其特征在于，所述待测试的API为带有入参的API。

3.根据权利要求1所述的Java卡标准API安全性测试方法，其特征在于，所述测试Applet的编写方法为：

定义一个全局static对象并初始化；

编写以所述全局static对象作为入参的调用所述待测试的API的语句；

对所述语句进行编译，得到编译结果；

若所述编译结果表示编译失败，则返回步骤“编写以所述全局static对象作为入参的调用所述待测试的API的语句”；

若所述编译结果表示编译成功，则生成Cap文件。

4.根据权利要求1所述的Java卡标准API安全性测试方法，其特征在于，所述对所述测试Applet的Cap文件进行修改，具体包括：

对所述Cap文件进行解析，得到解析出的12个组件；所述12个组件包括：Header组件、Directory组件、Applet组件、Import组件、Constant pool组件、Reference Location组件、Export组件、Debug组件、Class组件、Method组件、StaticField组件和Descriptor组件；

修改所述Method组件；

修改所述Reference Location组件。

5.根据权利要求4所述的Java卡标准API安全性测试方法，其特征在于，所述修改所述Method组件，具体包括：

将所述全局static对象对应的Java卡虚拟机指令修改为Java卡虚拟机压栈指令；

将所述全局static对象对应的索引依次修改为0到最大索引值之间的值，得到多个索引。

6.根据权利要求5所述的Java卡标准API安全性测试方法，其特征在于，所述修改所述Reference Location组件，具体包括：

删除与所述Method组件中的所述全局static对象对应的索引偏移。

7.根据权利要求6所述的Java卡标准API安全性测试方法，其特征在于，所述将修改后的Cap文件下载到Java卡中，具体包括：

将每个索引所对应的Cap文件依次下载到所述Java卡中。

8.根据权利要求7所述的Java卡标准API安全性测试方法，其特征在于，所述试图获取所述Java卡的有效信息从而根据获取结果确定Java卡标准API的安全性，具体包括：

在任意一个索引所对应的Cap文件下载到所述Java卡中之后，通过APDU指令运行所述待测试的API，得到运行结果；

若所述运行结果表示有数据读出，则记录当前Cap文件对应的索引值和读出的数据并将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读出且引起死卡，则记录当前Cap文件对应的索引值，并将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读取且未引起死卡，则将下载到所述Java卡中的Cap文件删除；

若所述运行结果表示无数据读取且所述Java卡无响应，则将下载到所述Java卡中的Cap文件删除；

根据记录的索引值和读出的数据确定安全性能。