银行新一代核心业务系统应用安全预案

162/162华夏银行新一代核心业务系统应用安全方案版本记录版本版本日期修改者讲明V0.12006/9/5中国惠普公司初稿V0.52006/10/20中国惠普公司依照华夏银行的建议，更改交易信息安全方案V1.02006/11/11中国惠普公司依照华夏银行的建议，更改文档章节结构

目录TOC\o"1-4"\h\z\u1. 整体安全方案概论 61.1. 此分文档的目的 61.2. 整体安全方案概论 72. 目前核心系统安全现况及新一代核心业务系统应用安全需求 82.1. 目前核心系统安全现况 82.1.1. 业务范围 82.1.2. 系统架构 82.1.3. 系统应用安全现况 82.2. 新一代核心业务系统应用安全需求 92.2.1. 遵循华夏安全准则需求 92.2.2. 业务范围 92.2.3. 系统架构 92.2.4. 应用安全需求及处理 102.2.5. 安全标准、原则及需求 11. 安全标准 11. 安全原则 11. 安全需求 113. 身份验证 143.1. 身份验证方式 143.1.1. 动态口令验证方案 143.1.2. USB-Key验证方案 153.1.3. 身份验证方案建议实施方式与实施时期 163.2. 身份验证系统架构方案 173.2.1. 单一入口服务系统(Portal)架构方案 174. 授权操纵 204.1. 授权治理架构 214.1.1. 授权组织架构方案 214.1.2. 授权治理流程 224.2. 授权系统架构方案 254.2.1. SSO系统架构方案 254.2.2. 独立授权服务器架构方案 265. 传输安全 285.1. 网络安全 285.1.1. 链路加密机加密处理 285.1.2. 目前所了解BANCS系统的处理方式 285.1.3. 终端用户与BANCSLink间网络安全 295.1.4. BANCSLink与BANCS间网络安全 305.1.5. BANCSLink与综合前置间网络安全(组合交易) 305.1.6. 外围系统与综合前置间网络安全 315.1.7. 综合前置与BANCS间网络安全 315.2. 应用安全 325.2.1. 应用安全方案 325.2.2. 点对点的加密方案 325.2.3. 选择性的金融交易加密方案 335.2.4. 交易信息敏感性数据加密方案 335.2.5. 交易数据完整性方案 375.2.6. 服务器间验证方案 376. 存储安全 406.1. 交易数据安全存储方案 406.1.1. 交易敏感性数据加密存储方案 406.2. 密码安全存储方案 416.2.1. 动态口令登入密码存储方案 416.2.2. USB-Key登入密码存储方案 416.2.3. 客户口令加密存储方案 426.2.4. 客户口令不可逆存储方案 436.3. 新旧系统密码移转方案 436.3.1. 用户登入口令的移转 446.3.2. 客户支付口令的移转 447. 安全治理 467.1. 密钥治理方案 467.1.1. 密钥生命周期治理方案 467.1.2. 密钥更换治理方案 557.2. 防病毒治理 577.2.1. 病毒传播路径 577.2.2. 防堵病毒传播方法 577.2.3. 防治病毒的解决方案 588. 推举方案 608.1. 身份验证方案建议 608.1.1. 建议方案的优/缺点分析 608.1.2. 建议实施方案 618.2. 授权操纵方案建议 628.2.1. 建议方案的优/缺点分析 628.2.2. 建议实施方案 628.3. 传输安全方案建议 638.3.1. 建议方案的优/缺点分析 638.3.2. 建议实施方案 638.4. 存储安全方案建议 648.4.1. 建议方案的优/缺点分析 648.4.2. 建议实施方案 64附件一：第二级信息系统安全等级 65附件二：第三级信息系统安全等级 71

整体安全方案概论在目前网络发达、网上交易盛行、网络诈欺事件及智慧型网络盗窃犯罪层出不绝的状态下，银行业务处理面临前所未有的挑战；既要维护银行的信誉与保障客户数据不外泄，同时又要能即时无误的处理客户业务需求，让客户无安全上的顾虑(不管是柜面交易或是从渠道进来的交易)，业务交易处理安全上的考量变得特不重要。规划一套业务应用安全机制及建设交易应用安全系统是当务之急的重要工作，尤其是对新一代核心业务系统更是重要。建设这种交易安全机制并不阻碍现行系统的运作，透过应用安全机制的建设，爱护客户及银行的数据与资产，让业务交易处理的安全性及信息的爱护更加完善，更是时时刻不容缓的工作。此分文档的目的信息安全是金融机构处理日常工作的最重要的指标，爱护客户的资产及银行的资本重要性，是银行业务处理的重心，核心系统应用安全是此文档要讲明/表达的目的。文档读者华夏银行大集中办治理层领导、华夏银行信息技术部领导、华夏银行大集中办项目治理办公室人员、华夏银行信息技术部项目治理办公室人员、华夏银行大集中项目监督委员会成员、华夏银行大集中项目治理委员会成员、华夏银行大集中工程在建项目经理、组长等。涵盖范围本文档用于描述华夏银行新一代核心业务系统（NGCBS）项目中有关核心系统应用安全，由总体架构组(OSA)依华夏银行新核心系统应用安全需求，整理后的整体设计方案。新一代核心业务系统(NGCBS)项目应用安全的范围包含：交易数据的安全需求数据传输的安全需求（广域网及局域网）数据库中数据的安全需求柜员的登录方式与授权治理

整体安全方案概论本方案的内容包含了以下几个面向：身份验证的安全方案身份验证的安全方案描述新一代核心系统应采纳何种方案，确保终端用户登入系统的身份，幸免使用假冒的身份。新一代核心系统的终端用户包含支行用户﹑分行用户﹑系统治理用户。此方案的详细内容请参考第3章。授权操纵(访问操纵)的安全方案授权操纵的安全方案描述新一代核心系统应采纳何种方案，确保每一位用户在系统上执行的作业或是系统功能均为合法的。幸免因用户非法的操作造成业务上的损失。此方案的详细内容请参考第4章。传输上的安全方案传输上的安全方案分为网络层的安全与应用层的安全。网络层的安全是确保数据在网络上传输时，确保数据的私密性与完整性。应用层的安全是确保数据在输入终端至处理终端间的传输过程中，确保数据对中间处理系统的私密性与完整性。此方案的详细内容请参考第5章。存储数据的安全方案存储数据的安全方案描述新一代核心系统应采纳何种方案，确保数据存储于数据库中的安全，包含数据的私密性安全与完整性安全。此方案的详细内容请参考第6章。安全治理的方案安全治理的方案包含两个部分，分不为密钥的安全治理与防病毒的安全治理。密钥的安全治理是描述密钥在生成﹑公布﹑备份﹑删除上的安全治理措施。防病毒安全治理是描述服务器与终端设备上防止病毒感染与病毒散步的安全治理措施。此方案的详细内容请参考第7章。本方案所涵盖的安区方案对应于OSA的安全架构，可用下表讲明：安全标准对应章节1对应章节2对应章节3身份验证3.身份验证访问操纵4.授权操纵私密性5.1网络安全5.2.1.交易信息敏感性数据加密6.存储安全完整性5.2.2.交易数据完整性辨识性5.2.4服务器间验证不可否认性5.2应用安全在本方案的最后，针对各章所提出的各种方案，依据各个方案的优劣点，提出建议实施的内容，作为新一代核心系统安全方案实施上的考量。

目前核心系统安全现况及新一代核心业务系统应用安全需求目前核心系统安全现况业务范围目前华夏银行的2K版核心系统是采纳各个分行分散式作业方式，华夏银行有28个分行，下辖大约总共300个支行；28个分行分布于全国各地，北从沈阳分行，南到深圳分行，西起乌鲁木齐分行，东达上海分行，幅员分布宽敞。2K版核心系统业务包含存款、放款等业务系统；其他的相关业务系统与治理系统皆各自建设在不同的外围系统上；每个分行有各自的外围系统，透过分行前置系统与2K版核心系统连接；各个分行有各自的中间特色业务系统，分行间的中间特色业务不尽全部相同；各个分行有各自的分行前置系统负责分行/支行间的业务交易处理。系统架构华夏银行目前正进行大前置系统项目，要将所有分行前置系统整合为一个集中式的总行综合前置系统及分行前置系统；同时将中间特色业务系统全部整合在总行综合前置系统与分行前置系统上。现有2K版核心系统后台的操作系统是AIX，前台VOST柜面系统服务器的操作系统是SCOUnix，前台柜面终端机的操作系统是SCOUnix。前台VOST柜面系统服务器放置在支行负责连接支行柜面交易与分行间的处理；有部分分行将前台VOST柜面系统服务器上收到分行端，有分行统一治理前端柜面系统。系统应用安全现况目前2K系统的交易处理是由各个支行的柜面服务器到分行2K版核心系统，交易处理上是除了客户密码是以软件加密方式处理外，其他的交易数据是没通过加密处理，完全是以明码方式传送。这种处理方式，对於交易信息的安全是无任何的保障；不安全阻碍所及的范围涵盖分行及下辖的支行职员与客户，对於客户资产及银行数据是完全没有任何的爱护。

新一代核心业务系统应用安全需求遵循华夏安全准则需求依”华夏银行大集中项目信息系统信息安全等级爱护要求1103.doc”文档的规范，要紧是着重在安全差不多要求上的技术类安全要求，对於治理类安全要求，需依照华夏银行的安全治理规范或安全治理方法等条款办理。新一代核心业务系统应用安全需求，是以差不多技术要求中的应用安全和数据安全等两方面的安全要求来规划。技术类安全上，则是侧重在业务信息安全类，要紧是爱护数据在存储、传输、处理过程中不被泄漏、破坏和免受未授权的修改。业务服务保证类与通用安全爱护类的安全需求，对爱护系统连续正常的运行及爱护系统的连续可用性需由新一代核心业务系统主机厂商对硬件及操作系统相关的建设与实施，同时华夏银行负责运行部门需订定相关的安全治理规范来保证系统的正常连续运作。有关主机系统安全的规范，需由新一代核心业务系统主机厂商来提供硬件及操作系统相关的安全数据；数据库系统的安全需由数据库厂商提供相关的安全数据。网络安全需由相关的路由器、交换机、通信线路等在内的厂商提供相关的信息系统网络环境的安全数据。详细有关安全需求等级的规范对比，请详如本文档的附件章节。业务范围新一代核心系统业务范围包含：存款、放款、华夏卡、支付结算等，所有的银行客户业务交易信息，皆与核心系统息息相关，是银行业务处理中最重要的部分。系统架构新一代核心系统是采纳集中式的作业方式处理，全国各地分行所有的交易全部都经由全行网络送到总行的新核心系统处理。新一代核心业务系统，除了新一代核心系统外，尚有总帐系统、总行综合前置系统、55个(与新一代核心系统有接口关系的)外围系统、核心配套外围系统(从2K系统独立出来的系统，如:人行大/小额系统、理财系统、卡记点积分系统等)及其他系统等(与新一代核心系统无接口关系，如:人力资源系统、稽核系统等)。新一代核心系统负责面向客户治理的交易处理作业；总帐系统负责面向华夏内部治理的后勤处理作业；综合前置系统负责华夏银行总行面向外部的交易处理(如对分行/支行交易处理、外围系统交易处理、中间特色业务系统交易处理、面向各种渠道交易处理、银联中心/银关通/银证通/财税库行/人民银行等外围金融机构的交易处理)，是华夏银行业务处理的重要把关门户。新一代核心系统(BANCS)、前端柜面系统(BANCSLink)及柜员终端机的交易处理是采纳集中式的作业方式，新一代核心系统产品并未有应用信息安全处理机制；目前华夏银行使用对客户密码采纳软件加密的方式，对於最重要的新一代核心业务系统是无法满足应用信息安全的需要；加上目前外在环境的变化与智慧型网络犯罪的盛行，无法防范这些种种的威胁，对华夏银行及所有客户的整体阻碍更是深远。应用安全需求及处理应用安全的规划，将从国际上的应用数据的安全标准(应用安全及传输安全)、安全原则(数据的真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性))及安全需求，来逐步讲明。同时，在应用安全上需要搭配相关的硬件/软件加密设备来进行敏感性数据加密；在网络上需要采纳链路加密设备，来处理网络层的传输安全需求。

安全标准、原则及需求安全标准应用的安全标准安全上的标准要紧有两种：数据加密标准(DES:DataEncryptionStandard)与公开密钥法则(PKI:PublicKeyAlgorithm)。数据加密标准(DES):需要产生一对密钥，必须要将自己产生的另一个密钥发送给对方，本身端用自己的密钥加密，对方端用所送的密钥去解密。一般应用在数据的端对端的加密/解密使用，普遍用於金融机构的数据加密/解密。另外对数据加密的强化，采纳TripleDES的加密方式。公开密钥法则(PKI):需要产生一对钥值，分为公钥及密钥，自己保留密钥，公钥发送给对方。本身用密钥对数据加密，对方用所送的公钥验证数据的正确性。一般应用在网络电子交易的加密/解密处理。传输的安全标准网络层传输的安全标准，要紧有几种，如：SSL(SecureSocketLayer)、VPN(VirtualPrivateNetwork)等来防护数据传输的安全。一般应用在网络层的数据传输加密/解密使用。业界一般常用的方式是SSL，但VPN的安全性较SSL的安全性高。安全原则参考国际的安全准则要求及目前相关的安全解决方案，不管是动态口令、USB-Key或数字证书(Certificate)方案，应用上的安全或是传输过程中的安全要求，皆能实现数据的真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性)。安全需求安全需求，不管是应用的安全需求或是传输的安全需求，从安全要求的四大要素真实性(私密性)、完整性(唯一性)、机密性(身份认证)和不可抵赖性(不可否认性)，来进行应用安全的处理。私密/真实性：确认数据输入的私密/真实性要紧是保证数据是由发送方所发送的原始数据。为了达到真实性的需求，必须对输入的数据进行加工，保持原始数据於传输过程中与原来是一样的。数据加工的方法之一既是对数据进行加密处理，保证送达的是原始数据。加密处理可采纳DES或PKI方式加密，对於数据量大或是加密频繁的交易，采纳DES加密方式会比用PKI加密方式效率较好。PKI加密方式较适合於数据量小或是加密频繁性低的交易。完整/唯一性：确认数据在传输的过程中不至於被篡改要紧是保证数据於传输过程中，可不能被内部/外部人员篡改，保证原来的数据值。为了达到完整性的需求，必须保障数据的完整性及可不能於传输过程中被人篡改。做法上是采纳发送者的密钥对整个数据验算出一个MAC值，连同数据一起发送给收信方；若数据於传输过程中被篡改，受信方於受到数据后，用发送方所给予的密钥(DES)/公钥(PKI)对整个数据验算出一个MAC值，进行验证时，所验算出来的MAC值与发送者发送时所产生的MAC值不相同，即可确定数据被篡改。机密性/身份确认：确认数据发送者的身份正确性要紧是确认数据发送者的身份是正确的，不是由其他人发送或有人假冒身份发送数据。机密性的确认，做法上采纳发送者所提供的密钥(DES)/公钥(PKI)对整个数据进行验算出一个MAC值，所验算出来的MAC值与发送者发送时所产生的MAC值相同，即可确认数据发送者的身份正确性。不可否認/不可抵赖性：确认数据的正确及完整性要紧是确认整个数据的完整性及正确性与由发送者发送的数据是相同的，发送者无法否定此份数据不是由发送者所发送。不可否認性的确认，做法上采纳发送者所提供的密钥(DES)/公钥(PKI)对整个数据进行验算一个MAC值，所验算出来的MAC值与发送者发送时所产生的MAC值相同，即可确认数据的正确及完整性。网络传输的安全需求网络传输的内部安全需求由於新一代核心系统才集中式作业处理，从华夏银行的支行/分行所发送的交易，全部经由网络传送到总行处理。除了上述的四点安全上的需求外，尚需要加入内部网络的传输安全布置(内部系统安全操纵治理，如VPN/SSL/加密处理)才能完整的防护数据的安全。支行/分行的网络传输应用安全需求，是华夏银行内部网络的交易，是固定/静态的交易处理；安全需求及防护上处理需要与外部不同。尤其内部的安全威胁及安全被破坏性大於外部。(内贼难防)网络传输的外部安全需求由於新一代核心系统才集中式作业处理，从不同渠道的交易也会经由网络传送到总行处理。除了上述的四点安全上的需求外，尚需要加入外部的网络传输安全布置(如动态口令)才能完整的防护数据的安全。渠道的网络交易安全需求，是华夏银行外部网络的交易，是不固定/动态的交易处理；安全需求及防护上处理需要与内部不同。外部的安全威胁及安全被破坏性小於内部，但若是内部连同外部进行安全破坏，更是难防护。(外贼难防，内贼更难防)

身份验证身份验证方式新一代核心系统的用户包含了分行或支行的行员。分行与支行的行员差不多上透过BANCSLink登入到核心系统(BANCS)或是其他的外围系统。因此，不论核心系统(BANCS)或是外围系统都需要对登入的用户进行身份的核验工作，确认登入者的身份，以利控管系统操作存取的权限。本建议书中，关于身份验证的机制，提供两个方案的选择，分不是动态口令验证与USB-Key验证方案。动态口令验证方案动态口令验证的方式是设置并发放给每一个用户一个动态口令盘。用户登入系统时，采纳以下的步骤：用户利用动态口令盘产生动态口令。用户再将动态口令输入登入页面的口令空格。应用系统服务端透过动态口令服务系统验证动态口令是否正确，均定是否同意用户登入。动态口令验证方案建议采纳市面上成熟的动态口令系统，整合现有的应用系统实现用户统一的登入身份验证方法。动态口令系统建置一般包含下列的步骤：引进并建置动态密码服务器系统。规划用户差不多信息与动态口令数据间的关系结构。规划动态口令盘的设置﹑发放﹑回收等作业程序与治理措施。依据动态口令盘的作业程序与治理措施，开发或客户化修改动态口令盘的治理应用系统。应用系统配合动态口令服务系统的登入验证程序修改。动态口令验证方案有下列的优点：使用方便。用户只需使用动态口令盘在每次登入时产生口令即可。用户终端设备无需安装任何的操纵软件与提供任何额外的接口。应用系统整合容易。应用系统只需于登入时调用动态口令系统提供的接口。动态口令验证方案有下列的缺点：一般的动态口令无法使用于交易数据的签名。由于动态口令盘大多是采纳离线作业方式，因此无法以连线侦测方式，侦测用户是否离席。USB-Key验证方案USB-Key验证方式是在USB-Key或IC卡上设置用户差不多信息以及登入密钥，并发放给用户使用。用户登入系统时，采纳以下的步骤：将USB-Key插入终端设备或是将IC卡插入IC读卡机内。用户输入USB-Key或IC卡的开启口令后，由登入页面自动读取USB-Key内的用户识不信息，并以登入密钥产生登入验证码。应用服务端利用密钥验证技术验证用户的识不信息与验证码是否相符，决定是否同意登入系统。USB-Key验证方案建议由有经验的安全系统开发商，依银行的需求规划建制一套符合需求的验证系统。USB-Key验证系统建置一般包含下列的步骤：规划USB-Key内的用户验证信息与验证密钥结构与产生方法。规划USB-Key的设置﹑发放﹑回收等作业程序与治理措施。依据USB-Key的作业程序与治理措施，开发USB-Key的治理应用系统，与验证服务系统。应用系统配合USB-Key验证服务系统的登入验证程序修改。以及登入页面配合USB-Key登入验证控件验证程序修改。USB-Key验证方案有以下的优点：采纳双因素强验证(包含USB-Key以及USB-Key的开启口令)。USB-Key与终端设备采纳连线方式，可随时验证用户是否离席。USB-Key可采纳双芯片(有线与无线)设计，于门禁系统结合。USB-Key可扩充加载数字证书，提供重要交易的数字签名功能。USB-Key验证方式有以下的缺点：市场上无统一标准的产品，需要开发建置。用户终端设备上需提供USB接口(采纳USB-Key)或是IC读卡机(采纳IC卡)。用户终端设备上需安装USB-Key的相关控件(可由登入页面自动下载安装)。应用系统整合较为复杂，登入页面需依照USB-Key登入验证程序修改。身份验证方案建议实施方式与实施时期由于新一代核心系统的整体系统架构复杂，而且有许多的外围系统。因此实施方案上，建议分为初期实施范围与后续时期实施范围。在实施方式上，建议采纳以下的实施方式：由BANCSLink提供统一的登入页面，让用户登入。BANCSLink将用户提交的身份验证数据，转发给核心服务系统(BANCS)或外围系统。核心服务系统与外围系统，各自透过统一的身份验证服务系统验证用户提交的身份验证数据是否符合，决定是否同意登入系统。在实施时期范围上，建议采纳以下的方式：在初期时期的实施范围，建议只有核心服务系统(BANCS)。其它各外围系统仍保留原有的身份验证方式。后续时期再逐一修给各个外围系统，将身份验证机制转移至统一的身份验证服务系统上。身份验证系统架构方案单一入口服务系统(Portal)架构方案为了让用户有一个统一的入口与统一的身份验证机制，能够采纳的方案之一是建置一套单一入口服务系统（PortalServer），负责提供用户的单一入口验证与用户权限治理机制。由单一入口系统提供所有系统，包含新核心系统﹑外围系统，统一的服务入口。单一入口系统所提供的功能不仅只是单一的登入入口(Single-Sign-On)，还包含整合用户与应用系统间的Session控管，以及用户对业务功能的权限治理等。单一入口系统方案的实施，必须通过下列的步骤：引进并建置一套单一入口服务系统。规划单一入口系统的身份验证方案与业务权限控管方案。规划各业务系统，包含核心系统﹑外围系统与单一入口系统间的Session操纵流程。规划单一入口系统上，各业务系统的业务与功能架构。依照规划方案客户化单一入口系统。依照规划方案修改或改造应用系统的Session控管机制与业务权限控管机制。依照规划方案修改或改造应用系统的业务与功能架构。单一入口系统方案尽管可提供全面的用户单一服务入口，然而在实施上会面临下列的问题：单一入口系统的架构所考虑的不仅是统一登入入口的实施，更应该考虑所有业务架构的统一性与整合性。单一入口系统关于各应用系统将的整合有一定的规范与标准(如JSR168)。各应用系统必须依照规范与标准进行大幅度的修改或是改造。BANCS与BANCSLink间的协定是采纳新一代核心系统自有的协定，对采纳单一入口的标准(如JSR168)，有实施上的极大困难。各分行的入口实际上是透过各分行所配置的BANCSLink服务器登入，并非直接的在单一入口系统(Portal)上登入。因此在系统架构上的配置会有困难度。在面临以上困难的状况下，关于单一服务入口系统的实现，建议采纳下列的方案：系统架构BANCS与BANCSLink间仍采纳原有架构与协定。BANCSLink透过单一入口服务系统验证用户身份，并登入。BANCSLink以单一入口服务系统回应的登入识不码，发送登入信息给BANCS，由BANCS在透过单一入口服务系统的登入识不码验证机制进行虚拟身份验证。BANCS提供的业务功能，不透过单一入口服务系统，由BANCS自行治理用户的权限。其它的外围系统，均必须依据JSR168标准，修改或改造应用系统，与单一入口服务系统整合，透过但一入口服务系统调用业务应用服务。单一入口服务系统方案有以下列的优点：可达到用户单一的服务入口。可提供用户统一的业务权限治理。单一入口服务系统方案也有下列的缺点：系统复杂度高，需要详细的规划。现有系统(包含核心系统与外围系统)的配合实施难度高。由于新一代核心系统的BANCS与BANCSLink间采纳自有的协定，关于单一入口服务协定标准的配合可行性有待商榷。

独立身份验证服务器架构方案另一种比较单纯的方案是建立一套独立的身份验证服务系统，提供新核心系统(BANCS)以及外围系统统一的身份验证机制。此种方案的实施必须有下列的步骤：开发建置一套独立的身份验证服务系统。独立身份验证服务系统搭配选定的身份验证机制(动态口令或USB-Key)，实现身份验证功能。BANCS以及外围系统的登入功能依照独立身份验证服务系统提供的身份验证接口，修改登入验证程序。此方案的系统架构图如下图：此方案有以下的优点：系统架构较为单纯，实施较为容易﹑省时。可提供统一的用户身份验证，用户不需针对不同的应用系统使用不同的登入代码﹑密码，甚至登入方式。应用系统(包含核心系统与外围系统)的修改幅度较小，容易整合。此方案也有以下的缺点：无法达到单一登入入口的服务水平，用户仍要在各个应用系统(包含核心系统与外围系统)执行登入动作。授权操纵目前华夏银行新一代核心系统项目，除了新核心系统、总帐系统及综合前置系统外，与新核心系统相关的外围系统约有55个系统。於目前的时空环境下，也无法将所有的外围系统前台柜面界面全部转换为BANCSLink前台柜面界面；部分的外围系统前台柜面环境将使用原来的前台柜面系统处理交易。同时，外围系统后台应用处理也是与新一代核心系统分开，各自处理各自的交易；核心系统及各个外围系统各自处理各个系统的交易授权。於此情况下，对於柜员的业务处理授权可能无一致性的授权方式，每个系统必须自行处理交易授权。考虑现实的状态及可行性的做法，有关授权操纵将从建立一套完整的安全治理流程开始，再依目前状态，建立一个授权系统架构，来建设整体的授权操纵治理。

授权治理架构授权操纵从系统建设时开始，订定一套完整的安全治理流程；从系统安全组织建立开始，先建立系统原始安全控管人员，再由原始安全控管人员建立系统安全操纵人员，再由系统安全操纵人员建立业务交易的授权安全治理。授权操纵讲明如下：授权组织架构方案授权组织架构授权治理建议依业务不与工作职责的划分，分不建立个不的群组授权，例如：依工作职责划分的群组权限，将每个职员分为不同的群组，每个群组的授权依其工作职责给与不同的权限；每个职员可能属於一个以上的群组。主管有核准的权限，但没有执行交易的权限经办/柜员有执行交易的权限，但没有核准的权限每个单位皆有自己职责的不同权限建立安全治理群组经办，负责建立每个职员/主管代号及授权建立安全治理群组主管，负责核准新建立的职员/主管及授权

授权治理流程系统建置安全操纵流程管系统建置时，由厂商或华夏银行安全人员建立两位系统原始安全控管人员(一位为经办，一位为主管).此两位原始安全控管人员，只限制在新增本系统所需要使用的安全控管人员安全控管人员先建立每个群组的交易权限(登录/核准)再建立每个使用者数据（信息）定义每个使用者所属分行代号及群组权限，并付予密码初始值(登录/核准)使用者使用者於前端柜面登入系统(使用者第一次登入系统时，需要更改初始密码)登入系统检查使用者状态及使用者密码无误后，即可进入xxxxxxxxxxx系统.(现在会依使用者的交易权限显示交易功能清单画面)

安全治理流程安全治理群组的经办员，依其权限能够登录使用者数据维护及群组数据维护安全治理群组的主管，依其权限能够放行登录使用者数据异动及群组数据异动各项参数维护、使用者数据查询、群组数据查询、使用者/群组数据明细表、使用者异动报表等，皆由安全治理群组人员负责维护

使用者数据治理流程使用者数据的建立及维护由安全治理人员负责。使用者数据包含使用者所属的分行/支行数据、所属权限群组、使用者名称及密码等，同时使用者的登录记录及密码错误次数等数据，皆保留/存放，作为安控稽核凭证。

授权系统架构方案SSO系统架构方案SSO授权系统架构是采纳单一授权方式，经由对使用者的一次授权，使用者可依授权於各个业务系统进行业务操作处理。SSO授权系统架构SSO系统授权流程如下：使用者登入时，经由单一登入(SSO)登入单一登入网页(PortalService)由单一登入网页(PortalService)经由登入服务器(AccessControlServer)，对使用者的代号与密码进行单一控管及验证，登入服务器(AccessControlServer)会将使用者的代号及密码，一一转换为后台每个系统的使用者对应代号及密码，建立信任机制，登入每个系统；对使用者只要登入系统一次单一登入网页(PortalService)会经由授权服务器(AuthorityControlServer)获得使用者所属的群组於每个系统中的授权使用者於一次登入后，可进入不同系统执行被授权的交易处理授权服务器(AuthorityControlServer)中有使用者於每个系统的授权数据，达到单一(SSO)授权目的；授权服务器(AuthorityControlServer)需先建立与每个系统的授权信任机制。使用SSO系统架构方案的优点：单一/统一的授权治理方式，对以后新增业务系统或新增业务交易处理，依循此标准授权方式，建设特不方便/迅速方便/简化系统授权治理简化系统的交易处理流程使用SSO系统架构方案的缺点：初期系统建置特不复杂，相关系统必需配合更改交易登入及交易授权建置成本较高独立授权服务器架构方案独立授权服务器的授权方式，是在没有建立单一签入(SSO)的架构下，建置一套独立的授权机制，处理使用者的业务交易授权。独立授权系统架构独立授权服务器授权流程如下：独立授权服务器建立使用者的群组授权权限，与每个系统建立信任机制使用者登入系统完成后，由业务交易系统向独立授权服务器发送验证信息，经独立授权服务器确认后，使用者得进行业务交易处理使用独立授权服务器架构方案的优点：建置成本较低初期系统建置复杂性小，相关应用系统更改幅度较小使用独立授权服务器架构方案的缺点：只能简化一部分系统授权治理对以后新增业务系统或新增业务交易处理，各个业务系统的改动量较大无法简化系统的交易处理流程

传输安全传输安全包含两个部分，网络安全及应用安全；网络安全卓重在数据於网络中传输时的安全防护，应用安全注重於数据的加密处理，以防止数据被篡改。网络安全应用数据於广域网络或局网中传输时，若采纳明码传输方式会有安全上的顾虑，容易引起外部或内部有意人的数据截取与篡改，造成安全上的问题。数据传输安全性的考量，从整体的网络及地理区域上分为下列几项：支行到分行传输分行到总行传输总行服务器间传输外部网络渠道传输对外机构的传输链路加密机加密处理对於上述数据传输的安全需求，第一个考虑的重点是在网络层加上网络传输加密处理，建议於每个路由器前皆需要加一套链路加密机，负责网络层的加密/解密处理。从支行的路由器开始到分行/总行的路由器，皆需增加一套链路加密机。外围系统间的网络传输、外围系统与核心系统间的网络传输等，皆需要加一套链路加密机。以下分为目前BANCS系统的处理方式及从地理区域考量讲明如下：目前所了解BANCS系统的处理方式新核心系统产品(BANCS及BANCSLink)的后台/前台的安全处理方式为：前端柜面机与BANCSLink间(BANCS传输安全示意图中红色线条部分)BANCS系统中有关前台柜面终端机与BANCSLink间，数据传输时，没有对数据进行加密处理。新核心系统厂商建议前端柜面终端机与BANCSLink间的数据传输，采纳SSL加密处理；由於SSL加密只负责通信层在网络传输时的加密，对於重要数据/报文并未加密处理，安全上仍然有漏洞，需要有完善的补强措施。BANCSLink与BANCS间(BANCS传输安全示意图中红色线条部分)BANCS系统中有关BANCSLink与BANCS间，数据传输时，没有对数据进行加密处理。新核心系统厂商建议由华夏订定安全策略及处理方式办理。BANCS传输安全示意图终端用户与BANCSLink间网络安全由於华夏银行28个分行分布宽敞，每个分行下约有10~12个支行，每个支行不配置BANCSLink柜面服务器，每个支行的柜面终端机需直接连结到分行的BANCSLink柜面服务器，经由BANCSLink柜面服务器连接到总行核心系统。目前华夏银行差不多启动网络建设项目，网络安全上，差不多将总行与分行间的网络安全采纳VPN方式处理，爱护总行与分行间的网络安全。分行与支行间尚未建置网络安全处理。分行与支行间网络传输安全示意图BANCSLink与BANCS间网络安全由於BANCS系统中有关BANCSLink与BANCS间，数据传输时，没有对数据进行加密处理，必须完善分行与总行间的网络(数据传输)安全。网络传输安全处理：於分行服务器（BANCSLinkServer）将数据传输到总行前，采纳链路加密机来对网络传输数据进行加密处理后，传送到总行。总行交易处理完成后，透过链路加密机进行网络层的加密处理，送回分行服务器分行服务器先由链路加密机将数据进行网络层的解密，再由加密机进行交易数据3DES解密处理后，传送到柜员端显现於柜面终端机页面上链路加密机的接入对应用系统来讲是透明的，即与应用系统无关，不需要更改任何应用系统程序。分行与总行间网络传输安全示意图BANCSLink与综合前置间网络安全(组合交易)综合前置系统要紧负责进出总行后台业务应用软件系统的桥梁，处理的交易数量众多及对处理的效率需求要能良好，若要考量安全上的需要，可能会对综合前置系统处理交易量及效率会有阻碍；要兼顾安全需要，同时要确保处理效率，不是件容易的事，可能无法两者兼顾。考量综合前置系统的交易处理类型及方式，除了组合型交易及中间特色业务外，其余的业务处理对综合前置系统来讲都只是过路财神左近右出或右近左出，对於此类的交易，不需要在综合前置系统进行解密后再加密送出，直接直转送出即可；即进出皆由链路加密机处理。网络传输安全处理：於分行服务器(BANCSLinkServer)将数据传输到综合前置系统前，采纳链路加密机来对网络传输数据进行加密处理后传送综合前置系统收到其他系统送到分行服务器(BANCSLinkServer)的交易，透过链路加密机进行网络层的加密处理，送回分行服务器外围系统与综合前置间网络安全网络传输安全处理：於外围系统将数据传输到综合前置系统前，采纳链路加密机来对网络传输数据进行加密处理后传送综合前置系统收到其他系统送到外围系统的交易，透过链路加密机进行网络层的加密处理，送回外围系统综合前置与BANCS间网络安全网络传输安全处理：於综合前置系统将数据传输到核心系统(BANCS)前，采纳链路加密机来对网络传输数据进行加密处理后传送核心系统(BANCS)透过链路加密机进行网络层的加密处理，送到综合前置系统

应用安全应用安全方案在网络安全方案中关于网络层均提供了链路加密机制。因此差不多上，交易信息在网络传输过程中均属据加密状态。点对点的加密方案因此，在那个地点要考虑的应用信息加密要紧是针对点对点的交易数据加密需求。这些点对点包含：用户对BANCSLink。用户对BANCS。用户对外围系统。外围系统对BANCS。点对点间的交易数据加密需求，着重在核心系统(BANCS)、综合前置系统及分行服务器(BANCSLink)间的应用加密处理，此三个系统前需要增加一套应用加密机来处理交易数据加密；对於外围系统不建议采纳应用加密处理。点对点应用加密架构图在整个新一代核心系统的交易信息需求分析上，发觉并无需要整个信息执行点对点的信息加密需求。只有针对部分敏感性的交易数据需要点对点的加密需求。敏感性数据的加密需求将在下一个章节提供具体方案。选择性的金融交易加密方案考虑交易的风险性及网络交易便利性，建议华夏银行对所有的金融交易皆进行应用加密处理；华夏银行可考虑实际上交易处理效率的需要，选取某些类不的金融交易进行应用加密处理。例如：跨银行/跨分行的取款交易、跨银行/跨分行的汇款交易、跨分行的通存交易、变更密码交易、变更客户名称/ID/地址交易等。国外的经验一般采纳所有的金融交易都需要做应用加密处理；尽管有些金融机构采纳选择性的金融交易做应用加密处理，以后产生的风险要由建议单位/人负责承担。核心系统开发商的建置客户中，台新银行选择了四种金融交易进行应用数据加密处理： 20017–先进汇款remittancebycash21016–汇出汇款(专帐交易)remittancebytransfer55032–汇出登录remittancedataentry(supplementarydataentry)55040–汇出放行remittanceapproval交易信息敏感性数据加密方案交易敏感性数据加密需求是针对部分的交易数据，必须从交易发动源头进行加密，直到交易终点处理是方可解开或是进行验证。这部分的方案要紧是针对客户支付口令的绝对私密性，不得在交易过程中有任何泄漏的风险。关于客户口令加密的方案能够分成几种情形讲明：大前置系统与核心系统(BANCS)大前置系统与核心系统间交易数据的加密，建议采纳Triple-DES加密方式，以下列的原则实施：由交易发起端对客户口令，以核心系统产生的「口令加密密钥」加密后(加密方式建议遵循ANSX9.8规范)，再放入交易信息内发送。交易同意端接收到交易信息后，将信息内以「口令加密密钥」加密的客户口令与数据库内加密的客户口令直接提交给加密机进行比对，确认是否符合。客户口令的加密比对必须在加密机内一次完成，不得语应用系统中解开。「口令加密密钥」由核心系统透过加密机产生，再利用密钥同步信息交换机制，与外围系统进行同步。用户与核心系统(BANCS)–点对点加密由于用户终端设备并无任何的加密设备。因此用户终端的加密必须考虑采纳加密密钥可公开的加密方式。此方案是利用非对称密钥的公钥可公开的技术，直接在用户终端备上一软件方式加密，再与核心系统端解开比对。此种方法采纳以下的实施原则：核心系统透过加密机产生加密用的交易加密的非对称密钥(RSAkeypair)，并取出公钥(Publickey)，称为「交易加密公钥」。核心系统将「交易加密公钥」公布给所有的BANCSLinks。用户在BANCSLinks上提交交易数据时，交易页面动态产生对称(Triple-DES)的「动态口令加密密钥」，对客户口令进行加密。(口令加密建议遵循ANSX9.8原则)。交易页面在将「动态口令加密密钥」以「交易加密公钥」加密后，连同交易数据提交BANCSLink。BANCSLinks将加密后的交易数据，以及加密后的「动态口令加密密钥」一并以交易信息送交核心系统(BANCS)。核心系统(BANCS)受到交易信息后，先利用「交易加密私钥」(Privatekey)解开「动态口令加密密钥」，再以「动态口令加密密钥」比对客户口令。核心系统(BANCS)关于「动态口令加密密钥」的解开，以及客户口令加密比对的动作，应该透过加密机一次性完成。用户与核心系统(BANCS)–BANCSLink加密另一种方案是基于用户终端与BANCSLink间采纳SSL或VPN网络加密方式，认定其交易信息泄露几率微小的前提下。只在BANCSLinks与BANCS间对口令加密。采纳以下的实施原则：核心系统透过加密机产生加密用的「口令加密密钥」(Triple-DESkeys)，并利用密钥同步信息交换机制，与BANCSLinks进行同步。用户与安全页面上提交交易数据，包含客户口令。交易数据透过安全网络(VPN或是SSL)，送到BANCSLink。BANCSLink收到用户提交的交易数据后，利用「口令加密密钥」对客户口令加密后，放入交易信息内送交核心系统(BANCS)。核心系统(BANCS)受到交易信息后，利用「口令加密密钥」解开并比对客户支付口令。核心系统(BANCS)关于以「口令加密密钥」解开并比对客户支付口令的动作，应该透过加密机一次性完成。用户终端与外围系统用户与外围系统间关于客户口令的加密沿用各外围系统目前的做法，建议不予改变。

交易数据完整性方案由于本建议方案中关于服务器间的网络，均以网络层加密机制爱护。交易信息在网络上传输时，保持加密状态。因此就整体安全需求上，比较没有交易数据完整性上的需求。服务器间验证方案各服务器间的验证目的是在防止内部人员利用假服务器发动假交易，造成交易的纠纷以及金额上的损失。服务器间的验证依据连线模式不同而必须有不同的设计方案。在那个地点，我们假设服务器间的交易连接方式是采纳非固定连接方式(Connectionless)。在此总连接方式下，服务器必须对每一笔交易信息均验证该交易发送方是否为合法的服务器。验证方式有下列两种：IP验证法IP验证法是针对没每一个交易信息验证信息发送方的IP是否为对应的合法IP。此种验证法必须采纳下列的实施步骤:每一部服务器必须设置一个固定的对外IP。应用系统中须设置每一个交易方服务器的正确IP。当应用系统收到交易信息时，透过网络层取得发送方的IP，再验证发送方的IP与设置中合法交易信息发送方的IP是否一致。此种验证法有以下的优点：不须改变交易信息的格式与交易流程。透过交易信息收发的网络层信息即可取得验证数据。此种验证法有以下的缺点：每一个服务器在网络层必须有固定的IP，关于使用VPN或是虚拟IP交换器的网络并不适用。只用IP的验证方法在安全上比较薄弱。有可能假服务器临时取代合法服务器的IP而可不能被察觉。当服务器因为网络位置变更，而更改IP时，必须更该其他应用系统上的IP设置。信息押码验证法信息押码验证法是在交易信息中，将部分的交易数据以密钥加密的方式，产生验证码，再将验证法放入交易信息中一起发送。交易接收方再以同样的方法﹑同样的密钥检核验证码是否正确。产生验证码的密钥通常使用Triple-DES的密钥以及加密算法(建议采纳CBC加密模式)。此种验证法必须采纳下列的步骤：交易信息必须增设交易验证码的字段。定义每一个交易信息内，用以产生验证码的交易数据字段。规划验证码密钥的产生规则与变更的同步交换规则。依照规划的验证码产生/验证规则，修改应用系统信息收送的机制。开发个服务系统间的密钥变更同步交换功能。此种验证法有以下的优点:此种验证方式，可使用与任何的网络环境。不锁定服务器的网络地址与实体位置，服务器的网络位置变更不阻碍任何设置。较高的安全强度，必须有存取密钥的权限才能产生验证码。此种验证法有以下的缺点：此种方法必须配合加密机使用，成本较高。次种方法必须变更交易信息格式，增加验证码字段。应用系统配合修改的幅度较大。

存储安全数据安全方案，要紧以爱护数据不被任意更改/篡改，确保数据的完整性为主。交易的数据中包含许多种信息，无法对所有的交易及将整个交易报文数据加/解密，可能会阻碍交易处理效率，建议只对报文的敏感性数据进行加/解密处理，同时要考量交易数据存储的安全。交易数据安全存储方案交易敏感性数据加密存储方案敏感性交易数据由於核心系统是整体系统交易的重心，对於交易数据的安全处理特不重要，尤其是客户的交易数据安全。交易的报文中，包含许多敏感性数据，如：客户帐号/卡号客户密码交易金额交易时刻(含:年月日时分秒)敏感性交易数据的加密处理方式对於敏感性的交易数据，必须要加密处理，以确保数据的完整性、正确性及不可否认性。敏感性交易数据的加密方式，建议采纳以3DES密钥加密处理外，同时视需要，对整个报文/关键字段以MAC生成校验值。(不建议采纳PKI加密方式，要紧是PKI加密速度较费时。)敏感性交易数据交易传输流程中，需经硬件应用及链路加密处理，尤其是客户密码需全程以乱码方式传输加密/解密处理，需经由硬件加密/解密机处理；禁止使用软件加/解密处理对於上述的敏感性交易数据，由应用软件系统透过API呼叫方式，连接外接的加密机进行加密处理，采纳以3DES密钥方式加密处理，同时生成MAC校验值，透过网络传送后台应用软件。核心系统对敏感性交易数据的处理流程为了减少核心系统的复杂性及减少核心系统的更改量，以免阻碍项目进度及时程，建议核心系统对交易数据的安全处理如下：BANCSLink於收到支行/分行的交易数据时，发送到核心系统前，先呼叫应用加密机对报文数据中的敏感性交易数据加密处理，同时要求加密机对整个报文/关键字段以MAC生成校验值。核心系统收到敏感性交易数据时，先呼叫应用加密机对报文数据中的敏感性交易数据解密处理，同时要求加密机对整个报文/关键字段的MAC校验值验证正确性后，才进行相关交易程序处理。敏感性交易数据存储除了加密处理外，对於敏感性交易数据的存储安全，也特不需要加以特不重视，以免敏感性交易数据被有心人窃取、窥视。有关敏感性交易数据的存储安全，建议处理方式如下：客户密码於柜员终端输入时，以乱码呈现；关敏感性交易数据输入后，传送前，需经硬件加密机进行应用加密处理；传输过程中，全程以乱码传送；应用软件系统后台以API呼叫方式，呼叫硬件加密机验证客户密码的正确性及将其他的敏感性交易数据解密处理客户密码存储於数据库时，是以乱码方式存放。密码安全存储方案密码包含用户登入密码﹑客户密码两种。两种密码的存储各有不同的建议方案。动态口令登入密码存储方案采纳动态口令盘的身份验证方式，用户的动态口令是依着时刻不停的演变。而密码的验证方式是由动态口令服务系统于系统内部自行验证。因此用户的密码存储是由动态口令服务系统本身具备的密码爱护的安全机制负责。因此，用户的登入密码(口令)不需要另行存储。USB-Key登入密码存储方案采纳USB-Key的身份验证方式，用户的口令是打开USB-Key存储的口令，直接存储于USB-Key中，以USB-Key本身的安全机制爱护。USB-Key内的登入验证密钥，是由加密机依据用户代码以验证主密码利用多样化演算法(Diverse)产生。而验证主密钥直接存储于加密机中。因此，用户的USB-Key口令与USB-Key内的验证密钥均不需要另行存储。客户口令加密存储方案客户口令是随着交易信息传送与服务期间。因此透过交易信息的客户口令的点对点加密机制，所有的交易信息内的客户口令均为加密状态。唯一会存储客户口令的系统应该是新核心系统(BANCS)。由于客户数量庞大，一般不可能直接存储于加密机中，而存储于数据库中。为了幸免客户口令泄漏，必须以加密方式存储于数据库中。建议采纳以下的方式：利用加密机产生或是采纳指定方式产生客户口令。客户口令产生后，直接以加密机的客户口令存储加密密钥加密后(建议采纳ANSX9.8规范)，存储与数据库内。客户口令存储加密密钥建议使用Triple-DES。客户口令比对时，直接将交易信息内加密的客户口令与数据库的加密客户口令提交给加密机，由加密机解密比对后，送回结果。当加密机内的客户口令加密密钥变更时，必须对数据库内所有用户的客户密钥进行重行加密处理(解密再加密)后再存储。此种客户口令加密存储方法有下列的优点：加密强度较强，不易泄漏。但此种客户口令加密存储方法也有下了的缺点：加密密钥更换时，必须重行加密所有的口令，处理费时繁复。假如加密密钥遗失，所有的客户口令皆失效，必须请客户从刑设置，可能造成重大损失。客户口令不可逆存储方案另一种存储客户口令的方法是采纳不可逆运算，将客户口令转换成不可还原的数字，直接存储于数据库中。此种方法采纳下了的方式：利用加密机产生或是采纳指定方式产生客户口令。客户口令产生后，直接以不可逆运算将客户口令转换成一组不可还原的口令数字存储与数据库内。客户口令不可逆运算，建议可使用SHA-256。客户口令比对时，直接将交易信息内加密的客户口令与数据库的口令数字提交给加密机，由加密机解密比对后，送回结果。此种客户口令不可逆存储方法有下列的优点：理论上无法利用口令数字还原正确的口令。不需使用密钥，维护上比较简单，依不需考虑密钥变更的问题。但此种客户口令不可逆存储方法也有下了的缺点：不可逆运算理论上造成重复的几率不等于零，有可能不同的口令会产生相同的口令数字。因此猜中的几率并非完全没有。新旧系统密码移转方案于本建议方案中，关于新旧系统间的密码已转问题，可从下列几方面讲明：用户登入口令的移转由于新系统于旧系统间使用的身份验证方式不同。不论新系统采纳动态口令盘或是USB-Key的那一种方案，用户的登入口令都必须换新。因此，建议采纳下列的步骤：预先制作所有用户登入使用的动态口令盘或是USB-Key。先行发放动态口令盘或是USB-Key给用户，并于新系统上设置每一个用户使用的动态口令盘编号或是USB-Key编号。当业务由旧系统切换为新系统时，要求所有用户开始使用动态口令或USB-Key登入系统。原有旧系统上的登入口令立即作废。客户支付口令的移转关于客户的口令，基于客户的方便性，不能因系统转换而更换客户的口令。若新系统采纳客户口令加密存储的方案，则建议采纳下列的步骤：利用加密机产生新的客户口令加密密钥。将原有旧系统的客户口令加密密钥，汇入/输入加密机内。开发一个程序，将原有旧系统的所有客户口令利用加密机重新加密(用旧密钥解密再用新密钥加密)。将新密钥加密后的客户口令存储到新系统数据库内的客户信息表内。若新系统采纳客户口令不可逆存储的方案，则建议采纳下列的步骤：将原有旧系统的客户口令加密密钥，汇入/输入加密机内。开发一个程序，将原有旧系统的所有客户口令利用加密机解密并产生口令数字(用旧密钥解密再用不可逆运算产生口令数字)。将客户口令数字存储到新系统数据库内的客户信息表内。

安全治理安全治理包含两个部分，分不是密钥治理及防病毒治理，分不於下列章节中讲明。密钥治理方案密钥治理方案阻碍整个系统的安全作业，华夏银行必须订定相关密钥治理策略，由安全设备厂商依照华夏的密钥治理策略，实施密钥的安全治理及运行。密钥生命周期治理方案密钥区分为三种，分为本地主密钥、区域主密钥及数据密钥。此三种密钥的层次、级不和治理方法(遵循ANSIX9.17标准)，其密钥层次如下图：三种密钥的层次图各种密钥在密钥层次中的作用本地主密钥(LocalMasterKey)又称主机主密钥(MasterKey)，要紧用来爱护它下一级的区域主密钥(ZoneMasterKey)(银行主密钥(BankMasterKey)、终端主密钥(TerminalMasterKey))。当区域主密钥需要导出或保存到加密机以外时，通常需要用本地主密钥(或衍生的密钥对)加密区域主密钥。区域主密钥中要紧有两种，一种是金卡中心与成员行之间的传输密钥(通常称为银行主密钥)，另一种是成员行主机与ATM或POS之间的传输密钥(通常称为终端主密钥)。它要紧用来加密下一层次的数据密钥(如：PIK、MAK)。数据加密密钥(DateEncryptKey)又称工作密钥(WorkingKey)，是最终用于加密传输数据的密钥，其上层两种密钥能够称为密钥加密/交换密钥(KeyEncrypt/ExchangeKey，简称KEK)。数据密钥一般分为两种，一种是用来加密PIN的密钥称为PIK(PinKey)，另一种是用来计算MAC的密钥称为MAK(MacKey)。密钥产生本地主密钥通常由各成员行(或下属机构)采纳加密机前面板上的键盘或直接通过IC卡注入到加密机中，各成员行的本地主密钥各不相同。一般本地主密钥的注入都由成员行的三位高层领导注入，三人分不保存一部分密钥(密钥重量,Component)，三部分密钥能够在加密机中以一定的算法(异或)合成为最终的本地主密钥(或通过衍生(Derive)生成密钥对)。区域主密钥(银行主密钥)一般由上级机构(金卡中心)产生并分发。上级机构(金卡中心)产生并保存下属机构(各成员行)的区域主密钥(银行主密钥)，同时将密码重量的明文或IC卡的形式将区域主密钥(银行主密钥)下发给下属机构(各成员行)。下属机构（成员行）将密钥重量注入到加密机内，假如区域主密钥（银行主密钥）是保存到本机构的主机数据库中，则将区域主密钥（银行主密钥）注入到加密机后，加密机显示本地主密钥加密的区域主密钥（银行主密钥）密文，由银行工作人员将其录入主机数据库。银行主密钥通常由两人注入，各自保存一部分。区域主密钥中的终端主密钥由各成员行自己注入到加密机中，同时下装到ATM和POS中，由于各成员行的ATM和POS数量都较大，一般是所有ATM和POS共用一个终端主密钥或是一组ATM和POS共用一个终端主密钥。数据密钥分为两种，一般不在加密机中保存。一种是金卡中心与成员行之间的数据密钥，一种是成员行主机与ATM或POS之间的数据密钥。前一种数据密钥能够由金卡中心主动向下分发，也能够由成员行主动向上申请。数据密钥在传输过程中由金卡中心与成员行之间共享的银行主密钥加密，成员行接收到数据密钥后都需要验证其正确性后才会启用新的数据密钥。后一种数据密钥每天由ATM或POS签到申请，由加密机随机产生，并由终端主密钥加密传送。

金卡中心与成员行及其终端(ATM、POS)之间的密钥关系如下图：金卡中心与成员行及其终端(ATM、POS)之间的密钥关系图上图中各个符号的含义如下：BMK:银行主密钥TMK:终端主密钥PIK1:金卡中心与成员行之间的PIKMAK1:金卡中心与成员行之间的MAKPIK2:成员行与终端(ATM、POS)之间的PIKMAK2:成员行与终端(ATM、POS)之间的MAKDATA:传输的数据（PIK1）BMK:被BMK加密的PIK1讲明:本地主密钥LMK：LocalMasterKey，本地主密钥，又称为文件主密钥(MDS)、加密机主密钥、主机主密钥，在密钥体系中处于最上层，以明文存储在加密机中，加密爱护存储在加密机外的其它密钥。LMK一般为双长度密钥，也有三倍长度密钥。区域主密钥ZMK：ZoneMasterKey，区域主密钥，在RACAL加密机中，指主机与主机间的传输主密钥。在密钥体系中处于中间层，能够通过LMK加密后存储在主机数据库中，也可直接存储在加密机中，一般为双长度，也有单长度和三倍长度密钥。用于主机间动态分发工作密钥时对其进行加密爱护BMK：BankMasterKey，银行主密钥，同ZMK，多用于金卡联网，在金卡联网中，有时POS和银行主机之间也使用BMK。MMK：MemberMasterKey，成员行主密钥，同ZMK。多用于金卡联网SMK：SharedMasterKey，共享主密钥，同ZMK.数据加密密钥TMK：TerminalMasterKey，终端主密钥，在RACAL加密机中，指主