scms功能（中文版）.docx

3功能需求13.1卡生产前流程33.1.1卡定义和注册43.1.2应用定义和注册43.1.3个人化信息定义和兼容性63.1.4生产准备83.2卡生产流程83.2.1卡激活93.2.2卡的客制化103.2.3卡生产完成133.3卡生产后流程143.3.1卡生命周期管理153.3.2应用生命周期管理153.3.3卡发行后173.3.3.1应用下载183.3.3.2应用下载渠道193.3.3.3应用下载安全203.3.3.4应用下载错误恢复223.3.3.5委托管理223.3.3.6持卡人可用性233.3.4支持商务流程243.3.4.1卡库存243.3.4.2收费243.4核心功能253.4.1密钥管理253.4.2管理和维护263.4.2.1访问控制263.4.2.2存档263.4.2.3报告273.4.3系统框架273.4.3.1性能273.4.3.2外部接口283.4.4环境框架293.4.4.1多应用和数据存储303.4.4.2分布式环境303 功能需求功能需求被简单的划分为两类，生产和管理职能卡所需要的功能，和核心系统功能。对于卡生产和管理功能，需求按以下三个主要流程分类：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标准的运行环境（JAVA卡）。因此，在采购芯片卡以前，发行方需要在对当前和未来需求进行评估的基础上，对卡种进行选择。各种可供选择的芯片卡的特征应该被显示在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）中代码和数据存储空间的要求是否满足卡所能提供的存储空间大小。37 SCM环境或者须禁止应用的删除，或者须跟踪应用被删除的指令，该要求对于当制卡所使用的技术不能保证EEPROM中具有足够大的连续存储空间时尤为重要。38 SCM环境须检查新应用对于卡中RAM的要求是否超过卡中当前组合所需RAM要求。39 SCM环境须检查应用对于加密功能的要求是否超过卡所能提供的加密性能。应用请求也需要被检查以验证是否符合发行方制定的商务规则，而这些商务规则可能是复杂的生命周期依赖规则。例如，发行方可要求只有某种应用能被下载到某种卡上。在提供下载服务之前，其他规则也需要建立。各种商务规则的原因可能源于以下因素的考虑结果：l 品牌划分l 安全冲突l 发行方风险冲突l 法律或所有权冲突l 持卡人对于应用的适用性3.1.4 生产准备智能卡的订单信息需从芯片选择和主要个人化信息流程的输出编译而来。订单信息应该传递给卡生产方。很多情形下，卡生产方就是订购芯片模块和激活卡的实体。但是，在卡的采购过程中，发行方可能需要直接和IC生产方直接沟通，特别是是否有应用组合需要被写入ROM当中。此外，在很多情况下，芯片供应商将直接生成自己的初始供应商主密钥，并直接传递给卡制造方。基于IC制造方和卡制造方之间的关系，SCM环境应能管理以下需求：40 SCM环境可与密钥管理系统接口以安全地生成一个初始卡供货商主密钥，该主密钥经加密后可提供给卡芯片生产商。41 SCM环境须通过密钥管理系统接口安全生成为在传输过程中保护初始卡供货商主密钥或其它应用提供商密钥所需的任何密钥加密密钥（传输密钥）。42 SCM环境可提供应用源代码或装载文件供卡芯片供应商进行IC版图流程。43 SCM环境应能提取和存储卡芯片制造商信息，如：卡序列号、卡芯片前个性化、卡芯片前个性化日期、卡芯片前个性化设备标示。44 SCM环境应能根据卡芯片制造商信息和芯片中版图化的应用输入或更新卡中应用概要内容。45 SCM环境应能根据卡芯片制造商信息保存版图化应用的生命周期状态。3.2 卡生产流程在初始或主要应用被确定、主持卡人数据库建立、以及适当的卡和卡设计选定以后，激活多应用智能卡的流程就能走往下一步了。生成个性化智能卡的流程包含若干子流程。功能需求以子流程作为分类，说明如图3-3。图3-3 卡生产流程的功能需求组织图对于卡生产流程的功能需求，重点并不是流程本身，而是在生产过程中各个参与者所使用的项目的准备工作。此外，还有一些和GP相关的、在多应用智能卡SCM环境中必须符合的关键概念。3.2.1 卡激活激活的定义是指加载初始卡管理器数据和密钥、安装补充安全域、以及加载初始安全域密钥的过程。激活过程通常在卡制造方进行，在激活过程中，应用可以选择性地加载和安装。对于本文档，被激活的卡是指GP智能卡已有发行方安全域，并已经过初始发行方衍生密钥个性化处理以后，而其他补充安全域也经过了衍生安全域密钥个性化处理。安全域密钥通常都由应用提供方提供。在卡个性化部分所讨论的卡生产流程的第二步包括对应用的加载、安装和个性化。这一步可以和卡激活合并为一个流程，由卡制造方或机构（？）操作完成。是否合并激活和个性化两个步骤的决定因应用而异，可能受影响于制造商、应用、卡渠道要求、以及个性化设备。SCM环境的数据准备系统负责部分激活流程，从初始发行方主密钥中生成必要的激活密钥。这一能力对于SCM环境在团队（？）操作中的使用尤为关键。46 SCM环境须与密钥管理系统接口生成和推导出SD密钥（参考GP KMS要求）。47 SCM环境须与密钥管理系统接口生成传输密钥，并将卡中密钥加密后传给卡激活服务商或卡制造商。48 SCM环境或相关的密钥管理系统可从最终发行主密钥产生独特的最终发行推导密钥。该要求尤其针对机构（？）内的个性化处理。49 SCM环境可与GP Scripting Language翻译器元件一起创建一套用于装载安全域和初始化卡管理器的指令或脚本。50 如果需要，SCM环境或相关数据准备元件可创建用于代表应用供商安装安全域，以及用专门的应用提供商密钥个性化安全域的指令或脚本。51 卡激活和/或初始化后，SCM环境须保存卡激活的结果、卡生命周期的状态以及任何制造商装载的应用的生命周期状态。GP卡的生命周期状态成为初始化完成，应用的生命周期状态可为：载入、安装、可选。52 SCM环境须根据卡上提供的卡制造商信息更新每张卡的概要信息以反映该卡的“初始化完成”的生命周期状态。53 如果未进行，SCM环境可记录相关的卡生命周期状态数据，包括：卡芯片前个性化、卡芯片前个性化日期、卡芯片前个性化设备标示。3.2.2 卡的客制化如上所述，在某些情况下可能，甚至需要，将主要个人化信息中应用的加载和个性化步骤与卡和安全域的激活合并。卡的客制化定义为针对某一特定持卡人，选定特定的芯片应用集并提供相应数据。因此，卡的客制化是针对具体应用的，也通常被称为卡的个性化。卡的客制化也需要生成Card Reference Number (卡参考序号，CRN)和Card Image Number (卡映像序号，CIN)。CRN是一个离卡逻辑数值，用以标明与卡相连的应用集，并使之与持卡人相连。CRN在持卡人生命周期内都存在。相对应的，CIN是一个写入卡内的在卡数值，用于衍生数据。CIN在卡的生命周期内存在。除了加载和个性化应用之外，应用加载服务器还需要“个性化”卡管理器和安全域，注入最终衍生卡管理器和安全域密钥。这些密钥总是独立由发行方或者应用提供方生成，以保证在发行时，只有发行方能够访问最终卡管理器密钥，也只有应用提供方能够访问最终安全域主密钥。对于数据准备系统和应用加载设备的数据准备和个性化的脚本而言，这些功能也是存在的。所准备的数据文件和相关脚本可被送到个性化机构、发行方初始化设备，或在某些情况下，送到卡制造方。值得注意的是，应用提供方对获取和生成适合的个性化数据负责。SCM环境或相关数据准备系统将把各个应用的数据合并到一个文件中，以便个性化设备操作。对数据收集和个性化的应用需求超出本文范围，再此不予讨论。在GP Guide to Common Personalization文档中，GP推荐了对个性化过程的标准化，和更有效使用ICC少量内存资源的方法。一个个性化设备通常只接受一种个性化准备文件，以及相关的指令集。这就需要对每个应用所需的所有个性化数据做事先收集和准备。符合GP Scripting Language标准的数据准备脚本和个性化脚本可用来加快这一过程，也可用于提供交互操作卡的客制化元素。数据准备说明如图3-4，个性化说明如图3-5。在数据准备过程中准备的文件或脚本由一系列的实施个性化的步骤或步骤模块组成。个人化信息中应该已经包含了所有应在卡上的主应用，及其相应的个性化需求。不仅应用数据必须明确，而且实施初始化和个性化流程的顺序也需要明确。应用数据和密钥的准备工作可由和SCM环境接口的独立系统完成，也可以由SCM环境自己完成。出于重发行和发行后下载的考虑，推荐该功能包含于SCM环境内，又或由外部系统提供时，该系统应和SCM环境密切结合。图3-4 数据准备流程图3-5 个性化流程SCM环境对于个性化的需求如下：54 SCM环境须能产生与单个持卡人应用个人化信息相关联的卡参照序号（CRN号），该号由应用提供商和相关系统共享作为一个通用逻辑参照号。当CRN对外公开时，可由任意数字组成而成为独特号码。55 SCM环境须能对每张卡产生一个唯一数字，用以识别卡和相对应的CRN号，此数字即为卡的CIN号。CIN号在卡个性化过程中写入卡内并可选择性地与CSN相关联，CSN号在卡使用记录数据中返回SCM环境。56 SCM环境须与密钥管理系统接口产生并安全存储最终卡管理器主密钥，从其导出各个最终卡管理器推导密钥。57 SCM环境须与密钥管理系统（？）接口产生最终卡管理导出密钥，和可选择地使用CIN为导出数据生成安全域导出密钥。58 SCM环境应基于CRN产生经过校验的个性化数据文件，以作为从众多应用系统和个性化要求对每个应用的输入。59 SCM环境或GP Scripting Language翻译器元件可准备一套基于卡和应用概要信息的GP个性化脚本。60 SCM环境须能与合适的应用数据准备系统接口。由应用提供商系统，而不是SCM环镜，负责导出和准备相关的用户个性化数据。61 SCM环境须能安全地将个性化脚本文件派送到卡发行者（？）或个性化系统。62 SCM环境须能在自身数据库中更新产品（如，新卡概要和应用生命周期状态），并将个性化处理流程的结果通知应用提供商。63 SCM环境可基于事先预备的一套应用和应用固化数据为一个卡用户群体创建一种特殊的卡产品。除了对卡上应用进行个性化外，个性化可还包括对磁条码进行编码，以及打印（？）或者加入持卡人信息到卡中。SCM环境或相关的数据准备系统应合理地管理磁条码个性化流程以及GP应用所做的要求。通常非芯片的个性化由另一个系统操作，其因所使用的个性化硬件设施而异。一旦卡已经从个性化机构收回来，并发送给了持卡人，SCM环境应完成以下功能需求：64 SCM环境须将卡生命周期状态数据更新为“确定”。65 SCM环境可存放准确的产品信息，如：卡芯片前个性化、卡芯片前个性化日期、卡芯片前个性化设备标示。66 SCM环境应将卡中每个应用的应用生命周期状态从“可选”更新为“已个性化”（对GP 2.0.1版本卡），或应用定义的生命周期状态（对GP 2.1.1版本卡）。67 SCM环境须将针对某个应用的个性化处理结果报告给相关应用系统。3.2.3 卡生产完成根据不同的应用和应用提供方，卡和卡内容可能需要和特定的应用交易和客户信息系统相关联。在某些情况下，该关联可能只是一个和发行方的持卡人数据库，或应用提供方数据库的简单链接。接口和所需数据的定义依赖于各个特定应用，以及在发卡方和应用提供方之间达成的客户服务级协议。根据这些需求，一些客户信息可以在SCM环境中复制，成为独立的客户信息库。通常来说，SCM环境应从以下方面管理客户概要信息：68 SCM环境须将所要求的应用个性化记录数据提供给卡发行商系统或应用提供商系统。69 SCM环境须将每个卡用户的概要代码如CRN号提供给卡发行商或应用提供商数据库作为索引。70 SCM环境应能从相关发卡商或应用提供商数据库中，用问题卡的持卡人用户概要ID（CRN号）提取卡用户识别数据（在电话认证中使用），。71 SCM环境可从自己的卡用户数据库中，用问题卡的卡用户概要ID（CRN号）提取卡用户或卡相关识别数据。72 SCM环境可从CSS和CIS系统中，使用问题卡的卡用户概要ID（CRN号）提取卡用户的个人信息，如姓名，地址，电话号码或账户号码。3.3 卡生产后流程和通用卡管理相关联的一些功能需求也应该是多应用智能卡管理的需求。虽然这些卡生命周期和应用生命周期管理的需求在本部分加以说明，但也适用于卡生产前流程和卡生产流程。生产后流程的步骤说明如图3-6：图3-6 卡后生产流程的功能需求组织图如果发行方允许智能卡应用的动态加载和删除，发行后阶段将是其主要的关注区域。在发行后期间，有众多的流程和动态功能需加以考虑，以便建立有效的SCM环境。最后，除了支持发行后期间特殊的卡客制化的需求外，SCM环境还有各种操作成分。这些操作部分按照商务支持流程加以分类，同样也适用于卡生产前和卡生产流程。当然，这些功能通常在卡被使用后才发挥作用。SCM环境通常并不需要代应用系统提供交易流程。也即，主机系统应能独立于SCM环境运行。该前提有两个重要特例：l 应用系统生成卡或应用生命周期状态的变化。这些变化将在应用系统通过速率检查（？）或其他方式检测出错误时产生。l 和应用的客户支持系统接口。应用提供方可能要发起卡或应用生命周期状态转化。3.3.1 卡生命周期管理73 SCM环境须能在卡生产流程和后发行流程（如卡的整个生命周期）中管理和跟踪一个多应用卡的任何状态变化。74 SCM环境须能在卡的整个生命周期中跟踪卡生命周期状态。75 SCM环境须能跟踪和更新卡的库存并实现卡的版本控制。76 SCM环境须能跟踪和更新平台库存并实现平台的版本控制。77 SCM环境须能在重新发卡时将CRN与新卡相关联。这可以用重新将卡的参考号与新发行卡的CIN号相关联来实现。CRN是逻辑上的卡用户卡和应用个人化信息的唯一参照，是由卡发行商独立于任何卡物理ICC号参照而设定的。78 SCM环境须能将一张新卡与已经存在的产品相关联以达重新发卡的目的。79 SCM环境须能将一张新卡与一个已存在的卡生命周期状态相关联，也就是说，当一张新卡发行后，SCM环境能正确地在指定生命周期阶段终止一张老卡。80 SCM环境应能产生和传输指令锁定或终止一张卡。81 SCM环境应能收到锁卡或终止卡的通知，并相应地更新卡的生命周期。82 SCM环境须建立卡用户的主文件保存相关卡用户信息和逻辑卡参照号（CRN），或与一个已建的卡用户主文件或客户信息系统（CIS）接口。CIS需求因应用而异，不在本文讨论范围。要求使用CRN连接应用相关持卡人数据和SCM环境的卡识别器。3.3.2 应用生命周期管理很可能卡生产方提供卡时不仅仅包含了GP所规定的功能。例如，某卡可能已被写入初始的付费应用，比如EMV付费应用。因此，SCM环境必须能够独立追踪卡和应用的生命周期状态，并保持足够的灵活性以应付在卡生产过程中的变化。SCM环境必须能够追踪、维护、和报告卡和应用的生命周期状态。对于应用生命周期管理，SCM环境必须支持以下功能需求：83 SCM环境须在卡的使用生命周期内跟踪应用生命周期状态。84 SCM环境须跟踪和更新应用库存并实现应用版本控制。85 SCM环境须管理与新应用版本相关的应用概要变化。86 SCM环境须能将一张新卡与已存在的应用生命周期状态想关联。也就是说，应用必须在新卡中重新赋予正确的生命周期状态。87 SCM环境应能产生和传递指令来锁定应用。88 SCM环境应能接受阻止/锁定应用的通知并相应地更新应用生命周期。89 SCM环境须能识别和管理应用，它们的生命周期状态，无论是初始化时产生的还是卡发行后更新的。SCM环境应能和现有系统接口并加以利用。在类似于客户服务和支持领域都有此需求。响应持卡人询问的客户服务代表可能需要和该持卡人相关的卡上应用的信息。更为重要的是，SCM环境必须能将应用或卡的状态变化传送到应用系统上，同时也能接收应用系统对卡和应用状态的更新信息。以下需求可以在完整的SCMS系统中实现，也可以在组成SCM环境的单独系统中实现。90 SCM环境须允许卡发行商完全阻止一张卡，完全阻止一个应用，或在报告卡遗失/被窃、可疑违法使用等时终止一张卡的使用。91 SCM环境须能通知应用系统任何实际发生的或被要求的卡或应用状态的变化。92 SCM环境须能收到从应用系统发来的卡状态的变化信息。93 SCM环境须能与客户服务呼叫中心接口获得卡遗失或被窃的信息。94 SCM环境须能提示卡和与卡相关、并在下次在线升级时可能被阻止或锁定的所有应用，这个信息也可作为要求传给应用系统。95 SCM环境须能强制执行商务规则和政策，在卡遗失或被窃时更改应用状态。96 SCM环境须能跟踪遗失或被窃卡及其替换卡的生命周期，直至某应用系统能报告或证实该卡已经被销毁。97 SCM环境应支持紧急情况下和一定时间周期内卡的临时替换。98 SCM环境应将卡的替换通知客户服务系统（CSS）。99 SCM环境须能从卡和应用库存数据库中描述卡中内容（包括原始内容和后继下载更新的内容）。100 如果发行部分更替的用户卡，SCM环境应在新应用从应用库存装载到卡中时更新卡数据库。部分更替卡不包含原始卡中的所有应用。黑名单是下次试图使用时必须被阻止的卡或者应用的列表。卡被放入黑名单中可因于很多商务原因。SCM环境能提供以下关于黑名单的功能：101 SCM环境应能管理黑名单卡处理状态，或黑名单卡上应用，或两者。SCM环境须将相关信息传给应用系统。102 SCM环境应能准备可下载到应用运营系统或终端或终端服务器上的黑名单。103 SCM环境应可发送黑名单到应用运营系统、设备或服务器，并从其收到相应的反馈。3.3.3 卡发行后GP卡规范被设计为允许卡发行者在卡片发行给持卡人后更改卡片内容。卡发行后部分包含了几个在初始卡生产过程中没有要求的商务、运营和技术因素。图3-7展示了一个下载基础设施的宏观图。从商务和运营的角度来看，卡发行者可以直接管理所有的变化，或者授权其控制给商务伙伴，比如应用提供商。这一第三方应用下载以及共享应用管理责任称为委托管理。这一机制让卡发行方有安全的渠道让应用提供商、平台运营商、或其它商务合作者对卡实施受控内容管理。内容管理控制也即委托管理权限说明后的额外安全域。从技术角度看，需要考虑加载文件和卡生命周期管理更新。首先GP卡需要对将被传输到卡上并更新卡内容的加载文件进行准备。加载文件可被DAP（数据验证模式）模块保护，该模块将验证加载文件的完整性。其次，加载和安装过程的成功信息必须传回到SCM环境中，带回相应的卡和应用生命周期状态信息。图3-7 卡发行后下载基础设施对支持卡发行后应用下载的需求分为几个领域。对于应用下载，这些领域是：l 通用应用下载功能，包括基础设施以及应用个人化信息兼容性检查；l 发行后可能通过几个渠道，每个渠道可有各自的要求；l 保证安全应用下载的安全需求；l 因发行后环境受通信基础设施的可靠性影响，应用下载期间的错误恢复十分重要。同时，作为这一功能的扩展，全卡恢复也为必须。l 对于更复杂的卡程序，GP智能卡的委托管理要求也需要支持。l 因为持卡人可能需要参与应用下载或卡恢复，方案的可用性须加以考虑，以提高整体卡程序的成功性。3.3.3.1 应用下载根据各个不同加载服务器的架构和分布，在一或多个加载服务器和SCM环境之间可能需要接口。这一接口让信息在卡和SCM环境之间安全传递。对于封闭的或低容量的卡程序，SCM环境可以当作应用加载服务器。无论在何种架构下，一定有某种机制管理应用下载流程在合理时帧内完成。成功下载完成必定触发卡定义的更新，该新卡定义将把新的下载应用及其正确的应用生命周期状态和某个持卡人和卡相关联。比较重要的一点是，应用代码和相应的个人数据可能并不存储在发卡人的SCM环境之中。应用可执行代码可能需要从应用提供商处下载，并安全存储，等待加载流程的调用。根据不同的应用数据库接口和下载基础设施，发行后下载可能也有性能方面的要求。同时，发行方可能需要和应用提供商或者第三方服务提供商达成商务协议来解决流程问题。这些服务的安排可能包括把应用和数据安全在线地传送到应用加载服务器，也可能发行方选择允许应用下载请求直接传递到应用提供商的系统之中。无论协议安排如何，重要的一点是，系统设计不应阻拦应用提供商对应用下载请求的响应。在会话密码集建立后，下载可以直接通过下载服务器和卡之间的在线会话进程完成，也可以通过集合打包或脚本完成。这些包中的指令是被MAC（消息授权）过的，用会话密钥进行加密，并作为应用下载包进行传输。类似的包可被生成，以便为接下来的个性化工作所使用，该包也可以和前面的包合并。包将存成某种格式文件，并被卡接收设备接收。卡接收设备将执行该包到卡上，并返回结果。为通过各种不同的传输渠道网络，文件可能需要被扩展。发行后流程也可以基于在卡、卡接收设备和应用加载服务器之间的一条条指令完成。以上方法的组合也是可行的。最后，在下载流程完成后，必须要给卡发行方SCM环境发送结果通知。为支持应用下载，对于发行方的SCM环境，或者第三方服务提供商的下载服务器需实现以下通用功能需求。104 SCM环境应根据产品来注册、更新和维护可用应用集合。105 SCM环境应支持应用下载文件集合、打包和分发到下载服务器或下载基础设施中。106 SCM环境应对多种下载基础设施（ATM、售货亭、互连网等）提供支持。这可能要求在SCM环境和应用下载服务系统之间的接口和所需数据元进行标准化。107 SCM环境应对多个应用提供商的发行后下载提供支持。这可能要求在SCM环境和应用提供方系统之间的接口和所需数据元进行标准化。108 下载服务器应和不同的卡接收设备进行接口，包括互联网客户。109 和客户的接口应在在低速网络连接上在合理时帧内进行操作。110 下载服务器应能于多在线应用下载请求下保持加载平衡。111 SCM环境和下载服务器应能连接到应用系统内，以重获应用加载文件。112 下载服务器可在预判到下载请求时存储相应的加载文件。113 下载服务器应和应用系统接口，以获取或验证个性化数据。114 下载服务器应提供打包加载文件、加载指令以及其他相关个性化数据的脚本或类似机制，并用会话密钥进行加密。115 下载服务器须用会话密钥把包/脚本传送到卡接收设备上，或用会话密钥基于一个指令或命令完成传送。116 下载服务器须在发行后下载流程中接收CAD和智能卡交互的结果（成功/失败）。117 下载服务器须将下载流程的结果更新到SCM环境系统中。118 SCM环境须将新应用和应用生命周期信息更新到卡产品定义中。119 SCM环境须将应用下载的结果更新到相关应用系统中。3.3.3.2 应用下载渠道应用下载可以通过多个外部源，以及持卡人或应用提供商的多个实体进行请求。发卡商或应用提供商也可能对某个特别设计的卡产品实施一个或多个应用的预授权。在这种情况下，该应用请求应自动保证加载成功，下载服务器可从受保护的应用仓库中直接获取加载文件。此以，一个应用请求可能是“推”或“拉”请求。“推”请求是在持卡人请求新应用时被执行的。发行后下载也可能由“推”请求触发完成，即，卡发行者或者应用提供商希望在不经过持卡人请求的情况下对卡进行更新。例如，卡发行者希望对应用版本升级之类的维护情况。卡更新请求可以通过以下各种渠道获取：120 SCM环境应允许持卡人通过在线方式或电话请求，对卡更新标志设置为手动或自动。121 SCM环境应和持卡人服务呼叫中心或持卡人支持系统进行接口，以支持卡更新请求（delayed next online pull）。122 SCM环境应允许通过SCM环境操作员，或应用提供商的在线/电话请求对卡更新标志设置为手动或自动（delayed next online push）。123 SCM环境应允许来自互联网的直接在线卡更新请求，该请求可能来自应用提供商或者卡发行者的网站（immediate online pull）。124 SCM环境应兼容任何来自无线移动电话用户或其他用户设备的直接在线请求（immediate online pull）。125 SCM环境可允许发行者对单张卡或者一群卡进行主动强迫下载（即，交易类型指出相类似的持卡人需求，新的应用版本要更新到每张卡上，或者出于应用维护需要，强制对应用进行替换）。SCM环境应支持以上机制，包括和对下载请求保持警