[发明专利]一种支持安全通道协议定制的JAVA卡平台实现方法

说明书

技术领域

本发明涉及智能卡技术领域，尤其涉及一种支持安全通道协议定制的JAVA卡平台实现方法。

背景技术

随着智能卡技术的飞速发展，智能卡已经成为了人们生活中不可缺少的一部分，它被广泛的应用于各行各业中。GlobalPlatform组织的出现使智能卡可以实现跨行业的应用，进一步促进了智能卡的发展。GlobalPlatform组织致力于提供一个通用的安全和卡片管理架构，它发布的一系列规范也逐渐成为了智能卡行业公认的标准。

在GlobalPlatform组织提出的安全和卡片管理架构中，一个很重要的部分就是安全通道协议，该协议为卡上的安全域和应用与卡外实体间的通信提供了一个安全的环境。

在安全通道协议中，定义了以下与信息的安全性相关的安全服务，包括：

实体认证：卡片和卡外实体通过交换密文进行相互认证；

完整性和真实性：保证卡片和卡外实体之间的数据传输是来自真实可信的实体，并且传输数据的顺序是正确的且未被修改的；

保密性：保证卡片和卡外实体之间传输的数据是不能被不可信的未认证的实体所见的。

GlobalPlatform组织提供了安全通道协议标识符来标识不同的安全通道协议，目前有明确定义的包括：

’01’：安全通道协议1，被标识为不推荐的，使用对称密钥的安全通信协议’01’是为了向后兼容于版本号为2.0.1的Open Platform卡片规范；

’02’：安全通道协议2，除了提供安全通信协议’01’中的服务外，还对其中的某些服务相对于老版本进行了优化。

’10’：安全通道协议’10’，使用非对称密钥的安全通信协议’10’提供了基于公共密钥体系的认证服务，以及对APDU命令和响应采取的、基于对称密钥加密的安全消息传送保护服务。；

’80’：安全通道协议’80’，安全通道协议’80’支持定义在《ETSI TS 102 225规范》中的空中下载的安全模式。

同时，GlobalPlatform组织规定，发卡者的安全域必须实现一种安全通道协议，其他安全域必须至少实现一种安全通道协议。也就是说，可以同时支持几种安全通道协议，并允许在几种安全通道协议中相互切换。

目前，市场上主流的智能卡主要为JAVA卡，由于同等存储空间的前提下用ROM比用EEPROM所占芯片面积要大大地减少，也就是说具有相同数量的程序代码的情况下使用硬掩膜的方式可以获得更小、更便宜的微控制器，所以目前多采用硬掩膜的方式来生产智能卡。但是，硬掩膜方式的缺点也很明显，一旦生产商完成了掩膜，再对程序代码做改动就不可能了。但是，不同行业对于安全通道协议的需求也可能不同，有些行业对安全的要求高，也许需要支持安全通道协议’10’，但其他的一些行业可能只需要安全通道协议’02’，而同一行业不同的用户需求也有可能不同，这就需要卡商可以提供一种满足不同用户需求的产品。

目前，要实现对多安全通道协议的支持，多采用条件编译的方式，条件编译的方式在仅需支持某一种安全通道协议的情况下是一个较好的选择，在JAVA语言中，可以借助编译器对条件编译的代码进行优化，从而去掉条件编译中为false的选项对应的代码，这样就可以通过条件编译的方式将用户需要的安全通道协议掩膜到产品中，而用户不需要的安全通道协议就不需要进行掩膜，从而节省空间，但是这种实现方式的缺点是：这种条件编译是有使用限制的，仅在非此即彼的情况下，可以实现仅将用户需要的安全通道协议掩膜，随着市场需求的不断变化，安全通道协议的不断增加，在安全通道协议大于两种的情况下，此种方式虽然也能实现对多安全通道协议的支持，但是就需要将所有支持的安全通道协议的代码掩膜到产品中，仍然会造成空间的浪费。

另外，也可以对市场上需要的每种定制需求都维护一套JAVA平台的代码，但这样做，维护起来的成本太高，且市场需求变化快，只要有新的需求出现，就需要再维护一套新的代码，适应性差。

发明内容

本发明提供了一种支持安全通道协议定制的JAVA卡平台实现方法，可以在满足客户不同定制需求的同时减少对JAVA卡平台代码的维护成本，也可以减少空间的浪费。

本发明提供了一种支持安全通道协议定制的JAVA卡平台实现方法，包括：

步骤一：使用不同的Applet类来实现不同的安全通道协议，将这些Applet类统一放在同一包中；