SCMS功能(中文版)

3 功能需求 (1)3.1 卡生产前流程 (3)3.1.1 卡定义和注册 (4)3.1.2 应用定义和注册 (4)3.1.3 个人化信息定义和兼容性 (6)3.1.4 生产准备 (8)3.2 卡生产流程 (8)3.2.1 卡激活 (9)3.2.2 卡的客制化 (10)3.2.3 卡生产完成 (13)3.3 卡生产后流程 (14)3.3.1 卡生命周期管理 (15)3.3.2 应用生命周期管理 (15)3.3.3 卡发行后 (17)3.3.3.1 应用下载 (18)3.3.3.2 应用下载渠道 (19)3.3.3.3 应用下载安全 (20)3.3.3.4 应用下载错误恢复 (22)3.3.3.5 委托管理......................................................... 错误！未定义书签。

3.3.3.6 持卡人可用性 (23)3.3.4 支持商务流程 (24)3.3.4.1 卡库存 (24)3.3.4.2 收费 (24)3.4 核心功能 (25)3.4.1 密钥管理 (25)3.4.2 管理和维护 (26)3.4.2.1 访问控制 (26)3.4.2.2 存档 (26)3.4.2.3 报告 (27)3.4.3 系统框架 (27)3.4.3.1 性能 (27)3.4.3.2 外部接口 (28)3.4.4 环境框架 (29)3.4.4.1 多应用和数据存储 (30)3.4.4.2 分布式环境 (30)3功能需求功能需求被简单的划分为两类，生产和管理职能卡所需要的功能，和核心系统功能。

对于卡生产和管理功能，需求按以下三个主要流程分类：1、卡生产前：一般指创建卡和应用、配置产品个人化信息、和为发行卡准备必须环境的流程。

2、卡生产：一般指生产个性化智能卡的流程，包括激活从供应商处得到的非个性化智能卡。

3、卡后生产：一般指管理个性化智能卡、以及对卡个性化和发行后对卡的任何改变的流程。

需要注意的是，虽然卡和应用的生命周期管理功能只列于生产后部分，但这些功能需求在卡生产前和生产中也是适用的。

为简单起见，这两个领域的功能都合并在卡生产后流程中，因为在该阶段中所有的功能需求都适用。

支持这些主要流程的核心功能依据主要功能域进行划分，主要是密钥管理、运营维护、以及系统框架。

核心功能也考虑到了实现中各种不同环境，因此也检查了在不同实现情景下环境框架的功能需求。

功能需求的组织结构图如图3-1。

图3-1 功能需求组织结构图需求说明中的一些约定在Section 1.7中说明，总结在表3-1。

表3-1 SCM环境功能需求总结3.1 卡生产前流程在发行个性化智能卡以前，智能卡所需功能必须被定义。

一旦这些卡和应用的特性在SCM 环境中注册后，产品个人化信息就能生成，而商务和技术的兼容性也就能被评估了。

对于合法的产品个人化信息，生产前的最后一步包括为切实卡的生产准备必须的SCM环境元素。

步骤如图3-2所示：图3-2 卡前生产过程功能需求组织图3.1.1卡定义和注册有多种智能卡，以及至少一个支持GP标准的运行环境（JA V A卡）。

因此，在采购芯片卡以前，发行方需要在对当前和未来需求进行评估的基础上，对卡种进行选择。

各种可供选择的芯片卡的特征应该被显示在SCM环境的卡概要数据库中。

卡概要是对某个芯片所需硬件和操作环境的描述。

概要包含芯片的详细信息，包括生产方信息和版本，芯片处理能力、内存能力（EEPROM，RAM，ROM），操作系统，运行环境和芯片中的应用集合。

GP卡概要是一个XML文件，可在从卡制造者到持卡人的过程中，给智能卡做一个快照。

SCM环境须满足以下管理卡概要的需求：[1] SCM环境须能输入和输出遵循Global Platform Systems Profiles Specification要求的卡概要。

[2] SCM环境应能管理多种卡概要。

[3] SCM环境须管理外部系统使用卡概要信息。

[4] 尽管已有跟踪卡或应用生命周期的变化的要求，SCM环境须跟踪和维护所有对卡概要的更新。

[5] SCM环境须存储和管理卡有效期的要求和相关应用对此要求的依赖。

[6] 如果卡应用概用包含安全域，SCM环境须跟踪卡中安全域，安全域的拥有者及每个安全域的特殊权限。

[7] SCM环境应能管理由不同GlobalPlatfom版本和不同GlobalPlatform System Profile Specification版本定义的卡。

3.1.2应用定义和注册应用概要是对某个应用所需资源、数据元素、流程、以及GP权限的描述。

应用概要信息包括数据和密钥需求、逻辑步骤的流程定义、以及应用初始化和个性化的命令。

SCM环境应被设计成为能满足分布式应用管理的系统，以避免发行方承担所有的应用管理责任。

因此，应用概要须包含应用代码在加载文件概要中的位置参考，以及和应用相关联的密钥的说明。

SCM环境须满足以下管理应用概要的需求：[8] SCM环境须能遵循Global Platform Systems Profiles Specification要求输入和输出应用概要。

[9] SCM环境须能存储和管理应用概要数据。

[10] SCM环境须能存储和管理应用有效期的要求（如：提前失效，满期失效或不失效）。

[11] SCM环境应能存储和管理加载文件概要及相关的基于应用概要数据要求的加载文件。

[12] SCM环境可存储或管理由应用开发商提供的应用执行代码或加载文件的内存位置，该内存位置可用作应用加载流程的输入信息。

[13] SCM环境须把一个特定应用加载文件与卡产品概要数据库中的一系列兼容卡产品相关联。

[14] SCM环境应管理合法应用在SCM环境中的注册，无论是否存在认证注册专门机构。

[15] SCM环境须存储和管理应用初始化要求，包括装载和初始化参数（如，要求DAP –Data Authorization Pattern （数字证书））。

[16] 如有要求，SCM环境须能支持内部或外部生成的数字证书，以保证加载文件的数据完整性。

[17] SCM环境须保存开卡前和开卡后更新要求，如某应用是否在开卡后装载。

[18] SCM环境须提炼数据共享和应用Applet间的依赖关系，以便支持未来应用程序开发和开卡后的应用下载。

GP卡管理器可以看作是另一个应用概要。

但是，对于GP智能卡，对管理卡管理器应用或权限有着特殊的需求，这也是SCM环境必须能实现的。

[19] SCM环境须存储由GlobalPlatform Card Specification定义的GlobalPlatform应用权限。

这些权限决定某应用是否选为缺省应用、是否可修改Global Pin或锁定Card Manager。

[20] SCM环境须存储应用PIN要求（无、当地或全局）及管理与PIN修改相关的商务规则。

3.1.3个人化信息定义和兼容性卡概要和应用概要的输出也即SCM环境的下一个功能需求，也即主要个人化信息的定义，以及确保该个人化信息和商务和技术规则的兼容性。

在发行多应用智能卡之前，发行者应定义在卡上的主要或初始应用组合。

主要个人化信息将由随卡初始发行的应用组成。

主要个人化信息由必备的应用集合和附加的可选应用集合组成。

基于卡概要和主要应用概要，发行方可选择在空余内存上的发行后下载。

如果发行方已经决定了发行后要下载的应用，这些应用的概要也应该提供，以保证所有的必要元素都没有遗漏，卡概要的完整性也不会有问题。

发行者需要从卡定义列表中选择最能满足某种产品定义的卡。

发行方必须确定在卡上的主要应用（如有）。

例如，在卡初始发行时就在卡上的应用通常都是在发行前就确定好了。

发行方也需要能够从现有可选应用列表中进行选择。

SCM环境应自动决定应用组合所需的内存和密码方法是否与所选卡概要存在冲突。

或者，SCM环境能够为所需的应用组合计算出一个在大小和性能上都适合的卡概要。

通过应用GP Systems Card Customization Guide中的冲突决策规则可以实现以上要求。

虽然以上的大部分工作都是手动完成的，或者由卡和芯片制造方完成，为谨慎起见，SCM 环境还是应该对这些数据进行控制，以满足发行后应用下载的需求。

在选择新卡或重发行卡的替换供应源上，这一能力也是有用的。

[21] SCM环境应允许发行商从一个符合GP规范并带有详细卡概要的卡表列中选择一个卡来发行。

[22] SCM环境应允许发行商选择一组必备和可选应用作为发行卡中的主要应用个人化信息的内容。

[23] SCM环境应允许发行商选择一组卡发行后可下载的应用。

[24] 作为一种选择，SCM环境应允许发行商选择一组应用组合（主要应用个人化信息）并允许卡管理系统计算合适的卡概要。

这种方式可能尤为适合于当一个或多个必备应用在卡生产过程中需要写入只读内存中，或当主要应用个人化信息装载的硬件需求需要计算时。

[25] SCM环境可选择不同的卡管理平台（如非标准私有卡管理平台）。

该要求仅适用于支持非Java卡的卡管理系统。

[26] SCM环境应计算ROM、RAM、EEPROM和加密算法要求以便卡制造商选择合适的卡芯片和开发合适的ROM程序。

[27] 一旦卡选择完成，SCM环境应根据卡和应用的定义信息，按卡和应用间的商务规则检查所选卡的兼容性。

[28] SCM环境应根据卡和应用的定义信息，按卡芯片中应用和卡芯片容量间的技术规则检查所选卡的兼容性。

[29] SCM环境应警示应用组合和所选卡间的商务冲突。

比如，可能存在的所选应用和卡管理平台间的品牌问题。

[30] SCM环境应警示应用组合和所选卡间的技术冲突。

比如，可能存在的加密算法或内存的局限问题。

[31] SCM环境应保证应用的兼容性，包括可能的应用互动（忠诚度计划和付款），品牌冲突，密钥初始化和应用定义。

[32] SCM环境应将应用个人化信息与一个或几个卡定义相关联，假设更多的卡定义是可用的。

[33] SCM环境须提出一整套依赖于复杂生命周期管理的应用商务规则，用以管理应用对卡和对其它卡上应用关系。

例如，当某应用被阻止时，卡是否该被阻止等。

现有的卡、应用、和个人化信息定义需要被检查，以确保所请求的应用能符合芯片限制，而且能被安全下载并正确地发挥作用。

这些检查可能在一张卡上或者一群卡上实施。

检查可能在下载请求时进行，也可能应用组合在一群卡上进行预查。

虽然以下并不包含在卡和应用定义之中，但它们仍然需要SCM环境进行技术兼容性检查：[34] SCM环境须检查卡的运行环境和版本是否与所装载的应用相兼容。

[35] SCM环境须检查卡平台（GlobalPlatform）的版本兼容性。

[36] SCM环境须检查新应用对于卡中固化内存（如EEPROM）中代码和数据存储空间的要求是否满足卡所能提供的存储空间大小。