CN108664327A

CN108664327A - 一种Java+Native应用的系统架构

Info

Publication number: CN108664327A
Application number: CN201810270657.8A
Authority: CN
Inventors: 于克兵; 曾林
Original assignee: Beijing CEC Huada Electronic Design Co Ltd
Current assignee: Beijing CEC Huada Electronic Design Co Ltd
Priority date: 2018-03-29
Filing date: 2018-03-29
Publication date: 2018-10-16

Abstract

本发明公布了一种将Java和Native应用整合到一起的系统架构，该架构在固件层之上设计OS层，OS层包含主流程派发单元和通用的内存管理单元，既支持标准的Java卡功能，同时又支持传统的Native应用。主流程派发单元存在于COS入口处，实现Java路径和Native路径的动态选择。传统Native应用是直接操作物理内存，实现读写等功能。由于标准Java平台中本身包含内存管理单元，所以本设计将Java平台中的内存管理单元设计为通用单元，提供内存读、写、分配、回收等功能的API供Java平台和Native应用调用，从而实现Java平台和Native应用的统一内存管理。在这种架构下能将两者的优点集于一身，既能实现Native应用的性能高、空间省的优点，又能实现Java COS的安全性高、支持后下载等优点。

Description

一种Java+Native应用的系统架构

技术领域

本发明涉及智能卡技术领域，特别是要求支持Java功能的智能卡领域。

背景技术

Java卡是Sun微系统为智能卡开发平台而制定的一个开放的标准。使用Java卡平台创建的智能卡上存有Java applet。在卡发行后也可以把applet加到卡上或修改卡上已有的applet。它们把数据存储在一个集成的微处理器芯片里。然后applet被下载到微处理器的内存里，由Java虚拟机来运行。

Java卡分为两层结构，底层为按照JavaCard规范实现的JavaCard平台，向上提供规范定义的接口(API)，通常支持JavaCard API和GP API。上层为按照应用需求开发的Applet，相当于Native卡片上的ADF。可以根据不同类型的应用，开发多个Applet。这些Applet相互独立，通过AID来选择。结构图如图1所示。

Native卡通过卡片操作系统(COS)来实现所有的功能。COS内部也按照功能的不同，分为多个层次，包括应用层具体交易APDU的实现，通讯协议层的实现，以及和芯片的具体交互等等。通常通过创建不同的ADF文件的方式，来区分不同的应用。结构图如图2所示。

Java卡相比于Native卡优缺点都比较明显：

优点：

1.提供一整套标准的JAVA卡编程的API，使得开发人员无需了解复杂的智能卡硬件和智能卡专用的技术，就可以进行智能卡应用的开发；

2.支持一卡多用途，可灵活支持多个应用，并且应用之间有防火墙进行安全隔离；

3.支持应用后开发和加载。开发一个全新的Applet应用。不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。

缺点：

1.执行效率低，性能较差

a)指令需要先经过Java平台进行预处理才能传给应用；

b)Java应用的执行依赖于Java平台的字节码解析；

c)Java语言为面向对象，无法直接操作底层硬件设备，任何对硬件的操作都需要使用平台的API。

2.发卡空间消耗大

由于Java应用需要创建各种对象，比如：密钥对象、算法对象、数组对象和变量等。而对象的管理是需要消耗用户空间的。实际需要5k用户数据空间的应用，用Java应用实现可能要消耗8-10k。

以上可以看出，Java卡虽然有很多优点，但是缺点也很明显。尤其对于智能卡行业来说，缺点变得尤其突出，性能差会导致产能的下降、用户体验效果降低甚至出现兼容性；发卡空间大导致卡片成本变高，多应用项目发卡空间存在局限性。所以设计一种Java与Native相结合的系统架构，将二者取长补短变得尤为有意义。

本发明设计了一种Java平台与Native应用相结合的系统架构，在固件层之上Java平台与Native应用可以并存，并且APDU可以分发给Java平台或者Native应用。但是将两者简单结合到一起仍存在一些不足。比如：无法实现APDU指令在Java平台和Native应用之间动态切换；两者的用户空间也无法实现统一规划(只能强制给Java平台和Native应用提前开辟一定大小的空间，无法交叉使用，势必造成一定空间浪费)。

为了解决上述两点不足本发明还在固件层之上设计了OS层，在该软件层中实现了主流程派发和内存管理两个单元。主流程派发单元可以实现APDU在Java平台和Native应用之间动态切换。内存管理单元可以实现两者用户空间统一分配和回收，以实现用户空间利用率最大化。

发明内容

本发明的目的在于提供一种将Java平台和Native应用有机的整合到一起的系统架构，使其既支持标准的Java卡功能，同时又支持传统的Native应用。主流程派发机制和独立的内存管理单元可以将Java COS和Native应用的优点集于一身，既能实现Native应用的性能高、空间省的优点，又能实现Java COS的安全性高、支持后下载等优点。

本发明设计的Java平台+Native应用的系统架构将Java平台和Native应用有机的整合到一起。其架构如图3所示。该架构包括：硬件层、固件层、OS层(包括主流程派发单元和内存管理单元和其它服务单元)、Java平台和Native应用。Java平台和Native应用共用硬件层、固件层和OS层，从OS层之上开始区分Java分支和Native分支。硬件层和固件层与纯JavaCOS或纯Native COS一致，无需特殊处理。其中硬件层为芯片的物理介质。固件层基于硬件层实现各硬件模块的驱动比如：IO通讯驱动、算法模块驱动等，供上层软件调用。

OS层实现统一内存管理、主流程派发机制等功能。其中主流程派发机制和统一内存管理为本架构设计的关键。

主流程派发机制如图4所示。当智能卡收到终端发送的APDU指令时，在OS层通过特殊派发机制确定该指令应该走Java分支还是Native分支。基于该派发机制，不仅可以实现当前指令走Java分支还是Native分支，还可以实现Java应用和Native应用在不复位的情况下切换。

内存管理单元将硬件存储介质统一进行管理。不论Java COS还是Native应用只要操作硬件存储介质，都需要通过内存管理单元实现。传统Native应用是直接操作物理内存，实现读写等功能。而标准Java COS中本身包含内存管理单元，可以实现内存的动态分配、读、写、回收等功能。如果按照传统方式需要将物理内存进行强制划分，一部分给Native应用，由Native应用直接操作物理内存。另一部分给Java COS，由Java COS内存管理单元进行管理。这样中方案的缺点是内存强制划分，容易造成空间浪费，而且不能动态调整。本设计将Java COS中的内存管理单元提取为通用单元，将内存读、写、分配、回收等功能封装成标准API。这样Java COS和Native应用都可以调用标准API，从而实现整片物理内存的统一管理，大大提高内存使用率。

附图说明

图1标准的Java Card系统架构

图2标准的Native Card系统架构

图3Java平台+Native应用的系统架构

图4主流程派发机制的处理流程

图5一种Java平台+Native应用的智能卡系统架构实例

具体实施例

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

本发明提供的技术方案是：将Java平台和Native应用同时置于固件层之上；在OS中设计一套主流程派发机制，实现APDU指令流的派发，从而确定当前APDU应该交给JavaCOS还是Native应用处理。同时在OS层中设计内存管理单元。将Java COS中的内存管理单元封装出标准API，实现内存分配、读、写、回收等功能。Java COS和Native应用都使用API操作内存，从而可以实现内存的统一管理。

为了使本发明的技术方案更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用于解释本发明，并不用于限定本发明。

图3为Java平台+Native应用的系统结构图。说明主流程派发单元和内存管理单元，在整个智能卡COS中所处的位置。

图5为Java平台+Native应用的智能卡系统结构处理流程图，说明从COS启动、初始化、接收APDU、派发指令以及指令处理的流程。

下面以支持Java平台的智能卡为例，讲述本发明的设计步骤。

在Java COS的软件结构中，将原Java平台的初始化内容(全局变量、Java状态等数据)进行拆分。一部分作为通用的初始化内容，另一部分作为Java平台特有的初始化内容。

在COS循环接受命令状态机中增加一套主流程派发单元(如图4)。上述通用初始化内容仍在主流程派发机制之前完成。主流程执行原理如下：第一条APDU分发选择：

Case1:"00A40400XX aid"，先去java应用注册表中查找，

如果找到AID，则切换当前环境为jcre。

如果没有找到，检查默认环境

如果默认环境不是nare寻找nare的top级应用，如果找到，切换环境为nare。如果也没找到，切换环境为jcre。

Case2:"00A4000002fid"

如果默选环境是nare，交给默认环境处理。

如果默选环境是jcre：

检查当前java默选应用是否是ISD：

如果是ISD，切换环境为nare，交给nare环境处理。

如果不是ISD，交给默认环境处理。

其他case：

交给默认环境处理。

非第一条APDU分发选择：

Case1:"00A40400XX aid"，先去java应用注册表中查找：

如果找到应用，则切换当前环境为jcre；

如果没有找到，寻找nare的top级应用：

如果找到交给nare；

如果没找到交给上一条apdu的环境处理。

Case2:"00A4000002fid"

交给上一条apdu的环境处理。

其他case：

交给上一条apdu的环境处理。

Java平台特有的初始化内容，在主流程派发后的Jcre分支内完成。Native应用特有的初始化内容，在主流程派发之后的nare分支内完成。

将Java平台的内存管理单元封装出标准API，作为公共服务单元。API参考如下：

●内存分配

memref app_nvm_alloc(u32size)；

功能：申请nvm空间，大小为size字节。

●内存读

void app_nvm_read_array(memref dest,memref src,u16size)

功能：读取NVM中的数据到RAM中

u8app_nvm_read_u8(memref src)；

功能：读取u8类型NVM中的数据值。

u16app_nvm_read_u16(memref src)；

功能：依照大端字节序读取u16类型NVM中的数据值。

u32app_nvm_read_u32(memref src)；

功能：依照大端字节序读取u32类型NVM中的数据值。

●内存写

void app_ram_write_u8(memref dest,u8value)

功能：写入u8类型数据值到RAM中。

void app_ram_write_u16(memref dest,u16value)；

功能：依照大端字节序写入u16类型数据值到RAM中。

void app_ram_write_u32(memref dest,u32value)；

功能：依照大端字节序写入u32类型数据值到RAM中。

void app_nvm_write_array(memref dest,memref src,u16size)；

功能：将RAM中的数据写入NVM中。

●内存回收

void app_nvm_free(memref address,u32size)；

功能：释放申请到的nvm空间

Native COS中所有关于内存的操作，都使用上述API，先分配，后使用

(读、写)，用完之后执行内存回收。

综上所述，当智能卡COS需要同时支持Java平台和Native应用时，可按上述步骤进行设计，既能实现Native应用的性能高、空间省的优点，又能实现Java COS的安全性高、支持后下载等优点。

以上所述仅为本发明的较佳实现方案而已，并不用以限制本发明，凡在本发明的精神和原则之内所做的任何修改、等同替换及改进等，均应包含在本发明的保护范围内。

Claims

1.一种Java+Native应用的系统架构，其特征在于，该系统架构包括硬件层、固件层、OS层、Java平台和Native应用，其中OS层包括主流程派发单元、内存管理单元和其它服务单元。

2.如权利要求1所述的系统架构，其特征在于，所述OS层共用于Java平台和Native应用。

3.如权利要求1所述的系统架构，其特征在于，所述主流程派发单元实现APDU在Java分支和Native分支间的动态派发。

4.如权利要求1所述的系统架构，其特征在于，所述内存管理单元提供内存读、写、分配、回收等功能API，同时供Java和Native应用调用，从而实现统一的内存管理。