标准规范下载简介

GBT 33242-2016 数字城市智能卡应用技术要求.pdf

图15生命周期管理流程图

可对应用进行锁定的卡内实体应包括具备“全局锁定权限”的应用、将要被锁定的应用、与其直接或 48

间接关联的安全域。可对被锁定的应用进行解锁的卡内实体应包括具备“全局锁定权限”的应用、与被 锁定的应用直接或间接关联的安全域。并符合下列要求： a 当收到SETSTATUS命令时，执行生命周期管理的安全域应执行以下规则： 1）实施该安全域自身的安全通信策略； 2）检查确认发起锁定或解锁请求的卡外实体可被认证为应用提供方或是目标应用的安全域 提供方。 b）当收到锁定或解锁应用的请求时，GP环境应执行以下规则： 检查确认发起请求的卡内实体就是被锁定或解锁的应用自身，与其直接或间接关联的安 全域，或者具备“全局锁定权限”的应用； 2） 检查确认发起解锁操作的卡内实体不是被执行解锁操作的应用自身； 3） 检查确认被锁定或解锁的应用已在GP注册表中进行了注册，且不具备“最终应用权限”； 4） 对于锁定操作，应将应用的生命周期状态设置为已锁定状态； 5） 对于解锁操作，应将应用的生命周期状态设置为其被锁定前的状态； 6） 对于锁定操作，应将应用被锁定前的生命周期状态记录下来，以确保将来可以且只可以 向后迁移到该状态。

9.5.3卡片的锁定和解锁

道路改建工程冬季施工方案.doc9.5.3.1管理要求

当卡片的生命周期状态被设为已锁定状态，则只有具备“最终应用权限”的应用可对其进行操作 的锁定操作应通过适当的安全机制和授权执行

9.5.3.2锁定请求来源

卡片锁定请求有以下两个来源： a）卡内来源：GP环境、主控安全域或者授权的应用都可从卡片内部发起卡片锁定请求。这些内 部请求有可能是对卡片的某种运行状况的响应； b）卡外来源：显式的卡片锁定请求可由发卡方向主控安全域，或是某个授权的代理向某个具备 “卡片锁定权限”的应用.发出APDU命令来发起

卡片锁定和解锁应符合下列要求： a 当收到SETSTATUS命令时，执行生命周期管理的安全域应执行以下规则： 1）实施该安全域自身的安全通信策略； 2 检查确认发起锁定或解锁请求的卡外实体可被认证为安全域提供方。 b 当收到锁定卡片的请求时，GP环境应执行以下规则： 1 检查确认发起请求的卡内实体具备“卡片锁定权限”的应用； 检查确认卡片的生命周期状态为安全状态； 3） 将卡片的生命周期状态设为已锁定状态。 当收到解锁卡片的请求时，GP环境应执行以下规则： 1） 检查确认发起请求的卡内实体具备“卡片锁定权限”的应用； 2）将卡片的生命周期状态设置为安全状态。

GB/T 33242—2016

9.5.4.1管理要求

当卡片生命周期状态为终结状态时， 应用。卡片终结操作应通过适当的安全机制和授权来执行

9.5.4.2终结操作

卡片终结操作应满足下列情况之一： a）卡内来源：GP环境、主控安全域或者授权的应用都可从卡片内部发起卡片终结请求； 6）卡外来源：显式的卡片锁定请求，可由发卡方向主控安全域，或是某个授权的代理向某个具备 “卡片终结权限”的应用.发出APDU命令来发起

9.5.4.3执行操作

卡片的终结应符合下列要求： a）当收到SETSTATUS命令时，执行生命周期管理的安全域应执行以下规则： 1）实施该安全域自身的安全通信策略； 2）检查确认发起终结请求的卡外实体可被认证为安全域提供方。 b）当收到终结卡片的请求时，GP环境应执行以下规则： 1）检查确认发起请求的卡内实体具备“卡片终结权限”； 2）将卡片的生命周期状态设置为终结状态。

9.5.5应用状况查询

应用（或安全域)的状况，如生命周期状态、权限以及其他在GP注册表中注册的参数等，可被适当 授权的实体所访问。当收到GETSTATUS命令时，执行生命周期查询的安全域应执行以下规则： a）实施该安全域自身的安全通信策略： b）检查确认发起查询请求的卡外实体可认证为被查询应用的应用提供方或安全域提供方

9.5.6卡片状况查询

卡片和主控安全域的状况可被适当授权的实体所访问， 首收到GEIS1A1US令时，执行生命 周期查询的安全域应执行以下规则： a）实施该安全域自身的安全通信策略： b）检查确认发起查询请求的卡外实体为已认证的安全域提供方。

9.5.7操作频度检测

9.5.7.1检测范围

GP环境应实现频度检测安全机制，频度检测应是对卡片上的安全敏感活动的主动监控、处理和控 制，并应至少包括： a） 内容安装； b） 卡片异常； ）应用异常。

9.5.7.2内容加载和安装

GB/T 33242—2016

GP环境可跟踪尝试加载和安装一个特定应用的连续失败次数，或者所有应用尝试失败总次 御性措施应包括锁定或终结卡片

储器资源管理数据元素描应包括可变存储器和只读存储器的使用需求，以及对每种存储对象（代 据）的使用需求，并应符合下列要求： 当卡片支持存储器资源管理时，GP环境应根据对应的存储器资源管理数据元素的描述，来分 配每种可用的存储器资源。存储器资源的分配应执行以下规则： 1）为可执行加载文件分配最小存储器，不得减少卡片上当前的可用存储器； 2）为应用分配存储器配额，不得减少卡片上当前的可用存储器； 3） 分配给应用的存储器配额的数量，不得小于该应用的保留存储器； 4）为可执行加载文件和应用分配其保留存储器。 当卡片支持存储器资源管理时，GP环境应执行以下规则： 1）当加载请求到达时，卡片应满足最小可用存储器的要求； 2）当成功加载了一个可执行加载文件（即执行了最后一条LOAD命令）后，分配给该可执行 加载文件的有效存储器应先从其保留存储器划拨。如没有保留存储器分配给该可执行 加载文件，则卡片的当前可用存储器资源的数量应相应减少； 3 当某个应用的安装请求到达时，分配给该应用的有效存储器应先从其保留存储器划拨： 直到保留存储器完全耗尽。如保留存储器已经耗尽，则其余分配给该应用的存储器应先 从其存储器配额划拨，且卡片的当前可用存储器资源的数量应相应减少。如该应用的存 储器配额或卡片的当前可用存储器资源已耗尽，则该应用的安装失败； 4 成功删除可执行加载文件或者应用，应通过有效释放该可执行加载文件或应用的保留存 储器，来增加卡片的当前可用存储器资源； 5） 当某个应用创建数据时，分配给该应用的有效存储器应先从其保留存储器划拨，直到保 留存储器完全耗尽。如果保留存储器已耗尽，则其余分配给该应用的存储器应先从其存 储器配额划拨，且卡片的当前可用存储器资源的数量应相应减少。如该应用的存储器配 额或卡片的当前可用存储器资源已耗尽，则该存储器资源分配失败 6 对存储器资源的报告结果与具体的实现有关； 7 当某个应用删除数据后，其释放的存储器应重新分配为该应用的保留存储器和存储器配 额。如没有保留存储器分配给该应用，则卡片可用的存储器资源大小应增加。

GB/T332422016

GP的安全通信特性应包括安全传送APDU命令，在多数流程中都隐含可选的认证过程，创建安 道的能力，应用能够使用安全域的服务等。安全通信协议应为安全域和应用与卡外实体之间的通 供安全的环境，

安全通道应在应用会话期间为卡片和卡外实体提供安全的通信路径。安全通道会话可划分为以下 三个连续阶段： a）安全通道发起：卡内应用和卡外实体已交换具备加密功能所需的信息。安全通道会话的发起 应包含卡上应用对卡外实体的认证； b） 安全通道运行：卡内应用和卡外实体应利用安全通道会话提供的加密保护进行数据交换。根 据安全通道协议的不同，安全通道服务可能有所不同； C 安全通道终止：当卡内应用或卡外实体的某一方判断出没有必要继续进行通信时，该通道就会 被终止。

10.3显式和隐式安全通道

安全通道会话在成功发起后应被打开 ，并包括卡内应用对卡外实体的认证过程。在同一安全信道 会话成功结束最后一次通信后，安全通道会话应被终止

10.3.2显式安全通道开

显式安全通道的开启应通过卡外实体发送APDU命令，或卡内应用调用API来开启安全通道会 话。卡外实体可采用APDU命令在当前安全通道会话中，指定所采用的安全级别（完整性和机密性）， 并使得卡外实体可选择要用到的密钥

10.3.3隐式安全通道开启

当卡片在收到第一个包含加密保护的APDU命令时，由安全通道协议处理器直接或调用API的 方式，初始化安全通道会话。安全通信协议处理器应默认安全级别和密钥，或是在发起安全通道会话 前，由卡外实体通过APDU命令指定密钥。

10.3.4安全通道终正

10.3.4.1管理要求

安全通道会话的终止应通过卡内应用调用API或是卡外实体发送APDU命令实现。当新的安全 通道会话在其他逻辑通道上建立时，现有逻辑通道上的安全通道会话不会被终止。当安全通道会话终 上时，所有的会话数据应被重置，完整性检测向量和会话密钥应被删除。

10.3.4.2正常终止

安全通道会话在以下情况发生时应终止 a）卡片应用会话被终止：

b）相关逻辑通道的显式关闭； c）卡片被复位或掉电。

10.3.4.3异常中正

错误条件应保持至安全通道会话被终止。安全通道会话在以下情况发生时应异常中止： a）卡片应用收到包含错误的加密保护的APDU命令； b）卡片应用收到的APDU命令缺乏安全通道会话期间建立的加密保护

10.4安全通道协议的直接/间接处理

卡片应用通过两种方式处理安全通道协议： a）直接处理：应用拥有自身的整套安全通道密钥且完全实现了安全通道协议； b 间接处理：应用调用安全域服务来处理安全通道协议，利用这些服务可允许独立于卡片支持 的安全通道协议的应用被编码

10.5.1对称加密算法下的认证

当使用对称加密的安全通道协议时，可信的卡外实体应拥有开启安全通道会话所需密钥的实 应无法区分安全域实际的提供方和拥有其安全通道密钥的代理方。卡片应无法区分安全域提供 安全域某个关联应用的提供方。

10.5.2非对称加密下的认证

当使用非对称加密的安全通道协议时，应获得一个对其公钥进行签名的证书的卡外实体，并能够被 安全域认证成功。卡片应能够区分安全域提供方、安全域某个关联应用提供方或其他卡外实体，三者不 必是同一实体。每个卡内实体的应用提供方ID在该实体的加载和安装过程中，应注册到GP全局注册 表，且不应被改变。

10.6安全的消息传送

在发送消息到接收实体之前，应允许发送实体向APDU消息中添加机密性和/或完整性及可信性 数据作为其组成部分，并应符合下列要求： a）发送给卡片的APDU命令应具备完整性、机密性； b）通过安全通道会话发送给卡片的APDU命令序列应具备完整性； c）根据采用的安全通道协议，卡片发送的APDU响应应具备机密性、完整性

在整个会话或单独命令响应期间，安全级别应建立对消息发送的最低安全保护。当前安全级别的 编码应符合表3的规定。安全通道协议的运作应依据已建立的安全级别，包括以下两种情形： a）在安全通道会话开启时，明确或隐含地设置强制性安全级别； b）针对某个独立的命令或响应，设置安全级别。

GB/T332422016

表3当前安全级别编码

10.8安全通道协议标识符

安全通道协议标识符应标志着在安全域中实现具体的安全通信协议和安全服务。下列内容可作为 安全通道协议标识符： a）“00”不可用； b） “01”～“7F”保留GP将来使用，其中包含如下规定： 1）“01”为安全通道协议1； 2）“02”为安全通道协议2； 3）“10”为安全通道协议10； C “80”～“EF”保留用于GP注册的个人用途，其中“80”为安全通道协议80； “FO”～“FF”保留用于未被GP注册的个人用途。

11应用协议数据单元（APDU)命令

11.1命令范围和安全级别

GPAPDU命令应用于实现卡片生命周期状态转换与查询、包括密钥在内的卡片数据的装载与册 除、安全通道的建立以及逻辑通道管理等，具体的指令包括： a） DELETE命令：用于删除卡上安全域的密钥、应用实例、包； b） GETDATA命令：用于获取卡上非敏感数据的数据内容； ） GETSTATUS命令：用于获取卡片目前的生命周期状态； d INSTALL命令：用于包下载的开启、应用实例的安装； e） LOAD命令：用于包的安装； f MANAGECHANNEL命令：用于逻辑通道的开启与关闭； g） PUTKEY命令：用于安全域密钥的加载； h） SELECT命令：用于应用实例的选择； 1 SETSTATUS命令：用于卡片生命周期的设置； STOREDATA命令：用于卡片数据的装载；

GB/T33242—2016

k）INITIALIZEUPDATE：用于初始化安全通道； EXTERNALAUTHENTICATE：结合INITIALIZEUPDATE，用于外部认证并建立安全 通道。 指令的具体要求可参考GP规范最新版本。对这些指令在不同的生命周期及安全级别下的执行条 件见表4。

表4每个卡生命周期状态被认证的GP命令

GB/T33242—2016

表6可执行装载文件的生命周期编码

用的生命周期被编码见表7所描述的一个字节。

用的生命周期被编码见表7所描述的一个字节。

表7应用的生命周期编码

应用可以自由使用4～7位，并且这些位的编码应超出本标准的范围，

安全域的生命周期被编码见表8所描述的一个

安全域的生命周期编石

发行者安全域继承卡的生命周期状态编码见表

表9发行者安全域的生命周期编码

11.2.2应用权限编码

应用的权限被编码见表10～表12，一个应用可以有一个或多个权限。

表10权限（字节1)

表11权限（字节2）

表12权限（字节3）

11.2.3一般性错误代码

可以被任何命令返回的错误代码描述详见表13

11.2.4CLASS字节编码

所有GP命令中的类字节将符合GB/T16649.4的要求，命令中在使用基本逻辑通道0和逻辑通道 1~3时，将采用表14的编码格式；命令中使用更多的逻辑通道4～19时，将采用表15的编码格式。

14CLA字节编码（O,

表15CLA字节编码（4～19）

11.2.5APDU命令和数据长度

所有GP命令都符合GB/T16649.4的要求，也就是Lc字节被编码为1字节 所有GP命令消息（包括APDU头）在长度上都被限制到255字节。

11.2.9密钥用途编码

密钥用途的编码如表20所示。

11.2.10密钥访问编码

倒虹吸施工方案密钥访问参数的值如表21所示

密钥访问参数的值如表21所示

11.2.11 Tag 编码

GP中对安全域的Tag编码规则如下： a） “00”“7E”：保留给ISO/IEC； b）“80”～“9E和“A0”～“BE”：保留给相关内容； “CO”～“DD”和“EO”～“FD”：保留给GP或通过GP注册的个别方案，其中“CA”和“EA”：保留 给ETSITS102226规范； d）“DE”和“FE”：保留给专用的和未经GP注册的； e）“1F1F”～“7F7F”：保留给ISO/IEC; “9F1F”～“9F7F”和"BF1F”～“BF7F”：保留给相关内容； & “DF1F”～“DF7F”和“FF1F”～“FF7F”：保留给GP或通过GP注册的个别方案，其中“FF 1F”～“FF3F”保留给ETSITS102226规范

生命周期示例说明 本附录举例说明了GP卡片和从它创建到终结的生命周期的迁移过程，同时也展示了若干可执行 我文件、可执行模块和应用的状态以及它们和卡片生命周期的相互关系。 图A，1说明了这些生命周期状态： a）应用A：该应用的代码以可执行模块的形式随着可执行加载文件在卡片制造期间驻留于可变 存储器中，并以一种与特定的实现相关的方式进行了安装。除了卡片处于已锁定状态之外，它 在卡片的整个生命周期中都是可用的。 b 应用B：该应用的代码以可执行模块的形式随着可执行加载文件在芯片制造期间驻留于只读 存储器中，并在卡片初始化之前进行了安装。它随着某个可执行加载文件在卡片终结前的某 个生命周期的时刻，从卡片上删除。由于该应用对应的可执行加载文件驻留在只读存储器中， 因此不能在物理上将其从卡片删除。 C） 应用C：该应用的代码以可执行模块的形式随着可执行加载文件以一种与特定的实现相关的 方式加载到卡片上，并在发卡后阶段当卡片处于安全状态时，进行了安装。该应用使用了一段 时间后在卡片终结以前随着可执行加载文件而删除。由于该应用和对应的可执行加载文件， 以及所有对应的可执行模块都驻留在可变存储器中，因此被彻底从卡片的可变存储器中清除 干净，其占用的存储器空间被回收以便重新利用。 d） 应用D：该应用的代码以可执行模块的形式随着可执行加载文件以一种与特定的实现相关的 方式加载到卡片上。除了卡片处于已锁定状态之外，它在卡片的整个生命周期中都是可用的， 直至卡片终结。 e） 应用E：该应用的代码以可执行模块的形式随着可执行加载文件出现，在发卡后阶段当卡片处 于安全状态时，以一种与特定的实现相关的方式加载并安装到卡片上。除了卡片处于已锁定 状态之外，它在卡片的整个生命周期中都是可用的，直至卡片终结。 应用F：该应用的代码以可执行模块的形式与应用E共存于同一可执行加载文件中，它在发卡 后阶段且卡片处于安全状态时，加载并安装到卡片上施工组织设计编制标准【中国建筑第八工程局企业标准】，并在卡片终结前的某个时刻，从卡片上 删除。 注：图A.1示例的说明并不能用于全面阐明在每个卡片生命周期状态时可执行的全部操作，

图A.1卡片生命周期和应用生命周期