CN101042738A - 一种实现智能卡多应用的方法及数据处理装置 - Google Patents

Abstract

本发明公开了一种实现智能卡多应用的方法，包括：设置至少一个容器；将数据按照容器和对象的方式存储，每个容器内包含至少一个应用的对象集合；设置容器的操作接口，以实现通用的针对对象的操作。由于本发明所述智能卡采用容器、对象的概念对应用数据进行存储，并在容器端提供通用的针对对象的操作，而将多应用的本身的安全机制和应用流程完全交给外部处理，达到了最大的通用性。所述通用性体现在，采用本发明所述智能卡的数据存储方法，只需要针对该智能卡进行一次开发即可，以后的个人化过程以及使用流程都可以采用通用流程实现，而不需要由于某个具体应用的特殊需要或者特殊指令对该智能卡进行重新开发的过程。

Description

一种实现智能卡多应用的方法及数据处理装置

技术领域

本发明涉及一种数据存储及信息安全技术领域，特别是涉及一种实现智能卡多应用的方法及数据处理装置。

背景技术

由于现有的磁条卡存在安全性差等缺陷，所以国内外各银行都在逐步采用智能卡(CPU卡)来代替磁条卡，并单独或联合行业用户发行了大量的智能卡。一般而言，智能卡是一个包含嵌入集成电路(IC)的塑料卡片，集成电路内包含一个微型的中央处理器(CPU)、ROM、RAM及其它附属外围电路，该集成电路具有和计算机类似的能力，例如：运行程序，处理输入和输出数据。当使用上述CPU卡的时候，需要由外部提供电源及其它接口设备。

为了规范从磁条卡向IC卡(通常指CPU卡)的迁移过程，三大国际卡组织Europay、MasterCard、Visa共同制订了基于IC卡的金融支付应用标准，简称EMV规范。所谓EMV迁移是指，按照EMV规范，在发卡、收单、信息转接、业务处理、相关产品认证等各个环节从磁条卡向IC卡迁移。

为了迅速适应国际化竞争的需要，尽快提高自身竞争力，国内银行卡EMV迁移正在逐步实施中，在不远的将来，CPU卡将成为大多数人随身携带的智能卡。发卡行通常都比较积极的拓展自己智能卡的功能，如何将发卡行的这种需求和行业用户的项目结合就是非常重要的课题。

国际标准化组织规定的ISO7816第1～7部分规定了一组覆盖CPU卡各个方面的标准。ISO7816包括：物理特性(第1部分)、尺寸和触点位置(第2部分)、电子信号和传输协议(第3部分)、行业间交换指令(第4部分)、应用程序标识符(第5部分)、行业间数据元素(第6部分)和行业间SCQL指令(第7部分)。

对于CPU卡来说，实现CPU卡的多应用是一个迫切的发展方向，所谓多应用是指在同一张智能卡上存在多个应用，如金融钱包、加油钱包、考勤门禁等，通常这些应用在逻辑上分别处于不同的应用区。实现CPU卡多应用必须主要考虑以下三部分内容：应用数据在智能卡上的存储机制；应用数据如何存取卡上数据；智能卡如何配合实际的应用实现具体的应用流程。

现有的普通IC卡操作系统遵循基于ISO7816标准的目录和文件方式，实现应用数据在智能卡上的存储机制，如图1所示。

现有的IC卡中采用目录和文件的方式进行应用数据的存储，即现有的基本都是面向文件系统的智能卡。所述文件数据的存储过程类似普通软盘等的存储机制，只不过现在常用的CPU卡的容量仅仅为8K或者16K字节，容量较小而已。并且，现在常用的CPU卡在操作文件时，存在以下限制：

1、CPU卡创建一个文件时必须先声明创建的文件的类型以及创建文件的空间大小；并且，确定后文件的长度就是固定、不能改变的了，从而导致以前申请的空间无法再次使用。

2、CPU卡创建完一个文件后不可以删除。(测试发卡的时候可以例外，但此时删除的是MF，即删除智能卡中的所有文件和目录)

3、CPU卡文件类型只有很少几种，即文件类型是固定的。

4、CPU卡创建文件、写文件必须通过向智能卡发送报文的方式进行，并且每次写的字节数一般不能超过256字节，处理过程复杂。

参照图1，现在常用的CPU卡一般包括主文件MF、专用文件DF以及基本数据文件MF等文件类型。卡的专用文件(DF，Dedicated File)与基本数据文件(EF)呈树状结构，每个专用文件是其下属基本数据文件的入口点。

所述主文件MF(Master File)即根目录，是智能卡文件系统的根，相当于DOS的根目录，每张卡有且只有一个MF文件。当然，不同智能卡厂商的MF的创建方式是不同的。主要有两种方式：在智能卡个人化过程中由发卡方创建，如明华、德生智能卡；或者，厂商提供智能卡的时候已经创建，发卡方不能再创建，如握奇智能卡。

所述DF(Dedicated File)文件相当于DOS的子目录。所述DF文件又可以进一步分为DDF和ADF，一般将包含下级目录的DF称之为DDF，不包含下级目录的称之为ADF。

对于现有IC卡多应用的实现是通过创建多个ADF(即创建多个目录)达到的。每个ADF代表一个应用。每个ADF下有相应的文件，相应的文件中存放相应的数据。

ISO7816标准也定义了一些针对文件系统的存取指令，如读二进制文件、写二进制文件等，现有的IC卡操作系统基本上都采用7816里定义的机制，另外再加入自定义的或行业应用的特殊指令来实现。

例如，CPU卡有这么一个指令：SELECT MF，这个指令表示进入智能卡的根目录，但由于CPU卡的操作系统比较简单，它处理不了这种纯粹字符的东西，向智能卡发送指令的时候必须把指令转换成十六进制的格式：转换成智能卡的指令格式是：00 A4 00 00 02 3F 00。

由于ISO7816标准仅仅规定了一些简单的存取指令，对于不同的应用则需要加入自定义的或行业应用的特殊指令来实现，所以，智能卡如何配合具体的应用的实现流程是无法统一的，例如，人民银行定义了实现消费和圈存的指令、中石化定义了灰锁的加锁解扣指令、劳动部定义了自己的实现老保和社保的指令等等。不同的行业应用根据自身需要，设置不同的文件结构、长度等进行存储，设置不同的专用指令来实现不同的应用流程。

总之，现有的CPU卡的存储机制导致下述的几个问题：

由于创建一个文件时必须先声明创建的文件的类型以及创建文件的空间大小；并且，确定后文件的类型、长度就是固定的，且不可以删除，从而导致以前申请过的空间无法再次使用。

由于不同行业应用发行CPU卡时都需要进行相应的开发过程，使得该CPU卡可以执行本行业或企业的专用指令、流程。本行业或者其他行业的新应用希望共同使用该CPU卡(即向该CPU卡中创建新应用)时，但是由于该CPU卡无法执行其特殊指令、流程，则不得不重新开发一个新卡，一方面导致开发成本极高，并且后续升级或业务整合的难以实现；另一方面又导致不同的应用需要使用不同的CPU卡，给消费者以及服务提供商带来不便。也就是说，现有技术向智能卡中创建应用的过程必须包括一个针对卡本身的开发过程，而且无法方便的向该智能卡中创建另一个应用，因为需要针对该新应用重新进行开发过程。

并且由于各行业的应用具有独特的特点，自定义了各种不同的应用指令和流程，而现有的智能卡无法适应各行业不同的具体应用流程，所以带来智能卡多应用实现中的困难。

现有技术中智能卡应用的开发主要是某个公司私有的开发行为。虽然所有智能卡看起来很像，但是每个智能卡的操作系统软件都是不尽相同的，在设计应用的接口上存在差异。这意味着如果A公司制造了一种智能卡，B公司也制造了一种智能卡，在这两种卡上构建相同的应用存在很大的不确定性，甚至不可能完成。这就导致智能卡的应用开发被限制在一个相对较小的圈子里，很难实现和推动智能卡的多应用。

由于现有技术无法制定出一套能够满足各行业对CPU卡应用的指令或流程，使得开发成本极高，并且后续升级或业务整合的难以实现。行业应用提供方单独发卡或为了某种原因和银行联合发卡，也迫切需要一个通用的规范来指导，以减少后续升级或业务整合时带来的风险和代价。

发明内容

鉴于上述问题，本发明的目的是提供一种公共的开放的智能卡平台，以便：减小或消除发卡行在业务开拓时的技术障碍，快速推动对智能卡多应用市场的开发；满足行业应用的特点和需求，保护各行业应用的独立性和私密性；并相互兼容多个应用开发商的应用。

为解决上述技术问题，本发明的目的是通过以下技术方案实现的：

一种实现智能卡多应用的方法，包括：设置至少一个容器；将数据按照容器和对象的方式存储，每个容器内包含至少一个应用的对象集合；设置容器的操作接口，以实现通用的针对对象的操作。

优选的，所述的实现智能卡多应用的方法，还可以包括：根据数据的特性，将数据分别存储为数据对象、计算对象和密钥对象；所述数据对象用于存储应用数据，所述计算对象用于存储敏感数据，所述密钥对象用于存储应用的密钥数据。优选的，所述对象还可以包括：将实现特定功能的指令序列数据存储为应用协议数据单元APDU对象。优选的，所述的实现智能卡多应用的方法，还可以包括：设置虚拟机和指令系统，用以支持APDU对象在智能卡内的执行。

优选的，所述的实现智能卡多应用的方法，还包括：如果所述对象属于同一应用，则APDU对象被外部调用，数据对象通过APDU对象被外部引用，密钥对象被数据对象或其它密钥对象引用。

优选的，所述对象包括以下信息：标识、属性、对象的存取条件以及对象的内容。优选的，所述对象的内容包括数据项存取条件以及数据项本身。优选的，所述具有相同存取条件的数据项采用统一的模板进行封装，模板内的所有数据项都继承模板的存取条件。

本发明还提供了一种数据处理装置，特别是智能卡，包括：微处理器、非易失性存储器以及操作系统；所述操作系统将数据按照容器和对象的方式存储在非易失性存储器中，存储在至少一个容器中，每个容器内包含至少一个应用的对象集合；所述操作系统设置容器的操作接口，以实现通用的针对对象的操作。

优选的，所述对象包括：用于存储应用数据的数据对象，用于存储敏感数据的计算对象，用于存储应用的密钥数据的密钥对象。优选的，所述对象还可以包括：用于存储实现特定功能的指令序列数据的应用协议数据单元APDU对象。优选的，所述的数据处理装置，特别是智能卡，还可以包括：虚拟机和指令系统，用以支持APDU对象指令的执行。优选的，如果所述对象属于同一应用，则APDU对象被外部调用，数据对象通过APDU对象被外部引用，密钥对象被数据对象或其它密钥对象引用。

与现有技术相比，从上述技术方案可以得出，本发明具有以下优点：

由于本发明所述智能卡采用容器、对象的概念对应用数据进行存储，并在容器端提供通用的针对对象的操作，而将多应用的本身的安全机制和应用流程完全交给外部处理，达到了最大的通用性，这是采用ISO7816文件系统的规范难以做到的。所述通用性体现在，采用本发明所述智能卡的数据存储方法，只需要针对该智能卡进行一次开发即可，以后的个人化过程以及使用流程都可以采用通用流程实现，而不需要由于某个具体应用的特殊需要或者特殊指令对该智能卡进行重新开发的过程。

采用对象的概念解决应用数据存储问题，并且提供标准的接口来实现对象的插入和存取操作，所以本发明对应用数据的具体格式没有限制，由应用本身自行定义和设定，从而同时解决了数据的存取问题；优选的，本发明还可以采用与传统方式一致的安全报文机制来保证系统和数据安全。

由于本发明采用了容器和对象的数据存储方式，所以本发明所述智能卡还可以具体将某个单独的应用作为容器，在该应用下面创建更多的子应用，从而可以实现多个微应用。

本发明所述的向智能卡中创建应用的流程可以适用于各种行业，提供了一种通用的创建流程。智能卡的发行过程中只需要进行一次开发即可，各种行业应用都可以采用本发明所述的创建应用的方法，向智能卡中创建应用，即本发明可以很方便的实现向智能卡中创建多应用。

为了配合应用流程的实现，本发明采用APDU对象来实现以前定义专用的指令的功能，将解决这个问题的主动权从智能卡交到应用一方，可以由应用具体设计相应的对象，只要插入容器就可以了。容器处理APDU对象类似一个钩子，当发现卡读取设备发来的指令不是标准的指令，则查看当前的APDU对象列表，如果某个对象符合处理请求则调用处理，即可实现以前定义专用指令的功能。

由于APDU对象的采用，使得本发明的存取对象的流程可以适用于各种行业的具体应用流程。一般的读取、引用对象等流程是统一的，而且执行特殊指令的流程也是统一的：先引用相应的APDU对象，然后由该APDU对象控制流程完成特殊的指令功能。

由于解决了数据的存储问题和存取问题，而且将应用流程的处理也交到实际应用去处理，本发明就可以提供统一的多应用平台。IC卡产业链的所有厂商都将可以开发出通用的、互相兼容的产品，降低成本，并推动整个产业的发展。

一个开放的、可互操作的多应用智能卡平台给不同的机构都将带来益处，例如，持卡人、商户、发卡方、收单方、系统集成商、智能卡供应商和卡读取设备供应商等。对发卡方而言，可以提供共同的平台供商业合作伙伴使用，给持卡人提供便利，保持其忠诚度，提高使用本行卡的积极性；对持卡人而言，可以很容易的、及时的获得发卡方提供的各种服务，随时能了解自己的积分额或VIP等级等信息；对商户、收单方、系统集成商、智能卡供应商和卡读取设备供应商而言，可以通过公共的平台和POS系统为各种应用服务，比如可以在持卡人的卡上轻松加入自己的积分系统，而无需任何投资。

由于本发明所述智能卡具有统一的接口，所以系统集成商、机具供应商都可以开发标准的产品，避免对某个具体的项目开发产品而增加开发成本，而发卡者也可以降低系统的兼容风险，并保持足够的开放性，确保后续业务能及时更新到智能卡和相关环节，保护投资收益。

附图说明

下面结合附图和具体实施方式对本发明作进一步详细的说明。

图1是基于ISO7816标准的目录和文件的智能卡数据存储方式示意图；

图2是智能卡的应用的装置框图；

图3是实现APDU对象的信息流程图；

图4是实现APDU对象的系统结构图；

图5是智能卡中数据存储的容器和对象的概念图；

图6是智能卡中数据存储的容器中不同类型的对象之间的关系图；

图7是容器认证流程的步骤图；

图8是插入对象的处理流程的步骤图；

图9是存取对象的处理流程的步骤图；

图10是引用对象的处理流程的步骤图；

图11是删除对象的处理流程的步骤图；

图12是读取对象的处理流程的步骤图；

图13是更新对象的处理流程的步骤图；

图14是对象加值的处理流程的步骤图；

图15是对象减值的处理流程的步骤图；

图16是解锁容器认证密钥的处理流程的步骤图。

具体实施方式

本发明中所述应用(Application)一般是指智能卡和卡读取设备(CardAcceptance Device，CAD)之间的应用协议以及相关的数据。一个典型的智能卡设备一般包括一个8或16位的运行在3.7MHz的微处理器，带有1K的RAM和多于16K的非易失性存储器(可编程只读存储器或者闪存)。智能卡可以分为可接触和非可接触。可接触智能卡通过读卡器和智能卡的8个触点物理接触来通讯并工作，而非可接触智能卡依靠在小于2英尺的一般距离之内的射频信号通讯。

本发明所述的典型的智能卡的应用并不是孤立的，而是包含智能卡、卡读取设备以及后端应用程序。参照图2，智能卡的应用的装置框图。

智能卡插入可以与另一台计算机相连的卡读取设备，从而实现数据传输和处理。卡读取设备又可称作终端、读卡器或者接口设备(IFD)。上述卡读取设备都具有向智能卡提供电源和建立数据传输连接的基本功能。

所述后端应用程序可以提供支持卡上APDU对象(或者称为小应用程序)的服务。例如，一个后端应用程序可以提供安全系统和卡上的证书的连接，提供强大的安全性。在一个电子付款系统中，后端应用程序可以提供信用卡访问其他付款信息的服务。所述APDU是指应用协议数据单元(Application ProtocolData Unit)。所述APDU对象类似JAVA小程序，包括能够实现一定功能的指令集合。

卡读取设备端主应用程序存在于一个例如个人计算机这样的台式机、电子付款终端、手机或者一个安全子系统中。所述卡读取设备主应用程序处理智能卡、APDU对象和供应商的后端应用程序之间的通讯。

卡读取设备(CAD)是处于主应用程序和智能卡设备之间的接口设备。所述卡读取设备CAD为智能卡提供电力，以及与该智能卡进行电子或者射频通信。所述卡读取设备CAD可能是一个使用串行端口附于台式计算机的读卡器，或者可能被整合到其他终端内，例如饭店或者加油站内的电子付款终端。该接口设备从主应用程序到智能卡转送应用协议数据单元(Application ProtocolData Unit，简称APDU)指令，并且从智能卡向主应用程序转送响应。当然，某些卡读取设备CAD还可以有用于输入个人识别号码的键盘，设置还有显示屏。

本发明所述智能卡中优选存在一个或多个能够实现一定指令功能的APDU对象，还需要存在支持软件，例如，智能卡的操作系统等。由于本发明所述智能卡可以存储APDU对象，使用APDU对象可以模拟任何已知的或可能的指令，则必须有相应的虚拟机和指令系统支持，即本发明所述智能卡还可以包括相应的虚拟机和指令系统，用以保证指令的执行。

参照图3，是实现APDU对象的信息流程图；参照图4，是实现APDU对象的系统结构图。

APDU对象是一个预定义的程序，通过CLA和INS与卡读取设备(CAD)发出的APDU命令建立关联。当容器内存在某个APDU对象，且卡读取设备CAD发出的APDU命令的CLA、INS字节与该APDU对象关联的CLA、INS相同，则该程序就会被执行，从而完成特定的应用功能。

要实现APDU对象，则需要设置相应的指令系统和虚拟机进行支持，引用APDU对象，其内容(用高级语言编写的程序)将被编译成一串指令序列，程序的执行其实就是对应的指令序列在机器码上执行，将APDU对象的程序编译成指令序列是一个转换过程，将人类容易理解的语言转换成机器容易理解的语言。为了提高运行效率，转换(编译)过程可以在卡片外部实现，下载到卡片上的是转换后的指令序列。

对APDU对象的引用其实就是执行相应的指令序列，指令序列里的每一条指令又叫微指令。实际中，不同的芯片可能具有不同的机器结构和指令集，将微指令定义的功能在具体的芯片平台上实现必须将其再次翻译称该芯片平台的专用的指令，这个翻译的机制和方法就称之为虚拟机。

参照图3可知，由于设置了实现APDU对象的指令系统，所以编译后的APDU对象(微指令序列)可以在任何芯片平台上运行，因为其指令系统与具体的芯片平台无关。图4示出了实现APDU对象的系统结构图。虚拟机定义微指令的翻译规则和过程，包括如何存取操作数等、如何维护指令栈、指令寄存器及符号表。不同的芯片实现APDU对象的虚拟机是相同的。

实现APDU对象的指令系统可以根据实际数据处理过程的需要进行设定。当然，一般指令系统可以设定加指令、减指令、乘指令、除指令、比较指令、条件转移指令、左位移指令、右位移指令、压栈指令、出栈指令、存操作数等，本发明对此并不加以限定。

参照图5，首先对智能卡中数据存储的容器和对象的概念进行详述。

容器在现实环境中，有许多物体可以参照，比如办公室、城市、村庄和社会等，其中包含了许多其它的、各种各样的东西，被容器包容的称之为对象。对象在容器内有一定的关联，也可能没有，但是容器内的对象需要共同遵守容器的规则。

对于智能卡来说，智能卡本身其实就是一个容器，主文件(MF，Master File)包含了卡上所有的应用对象，MF下的DF又是一个子容器，包含了应用具体的数据或者密钥。容器就是一组提供一系列服务的管理器，只要符合容器的服务要求(规范)容器就可以允许使用范围内的管理服务(针对对象的操作)。智能卡上的一个DF，以唯一的应用标识符(AID)标识，在支付系统环境(PSE)里可以标识成一个应用。

本发明的核心之一就在于是采用了容器和对象的数据存储架构，并在容器端提供通用的插入和引用对象的操作，用以达到通用平台的目的；而将多应用的本身的安全机制和应用流程完全交给外部处理，达到了最大的通用性，这是采用ISO7816文件系统的规范难以做到的。

由于不同的数据涉及的操作、操作条件以及安全程度是不尽相同的，因此为了使容器提供的基本通用操作更好的满足各种数据，本发明所述智能卡根据不同的数据类型，分别存储成不同类型的对象。例如，可以定义以下四类对象：数据对象、计算对象、密钥对象和APDU对象。参照图6，是不同类型对象之间的关系图。

数据对象是用来存储具体应用数据的，一个应用可以有多个数据对象。所有应用数据都必须对应到相应的对象上，一个数据对象可以包含一个或多个应用数据项，不同的数据项采用TLV结构封装，每个数据项的存取条件(AC，Access Condition)都可以单独定义。所述TLV是一种结构形式，其中T＝TAG：标识；L＝LENTGTH：长度；V＝value：值。当然，具体数据项也可以采用其他可以变长度的结构体，但是所述TLV结构使用起来非常方便，创建时，定义一段结构体大小加上可变长数据长度的空间给它即可；释放时，直接把整个结构体释放掉就可以了；所述释放是指将整个结构占用的空间释放，故本发明采用数据对象的形式可以重复使用申请过的空间。

计算对象是一种特殊的数据对象，用来存储特殊的敏感数据，比如忠诚项目里的积分值等，一个计算对象只能存储一个敏感数据项。计算对象的其他设置与数据对象相同。

密钥对象存储应用安全控制的密钥，一个密钥对应一个密钥对象，密钥对象用来保护数据对象。一个密钥对象只能存储一个密钥，密钥本身的使用也可以指定其它的密钥对象来保护。所述密钥对象可以采用单倍长和双倍长对称密钥，也支持非对称密钥。通过密钥对象，可以实现外部认证或线路保护等安全机制。

APDU对象类似JAVA小程序，包括能够实现一定功能的指令集合，它可以应用自定义的接口，微处理器负责将卡读取设备发来的APDU指令转接到对应的APDU对象，由它来执行具体的动作。APDU对象类似一个钩子函数，当进入容器内指定的应用，一旦发出APDU对象定义的APDU指令时，容器将控制权交给APDU对象，由它解释这条指令。通过相应的虚拟机和指令系统支持，APDU对象可以模拟任何已知的或可能的指令，从而达到较高的通用性。

由于智能卡大多数情况下是由主应用的发行者拥有，所述多应用容器可以设置一个控制密钥用以控制应用的增加和删除。各应用内的对象则可以由自定义的安全策略控制，即应用本身的安全机制、应用流程交给外部进行处理，进一步提高行业应用的通用性。

所有的数据对象都可能受密钥对象保护，密钥对象也可能受其它密钥对象保护，但是APDU对象不受密钥对象保护，因为所述APDU对象用来模拟一个通用接口。当APDU对象的内部处理引用到数据对象或密钥对象时，和外部引用的条件是一样的，即需要满足不同对象各自的存取条件(AC)。

当两台计算机彼此进行通信时，它们之间交换的是根据一系列协议构造的数据包。类似地，智能卡也使用自己的数据包---称作APDU(ApplicationProtocol Data Unit，应用协议数据单元)与卡读取设备进行对话。一个APDU数据包包含一条指令或响应信息。智能卡的通信采用的是主从模式，而智能卡永远扮演从动的角色；换句话说，智能卡总是在等待来自卡读取设备的命令APDU。随后，智能卡执行APDU规定的动作，并以一个应答APDU向卡读取设备做出回答，即智能卡与卡读取设备之间互相交换命令APDU和应答APDU。

下表分别详述命令APDU和应答APDU的格式。

            表1：命令APDU和应答APDU的格式

命令APDU
									标题头(必须)					主体(可选)
CLA	INS	P1	P2		Lc	数据字段		Le
									应答APDU
主体(可选)				尾部(必须)
									数据字段				SW1			SW2

上表中所述命令APDU的标题头对被选指令进行编码，它包括4个字段：类(CLA)、指令(INS)、和参数1和2(P1和P2)，其中每个字段包含一个字节。

CLA：类字节，该字节用来表示指令的类别；

INS：指令字节，该字节表示指令代码；

P1-P2：参数字节，该字节对命令APDU提供进一步说明。

上表中所述命令APDU的主体部分包括三个字段，其中，Lc表示命令APDU的数据字段的字节数；Le表示以下应答APDU的数据字段希望的字节数。

上表中所述应答APDU的尾部的状态字节SW1和SW2表示命令APDU在智能卡中的处理状态。

下面对本发明所述智能卡在与卡读取设备进行APDU交互时使用的数据元进行描述，其长度以字节为单位。

容器至少包括两个数据元：容器实现版本和容器唯一性标识，当然，所述容器还可以包括其他的数据元，例如下面所示：

                     表2：容器数据元

数据元	类型	长度	含义
				容器版本容器名称智能卡序列号容器特性应用类个数剩余空间应用类列表	二进制二进制二进制二进制二进制二进制TLV模板	1168222可变	容器的实现版本容器的名称智能卡的唯一性标识容器的安全特征信息容器内的应用个数容器的剩余空间容器内的应用列表

                        表3：对象包含的数据元

数据元	代码	类型	长度	含义
					标识	OUID	OID	5-16	对象的唯一标识
属性	Attrib	二进制	可变	对象的属性
					对象AC	OAC	二进制	2	对象的存取条件
内容	Content	TLV	可变	对象的内容

表3描述了对象可能包括的一些数据元。其中对象标识用于唯一的标识容器内的一个对象，由于容器内可能容纳了多个应用，每个应用都定义个多个对象，这就要求对象标识必须能区别不同的应用和相同应用内的不同对象。

在ISO7816里，标识一个应用使用称为AID的定义方法，AID的长度可以是从5到16字节；ASN.1(Abstract Syntax Notation 1)标准定义了一种通用的对象标识方法OID，具体定义和编码格式请参阅X.208。OID的长度没有限制，OID的格式是按照树状的规则定义的，每一层都由ISO或其它国际组织定义。OID存储时有特殊的压缩存储格式，可以节省很多空间。所以，在这里优选采用OID来标识容器内的对象。下面的例子是部分OID定义及存储格式：

                     表4：OID格式及存储示例

OID	含义	存储格式
			1.2.840.113549.1	pkcs-1	2A 86 48 86 F7 0D 01
1.2.840.113549.1.9.1	emailAddress	2A 86 48 86 F7 0D 01 09 01
			1.2.840.113549.3.7	desCBC	2A 86 48 86 F7 0D 03 07
5.9.86.0.0.1	未知	D1 56 00 00 01

采用OID类型作为对象标识(OUID)，OUID可以分为两部分：末位域标识对象在本应用内的编号(OSN)，前边所有的域标识对象所属的应用类(OAID)。在一个容器内使用OAID来唯一的标识一个应用类，OSN的取值范围限制为1～254，也就是一个容器内的应用最多可有254个对象。例如：

对象数据元中的对象属性可以用两个字节定义，分别定义对象的类型和属性，下面详述。

                        表5：对象属性第一字节定义

8	7	6	5	4	3	2	1	定义
									x	x							对象类型(Object Type)00：数据对象01：计算对象10：密钥对象11：APDU对象
		如果是密钥对象，定义密钥的用途(Purpose)
									1						允许外部认证
			1	允许内部认证
						1	允许计算签名
				1				允许校验签名
							x		x	保留

第一字节位8、7标识了一个对象的类型，如果是数据对象、计算对象或APDU对象，剩余位和第二字节均保留使用。

如果是密钥对象，则第一字节的剩余位，用于定义密钥对象的用途。如果是密钥对象，则第二字节用于定义密钥的属性。表5示出了定义的一些具体情况：

                表6：对象属性第二字节定义

8	7	6	5	4	3	2	1	定义
									x	x	x						密钥属性(Attribute)000：PIN Key001：PUK010：3DES Key011：Mac Key100：Enc & Mac Key101：Public Key110：Private Key111：RFU
			x	x				补齐模式(Padding Mode)01：PBOC10：PKCS1其它保留
											x	x	x	算法(Algorithm)001：3DES010：SSF33100：RSA其它保留

每个在容器内的数据对象可以通过APDU被外部引用，密钥对象可以被数据对象或其它密钥对象引用，APDU对象可以被外部调用；对象间的引用仅限于容器内的同一应用，即对象都具有相同的OAID，所述OAID用来标识对象所属的应用类；所有的对象也可以被删除，引用或删除的前提定义为使用条件(AC，Access Condition)。

基于对象的操作可以有两类：引用(Reference)和删除(Delete)。

数据对象的引用条件没有意义，对象只是一个数据项的集合，并且所有数据项都分别有自己的AC。APDU对象的引用条件也没有意义。

密钥对象的引用操作根据密钥的用途和属性解释，如果是PIN，则解释为校验口令，如果是外部认证密钥，则解释为使用外部认证；如果是加密密钥则解释称线路保护密钥，由密钥属性决定保护方式，如果是属性定义为MAC KEY，是明文加MAC的保护方式，如果属性定义为ENC & MAC KEY，则为密文加MAC的保护方式；下表是当引用到一个密钥对象时的动作解释。

                      表7：密钥对象的动作解释

	密钥用途
					密钥种类	外部认证	内部认证	计算签名	校验签名
PIN KEY	-	-	-	-
					3DES KEY	√	√	-	-
MAC KEY	线路保护密钥，明文加MAC方式
					Enc & MAC KEY	线路保护密钥，明文加MAC方式
Public KEY	-	√	√
					Private KEY	-	-	-	√

对象的使用条件(AC)可以定义为一个字节，取值为0～255。根据基于对象的操作，每个对象有两个AC，第一字节定义为引用条件(Reference AC，RAC)，第二字节定义为删除条件(Delete AC，DAC)，AC的定义如下表所示：

               表8：对象AC的定义

值	定义
		0	自由
1-254	对象编号，具体含义由对象的属性解释
		255	禁止

当AC取值为0时，表示无条件，即任何条件都可以访问；如果为255，则表示为禁止；其它则指向某个对象，由该对象的属性定义来决定访问的条件。

对象的内容可以分为两部分结构，一部分定义对象内部存储的数据项的属性，一部分是数据项本身。数据项的属性是指数据元的存取条件，多个数据项的存取条件组成一个列表。即对象的内容由数据项使用条件列表(ACL)与数据项本身组成。使用条件列表(ACL)的格式可以采用类似EMV规范里的DOL的概念，由一组标签(Tag)和存取条件(AC)组成，格式是一个Tag后紧跟此Tag定义的数据元的AC。为了减少ACL的长度以及增强易用性，建议将具有相同AC的数据项用一个模板来包装，模板内的所有数据项都将继承模板的AC。

下面描述基于数据项的操作和使用条件：

在数据对象内，数据项的操作通常是读(Read)和写(Update)，对于特殊的数据项，比如金额或点券等敏感信息，出于安全的考虑，允许的操作是递增(Increase)和递减(Decrease)；对于密钥对象的数据项，允许的操作只有写(Update)；而对于APDU对象，优选的，不允许进行操作。

数据项使用条件可以定义为两个字节，对于数据对象，第一字节定义为读条件或递增条件，第二字节定义为写条件或递减条件；对于密钥对象，第一字节定义为密钥的错误使用保护计数器，高半字节为最大值，低半字节为初始值，第二字节定义为写条件。

所有的数据项都可以用TLV结构表示，一个对象内不允许出现相同标签的数据项，不同的对象的数据项可以采用相同的标签。

下面描述容器和应用类的创建和选择机制：

由于本发明是针对多应用而设计的，可以涵盖开放平台和非开放平台，所以容器的创建这里不作要求和描述，即对此不进行限定。

容器作为多应用的载体，当卡读取设备发出SELECT命令选择容器后，智能卡需要返回容器本身的一些信息和公共信息，需要返回的容器信息见下表：

表9：SELECT命令后需要返回的容器信息

版本号	1字节
		智能卡唯一性标	8字节
容器特性	1字节
		应用类个数	2字节
剩余空间	2字节

公共信息可以保存在一个公共信息对象中，当卡读取设备选择容器后，智能卡检查容器内如果存在这个对象，则把它的数据项附加在容器信息后返回。公共信息对象的创建是在创建容器时一起创建的，如何创建及写入信息本发明不进行限定。当然，优选的，可以将持卡人的信息作为公共信息对象内容的一部分。

容器的认证可以是外部认证，也可以是PIN认证，一旦完成容器的认证过程，容器就允许进入创建对象的状态。

应用类的创建必须在完成容器的认证后才可以使用Insert Object命令创建，一个应用类可以创建多达254个对象，插入的对象的OID的OAID必须是认证时使用的OAID。

当卡读取设备发出本发明定义的应用类选择命令后，相应的应用类被选中，并根据当前应用类的密钥对象的设置复位容器的状态机。

创造性的提出采用容器和对象的概念存储多应用数据之后，本发明还需要解决应用流程中如何实现对智能卡上的对象数据的存取。下面主要详细介绍涉及容器的认证、插入对象和存取对象的流程步骤。其中，有可能涉及到采用状态字表示的结果，下表描述了优选使用的状态字及其含义。

表10：优选使用的状态字及其含义

状态字	含义
		90 00	成功执行
65 81	内存错误
		69 85	使用条件不满足
69 82	安全条件不满足
		67 00	长度不对
6A 88	引用数据未找到
		6B 00	P1，P2参数不正确
6A 80	数据域内容不正确
		69 83	认证模式锁定
69 88	密文数据或MAC错
		6E 00	CLA不支持
6D 00	INS不支持

参照图7，下面详细介绍容器的认证流程步骤。

容器的认证流程即获取访问权限(GET ACCESS RIGHT)的过程，容器认证可以采用PIN认证或者外部认证方式。取得容器的认证以获取插入对象的权限，可以在认证的同时创建该应用类，也可以选择以前创建的应用类以添加对象。但是经过认证获取的访问权限，当遇到下列任何一种情况时，这种权限将立即失效：

□□卡读取设备发出了一个SELECT CLASS命令

□□卡读取设备发出了GET ACCESS RIGHT命令

□□卡读取设备退出容器

通过容器的认证流程之后就可以将对象插入到容器内，容器的认证流程步骤一般可以包括以下步骤：

步骤1：根据P1判断是认证还是操作，如果是操作则转入步骤4。

步骤2：根据P1判断认证模式，如果是创建模式则转入步骤4，否则转步骤3。

步骤3：当前认证模式为添加模式，在容器内搜索指定的应用类，如果找到转步骤4，否则报引用数据未找到(6A88)。

步骤4：根据容器内的特征信息，判断认证的具体方法，如果是PIN认证则转到步骤5，否则转到步骤6。

步骤5：如果是PIN认证模式，则校验容器PIN，首先判别PIN是否锁定，如果锁定则终止并返回0x6983；否则比较校验值和对象内存储的值作比较，如果不同，则将错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为0，则表示该PIN已锁定；如果校验成功则恢复PIN的错误计数器为初始值，转到步骤9。

步骤6：首先判别容器认证密钥是否锁定，如果锁定则终止并返回0x6983；否则继续解析输入的OAID，如果其长度不足8字节，则后补0xFF直到补齐8字节，之后用作分散因子；如果OAID长度大于8字节，则取其最右8字节作为分散因子。用分散因子分散容器主控密钥得到应用类控制密钥，分散方式详见《中国金融集成电路卡规范-电子钱包电子存折应用规范》即可。

步骤7：利用相同的分散方法，用智能卡唯一性标识将应用类控制密钥分散，得到认证过程密钥。

步骤8：检查卡读取设备是否取过随机数，如果随机数有效则用该随机数作为输入，用认证过程密钥将其加密得到认证密文，和输入的密文比较，如果不一致则认证过程失败，将错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为0，则表示该密钥已锁定；如果认证成功恢复认证密钥的错误计数器为初始值转步骤9。

步骤9：判断是认证还是认证开关操作，如果是认证转步骤10，如果是认证开关操作转步骤11。

步骤10：根据P1的设置，在容器内创建新的应用类入口或选择指定的应用类入口，且在容器内并设置认证成功标志。

步骤11：根据P1的设置，激活或关闭容器认证功能。

参照图8，下面详述插入对象Insert Object的处理流程。所述插入对象的过程是指对象的创建过程，在创建对象的过程中将同时进行容器管理。

步骤1：检查P2是否为0x00；同时检查P1是否是指定范围内的值，如果有一项不满足则终止并返回6B00；

步骤2：检查内部状态，确认是否成功完成认证过程，如果完成则允许插入对象，否则终止并返回安全条件不满足代码6982。

步骤3：从数据内解析出对象标识OUID，检查是否具有和当前应用类入口相同的OAID，如果不满足则终止并返回数据域不正确代码6A80。

如果满足，则解析出对象属性Attrib和对象存取条件OAC。分析对象属性是否和P1参数里设定的插入对象的类型匹配，如果不满足则终止并返回数据域不正确6A80，否则继续分析，如果是密钥对象则解析属性的后续字节，并根据密钥的算法计算密钥的长度。

如果属性满足，则解析对象的内容，首先分析并保存存取条件列表ACL，在识别数据项内容时逐项在ACL里检索，如果定义了数据项的AC，则记录该数据项的AC到对象的ACL列表；如果在ACL里定义的标签是一个应用定义的模板，则模板内的所有数据项继承模板的AC；如果在ACL里没有定义数据项的AC，则设置缺省值0x00FF，表示读写权限为自由；如果是密钥对象，则记录对象的引用条件、计数器及更新条件到当前应用类入口的状态机描述列表中。

如果在解析对象内容时出现数据域内容不正确的情况，应终止并返回6A80，智能卡必须释放所有为该对象申请的临时空间，其它状态应恢复到插入该对象前的状态。

步骤4：将当前解析的对象插入当前应用类入口的对象列表中。

如果认证过程成功后，没有一个该应用类的对象插入到容器内，当卡读取设备选择离开容器或用另一个应用类的OAID进行认证时，当前的应用类入口应该释放。

参照图9，下面详述对象的存取Access Object处理流程。

对象的存取过程实际是对应用数据的存取，也可能是执行某个特定的功能，基于对象的操作可以至少包括两类：引用(Reference)和删除(Delete)。所述对象的存取Access Object处理流程可以包括以下步骤：

步骤1：检查P1、P2的值以及合法性，如果P2不为0x00或P1的值位8没置位，则终止并返回6B00。同时分析P1的值，进而确定具体的操作类型。

步骤2：解析输入的对象OUID，确认和当前应用类入口具有相同的OAID，如果不满足则终止并返回数据域不正确代码6A80。

在当前应用类入口对象列表里检索该对象，如果没找到，则终止并返回6A88。

步骤3：根据步骤1分析得到的操作类型，分别进入对应的操作流程。

下面分别对具体的操作流程进行详述：引用(Reference)过程流程、删除(Delete)过程流程、读取(Read)过程流程、更新(Update)过程流程、加值(Increase)过程流程、减值(Decrease)过程流程以及Unblock CAK处理流程。

(1)参照图10，详细描述引用(Reference)过程的流程步骤：

步骤4：将指令的数据域内容分解并检查数据域长度Lc和数据域是否匹配，以及数据域内部的结构是否正确。如果不正确返回数据域长度不正确代码6700。

步骤5：检查当前对象是否允许引用，如果不能引用则终止并返回6985。

根据对象的属性确定当前的引用操作是否合法，如果不正确返回使用条件不满足代码6985。

步骤6：如果当前对象为PIN密钥对象且P1指明是校验口令，则进入校验口令过程，首先判别此密钥对象是否锁定，如果锁定则终止并返回0x6983；否则比较校验值和对象内存储的值作比较，如果不同，则将错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为O，则表示该密钥已锁定。

步骤7：如果当前对象为PUK密钥对象且P1指明是PIN解锁，则进入PIN解锁过程，首先判别此密钥对象是否锁定，如果锁定则终止并返回0x6983；否则继续检查目标对象是否为PIN对象，如果不是则终止并返回使用条件不满足6985，如果目标对象是PIN密钥对象则继续检查该对象是否已经锁定，如果没有锁定则终止并返回安全状态不满足6982，否则就比较校验值和PUK对象内存储的值，如果相同则将目标PIN对象解锁，并设置其错误计数器为该密钥对象允许的最大值，如果不同，则将PUK密钥对象的错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为0，则将该密钥设置锁定标记。

步骤8：如果当前对象为密钥对象，当密钥属性是允许外部认证且P1指明是外部认证，则进入外部认证过程，首先判别此密钥对象是否锁定，如果锁定则终止并返回0x6983；

如果没有锁定，则检查卡读取设备是否取过随机数，如果随机数有效则用该随机数作为输入，用对象内的密钥将其加密得到认证密文，和输入的密文比较，如果不一致则认证过程失败。

如果密钥类型为非对称密钥，则按密钥属性里指明的方法补齐数据后处理。

步骤9：如果当前对象为密钥对象，当密钥属性是允许内部认证且P1指明是内部认证，则进入内部认证过程，首先判别此密钥对象是否锁定，如果锁定则终止并返回0x6983；

如果没有锁定，则将输入数据作为输入，用对象内的密钥将其加密得到密文并返回。

如果密钥类型为非对称密钥，则按密钥属性里指明的方法补齐数据后处理。

步骤10：如果当前对象为密钥对象，当密钥属性标是允许计算签名且P1指明是计算签名，则进入计算签名过程，首先判别此密钥对象是否锁定，如果锁定则终止并返回0x6983；

如果没有锁定，则检查卡内是否设置或计算Hash值，如果没有报6985，否则将Hash值按密钥属性里指明的算法补齐到密钥模长计算签名。

步骤11：如果当前对象为密钥对象，当密钥属性是允许校验签名且P1指明是校验签名，则进入校验签名过程，首先判别此密钥对象是否锁定，如果锁定则终止并返回0x6983；

检查卡内是否设置或计算Hash值，如果没有报6985，否则将输入的签名数据解开，解析出Hash值，和卡内的Hash值比较，比较结果一致返回9000，否则返回9xxx。

(2)参照图11，详细描述删除(Delete)过程的流程步骤：

步骤12：检查LC及数据的长度，如果不匹配则终止并返回6700。

步骤13：检查当前应用类的状态机，如果对象的删除条件满足，则将对象释放，并更新与此对象相关的列表。

(3)参照图12，详细描述读取(Read)过程的流程步骤：

步骤14：检查LC及数据的长度，如果不匹配则终止并返回6700。检查当前对象的属性是否为普通的数据对象，如果是计算对象或密钥对象，则终止并返回6985。

步骤15：根据读取数据项列表(DOL)，逐项检查当前应用类的状态机，如果数据项的读取条件满足，则将该数据项的内容读出并保存到一个列表，直到所有数据项处理完成。如果有一项的读取条件不满足，则终止并返回6985。数据项的内容读取完成后，返回读取的数据项内容列表。

(4)参照图13，详细描述更新(Update)过程流程：

步骤16：检查LC及数据的长度，如果不匹配则终止并返回6700。检查当前对象的属性是否为普通的数据对象，如果是计算对象或密钥对象，则终止并返回6985。

步骤17：根据更新数据项列表(DOL)，逐项检查当前应用类的状态机，如果所有数据项的更新条件都满足，则将该数据项的内容更新。如果有一项的读取条件不满足，则终止并返回6985，智能卡必须确保没有一项数据被更新。

(5)参照图14，详细描述加值(Increase)过程流程：

步骤18：检查LC及数据的长度，如果不匹配则终止并返回6700。检查当前对象的属性是否为计算对象，如果不是则终止并返回6985。

步骤19：检查当前应用类的状态机，如果数据项的加值条件满足，则将该数据项的内容更新，否则终止并返回6985，

(6)参照图15，详细描述减值(Decrease)过程流程：

步骤20：检查LC及数据的长度，如果不匹配则终止并返回6700。检查当前对象的属性是否为计算对象，如果不是则终止并返回6985。

步骤21：检查当前应用类的状态机，如果数据项的减值条件满足，则将该数据项的内容更新，否则终止并返回6985，

(7)参照图16，详细描述Unblock CAK解锁处理流程：

UnBlock CAK解锁处理流程可以用来解锁容器认证密钥，所述密钥可以是PIN密钥或是认证密钥。所述解锁处理流程优选的可以包括以下步骤：

步骤1：检查LC及数据的长度，如果不匹配则终止并返回6700。

步骤2：判断当前容器的认证模式，并判断指令里指明的模式是否正确，如果不正确，终止并返回安全条件不满足代码；否则继续，如果是PIN认证模式，转步骤3；如果是外部认证模式转步骤6。

步骤3：判断具体的操作类型，如果是解锁PIN，则转步骤4；如果是修改PIN，则转步骤5。

步骤4：首先判别用于容器认证的PIN密钥是否锁定，如果没有锁定则终止并返回0x6985；

否则继续判断用于容器认证的PUK密钥是否锁定，如果锁定则终止并返回0x6983；

否则比较校验值和保存PUK的值作比较，如果不同，则将PUK错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为0，则表示PUK密钥已锁定。如果校验成功则44将容器认证PIN的错误计数器恢复为初始值，同时恢复PUK密钥的错误计数器为初始值并结束指令流程。

步骤5：首先判别用于容器认证的PIN密钥是否锁定，如果锁定则终止并返回0x6983；

否则比较校验值和保存的PIN值作比较，如果不同，则将PIN错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为0，则表示PIN密钥已锁定。如果校验成功则更新PIN的值，恢复PIN的错误计数器为初始值并结束指令流程。

步骤6：首先判别容器认证密钥是否锁定，如果没有锁定则终止并返回0x6985；

否则继续判断解锁容器认证密钥的密钥是否锁定，如果锁定则终止并返回0x6983；解析输入的OAID并检查长度，如果不足8字节，则后补0xFF直到补齐8字节，之后用作分散因子；如果OAID长度大于8字节，则取其最右8字节作为分散因子。用分散因子分散用于解锁容器认证密钥的解锁密钥，得到应用类解锁密钥，分散方式可以详见《中国金融集成电路卡规范-电子钱包电子存折应用规范》。

利用相同的分散方法，用智能卡唯一性标识将应用类解锁密钥分散，得到解锁过程密钥。

检查卡读取设备是否取过随机数，如果随机数有效则用该随机数作为输入，用解锁过程密钥将其加密得到认证密文，和输入的密文比较，如果不一致则解锁过程失败，将解锁密钥的错误计数器减1，返回0x6Cxx，xx为剩余的可尝试次数；如果错误计数器为0，则表示该密钥已锁定；如果比较结果一致则将容器认证密钥的错误计数器恢复为初始值，同时恢复解锁密钥的错误计数器为初始值并结束指令流程。

由于本发明所述智能卡上可以存在多个应用，则为了独立地管理容器内的不同应用类，每一个应用类优选的应该放在一个单独的区间。亦即在应用类之间应该设计一道“防火墙”以防止跨过应用类进行非法访问。

为了实现密钥功能的独立性，优选的，用于一种特定功能的加密/解密密钥不能被任何其他功能所使用，包括保存在IC卡中的密钥和用来产生、派生、传输这些密钥的密钥。

安全报文传送的目的是保证数据的可靠性、完整性和对发送方的认证。数据完整性和对发送方的认证可以通过使用MAC来实现。数据的可靠性可以通过对数据域的加密来得到保证。

实现上述的安全报文传送的具体方式可以参见下述实例。

例如，采用APDU报文进行传送，当CLA字节的第二个半字节等于十六进制数字“4”时，表明对发送方命令数据要采用安全报文传送。当使用安全报文传送时，命令数据域中的数据用TLV结构标识，格式可以采用“OUID+命令关联数据+MAC”。为保证命令中明文数据的保密性，可以将数据加密。加密时包含加密数据的标签和长度，在APDU加密数据中不包括OUID和读写数据时的DOL。

在执行安全报文前从智能卡取得的随机数前两个字节定义为ICVprefix，将ICVprefix用指定数据补齐为8字节作为计算MAC得ICV。

ICVprefix＝智能卡随机数前两个字节

ICV＝ICVprefix+“0F 00 00 00 00 F0”

如果连续进行安全报文传输，则将ICVprefix作为整数值加1后的值做为新得ICVprefix，重新补齐后做为新得ICV参与安全报文MAC得计算，如此类推。如果在连续的安全报文之间有使用随机数的命令、发出选择容器命令或选择应用类命令出现，则前面取得的随机数失效，卡读取设备必须重新取智能卡随机数以计算ICVprefix。MAC的计算数据从CLA字节开始到数据域结束。

下面通过一个咖啡店对顾客发行积分卡的具体实施例对本发明的思想进行详细说明。

某咖啡店准备对顾客发行积分卡，以便在激烈的市场竞争中保持顾客的忠诚度，计划将对持积分卡的顾客实行一定的优惠和赠送，但这些优惠计划是可变的，也可能针对不同的顾客群实施不同的优惠计划。对智能卡的要求是智能卡上要记录顾客的积分值、VIP级别和身份识别信息，可以在发卡后安全的修改相关内容。

根据积分计划需求，可以做如下设计：

                  表11：发行积分卡的初始化信息

应用信息
					应用类名称OUID				6.86.1.0.0.1
应用类标识				QQ咖啡店
					密钥对象
对象序号	对象属性	代码	密钥用途
					01	80 69 00	DropKey	管理密钥，用于删除对象
02	80 89 00	MtKey	维护密钥，用于修改基本信息
					03	80 89 00	IncKey	积分加值密钥
04	80 89 00	DecKey	积分减值密钥
					数据对象
对象序号	对象属性	说明
					05	00	持卡人基本信息

标签		数据项	读权限	写权限
					B1		固定数据模板	-	-
91		持卡人姓名	自由	不允许
					92		会员编号	自由	不允许
93		VIP级别	自由	维护密钥
					06	40	积分对象

所需要发行的智能卡设计完成之后，就可以开始智能卡个人化过程。所述个人化阶段主要是将应用对象插入到容器中，如何在智能卡上创建容器这里不做描述，在个人化时，根据实际的商业营运模式，可能是单独发卡，也可能是在合作伙伴的卡上添加本积分计划。

假定所述需要个人化的智能卡采用以下的APDU命令编码

                      表12：预置的APDU命令编码

CLA	INS	名称	引用
				80	40	插入对象(INSERT OBJECT)	-
8X	42	引用对象(ACCESS OBJECT)	-
				80	46	获得访问权限(GET ACCESS right)	-
80	24	解锁容器认证密钥(UNBLOCK CAK)	-
				80	58	容器加锁/解锁(LOCK/UNLOCK)	-
80	48	计算Hash(COMPUTE HASH)	-
				80	A4	选择应用类(SELECT CLASS)	-
80	4E	取应用类列表(LIST CLASS)	-
				00	C0	取返回数据(GET RESPONSE)	ISO/IEC7816-4
00	84	取随机数(GET CHALLENGE)	ISO/IEC7816-4

所述智能卡个人化过程可以包括以下步骤，其中命令部分采用上表进行代替对应示出。

步骤1：选择容器，得到容器的认证信息

To Card：00 A4 04 00 10“CUP CONTAINER001”

From Card：

70 1D 5F 01 01 40 5F02 08 11 22 33 44 55 66 77 88 5F03 01 00 5F04

02 FF FE 5F05 02 A0 00

在此假定容器的认证功能为激活状态，认证模式为PIN认证；同时已经获知容器的剩余空间以及容器的版本号等信息。

步骤2：认证容器

To Card：

80 46 01 00 1D 61 11 4F 05 46 01 00 00 01 50 08“QQ咖啡店”57 08

26 12 34 56 FF FF FF FF

From Card：90 00

根据第1步得到的信息，用容器的PIN对容器进行认证并创建本应用类，假设容器PIN的值为“123456”。

在该步骤中，如果是外部认证模式，则首先从智能卡取随机数，将用认证密钥加密随机数后的认证数据替换上面的认证数据；如果第一步标明容器认证功能为关闭，则可以跳过这一步。

步骤3：插入应用对象

首先需要插入所有应用密钥到容器中：

To Card：

80 40 80 00 2E 7A 2C 51 06 46 01 00 00 01 01 52 03 80 69 00

53 02 00 01 7B 19 54 03 55 FF 02 55 12 00 00 DropKey

From Card：90 00

To Card：

80 40 80 00 2E 7A 2C 51 06 46 01 00 00 01 02 52 03 80 89 00

53 02 00 01 7B 19 54 03 55 FF 02 55 12 00 00 MtKey

From Card：90 00

To Card：

80 40 80 00 2E 7A 2C 51 06 46 01 00 00 01 03 52 03 80 89 00

53 02 00 01 7B 19 54 03 55 FF 02 55 12 00 00 IncKey

From Card：90 00

To Card：

80 40 80 00 2E 7A 2C 51 06 46 01 00 00 01 04 52 03 80 89 00

53 02 00 01 7B 19 54 03 55 FF 02 55 12 00 00 DecKey

From Card：90 00

需要注意的是，如果需要密文安装密钥，则首先必须安装一个传输密钥，再将所有准备密文安装的密钥的属性和ACL列表用Insert object指令写入容器后，用Access object以密文的方式将密钥值导入容器。

再插入应用的数据对象：

To Card：

80 40 00 00 2C 7A 2A 51 06 46 01 00 00 01 05 52 01 00

53 02 00 01 7B 19 54 06 B1 00 FF 93 00 02 B1 0C 91 05“Tiger”92 03

39 35 38 93 01 01

From Card：90 00

To Card：80 40 40 00 1E 7A 1C 51 06 46 01 00 00 01 06 52 01 40 53 02

00 01 7B 0B 54 03 56 03 04 56 04 00 00 00 00

From Card：9000

至此，积分应用的个人化工作就完成了。

积分智能卡的个人化完成之后，下面对积分应用的使用示例进行详细介绍：

根据实际的业务需求，积分应用的使用示例包括两方面，一方面是查询积分和个人信息，另一方面是增减积分值。

假设，我们已经预定义了一些算法和数据代码，如下表所述，

   表13：预置的算法和数据代码

代码	含义
		Fenc	加密算法
Fmac	MAC算法
		Fpad	数据补齐算法
ICV	计算安全报文的初始值
		MD	计算MAC的输入数据

□□查询积分和个人信息

查询个人信息：

To Card：80 A4 00 00 05 46 01 00 00 01

From Card：90 00

To Card：

80 42 B0 00 0D 51 06 46 01 00 00 01 05 58 03 91 92 93

From Card：“Tiger”39 35 38 01

查询积分：

To Card：80 A4 00 00 05 46 01 00 00 01

From Card：90 00

To Card：80 42 B0 00 0B 51 06 46 01 00 00 01 06 58 01 56

From Card：00 00 00 00

□□增减积分值

增加1000点积分：

To Card：80 A4 00 00 05 46 01 00 00 01

From Card：90 00

To Card：00 84 00 00 08

From Card：F2 87 AA 3D 93 6A C1 8F 90 00

To Card：84 42 C0 00 1B 51 06 46 01 00 00 01 05 58 01 93

57 08 EncValue 59 04 Mac

From Card：90 00

EncValue＝Fenc(IncKey，“00 00 03 E8”)

MD＝Fpad(“84 42 D0 00 1B 51 06 46 01 00 00 01 06 58 01 56 57 08”EncValue)

ICVprefix＝“B0 01”

ICY＝ICVprefix+“0F 00 00 00 00 F0”

Mac＝Fmac(IncKey，ICV，MD)

扣减500点积分：

To Card：84 42 E0 00 1B 51 06 46 01 00 00 01 06 58 01 56

57 08 EncValue 59 04 Mac

From Card：90 00

EncValue＝Fenc(DecKey，“00 00 01 F4”)

MD＝Fpad(84 42 E0 00 1B 51 06 46 01 00 00 01 06 58 01 56 57 08EncValue)

ICVprefix++

ICV＝ICVprefix+“0F 00 00 00 00 F0”

Mac＝Fmac(DecKey，ICV，MD)

□□修改VIP等级

To Card：80 A4 00 00 05 46 01 00 00 01

From Card：90 00

To Card：00 84 00 00 08

From Card：B0 01 0E 6F 1E 76 5E 60 90 00

To Card：84 42 D0 00 1B 51 06 46 01 00 00 01 06 58 01 56

57 08 EncValue 59 04 Mac

From Card：90 00

EncValue＝Fenc(MtKey，“02”)

MD＝Fpad(“84 42 C0 00 1B 51 06 46 01 00 00 01 05 58 01 93 57 08”EncValue)

ICVprefix＝“F2 87”

ICV＝ICVprefix+“0F 00 00 00 00 F0”

Mac＝Fmac(MtKey，ICV，MD)

在积分应用使用一段时间后，可能要添加新的对象来支撑新的业务需求，这其实就是对已发行应用的修改或维护。下面对可能发生的积分计划变更的流程进行说明：

□□删除对象

删除对象的权限可以由应用类自己控制，所以无需对容器进行认证，只要符合对象的删除条件，就可以将指定的对象删除。

□□添加对象

添加对象必须完成对容器的认证，过程和个人化相同。

□□修改对象

由于对象创建后只能修改数据项的内容，无法添加数据项或修改数据项的属性，如果应用必须修改对象的内容，则必须首先删除该对象，然后再重新创建该对象。

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

Claims (13)

1、一种实现智能卡多应用的方法，其特征在于，包括：

设置至少一个容器；

将数据按照容器和对象的方式存储，每个容器内包含至少一个应用的对象集合；

设置容器的操作接口，以实现通用的针对对象的操作。

2、如权利要求1所述的实现智能卡多应用的方法，其特征在于，还包括：

根据数据的特性，将数据分别存储为数据对象、计算对象和密钥对象；所述数据对象用于存储应用数据，所述计算对象用于存储敏感数据，所述密钥对象用于存储应用的密钥数据。

3、如权利要求2所述的实现智能卡多应用的方法，其特征在于，还包括：

将实现特定功能的指令序列数据存储为应用协议数据单元APDU对象。

4、如权利要求3所述的实现智能卡多应用的方法，其特征在于，还包括：

设置虚拟机和指令系统，用以支持APDU对象在智能卡内的执行。

5、如权利要求3所述的实现智能卡多应用的方法，其特征在于，还包括：如果所述对象属于同一应用，则APDU对象被外部调用，数据对象通过APDU对象被外部引用，密钥对象被数据对象或其它密钥对象引用。

6、如权利要求1所述的实现智能卡多应用的方法，其特征在于，所述对象包括以下信息：标识、属性、对象的存取条件以及对象的内容。

7、如权利要求6所述的实现智能卡多应用的方法，其特征在于，所述对象的内容包括数据项存取条件以及数据项本身。

8、如权利要求7所述的实现智能卡多应用的方法，其特征在于，所述具有相同存取条件的数据项采用统一的模板进行封装，模板内的所有数据项都继承模板的存取条件。

9、一种数据处理装置，特别是智能卡，其特征在于，包括：微处理器、非易失性存储器以及操作系统；所述操作系统将数据按照容器和对象的方式存储在非易失性存储器中，存储在至少一个容器中，每个容器内包含至少一个应用的对象集合；所述操作系统设置容器的操作接口，以实现通用的针对对象的操作。

10、如权利要求9所述的数据处理装置，特别是智能卡，其特征在于，所述对象包括：用于存储应用数据的数据对象，用于存储敏感数据的计算对象，用于存储应用的密钥数据的密钥对象。

11、如权利要求10所述的数据处理装置，特别是智能卡，其特征在于，所述对象还包括：用于存储实现特定功能的指令序列数据的应用协议数据单元APDU对象。

12、如权利要求11所述的数据处理装置，特别是智能卡，其特征在于，还包括：虚拟机和指令系统，用以支持APDU对象指令的执行。

13、如权利要求11所述的数据处理装置，特别是智能卡，其特征在于，如果所述对象属于同一应用，则APDU对象被外部调用，数据对象通过APDU对象被外部引用，密钥对象被数据对象或其它密钥对象引用。

Images