java卡,gp规范

Globalplatform全球平台——————————卡规范版本 2.1.12003.3收到这份文件的人如果认为该文档上的实施规范侵犯了自己的专利权或知识产权请提交疑问和相关有力的证明文件。

目录1 介绍......................................................... . (13)1.1 概述......................................................... .. (14)1.2 参考文献......................................................... (14)1.3 术语及定义......................................................... (15)1.4 缩写和符号......................................................... (17)1.5 修订历史......................................................... . (17)1.51. 开放平台卡规范V2.0到开放平台卡V2.0.1 (17)1.5.2 全球平台卡规范V2.1中的主要调整 (18)1.5.3 全球平台卡规范V2.1中的修订 (19)构......................................................... (20)3 卡架构......................................................... .. (21)3.1 运行环境......................................................... (22)3.2 卡管理机制......................................................... .. (22)3.2.1 全球平台环境（open）............................................................. (22)3.2.2 发卡方安全域................................................................... .. (22)3.2.3 持卡人验证管理................................................................... . (22)3.3 安全域......................................................... (22)3.4 全球平台API........................................................ .. (23)容......................................................... (23)4 安全架构......................................................... . (24)4.1 目标......................................................... . (24)4.2 安全责任4.2.1 发卡方的安全责任4.2.2 应用提供者的安全责任4.2.3 控制机构的安全责任4.2.4 卡上组件的安全责任4.2.5 后台系统的安全责任4.3 加密支持4.3.1 对卡内容的完整性和身份认证的管理4.3.2 安全会话5 生命周期模块5.1 卡的生命周期5.1.1 卡的生命周期状态5.1.2 卡的生命周期转换5.2 可执行加载文件/可执行模块的生命周期 5.2.1 可执行加载文件的生命周期5.2.2 可执行模块的生命周期5.3 应用和安全域的生命周期5.3.1 应用的生命周期状态5.3.2 安全域的生命周期状态5.4 生命周期示例图6 卡片的管理模块6.1 卡管理模块总览6.1.1 OPEN模块6.1.2 发卡方安全域模块6.1.3 持卡人验证管理句柄模块6.2 卡管理模块提供的服务6.2.1 应用访问OPEN的服务6.2.2 应用访问持卡人验证管理的服务6.2.3 应用访问发卡方安全域的服务6.2.4 发卡方安全域访问应用6.3 命令调度6.3.1 基本的逻辑信道6.3.2 补充的逻辑信道6.4 卡内容管理6.4.1 卡内容的下载和安装6.4.2 内容移除6.4.3 内容引渡6.5 委托管理权6.6 全球平台的注册6.6.1 发卡方安全域的数据元素描述6.6.2 应用/可执行加载文件/可执行模块的数据元素6.7 对安全的管理机制6.7.1 应用锁定6.7.2 卡锁定6.7.3 卡的销毁6.7.4 运行速度检测6.7.5 跟踪和事件日志6.7.6 安全内容的下载和安装6.8 发卡方安全域6.8.1 发卡方标识编号6.8.2 卡的描述编号6.8.3 卡的识别数据6.8.4 实卡的密钥信息6.9 CVM 管理机制6.9.1 CVM状态6.9.2 CVM格式7 安全域7.1 概述7.2 安全域服务7.2.1 应用访问安全域服务7.2.2 安全域访问应用7.3 对个人化的支持7.4 对运行时间管理的支持7.5 DAP 验证7.6 委托管理权7.6.1 下放下载功能7.6.2 下放安装功能7.6.3 下放引渡功能7.6.4 下放删除功能7.7 委托管理权的令牌，回执和DAP验证 7.7.1 下载令牌7.7.2 下载回执7.7.3 安装和引渡令牌7.7.4 安装回执7.7.5 引渡回执7.7.6 删除回执7.7.7 下载文件数据块的hash7.7.8 下载文件数据块签名（DAP验证）8 安全通信8.1 安全信道8.2 显式/隐式的安全信道8.2.1 显式安全信道的启动8.2.2 隐式安全信道的启动8.2.3 安全信道的关闭8.3 直接/间接的交出安全信道协议8.4 实体认证8.5 报文发送的安全8.6 信道协议标识的安全9 APDU命令的参考9.1 基本编写规则9.1.1 生命周期状态的设定9.1.2 应用权限设定9.1.3 一般错误状态9.1.4 类字节设定9.1.5 APDU命令和响应数据9.1.6 Key类型设定9.1.7 在委托管理响应消息中的可选回执9.2 删除命令9.3 获得数据命令9.4 获得状态命令9.5 安装命令9.6 下载命令9.7 管理信道命令9.8 输入密钥命令9.9 选择命令9.10 设置状态命令9.11 存储数据命令A 全球平台的 APIA.1 非开放平台java卡的APIA.2 java卡上的全球平台A.3 Windows支持的智能卡上的全球平台B 算法（密码的和hash的）B.1 数据加密标准（DES）B.1.1 加密/解密B,1,2 MACingB.2 hashing算法B.2.1 安全hash算法（SHA-1）B.3 公共密钥加密方案1（PKCS#1）B.4 DES填充C 安全内容管理C.1 密钥C.1.1 发卡方安全域密钥C.1.2 安全域密钥C.2 加载文件数据块hash C.3 令牌C.3.1 加载令牌C.3.2 安装令牌C.3.3 引渡令牌C.4 回执C.4.1 加载回执C.4.2 安装回执C.4.3 删除回执C.4.4 引渡回执C.5 DAP验证C.5.1 PKC策略C.5.2 DES 策略D 安全通道协议01D.1 安全通信D.1.1 SCP01的安全信道 D.1.2相互认证D,1,3 消息的完整性D.1.4 消息数据的保密性 D.1.5 ICV加密D.1.6 安全等级D.2 加密密钥D.3.1 DES会话密钥D.3.2认证密码D,3,3 APDU命令MAC的生成和验证D.3.4 APDU数据域的加密和解密D.3.5 密钥敏感数据的加密和解密D.4 安全信道的APDU命令D.4.1 初始化更新命令D.4.2 外部认证命令E 安全信道协议02E.1 安全通信E.1.1 SCP02的安全信道E.1.2 实体认证E.1.3 消息的完整性E.1.4 消息数据的保密性E.1.5 安全等级E.2 加密密钥E.3 加密算法E.3.1 密码块链（CBC）E.3.2 使用显式信道初始化的ICV消息的完整性 E.3.3 使用隐式信道初始化的ICV消息的完整性 E.3.4 ICV加密E.4.1 DES 会话密钥E.4.2 显式信道初始化中的认证密码 E.4.3 隐式信道初始化中的认证密码 E.4.4 APDU命令C-MAC的生成和验证 E.4.5 APDU响应R-MAC的生成和验证 E,4,6 APDU命令数据域的加密和解密 E.4.7 敏感数据的加密和解密E.5 安全信道APDU命令E.5.1 初始化更新命令E.5.2 外部认证命令E,5,3 开始R-MAC会话命令E.5.4 结束R-MAC会话命令F 全球平台数据的值和卡识别数据F.1 数据的值F.2 卡识别数据结构F.3 安全域管理数据Copyright 2003 GlobalPlatform Inc. All Rights Reserved.The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of thisinformation is governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictlyprohibited.表格索引目录略Part1 介绍1 介绍全球平台是一个由通信支付行业领头的公司，政府和供应商联合成立的组织，是第一个去为智能卡在多行业之间的应用促进形成一个全球化的基础架构的组织。

GlobalPlatform Card Specification NutShell1.AbstractThe GlobalPlatform card specification is a standard for the management of the infrastructure of a smart card. This management comprises the installation, the removal of applications and additional management tasks on a card. The main authority for this is the card issuer, which has full control over the card contents, but he can grant also other institutions to administrate their own applications. This management is achieved by applying cryptographic protocols, which authenticate and encipher these processes. The Open Platform specification should enable multi application capable smart cards which can be joined by multiple institutions where all installations are authorized by the card issuer and each institution has its own secure area on the card.2.Overview over Architecture2.1 Runtime EnvironmentGlobalPlatform can be built on top of every multi application capable runtime environment. In practice the runtime environment is always the Java Card Runtime Environment.2.2 Security DomainA Security Domain is a protected area on a smart card. To this Security Domain are assigned applications, which can use cryptographic services it offers. By default only the Security Domain of the card issuer exists on a card. If another institution wants to have its own Security Domain, e.g. for having its own secure application environment or managing its own applications, such a domain can be created with the help of the card issuer. Institutions managing their own applications are also referred to as Application Providers.2.3 Card ManagerThe card manager is the central component of a GlobalPlatform card. Every service is executed by it and it offers interfaces to use its services internal through the GlobalPlatform API and external through APDU commands. In addition the Card Manager includes the Security Domain of the card issuer, due to the fact that it can also own applications on the card.2.4 GlobalPlatform APIThe GlobalPlatform API gives applications on the card access to certain management functions of the Card Manager and the possibility to authenticate the communication partner and using a secure channel with it within the current active Security Domain.3.Concepts and FunctionalityFor a use case diagram illustrating the common usages see the following figure:3.1 Mutual Authentication and Negotiated Security LevelTo access the management functions of a card it is necessary to authenticate the host and the card against each other. Only in an early life cycle state of teh card, this is not necessary. If the Security Domain of the card issuer is not the default selected application or another Security Domain should be the context of the communication session it must be chosen by executing a SELECT command, which must be given the AID of the Security Domain. An AID is a hexadecimal identifier for application concerning card content. The most common default AID of the Security Domain of the card issuer is A0 00 00 00 03 00 00 00.Each Security Domain owns at least a set of three 3DES keys, the Secure Channel Keys, which must also be known to the host system. These three keys are the Encryption Key, which is used to generate an encryption session key for encrypting the transmitted messages, the Message Authentication Key, to generate a MAC session key for ensuring the integrity of transmitted messages and the Key Encryption Key to encrypt newly transferred keys. The first command sent to the card is the INITIALIZE UPDATE command. The INITIALIZE UPDATE command transmits a random number and states which key set version should be used during thefollowing session and at which key index the three successive keys are found. The values 0 for the key set version and 0 for the key index are used to denote the first available keys. The random number is encrypted with the Encryption Key in 3DES ECB mode and the resulting card cryptogram is sent back with an own random number to challenge the host. If the card cryptogram is verified successfully the host encrypts the random number of the card also in 3DES in ECB mode and sends the host cryptogram back in an EXTERNAL AUTHENTICATE command. The card verifies also this host cryptogram. With the EXTERNAL AUTHENTICATE command the host proposes a security level during the communication of this session. This security level can be plain text, where no integrity or confidentiality is given, the integrity of each message can be protected by appending a MAC using the MAC session key or in addition to the integrity also the confidentiality of the messages can be assured by using the encryption session key.3.2 Loading, Installation and Removal of contentsThe most noticeable task is the management of the card content. These are the loading, the installation and the removal of card contents. These tasks are performed in the context of a Security Domain.3.2.1 Loading and InstallationThe complete loading and installation happens in four steps:3.2.1.1 INSTALL [for load]The INSTALL [for load] command prepares the card to a following LOAD command. With this command the AID of the Load File Data Block is transmitted and the AID of the Security Domain, in which the Load File Data Block will be installed. A Load File Data Block is a data block, which contains one or more applicationsor libraries. In the case of the Java Card Runtime Environment this is equivalent to a package which can be saved in a format like the CAP format or the more common IJC format. Also parameters concerning the resource allocation on the card are indicated. These are the necessary space for storing the Load File Data Block referred to as Non Volatile Code Space Limit, the needed space of persistent memory to store the resulting data of the application, referred to as Non Volatile Data Space Limit and the amount of volatile memory space, which is needed during execution of the application, referred to as Volatile Data Space Limit. The most cards are only interested in the Non Volatile Code Space Limit. Optional a Load File DAP can be given. A Load File DAP is a hash to verify to correct transmission of a Load File. To accomplish this, the whole Load File is hashed by SHA-1. A Load File can contain in addition to a Load File Data Block prefixed Load File Data Block DAPs. The point DAP Verification and Mandated DAP Verification should clarify this. If all given arguments are checked, which is the case, if no content on the card has the same AID like this Load File Data Block, the associated Security Domain does exist and the requested resource allocations can be satisfied.3.2.1.2 LOADThe LOAD command transfers the Load File in one or multiple messages depending on the Load File size to the card. If a Load File DAP was contained in the INSTALL [for load] command, the validity of this hash is verified. From the contained Load File Data Block a so called Executable Load File is created with the same AID as the Load File Data Block. An entry of the Executable Load file is created in the registry of the Card Manager and its associated Security Domain. The registry contains information of all installed contents, its privileges and its associated Security Domains.3.2.1.3 INSTALL [for install]This command installs an application from an Executable Load File. Therefor the AID of the Load File Data Block, which is the Executable Load File, the AID of the one to be installed content in the Executable Load File and the intended AID of application instance is declared. The one to be installed content equals in the context of the Java Card an applet class. The AID of the application instance corresponds to the AID of the applet class instance which is running the whole card life and which is used to select the application. In addition the resource concerning parameters like in INSTALL [for load] for the application are given. Most cards are only interested in the amount of the Non Volatile Data Space Limit. Another mandatory argument is the application privileges. Some notable privileges here are the Security Domain privilege, which states that the installed application is a Security Domain and the privilege, that the application is the default selected application, which means that it is selected implicitly byconnecting to a card. Other privileges are mentioned in the following paragraphs. To the installed application a maximum of 32 bytes of install parameters can be passed. In the Java Card terminology the install method of the applet is called with these parameters. If the Executable Load File is existent on the card, the application is contained in the Executable Load File, the application instance AID is not used by another content on the card and the resource requirements can be satisfied, the Card Manager creates an application from the Executable Load File, an entry for the application instance in the registry and associates its Security Domain.3.2.1.4 INSTALL [for make selectable]The INSTALL [for make selectable] command makes the application available to be selected. The AID of the application instance and the applet privileges are required. If the AID exists the application instance is marked as SELECTABLE in its life cycle status. A life cycle state of an application defines the selectable state of an application. E.g. after the INSTALL [for install] command the application is in the state INSTALLED. A complete overview of the life cycle states is given in the paragraph Life Cycle Management. The last to steps can be combined in a INSTALL [for install and make selectable] command.3.2.2 Removal3.2.2.1 DELETEA DELETE command deletes content on a card by its AID. Before this is done it is checked if the AID exists in the registry and if this content is not referenced by another installed content on the card. E.g. installed applications depend on their Executable Load File. If the content can be deleted its entry is removed from the registry and all persistent is marked as available.3.3 Delegated ManagementBy default only the Security Domain of the card issuer is allowed to load, install and remove contents on a card. To enable also other Application Providers with their Security Domain on the card to manage their contents the privilege of Delegated Management was introduced. This privilege must be given to the Security Domain by installation time. In order that the card issuer keeps the control of the card each content change must be authorized by him. Content which is loaded and installed on a card must be signed by a digital signature of the card issuer. The loading of content is granted by the verification of a Load DAP, also referredto as Load Token, during the INSTALL [for load] phase. The installation of content is granted by the verification of a Install DAP, also termed Install Token, in the INSTALL [for install and make selectable] command. Separate INSTALL [for install] and INSTALL [for make selectable] commands are not possible. These DAPs are calculated with RSA PKCS#1 over the parameters given in the INSTALL [for install and make selectable] command. To verify the signature the Security Domain of the card issuer must has access to a public RSA key, referred to as Token Key. In the case of a DELETE command no DAP is necessary. The execution of the loading, installation and removal is confirmed by the return of the Receipt. A Receipt is the proof to the card issuer that the owner of the Security Domain with Delegated Management privilege has carried out the operation. The Receipt is a MAC with a variation of 3DES in CBC mode. To calculate this Receipt the Security Domain of the card issuer must know a 3DES key for the Receipt generation. This key is termed Receipt Key. There is one Receipt type according to each loading and installation process. Every Receipt signs some card unique data together with a confirmation counter. The card unique data is some data which makes this card distinguishable from other cards. The confirmation counter assures that no former Receipt can be used to forge the confirmation. The Load Receipt signs in addition the Executable Load File AID created by the LOAD command and the associated Security Domain AID. The Install Receipt signs also the Executable Load File AID and the application instance AID. The computation of the Delete Receipt includes the AID of the deleted content.3.4 DAP Verification and Mandated DAP VerificationDAP Verification permits another institution as the card issuer to verify the integrity of a Load File Data Block. This can be useful if a Security Domain has not the ability to load content to the card or if a controlling entity may require that all content is certified. At installation time the Security Domain must obtain the DAP Verification privilege and after its installation a DAP Verification Key, a 3DES key or public RSA key, must be deposited in it to verify the integrity of the loaded content. To check the integrity a Load File Data Block DAP must be created by calculating a digital signature with RSA PKCS#1 or a MAC with a variation of 3DES in CBC mode over the Load File Data Block. The result of this operation is also called DAP Block. This DAP Block is prefixing the Load File Data Block and transferred as Load File with the LOAD command. The DAP Block is verified by the Security Domain with its key. If the DAP Block is valid the loading is granted. The difference between DAP Verification and Mandated DAP verification is that the Card Manager only contacts the Security Domain with the first privilege if the Security Domain is the associated Security Domain of the content to be loaded while a Security Domain with the second privilege must always verify the content which is loaded to the card.3.5 Key ManagementTo support the management function a variety of keys are necessary. Apart from the mandatory Encryption Key, Message Authentication Key and Key Encryption Key the Security Domain of the card issuer can have a Token Key and a Receipt Key, referred to as Delegated Management Keys, to support Delegated Management. A Security Domain or another institution can have a DAP Verification Key.3.5.1 PUT KEYThe PUT KEY command is used to populate the Security Domain with keys or replace existing keys. The pure Open Platform specification does not provide a way to delete keys. Beneath the possibility to put or replace Secure Channel and Delegated Management Keys, single keys can also be managed. The PUT KEY command must be passed one or multiple keys, the key set version in which the key(s) should be added or replaced and the key index within this key set version where the first key should be stored. For Delegated Management Keys there may be restriction on the key set version number. On some card it is possible to view key information or delete keys. If the card does not offer a way of deleting keys and view key information the tracking of available keys is the responsibility of the owner of the Security Domain.3.5.2 Viewing Key InformationIf a card supports the retrieval of key information the GET DATA command is used to obtain key information templates of the selected Security Domain. Key information templates contain the key set version number the key belongs to, the key index of the key and the key type.3.6 DELETE [key]Another optional enhancement is the deletion of keys in a Security Domain. Necessary parameters are the key set version number and the key index. It is possible to delete a whole key set version by giving the key set version number and a key set index of zero. The same is possible for keys with the same key index by giving a key set version number of zero.3.7 Life Cycle ManagementTo reply to security violations each application, Executable Load File and the Card Manager have a life cycle state.For the card issuer Security Domain those values can be OP READY, INITIALIZED, SECURED, LOCKED and TERMINATED. The difference between OP READY and INITIALIZED is only administrative and both mean, that the card is ready for receiving command, but is not ready for card holder. The state INITIALIZED can mean that already a key set version is installed. The state SECURED means that the card is ready for the card holder. A key set version is installed and all communication must take place in a secure channel. The last three states are irreversible. The state LOCKED may mean that a security violation has occurred and no application except the Card Manager can be selected and no key and content change is allowed to happen. The state TERMINATED means the end of the life of the card and the card shall only respond to a GET DATA command. Usually only the Security Domain of the card issuer can lock or terminate the card. Other Security Domains must have the Card Manager Lock privilege and Card Terminate privilege respectively.An Executable Load File can only be in the state LOADED.An application has three possible life cycle states. These are INSTALLED, SELECTABLE and LOCKED. If an application should not be selectable the application can be LOCKED. An application can only be unlocked by its Security Domain.A Security Domain can be in state INSTALLED, SELECTABLE, PERSONALIZED and LOCKED. The state PERSONALIZED means that the Security Domain is equipped with some personal content like keys. A Security Domain can be associated with content in this state. For a Security Domain the state LOCKED means, that only the Security Domain of the card issuer can unlock it.3.7.1 GET STATUSWith this command the life cycle status of the Card Manager, Executable Load Files and applications can be obtained. Additional the application privileges are returned.3.7.2 SET STATUSThe command SET STATUS is used to set the life cycle state of an installed content. The AID of the card content to set the life cycle state must be given. Some lifecycle states can only be set with a method of the Open Platform API by an application on the card.3.8 Card DataThere is a variety of card data objects. The Open Platform specification proposes only that the CPLC data should be retrievable. CPLC is an abbreviation for Card Production Life Cycle. This data object contains information about the production process of the card like the operating system or the ICC manufacturer. The Card issuer BIN data contains usually the serial number of the card. Apart from that the user defined Card issuer data can be used e.g. for deriving the keys. Some other possible values can be the available resources like EEPROM space.3.8.1 GET DATAThe GET DATA command is used to retrieve the above data. Each card data object has a tag name which is used to access it.3.8.2 PUT DATAPossible writable data can be stored with the PUT DATA command. The same tag names for the card data objects like in GET DATA are used.。

PBOC2.0 DC；
社保；
PSAM或者ESAM；
Key卡；
USBKey。
案例数量
数量逐步增加，突出表现在借贷记应用领域、新业务领域和复合应用领域。
已经广泛的应用在一些传统的领域，或者有一定历史的项目中。
容量和价格
EEPROM空间大小
通常为20K，36K，72K或者更大，便于对于多应用的支持
通常为8K,16K或者32K,36K，便于节约成本，大批量展开。
RSA密钥长度支持
按照JavaCardAPI接口V2.2.1，支持512，736，768，896，1024，1280，1536，1984，2048位长度的密钥。
可以支持芯片所能支持的按8字节或者4字节长度递增的密钥长度。
协作开发
可以开发一种特殊的Applet，作为可以被其他应用Applet调用的通用的功能模块(Library)，以便于统一提供一些功能的实现。
添加全新的指令
对相应的Applet源代码进行单独的修改，不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。
只需要对修改的Applet进行测试和认证。
对卡片操作系统（COS）进行修改，可能会影响其他应用的指令的实现和稳定性。
需要重新进行整体的测试和认证。
不同应用下，相同的指令支持不同功能
由于卡片EEPROM空间通常小一些，所以价格相对比较便宜。
开发一个全新的Applet应用。不影响其他应用的实现和稳定性，不影响底层的JavaCard平台的实现和稳定性。
只需要对新增的Applet进行测试和认证。
对卡片操作系统（COS）进行修改，增加新的应用和交易。可能会影响其他应用的指令的实现和稳定性。
需要重新进行整体的测试和认证。

13
1.2.2 安全通信
GP所定义的安全通信包括将APDU命令封装成安全报文、认 证和安全信道的发起、运作和终止。 安全通道实现
安全通道在应用会话期间为卡和卡外实体提供了一个安 全的通信路径。分为三个阶段：
安全通道开启：交换信息完成加密，包括认证过程。 安全通信的运行：数据交换。 安全通道的终止：两者某一方判断出没有必要借助该 安全通道会话继续通信时，通道被终止。
Java卡、GP规范和eSIM卡
刘亚雪
1
1 GP规范学习了GP规
GlobalPlatform是一家由支付和通信业的领先厂商、政府 相关部门以及供应商社区共同建立的一个组织，并率先提 出了一个跨行业的智能卡全局基础架构及其实现，其目标 是为了减少隐藏在快速增长的跨行业、多应用的智能卡背 后的障碍，使得发卡商在各种各样的卡片、终端和后台系 统前，继续享有选择的自由。 对于Java卡：是Java卡上的一套Java应用代码管理机制， 负责Java应用的安全管理，通过安全信道、安全域、密钥 权限等安全因素实现对Java应用的加载、安装、删除等动 态管理。
主要功能： 1.为应用的开发提供API； 2.APDU命令转发和应用选择，当OPEN成功处理了
SELECT命令后，命令中指定的应用会被标识为已选择应用 ，接下来的APDU命令必须都转发给这个已选择应用；
3.安全管理，安全域、应用程序与卡片的锁定和 解锁、终止卡片、授权和日志的管理；
4.卡内容管理，卡片内容的认证、安装、加载、 删除和访问控制；
可变内存（如EEPROM）：文件可以在发卡前或发卡 后加载或删除。 2.卡片内容管理是指卡内容进行加载、安装、引渡、注册 更新和删除的操作。 3.卡内容管理可被看做以下三种实体：OPEN、发卡方安全 域、持卡人认证方法服务提供者