GB T 23695-2009 银行业务.安全文件传输(零售).pdf

《GB T 23695-2009 银行业务.安全文件传输(零售).pdf》由会员分享，可在线阅读，更多相关《GB T 23695-2009 银行业务.安全文件传输(零售).pdf（32页珍藏版）》请在麦多课文档分享上搜索。

1、ICS35.240.15 A 11 道B中华人民共和国国家标准GB/T 23695-2009 银行业务安全文件传输(零售)Banking-Secure file transfer(retaD) (lSO 15668: 1999 , MOD) 2009-05-06发布2009-10-01实施副甲B伽/ J/ 中华人民共和国国家质量监督检验检疫总局中国国家标准化管理委员会发布GB/T 23695-2009 目次前言.m 引言.N 1 范围-2 规范性引用文件.2 3 术语和定义.3 4 原则45 应用.56 鉴别机制.10 附录A(资料性附录)机制示例.附录B(资料性附录)实施的例子17附录c(资

2、料性附录)保证文件传输完整性确认的示例.20 附录D(资料性附录)安全服务的图形概要参考.24I GB/T 23695-2009 目U1=1 本标准修改采用ISO15668: 1999(银行业务安全文件传输(零售)(英文版)。本标准根据ISO15668: 1999重新起草，与ISO15668: 1999的技术性差异及原因为:-一删除2规范性引用文件中对此文件的引用:ISO 8731-1: 1987 (银行业务核准的报文鉴别算法第1部分:DEA) ，因为此标准中的算法不符合我国密码管理部门的有关规定，且该标准己于2005年被ISO废止。一一删除2规范性引用文件中对此文件的引用:ISO11568(

3、所有部分)(银行业务密钥管理(零售门，因为此标准中的算法不符合我国密码管理部门的有关规定。一一一删除图1终端软件的表示(示意图)中的标号8，因为图1注释中未给出标号8的说明，且根据原文可知标号8是指引导程序(标号7)的运行环境或其他支持程序，而标准中提到引导程序(即层a)的安全性不在本标准的讨论范围之内，它的运行环境和支持程序被标为了灰色。在不影响理解的情况下，删除图中未给出解释的标号8。一-5.1.2. 3中密钥管理技术应符合ISO11568的要求，改为密钥管理技术应遵循我国密码管理部门的有关规定。一一6鉴别机制和A.1鉴别机制中，己核准的算法参考ISO11568改为已核准的算法应遵循国家的

4、相关规定。一一删去A.3中最后一句:ISO 9807给出了已经核准的用于计算MAC的算法列表，其中在ISO 8731-1中说明的算法，以操作的密码分组链模式使用DEA，它是当n=64 , m= 32 , ISO/IEC 9797的一个特殊情况。因为ISO8731中的算法不符合我国密码管理部门的有关规定。一一删去A.2最后一句一-ISO/IEC10118-2，附录A，说明一种使用n=64，哈希长度=56的DES方法。一-一删去A.2. 3所举的例子，因为其中引用了DSA、RSA，不符合我国密码管理部门的规定。一一删去资料性附录B，因为其中引用了DEA，不符合我国密码管理部门的规定。一一C.4.3

5、.3中MAC密钥应遵循ISO11568 ，改为MAC密钥应遵循我国密码管理部门的有关规定。为便于使用，本标准做了下列编辑性修改:一一用本标准代替本国际标准;一一删除国际标准前言;一一修改图1、图2中的印刷错误。本标准的附录A、附录B、附录C和附录D为资料性附录。本标准由中国人民银行提出。本标准由全国金融标准化技术委员会归口。本标准负责起草单位:中国金融电子化公司、泛太领时科技(北京)有限公司。本标准参加起草单位:中国人民银行、中国工商银行、中国农业银行、中国建设银行、交通银行、中国银联股份有限公司、华北计算技术研究所、北京工商大学。本标准主要起草人:王平娃、李曙光、吕毅、杨颖莉、鲍乐群、万良君

6、、林中、张启瑞、仲志晖、景芸、刘运、钱湘隆、赵金波、曹文中、李劲松、刘先、周亦鹏、王戚。皿G/T 23695-2009 sl 本标准说明在零售银行业务环境下如何保护文件传输。使用该类文件传输的典型例子是在卡的接收设备和收单机构之间，或在收单机构和发卡方之间的文件传输。lV GB/T 23695-2009 银行业务安全文件传输(零售)1 范围批发银行业务的文件传输是在安全性相对高的主机之间进行大量的信息交换(大宗文件传输);与此相比，零售银行业务文件传输以量少、下载设备操作环境的可信赖程度较低为特点。这类设备可以是(但不仅限于)电子销售点终端(EPOS)、自动售卖机(AVM)、自动柜员机(ATM

7、)或与支付网关通信的商户服务器。假设参与安全文件传输的实体之间预先建立的关系已经存在，尤其是涉及与文件传输责任相关的法律和商业等方面。本标准适用于零售银行业务中不同类型的文件传输，但不包括IS08583中涉及的交易报文。文件传输必须要求时效性，并且至少需要符合下列安全服务要求之一:一一报文源鉴别;一一接收方鉴别;-一完整性;一一一机密性;一信息源的不可否认性;一一接收的不可否认性;一-可审计性。假设在传输前发起方传送的全部数据的合法性和正确性已经确认。不同类型的传输文件可包括:一-一软件;一一已经执行和注册的零售交易(上载); 一一与收单机构相关的技术数据(存取参数)(下载); -一与收单机构

8、相关的应用数据(BIN列表、黑名单)(下载)。该类文件传输的特点:a) 传输的数据类型可以是:一一非保密数据(零售交易、技术类数据和应用数据的集合); 一一保密数据。b) 可以接收数据的实体数量z一-一个一一多于一个(甚至向数千的接收者广播)。c) 通讯通路可以包括以下一个或全部:一一电信z公用网络、专用网络。d) 该类传输的方式是:一一直接连接、实时传输(电路交换); 一一存储转发传送(报文交换)。注:本标准考虑到了传输过程中的安全服务要求。确保文件传输完成之后不被更改的要求不在本标准的范围之内。1 G/T 23695-2009 安全文件传输的许可形式安全文件传输传输功能除了通信服务以外，不

9、提供任何安全服务，在这种情况下文件应在传输之前被保护。安全性由发起方和接收方自己管理。他们不信赖底层的传输机制。在通信层(发送方和接收方)上，没有附加的安全性。SFT=Secure File Transfer 立件的安全传输在这种情况下，仅当从发送方到接收方的过程中才考虑安全性，发起方完全信任发送方。例如，当发起方是发送方且安全性由传输层保证，由于发起方没有附加安全性，因此它不是端对端的安全性。在这种情况下，传输功能完全包括安全服务。文件元需在安全传输之前被保护。| 发起方一安全文件的安全传输安全功能在安全功能和传输功能之间分离。例如，发起方生成一文件，利用签名私钥对该文件签名，并且用仅由终端

10、用户(接收者)知道的密钥对该文件加密。所举的例子可以避免发送方组织中的人看到发起方文件的内容。而且发起方信额它的代理来处理文件传输以及考虑发送方与接收方之间的鉴别、完整性。发起方发送方接收方2 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。GB 15851-1995信息技术安全技术带消息恢复的数字签名方案CidtISO/1EC 9796: 1991) GB/T 15852.

11、1-2008信息技术安全技术消息鉴别码第1部分:采用分组密码的机制。SO/IEC9797-1: 1999 , IDT) GB/T 17903. 2-2008 信息技术安全技术抗抵赖第2部分:采用对称技术的机制(lSO/1EC 13888-2: 1998 , IDT) GB/T 17903. 3-2008信息技术安全技术抗抵额第3部分z采用非对称技术的机制(ISO/1EC 13888-3: 1997 ,IDT) 1SO 8372: 1987 信息处理64位分组密码算法的操作模式1SO 8583: 1993 产生报文的金融交易卡交换报文规范1SO 9564-1 :1991银行业务个人识别码的管理与

12、安全第1部分:P1N保护原则和方法ISO/1EC 9796-2: 1997信息技术安全技术带消息恢复的数字签名方案第2部分z使用晗希函数的机制2 1SO/1EC 9798-1: 1991信息技术安全技术实体鉴别机制第1部分z一般模型1SO/1EC 9798-2: 1994信息技术安全技术实体鉴别第2部分z对称加密算法机制150/1EC 9798-3: 1993信息技术安全技术实体鉴别机制第3部分z公钥算法实体鉴别ISO/1EC 9798-4: 1995信息技术安全技术实体鉴别第4部分z使用密码校验功能机制150 9807: 1991 银行业务和相关金融服务报文鉴别要求(零售)GB/T 2369

13、5一2009ISO/IEC 10116 :1 993 信息技术n位分组密码算法的操作模式ISO/IEC 10118-1: 1994信息技术安全技术晗希函数第1部分:概述ISO/IEC 10118-2: 1994 信息技术安全技术晗希函数第2部分z使用n位分组密码算法的哈希函数3 术语和定义下列术语和定义适用于本标准。3. 1 黑名单hot Iist 发卡商或其代理商排列并在交易中无效的主账户号码(PAN)列表。3.2 数字签名digital signature 附加于数据单元之后的数据或者是数据单元加密后的某种形式，以使数据单元允许它的接受者检验数据单元的来源和完整性，及防止接受者的伪造。3.

14、3 e u a v n o 汹值qad马v民e、vbm的验值校验件枝文件叫于文F用3.4 晗希值hash code 对数据哈希后的结果。3.5 晗希函数hash function 将位串映射为定长位串的函数，在本标准中它具有以下两个特性:一-对于一个给定的输出不可能推导出与之相对应的输入;一一对于一个给定的输入不可能推导出第2个具有同一输出的输入。3.6 应用管理器application manager 终端软件的一部分，负责预期可执行对象安全下载的验证。3. 7 报文鉴别码message authentication code MAC 发送方和接收方传递报文包含的代码，用于证实报文来源及部分

15、或全部报文文本的有效性。注:代码是双方协定的计算结果。3.8 发起方originator 生成传输到接收方的文件并且对其安全性负责的实体。3.9 接收方receiver 接收文件的实体。3. 10 发送方sender 发送文件的实体。3 G/T 23695-2009 3. 11 主办方sponsor 评估文件传输风险的实体。4 原则4. 1 报文源鉴别报文源鉴别的目的是保证向接收方声称的发起方是真正的发起方。当被授权的接收方从授权的发起方子集中接收特定文件时，报文源鉴别可以向接收方保证所传输的文件是真实的。报文源鉴别可以与文件传输同时发生，在直连模式下也可以先于传输过程发生。如果使用存储和转发

16、传输，报文源鉴别应在传输完成后，接收方得到这个文件时进行(安全文件的传输属于该模式。鉴别报文内容的技术可以提供报文源鉴别，但这些技术要求整个文件的传输在鉴别可以确认前完成。也许有要求在发起传输之前需要进行报文源鉴别的情况。例如，尽管非法的发起方最终会被检测到，传输的文件也会被拒绝，但还是有防止冒名顶替者伪装成合法的文件提供方并且在传输大文件延时占用通信信道的要求。4.2 接收方鉴别该项安全服务在传输过程之前鉴别接收方的身份，因此，只有当接收方的身份被确认时，传输才会进行。一些接收方(POS终端)只允许接收某些类型的文件。部分鉴别过程由发起方控制，发起方有控制接收方接收某种类型文件的权利。进行接

17、收方鉴别的另一个目的是防止未授权方伪装成合法的接收方并防止发起方传输一冗长文件给伪装者占用发起方的通信资源。接收方鉴别不能防止未授权方探知文件内容(通过侦昕勺。没有该项安全服务以及机密性安全服务，任何人都可轻易地伪装成合法的接收者获取文件。如果要保证仅使文件的授权接收方接收到文件，那么必须使用机密性安全服务。只有通过该方法才能确保未授权方不在通信信道上侦昕并获取文件内容。注2相关安全服务，接收的不可否认性可以确保在传拍完成之后，授权方成功地接收到该文件。4.3 完整性对传输文件或者传输文件一部分的意外的或未授权的变更，应在传输时或传输之后被检测到。完整性服务在单个传输过程中可以控制整个文件，或

18、能够分别控制文件的几个部分。4.4 机密性在需要时传输文件的机密性应得到保证并应用到整个文件或文件需要保密的部分中。4.5 信息源的不可否认性该项安全服务提供了这样的证据z声称的发起方实际生成了传输的文件(如果没有该证明，发起方可能错误地声称文件是接收方生成的，或接收方可能生成了该文件但错误地声称该文件来自发起方。4.6 接收的不可否认性该项安全服务提供这样的证据:声称的接收方实际收到了传输的文件。没有该证据，接收方可能声称没有收到该文件。该项服务由附录A说明的机制实现。接收方发给发起方不可否认的标记报文，如果za) 目的接收方收到了该文件zb) 文件内容没有被更改。注:不可否认性的范围可由国

19、内的法律、规章规定。4. 7 可审计性如果应用需要可审计性，发送方/发起方和(或)接收方有必要适当记录传输过程的细节(时间和日4 GB/T 23695-2009 期、文件种类、文件容量、版本编号等)。这些记录包括传输失败的数据尝试，也包括成功传输数据的尝试。如果发生欺诈的尝试，失败的传输记录可以帮助识别尝试的来源。5 应用5. 1 软件下载5. 1. 1 定义终端软件包括下列不同的功能层次(见图1):a) 可信赖的、固定的软件，在安全文件传输之前被预先加载，负责执行应用管理器的下载和安全运行的安全性机制;b) 应用管理器负责执行不同应用程序的下载和安全运行的安全性机制;c) 不同的应用，由可执

20、行实体或解释性实体组成。注:以上所述是加载和驱动终端设备程序过程中具有代表性的功能层次。只有层b和层c是可下载的。层a的安全性不在本标准范围之内。1 2 3 口4c b 6 h-Ea 1一一应用1;2-应用2; 3一一应用3;4一-可执行对象或解释性对象;5一-密钥z6一一应用管理器z7-一信赖的、固定的、预先加载的软件(引导程序bootstrap)。图1终端软件的表示(示意图)软件下载所要求的安全性服务:一一互相鉴别或发起方/发送方的单方鉴别;一一传输文件的完整性确认。在适当时敏感数据可以要求机密性(例如密钥)。当下载功能在特定的缓存区中处理，并且在软件接收前已经执行了完整性检验时，可以不要

21、求对发送方通过设备事先鉴别，只完成发送方的固有鉴别。每个层面的操作顺序应是:相互鉴别、软件传输、完整性确认。如果相互鉴别失败，不应进行软件传输。如果完整性确认失败，接收设备不接收软件，并且所有操作步骤应重新执行。注:对接收方不必总进行鉴别.对接收方来说，下载软件时进行报文源鉴别已经足够.5 GB/T 23695-2009 5. 1.2 相互鉴别5. 1. 2. 1 实施无论软件下载的发起方是哪个实体，在任何层面上，相互鉴别的成功执行应先于任何文件传输。一当下载应用管理器时，应通过预先加载的可信赖的、固定的软件所提供的相互鉴别安全服务进行保护;一一应用下载本身应通过相互鉴别服务保护，在应用管理器

22、中实施，并且对每一个授权的应用均使用专用密钥。通常，发送方可管理几个应用，每个应用可传输到设备上。相互鉴别过程包括发送方对每个接收设备及其接收每个应用程序的权限的验证，它包括:一一每个设备应由唯一的识别码标识;一一发送方将授权应用的列表和每个设备识别码关联。5. 1. 2. 2 机制相互鉴别机制要求2次或3次报文交换并且可以通过对称或非对称算法实现。ISO/IEC9798详细说明了该安全机制。当使用对称算法时，ISO/IEC9798号:1997和ISO/IEC9798-4: 1995适用。当使用非对称算法时，ISO/IEC 9798-3: 1993适用。相互鉴别并不涉及可信赣第三方，可以使用序

23、列号(或时间戳进行两次鉴别或使用随机数进行三次鉴别。详见附录A。5. 1. 2. 3 密钥管理密钥管理技术应遵循我国密码管理部门的有关规定。对称骂法在所有下载之前应安全地安装初始密钥。同一个密钥可用于两个设备，但建议相互鉴别的每个设备使用唯一密钥，防止一个设备通过改变它的标识伪装为另一个设备，并且防止生成一个错误的发送方损害设备的密钥囚每个层面下载之前，用于相互鉴别的密钥可以不同。非对称法非对称算法的使用要求接收方与发送方具有信赖关系，用于相互鉴别的密钥是:一一私钥驻留在设备中，并将与之关联的公钥传给发送方用以鉴别终端;一一所有设备每一层面具有一个唯一的公/私密钥对。即使发送方不同，但对b和c

24、两个层面而言，设备的私钥可以相同。用于鉴别应用管理器的发送方的公钥应驻留在每一设备中，并防止被替代。用于鉴别应用管理器的公钥应与应用管理器同时安全下载或者预先安全加载。5. 1.3 完整性5. 1. 3. 1 实施应通过向文件内容添加FVV确保传输文件的完整性。文件的FVV只需计算一次，因为它不需依额下载操作和接收设备的标识。设备中一层软件下载后和在将其激活之前，该设备应确认下载文件的FVV。5. 1. 3. 2 机制依照所使用的算法，需要一步或多步生成FVV，详见图2和附录A。6 GB/T 23695-2009 1 3 2 5 4 6一一-一-一-B 1一一文件;2-一不包含密钥的算法;3一

25、一包含密钥的算法;4一一非对称算法;5一一，对称算法;6-一步骤1; 7一一步骤2; 8一一密钥;9-一晗希值z10-报文鉴别码(MAC);11-不做进一步处理;12-一数字签名;13一-文件校验值(FV呐。5. 1.3.3 密钥管理11 13 圄2FVV的生成FVV需要使用密钥(对称算法)或私钥(非对称算法)或不使用密钥的值(哈希值)。基于密钥的FVV的操作由加密设备进行。对称算法用于每一层完整性的密钥应不同。用于确认下载的应用管理器完整性的密钥应在设备交付使用之前安全地安装。用于确认下载的应用完整性的密钥应是:一一在设备交付使用之前安全安装;或一一与应用管理器同时安全下载。这些密钥的完整性

26、和机密性应使用一系列预先安装的密钥保护。7 GB/T 23695-2009 非对称算法每一层面有唯一的公/私密钥对，发送方保留私钥，所有接收方的公钥相同。用于确认下载的应用管理器完整性的公钥应在每一个设备中，并防止被替换。用于确认下载的应用完整性的公钥应与应用管理器同时下载或预先加载。加密晗希技术晗希函数有两个阶段的操作。生成FVV的第一步是，对整个传输文件进行晗希计算，使用晗希算法，不使用任何密钥(保密或其他的)。第二步，包括应用对称或非对称的晗希算法，附加数据与合适的填充生成FVV。5.1.4 机密性软件下载可以不需要机密性。当机密性服务被要求用于密钥和数据时，从发送方下载密钥或私钥，而且

27、该密钥应经过加密保护。5. 1.5 接收的不可否认性接收并确认了软件的完整性之后，设备应向发送方发送一安全确认，确认接收的完成(成功或失败)以及完整性验证结果。一一安全确认应包括肯定或否定的结果，以及在相互鉴别阶段由设备使用相同的密钥发给发送方的鉴别报文;一-时间磁。安全确认应符合GB/T17903. 2一2008或GB/T17903. 3-2008的要求。接收到安全确认时发送方应确认和记录。5. 1. 6 发起的不可否认性不可否认性应被用于确保服务的完整性。当非对称算法用于确保完整性服务的同时也提供发起的不可否认性，因为只有发起方知道计算签名所需要的私钥。在这种情况下，设备应记录签名。注:如

28、果签名的数据不包括时间碍，不能完全达到发起不可否认性的目的。5. 1. 7 可审计性为了确保不可否认性服务，5.1.5和5.1.6中所描述的信息应记录日志。5.2 参摄下载5.2. 1 定义参数下载包括应用数据(例如BIN列表、最低限度)、黑名单文件、传输和更新发送方访问参数。接收方的应用软件应发起这样一类传输，它可能包括与先前用于下载应用软件完全不同的协议和发送方。用于参数传输的安全服务由发起方或发送方控制。通常，应用软件提供商通过应用服务器提供应用，参数由发起方通过参数服务器提供，两方实体可以相同。在该情况下，安全机制和密钥应由应用提供者通过应用软件依照主办方说明实施。参数下载要求的安全服

29、务有:一一互相鉴别或发起方/发送方的单方鉴别;一一完整性确认;一一适当的机密性;一一依据参数类型接收的不可否认性。当需要上述参数时，操作的顺序应是相互鉴别，参数传输，完整性确认和接收的不可否认性。在相互鉴别失败的情况下，不应执行参数传递。如果完整性确认失败，设备不应保留参数，整个操作应重新执行。注z没有必要总是鉴别接收方.对接收方而言，对下载的参敛报文源鉴别己足够，8 GB/T 23695-2009 5.2.2 相互鉴别应用软件下载的相互鉴别要求适用于此。这种文件传输可看作是应用下载操作的附加层。5.2.3 完整性应用软件下载的完整性要求造用于此。这种文件传输可看作是应用下载操作的附加层。5.

30、2.4 机密性根据网络种类，机密性服务可以被要求用于传输活动表，最低限度等参数。当需要时，机密性服务的执行应满足本地规则。5.2.5 接收的不可否认性如果主办方要求，应用软件下载的接收不可否认性要求适用于此。5.2.6 发起的不可否认性如果主办方要求，应用软件下载的发起的不可否认性要求适用于此。5.2.7 可审计性为了确保不可否认性服务，应记录5.1.5和5.1.6中所描述的信息日志。5.3 零售交易上载5.3. 1 定义对于这种环境，发起方/发送方是终端或商户服务器。零售交易上载包括，向收单机构服务器发送的该时期金融交易文件和附加的相关数据，例如金融交易笔数和交易总额。零售交易上载需要的安全

31、服务有:一一相互鉴别;一一交易文件传输的完整性确认。操作的顺序应是:相互鉴别、交易文件传输、服务器进行完整性确认、服务器发送接收的证据。如果相互鉴别失败，应不执行文件传输。如果完整性确认失败，服务器应拒绝交易，相互鉴别应重新执行。5.3.2 相互鉴别5.3.2.1 实施零售交易上载应通过应用层实施的相互鉴别进行保护。5.3.2.2 机制如同软件下载，ISO/IEC9798适用于此。因为同一个收单机构可从不同生产商提供的设备中收集交易，所以该机制应独立于设备。5.3.2.3 密钥管理对称算法因零售交易上载操作在收单机构的控制之下，用于相互鉴别的密钥由收单机构确定，它们应在设备中的保护区域，例如，

32、ISO10202-4: 1996(;ISO/IEC 10118.2 信息技术安全技术晗希函数第2部分:使用n位分组密码算法的晗希函数。., ISO/IEC 10118-2: 1994，详细说明使用n位分组密码算法的晗希函数(拥有n位分组长度的明文块和密文块)。不对位分组密码算法详细说明。详细说明了两类哈希函数。第一类提供小于或等于n位长度的晗希值，第二类提供小于或等于长度为2n的哈希值。. ISO/IEC 10118-3，标准的SHA-1，RIPEMD-128和RIPEMD-160。.3 报文鉴别码报文鉴别码可用于鉴别文件的来源和保护从发送方到接收方文件的完整性。它由文件发送方生成，并和文件一

33、同传输。报文鉴别码可应用于整个文件或文件的一部分。GB/T 15852. 1一2008详细说明了数据完整性机制:该方法使用密钥和n位分组密码算法来计算m位密码校验值。密码校验值作为报文鉴别码CMAC)。15 G/T 23695-2009 A.4 密码算法A.4.1 对称密码ISO/IEC 10116: 1993的标题为信息技术n位分组密码算法的操作模式)，说明了n位分组密码算法的4种操作模式(它并不对位分组密码算法进行说明): 一一电子编码本模式(ECB); 一一密码块链接模式(CBC); 一一密码反馈模式(CFB); -一输出反馈模式(OFB)。和每种模式各属性的注释。注:当n=64时，IS

34、08372:1987与IS0/IEC10116: 1993一致。A.4.2 非对称密码RSA是非对称密码的例子。16 GS/T 23695-2009 B.l 系统的说明该例子涉及的POS终端构成如下:一一软件:附录B(资料性附录)实施的例子 操作系统的安全应用管理器部分; 若干零售银行业务应用; 每种应用的参数文件，包括BIN列表，活动表，最低限度.一一硬件: 终端(CPU,ROM, RAM,h 安全密码处理器; 可移动的IC卡，收单机构用于识别和鉴别商户。设备连接的不同服务器如下:一一生产商服务器，用于下载应用管理器;一一应用提供商服务器，用于下载应用软件;一一参数服务器，收单机构控制，用于

35、下载参数;-一-收单机构服务器，接收金融交易文件。B.2 终端的密码函数注解:一一-A=eK(B):使用对称密钥K生成的B的加密数据;一-B=dK(A):使用密钥K解密密文A，恢复为明文B.B.2.1 软件下载lB. 2. 1. 1 完整性确认:非对称立法非对称算法用于软件下载的完整性确认。这种方法将公钥保留在终端。该密钥不要求机密性保护，但要防止被替换。该方法防止生成虚假签名，甚至于在已经成功攻击终端的安全设备的情况下，也可防止生成虚假签名。B.2. 1. 2 相互鉴别:对称算法对称算法用于相五鉴别。不管使用何种算法，相互鉴别都要求使用存放在终端的密钥。为防止使用从泄密的终端获取的密钥来伪造

36、终端，下载应用管理器话要衍生鉴别密钥。实施衍生密钥系统，尽管对称算法可同唯一主密钥和衍生算法一起实施，仍将要求通过非对称算法保留所有终端的全部密钥表。B.2. 1. 3 应用管理器实施的密钥管理B.2. 1.3. 1 相互鉴别DEAl作为对称算法用于相互鉴别。KAM:用于衍生的相互鉴别主密钥，由生产商生戚，安装于生产商服务器之上。KATi:由生产商生戚相互鉴别衍生密钥，在交付之前安装于终端的安全密码处理器之上。17 GB/T 23695-2009 TID:终端标识符。KATi=eKAM(TID) ; TID=dKAM(KATi)。B. 2. 1. 3. 2 完整性RSA作为非对称算法用于完整性

37、鉴别。SKKI:生产商使用的私钥，用于签名软件(当签名不包括时间戳或序列数时，元需安装在生产商服务器上)。PKKI:生产商生成的公钥，在交付之前安装在终端的安全密码处理器上。B.2. 1. 4 应用实施的密钥管理B.2. 1. 4. 1 相互鉴别DEAl作为对称算法用于鉴别终端。KAAn:应用n的相互鉴别密钥，由应用提供商生成，安装在应用服务器之上。必须安全地发送给终端，在安全密码处理器上进行保护。为达到此目的，生产商应生成非对称密钥对:SKAAn、PKAAn.生产商向所有应用提供商公布公钥，以便于他们可加密KAAn.每个应用提供商返回密码ePKAAn(KAAn)给生产商。私有传输密钥SKAA

38、n在交付之前，由生产商安装在终端的安全密码处理器之上。应用管理器软件保留安装在终端上的应用列表和用于相互鉴别的相关密码ePKAAn(KAAn)。在应用管理器下载操作过程中，应用列表和相关密码传输给终端。B. 2. 1. 4. 2 完整性RSA作为非对称算法用于确认应用软件的完整性。应用提供商n生成非对称密钥对:SKAnI、PKAnI。它发布公钥给生产商。SKAnI:应用提供商n使用的私钥，用于签名它的应用软件(当签名不包括时间戳或序列数时，元需安装在服务器上)。PKAnI:终端已下载的应用管理器中包含的关联密钥。安装在终端上的终端软件维护应用列表和用于完整性确认的关联公钥。B. 2. 2 参数

39、下载与收单机构相关的密钥，可以保存在可移动的安全加密设备中，由收单机构用于标识和鉴别商户。B. 2. 2.1 相互鉴别DEAl作为对称算法用于终端的鉴别。KAQM:收单机构和终端的相互鉴别的主密钥，由收单机构生成，安装在参数服务器上。KAQRk:相互鉴别的衍生密钥，由收单机构生成，安装在零售商k的终端上，例如通过商户的IC卡进行安装。RID:零售商标识符。KAQRk=eKAQM(RID)。B.2.2.2 完整性确认RSA作为非对称密钥用于确认应用参数的完整性。SKPI:收单机构使用的私钥，用于签名它的应用参数(需作为签名安装在服务器之上，须包括时间戳或序列数)。PKPI:由终端使用的包含在商户

40、IC卡中关联公钥。B. 2. 3 交易上载B. 2.3.1 相互鉴别当完整性服务和接收不可否认性服务按照本标准实施时，在传输交易文件之前，本标准不再明确提出其他的鉴别的安全要求。本例实现了这两种服务。18 GB/T 23695-2009 B.2.3.2 完整性确认z对膏、算法对称算法用于交易文件的完整性确认。完整性确认使用基于衍生密钥的方法，该项服务由收单机构服务器提供终端的鉴别服务。DEAl作为对称算法用于交易文件的完整性确认。KTQM:收单机构的主密钥，由收单机构生戚，安装在收单机构服务器上。KTQRk:完整性确认衍生密钥，由收单机构生戚，加载于商户IC卡上。KTQRk=eKTQM(RID

41、)。使用街生密钥可防止生成虚假签名，甚至于在已经成功攻击终端安全设备的情况下，也可防止生成虚假签名。B.2.3.3 接收的不可否认性:非对称算法该服务使用非对称算法，私钥SKPNR由收单机构生成并驻留在收单机构服务器中，当成功接收交易文件和确认完整性时，私钥SKPNR用于生成实时证书。保护防止替换的公钥PKPNR包含在由收单机构发送的参数文件中并保护其完整性。终端使用该证书鉴别接收金融交易文件的收单机构服务器，在成功确认证书之后，立即清除该文件。商户IC卡KAQRk PKPI KTQRk 终端iKATi PKKI SKAAn (1) Cert (KA Ti) (2) Cert (KATi) 生

42、产商服务器KAM (SKKD PKAnI 应用服务器nK AAn PKAAn (SKAnl) (3) KemeI+(KAAn)PKAAn+ PKAnI +Sign(SKKI) (4) Cert (KAAn) (5) Cert (KAAn) 6) Application+Sign (SKAnI) (7) Cert (KAQRlc) (8) Cert (KAQR1c) (9) p缸缸neters+SKPNR + Sign(SKPD (10) Transactions+Sign (KTQR1c) (11) Ce口(SKPNR)注:(K)表示密钥K元苟安装在服务器之上.参数服务器KAQM (SKPD

43、收单机构服务器KTQM SKPNR (1) (2)应用管理器的下载z终端和使用对称衍生密钥KATi的生产商服务器之间的相互鉴别，(3)下载应用服务器+在应用下载中使用的密钥:生产商服务器使用非对称密钥SKKI签名。(4)(5)应用下载2终端和使用对称密钥KAAn的应用服务器相互鉴别。(6)应用下载:应用服务器使用非对称密钥SKAnI签名。(7川的参数下载:终端和使用对称衍生密钥KAQRk的参数服务器相互鉴别。(9)参数下载十交易上载过程使用的密钥z参数服务器使用非对称密钥SKPI签名。(10)交易文件上载:终端使用对称衍生密钥KTQRk签名。(11)交易文件上载2收单机构服务器使用非对称密钥S

44、KPNR认证。图B.l19 GB/T 23695-2009 附录C(资料性附录)保证文件传输完整性确认的示例该示例来自澳大利亚的国家标准AS2805-10。C.l 范围该示例不包括文件传输处理机制的任何规则，仅限于数据校验方式。该示例详细说明了两个通信实体传输期间确保文件完整性的方法za) 直接从文件计算出来完整性校验值;b) 用文件的哈希结果计算出完整性校验值。完整性校验值称为文件校验值(FVV)，参见4.3。该示例不包括确保文件机密性或文件传输的技术。注:发送FVV管理文件的报文示例参见附录A和附录B中的图B.1.C.2 定义以下定义适用于本示例。C. 2.1 数据密钥用于数据加密或解密的

45、密码密钥。C.2.2 文件技验值(FVV)用于文件投验的导出值。C.2.3 中间节点向安全密码设备。CD)提供数据转发服务的计算机系统或设备。C.2.4 MAC密钥(KMAC)用于计算、校验或既计算又校验报文鉴别代码的密钥。C.2.5 安全密码设备(SCD)提供安全密码服务的作为系统一部分的接收方;终端密码单元(TCU)是一种安全密码设备(SCD)。C. 2. 6 安全机制相互认可的实体进行手工交付时用以确保物理安全的方法。C. 2. 7 主办方负责文件内容合法性和完整性的实体。C.3 综述C. 3.1 概述文件传输完整性确认是独立于文件传输的功能，验证被加载或更新到SCD中的文件是否与发送方

46、的一致。通过使用该技术，可以在非安全的网络上发送完整的文件或文件更新，并且在被载入到SCD并检验之前，将其存储在中间节点上，因此该方法为网络传输提供了更多的选择性。20 这仅仅是对SCD中的文件进行FVV交换和验证，并且是在安全报文交换中进行的。这一节提供了使用的原则的概述。管理文件传输完整性确认的步骤如下za) 报文鉴别:GB/T 23695-2009 b) 对文件进行晗希;c) FVV加密。C. 3. 2 原则强调文件传输完整性确认的原则如下:-一在任何情况下，整个文件应使用FVV;-一-FVV应通过安全机制、加密或MAC方式从发起方到接收方进行传输;-一只有在FVV确认之后才能使用文件;

47、-一如果接收到的是更新文件，那么在更新被应用前应使用FVV验证该文件的正确性;-一-主办方应负责文件的准确性和FVV的生成;-一一文件接收方应通过FVV检验文件的完整性;一一接收方应使用SCD安全地计算出FVV。C.4 功能元的说明C. 4.1 文件确认值FVV衍生于文件的内容，目的是确认文件的完整性。当进行修正时，应使用FVV检验文件的完整性a文件被修正时，修正后的文件的完整性应使用FVV进行检验。这可确保修正被正确地应用。C.4.2 FVV衍生C. 4. 2.1 概述当SCD能支持基于密钥的技术，FVV应通过基于密钥的模式衍生。当基于密钥的技术不适合，例如，由于接收方数量过多的原因，可使用基于哈希的技术，不要求使用密钥进行计算。FVV应基于完整的物理文件进行计算。基于密钥的技术将只使用IS09807: 1991上所说明的算法。除了不使用密钥之外，非基于密钥技术在操作上和基于密钥的技术相似。尽管使用ISO9807: 1991中的单倍和双倍长度的哈希函数会简单一些，但哈希函数并不仅限于某种特定的方法。C.4.2.2 基于密钥的FVVFVV通过使用SCD中指定的特定密钥，通过MAC方式进行计算。C.4. 2. 3 非基于