手机支付系统安全技术规范应用（业务）分册

QB-F3-13实施2009-3-13发布中国移动通信集团公司 发布QB-F-003-2009中国移动通信企业标准中国移动手机支付系统安全技术规范 应用（业务）分册Security Technology Specification of Mobile payment service Application (Service) Part版本号：1.0.0目 录前 言IV1范围12规范性引用文件13术语、定义和缩略语13.1术语13.2缩略语24应用（业务）安全模型25对称密码体系36非对称密码体系46.1实施原则46.2证书方案56.2.1证书分类与格式要求56.2.2证书申请/颁发要求66.2.3证书管理86.2.4证书应用方案97访问控制147.1实施原则147.2访问控制技术要求157.2.1用户名/口令方式157.2.2基于共享密钥的身份认证167.2.3USB key身份认证方式177.2.4短信动态口令方式177.3手机支付系统访问控制方案187.3.1手机支付系统的用户模型197.3.2手机支付系统访问控制方案208通信安全228.1实施原则实施原则228.2通信安全技术要求238.2.1TLS/SSL238.2.2HTTPS248.2.3SFTP248.2.4GSM 03.48258.2.5ISO8583+278.3通信安全方案289可用性309.1实施原则实施原则309.2可用性方案309.2.1数据备份309.2.2应用进程监控329.2.3业务流程异常处理339.2.4灾备及相关控制措施3310安全审计3410.1实施原则实施原则3410.2安全审计技术要求3410.3安全审计方案3510.3.1管理操作审计3510.3.2业务流程审计3710.3.3应用/业务异常审计3710.3.4审计日志的管理3811防攻击/防病毒3811.1实施原则实施原则3911.2防攻击/防病毒技术要求3911.2.1应用层攻击和病毒防范3911.2.2访问量控制4011.3防攻击/防病毒方案4012编制历史41附录-A 远程支付业务流程审计明细表42附录-B 现场支付业务流程审计明细表46前 言根据手机支付的业务要求，本标准针对手机支付系统的应用（业务）方面提出了相关的技术规范，是构建手机支付系统应用层安全体系的依据。本标准主要包括以下几方面内容：应用（业务）安全模型、对称密码体系、非对称密码体系、访问控制、通信安全、可用性、安全审计、防攻击/防病毒等内容。本标准是手机支付业务系列标准之一。本标准的附录A和附录B为标准性附录。本标准由中移技200967号文件印发。本标准由中国移动通信集团数据部提出，集团公司技术部归口。本标准起草单位：中国移动通信有限公司研究院本标准主要起草人：任晓明、刘斐、郭漫雪、周智、粟栗、柏洪涛、刘海龙、魏来、李征、朱本浩、张雨廷、黄更生、曹一生481 范围本技术要求对中国移动手机支付系统的应用安全，包括访问控制、数据安全存储、通信安全、可用性要求、安全管理、防攻击/防病毒等方面的技术要求。本技术要求，原则上在中国移动通信集团内部使用，用于在手机支付服务系统的建设，为集团公司和省公司提供技术依据。适用于GSM/GPRS/EDGE/3G网络环境。2 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。1QB-D-003-2005中国移动网络安全总体技术要求v2.1.2中国移动通信有限公司2QB-F-001-2009中国移动手机支付系统安全总体技术要求中国移动通信有限公司3中国移动手机支付业务总体技术要求-总册及远程支付分册中国移动通信有限公司4中国移动手机支付业务总体技术要求-现场支付版中国移动通信有限公司5中国移动日志集中管理与审计系统功能及技术规范中国移动通信有限公司6中国移动内部控制手册中国移动通信有限公司7QB-F-002-2009手机支付系统安全技术规范 基础设施分册中国移动通信有限公司8PCI_DSS V1.1PCI Security Standards Council9中国移动帐号口令管理办法中国移动通信有限公司3 术语、定义和缩略语下列术语、定义和缩略语适用于本标准：3.1 术语术语解释机密性信息未被非授权的用户或实体获取的状态完整性信息没有被非授权更改或破坏不可否认性一种确保通信参与方不能否认所参与的通信过程的机制可用性按照系统设计的要求，系统或资源在任何时候应该为授权用户所提供的可访问和可使用的特性安全审计对系统中各类事件、操作进行记录和检查以确保与安全策略相一致的过程访问控制对用户和系统与其它系统和资源通信和交互进行控制的机制身份认证确保用户与其声明的身份一致的过程数字签名针对被保护的数据对象采用密码算法计算的一段数据，用于数据对象的接收方验证数据的来源和完整性可信网络窃听、篡改、DoS攻击等风险很小的网络，如VPN、IP专网等非可信网络存在窃听、篡改、DoS攻击等风险或风险较大的网络安全域一个逻辑范围或区域，统一区域中的信息资产具有相同或相近的安全属性X.509由ITU-T(ISO/IEC)针对公钥证书和属性证书框架提出的标准。3.2 缩略语缩略语英文全称中文含义IDSIntrusion Detection System入侵检测系统IPSIntrusion Prevention System入侵防御系统VPNVirtual Private Network虚拟专用网SSLSecure Socket Layer安全套接层TLSTransport Layer Security传输层安全PKIPublic Key Infrastructure公开密钥基础设施DOSDenial of Service拒绝服务攻击DDOSDistributed Denial of Service分布式拒绝服务攻击HAHigh Availability高可用性IPSecIP SecurityIP安全CACertification Authority 证书机构MACMessage Authentication Code消息认证码ACLAccess Control List访问控制列表4 应用（业务）安全模型在手机支付系统安全总体技术要求中定义了如下图所示的安全模型，本文档将主要介绍应用安全层的技术要求与规范。安全体系系统安全层网络安全层物理安全层应用安全层基 础 设 施各种威胁/攻击访问控制通信安全可用性安全审计防攻击/病毒密码体系环境安全、媒体安全、设备安全在应用安全层中需要提供的安全功能，包括密码体系、访问控制、通信安全、可用性、安全审计、防攻击/防病毒等，说明如下：n 密码体系：系统的加解密、完整性保证措施及相关的密钥管理机制，具体包括对称密码体系和非对称密码体系（PKI）n 访问控制：对移动手机支付业务中的各种应用进行访问控制n 通信安全：通信过程中的安全，包括加密、不可否认性、完整性等n 可用性：各种保证应用的可用性的措施n 安全审计：包括应用层的安全审计功能n 防攻击/防病毒：对各类攻击和病毒的防范措施下面对以上所述安全功能分别说明。【说明】：下列各个部分“实施原则”均与手机支付系统安全总体技术要求中的“实施原则”相一致，如有冲突，以手机支付系统安全总体技术要求为准。5 对称密码体系手机支付系统中对称密码体系定义了如下类型的对称密钥，简单说明如下：密钥类型应用说明手机支付业务密钥完成手机支付各业务流程所需要的相关的各类密钥，包括消费、充值、控制和维护密钥等POS服务系统密钥POS与POS服务系统之间通信所采用的密钥，包括密钥加密密钥和工作密钥等PSAM卡密钥PSAM卡的卡片和应用管理和消费操作相关的各类密钥，包括卡片/应用控制和维护密钥以及消费密钥等OTA密钥OTA相关的各类密钥，包括业务下载密钥、RAM密钥和RFM密钥等用户卡密钥用户卡安全域相关的各类密钥，用于与OTA等平台通信过程中建立安全信道对以上各类密钥的层次结构、管理要求（包括、生成、传输、保存等），可参考如下系列规范：l 手机支付系统密钥管理技术规范手机支付业务分册l 手机支付系统密钥管理技术规范POS服务系统分册l 手机支付系统密钥管理技术规范PSAM卡分册l 手机支付系统密钥管理技术规范-OTA分册l 手机支付系统密钥管理技术规范-用户卡分册6 非对称密码体系6.1 实施原则本系统中的非对称密码体系指基于非对称加/解密算法（如：RSA算法）的密码体系及相关的应用模式，比如基于X.509证书的各类应用，本系统采用数字证书进行的操作包括数字签名、密钥协商等操作。本系统中，非对称密码体系主要应用于如下方面：l WEB服务器认证：WEB Client通过HTTPS访问WEB Server，通过Server的证书进行服务器认证，Server证书由第三方CA签发l 应用（服务器）间认证与安全通信：采用SSL协议，通过服务器证书进行双向身份认证，服务器证书由中国移动CA签发l 用户的强身份认证（USB Key）：采用证书做身份认证，证书由中国移动CA签发l 如下各类实体间的业务（企业间的数字签名等）：n 金融机构系统 手机支付系统n 商户系统 手机支付系统n 业务平台 手机支付系统n 等等在以上的应用领域中，对证书的要求如下：l 证书类型：包括服务器证书（服务器的身份认证）、企业证书和管理员证书l 证书管理：包括证书的申请、签发、更新、注销等功能，由CA完成（中国移动CA或第三方CA）。6.2 证书方案6.2.1 证书分类与格式要求手机支付系统中，所应用的数字证书包括三类，即：服务器证书、企业证书和管理员证书，下面对三种证书的格式要求给予说明（以下格式中仅列出了在本系统中对证书格式的基本信息要求，即必须提供的信息域，其它可扩展的格式内容未列出）。 服务器证书服务器证书主要用途如下：l 对服务器身份的认证l 在各服务器之间建立安全通道（SSL）过程中的密钥协商等服务器证书的格式要求如下：内容值备注版本X.509v3颁发者O= China Mobile Communications Corp.OU=CA ServicesCN=China Mobile Server CA该域根据所使用CA的不同而不同主体O=China Mobile Co., Ltd.CN= IP地址/域名1、 对于后台服务器之间通信的服务器证书，该域为服务器的IP地址2、 对于WEB服务器证书，则该域为服务器的域名证书有效期2年算法SHA1withRSAEnctyption基本限制扩展CAFalse 商户（企业）证书商户（企业）证书的主要用途如下：l 其它平台对商户身份的认证l 商户在与其它平台交互过程中进行数字签名（不可否认性）商户证书的格式要求如下：内容值备注版本X.509v3颁发者O= China Mobile Communications Corp.OU=CA ServicesCN= China Mobile Enterprise CA该域根据所使用CA的不同而不同主体O=XXX Co., Ltd.CN=商户名称证书有效期2年或者更长算法SHA1withRSAEnctyption基本限制扩展CAFalse 管理员证书管理员证书的主要用途如下：l 其它平台对管理员身份的认证l 管理员操作的不可否认性保证管理员证书的格式要求如下：内容值备注版本X.509v3颁发者O= China Mobile Communications Corp.OU=CA ServicesCN=China Mobile Personal CA该域根据所使用CA的不同而不同主体O=China Mobile Co., Ltd.CN=管理员名称证书有效期2年或者更长算法SHA1withRSAEnctyption基本限制扩展CAFalse6.2.2 证书申请/颁发要求手机支付系统中，对于不同类型的证书，申请流程要求不同，对于各类数字证书的申请与颁发需要按照如下要求进行： 服务器证书的申请手机支付系统中的核心服务器均配置了加密机，该类服务器的证书采用加密机管理，加密机提供相应的证书操作接口（签名、验签等），相关的证书申请流程如下图所示：其中，配置加密机的服务器证书申请操作如下：1、 首先由加密机生成公私钥对2、 从加密机中导出公钥，并按CA的要求生成证书请求（包含公钥）3、 发送证书请求至CA4、 CA签发证书5、 将证书导入加密机未配置加密机的服务器申请证书操作按照CA提供的标准方式进行，本规范中不做详细规定。 管理员证书的申请手机支付系统中管理员证书以USB Key承载，其申请流程如下图所示： 其中，主要操作如下：1、 由USB Key生成公私钥对2、 从USB Key中导出公钥，并按CA的要求生成证书请求（包含公钥）3、 发送证书请求至CA4、 CA签发证书5、 将证书导入USB Key 企业证书的申请企业证书包括中国移动企业证书和其它企业的证书，对于其它企业申请证书，则可以参考CA的相关申请流程进行，本规范中不做规定。对于中国移动企业证书主要用于同其它企业的服务交互过程中的签名等操作，该证书也采用加密机管理，其申请流程与服务器证书的申请流程相同。6.2.3 证书管理手机支付系统中对证书相关私钥的保存、证书的存储与访问、证书的更新以及证书作废等管理要求如下表所示：管理要求管理要求优先级私钥的保存l 服务器证书对应的私钥需要采用加密机保存l 管理员证书对应的私钥采用USB Key保存l 中国移动企业证书对应的私钥采用加密机保存强制证书的存储与访问l 服务器证书在服务器系统中保存，在交互中传递给对方l 管理员证书在USB Key中保存，在交互中传递给对方l 中国移动企业证书在服务器中保存，在在交互中传递给对方强制证书的更新l 证书更新需要按照证书申请/颁发流程申请新的证书强制证书作废l 证书作废后，需要报告到CRL服务器，CA提供CRL接口强制l 证书验证过程中，可以到CRL检查证书是否作废可选证书查询l CA需要提供证书的查询服务强制6.2.4 证书应用方案 对服务器的认证在下表中列出了手机支付系统中需要采用数字证书对服务器进行身份认证的通信双方实体以及采用证书做身份认证的相关要求。通信双方证书应用优先级PC客户端 - OTA WEB Portal对于需要采用HTTPS的情况（参考“通信安全”部分中对采用HTTPS的建议）客户端需要对服务器单向认证：1、 按照“非对称密码体系 - PKI”部分中的证书申请流程为服务器申请服务器证书，并在服务器中安装2、 在PC客户端内置颁发服务器证书CA的根证书3、 PC客户端采用服务器证书对服务器做单向身份认证（承载协议为TLS/SSL，详见“通信安全”部分的说明）强制 PC客户端 前置模块（WEB Portal）强制OTA模块 SIM卡应用管理模块服务器之间的双向认证：1、 按照“非对称密码体系 - PKI”部分中的证书申请流程为服务器申请服务器证书，并在服务器或加密机中安装2、 在每个服务器上内置对方服务器的证书对应CA的根证书3、 通信双方服务器分别采用对方服务器证书做双向身份认证（承载协议为TLS/SSL，详见“通信安全”部分的说明）强制OTA模块 - 卡管模块支付处理模块 帐户模块前置模块（WEB Portal） SIM卡应用管理模块支付处理模块-（前置模块）-商户系统支付处理模块-（前置模块）-业务平台支付处理模块-（前置模块）-金融机构系统要支持与金融机构协商确定的通信协议强制支付处理模块-（前置模块） BOSS说明：本接口涉及到支付系统与BOSS/一级BOSS/SCP之间的通信，需要支持与相关部门协商共同制定相关规范，本规范中建议采用数字证书的认证方式（基于SSL协议），说明如下：服务器之间的双向认证：1. 按照“非对称密码体系 - PKI”部分中的证书申请流程为服务器申请服务器证书，并在服务器或加密机中安装2. 在每个服务器上内置对方服务器的证书对应CA的根证书3. 通信双方服务器分别采用对方服务器证书做双向身份认证（承载协议为TLS/SSL，详见“通信安全”部分的说明）可选支付处理模块-（前置模块） 一级BOSS可选支付处理模块-（前置模块） SCP可选支付处理模块-（前置模块） 网管可选支付处理模块-（前置模块） 手机支付二线客服可选 用户的强身份认证-USB Key在下表中列出了手机支付系统中需要采用数字证书做管理员身份认证的的相关要求。用户证书应用优先级以下各平台应用管理员（超级管理员）：l 手机支付服务平台l 帐户平台l POS服务平台l SIM卡应用管理平台l OTA平台l 卡管平台1、 通过节所述的证书申请流程，申请了管理员证书，并在USB Key中安装2、 在管理员登录服务器过程中采用USB Key做身份认证，具体要求详见“访问控制”部分的说明强制 数字签名为了满足交互双方对交互信息的不可否认性要求，可以采用数字签名机制，发出信息（请求信息或响应信息）的一方对信息签名，一方面可以保证信息的完整性，同时可以为对方提供不可否认性保证。手机支付系统中需要采用企业证书做数字签名的场景主要指支付系统和合作伙伴（金融系统、商户等）之间交互过程，其中包括如下两类：l 手机支付系统与金融机构系统之间的交互l 手机支付系统与商户系统之间的交互下表列出了以上两类交互过程中需要采用企业签名的交互接口，及需要签名的信息，具体的信息格式参考各个业务平台的设备规范和接口规范：说明：本文档仅列出必须要求签名的最小信息集合，同时本文档仅对需要签名的信息做描述性说明，具体的数据类型和组织方式以设备规范和接口规范为准。业务流程接口名称证书应用需签名的信息说明优先级手机支付系统与金融机构系统之间的交互充值银行卡绑定接口l 绑定信息：银行系统（或网银）对绑定信息签名l 交易名称：充值银行卡绑定l 交易日期/时间：当前日期时间l 交易信息：银行号、银行名称、银行卡类型、银行卡号、手机号码、证件类型、证件号码强制l 响应：支付处理平台对响应签名l 交易名称：充值银行卡绑定响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制充值银行卡解绑接口（移动发起）l 绑定请求：支付处理平台对请求签名l 交易名称：绑定请求l 交易日期/时间：当前日期时间l 交易信息：银行号、银行名称、银行卡类型、银行卡号、手机号码、证件类型、证件号码强制l 绑定响应：银行系统对响应签名l 交易名称：绑定响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制资金转入（充值）接口l 扣款请求：支付处理平台对请求签名l 交易名称：扣款请求l 交易日期/时间：当前日期时间l 交易信息：银行号、银行名称、银行卡号、充值金额、充值时间、手机号码强制l 扣款响应：银行系统对扣款响应签名l 交易名称：扣款响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制l 冲正请求：支付处理平台对请求签名l 交易名称：冲正请求l 交易日期/时间：当前日期时间l 交易信息：原交易信息中的：银行号、银行名称、银行卡号、充值金额、充值时间、手机号码强制l 冲正响应：银行系统对扣款响应签名l 交易名称：冲正响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制资金转出（提现）接口（包括重发）l 提现请求：支付处理平台对请求签名l 交易名称：提现请求l 交易日期/时间：当前日期时间l 交易信息：银行号、银行名称、银行卡号、转出金额、转出时间、手机号码、用户姓名强制l 记账成功：银行系统对响应签名l 交易名称：记账成功l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制前置模块和商户系统之间的交互下订单接口l 下发订单：商户系统对订单信息签名l 交易名称：下发订单l 交易日期/时间：当前日期时间l 交易信息：商户编号、支付金额、手机号码、渠道、流水号、订单号强制l 订单响应：支付处理平台对响应签名l 交易名称：订单响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制支付结果接口l 支付成功通知：支付处理平台对通知签名l 交易名称：支付成功通知l 交易日期/时间：当前日期时间l 交易信息：商户编号、支付金额、手机号码、订单号强制l 支付成功通知响应：商户系统对响应签名l 交易名称：支付成功通知响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制订单取消接口l 订单取消请求：商户系统对取消请求签名l 交易名称：订单取消请求l 交易日期/时间：当前日期时间l 交易信息：原订单号、原交易流水号、原交易批次号、商户编号、渠道、流水号强制l 取消响应：支付处理平台对取消响应签名l 交易名称：订单取消响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制订单支付撤销接口l 订单撤销请求：商户系统对撤销请求签名l 交易名称：订单撤销请求l 交易日期/时间：当前日期时间l 交易信息：原订单号、原交易流水号、原交易批次号、商户编号、渠道、流水号强制l 撤销响应：支付处理平台对撤销响应签名l 交易名称：撤销响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制订单支付退货接口l 退货请求：商户系统对退货请求签名l 交易名称：退货请求l 交易日期/时间：当前日期时间l 交易信息：原订单号、原交易批次号、原交易流水号、原交易时间、商户编码、流水号强制l 退货响应：支付处理平台对退货响应签名l 交易名称：退货响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制预授权接口l 预授权订单：商户系统对预授权订单签名l 交易名称：预授权订单l 交易日期/时间：当前日期时间l 交易信息：手机号码、预授权金额、商户编号、渠道、流水号强制l 结果通知：支付处理平台对结果签名l 交易名称：结果通知l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制预授权完成接口l 预授权完成请求：商户系统对预授权完成请求签名l 交易名称：预授权完成请求l 交易日期/时间：当前日期时间l 交易信息：用户手机号码、商户编号、预授权号、预授权完成金额、流水号强制l 支付成功：支付处理平台对支付成功响应签名l 交易名称：支付成功l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制预授权撤销接口l 预授权撤销请求：商户系统对预授权撤销请求签名l 交易名称：预授权撤销请求l 交易日期/时间：当前日期时间l 交易信息：用户手机号码、商户编号、预授权号、流水号强制l 响应：支付处理平台对响应签名l 交易名称：响应l 交易日期/时间：当前日期时间l 交易信息：请求中的交易信息l 操作结果：成功/失败强制冲正接口l 冲正请求：商户系统对请求签名l 交易名称：冲正请求l 交易日期/时间：当前日期时间l 交易信息：被冲正交易流水号强制l 冲正响应：支付处理平台对响应签名l 交易名称：冲正响应l 交易日期/时间：当前日期时间l 交易信息：被冲正交易流水号l 操作结果：成功/失败强制对账接口l 对账请求：商户系统对请求签名l 交易名称：对账请求l 交易日期/时间：当前日期时间强制l 对账响应：支付处理平台对响应签名l 交易名称：对账响应l 交易日期/时间：当前日期时间l 操作结果：成功/失败强制7 访问控制7.1 实施原则下表列出了本系统中可供选择的访问控制方式及其级别划分和相关认证强度的说明：身份认证方式说明安全强度USB Key认证通过USB Key进行签名和身份验证等（基于非对称密码体制）。强基于短信的动态口令+静态口令静态口令+动态口令（通过手机短信发送），也属于双因素认证，但该方式中动态口令通过明文发送，其强度有所降低。强基于共享密钥的身份认证通过对称加密算法进行身份认证。较强用户名/口令采用用户名+口令的方式实现认证过程。弱/较弱手机支付系统安全总体技术要求中所提出的实施原则如下表所示：访问方式权限级别通过非可信网络访问通过可信网络访问超级管理员强认证强认证普通管理员强认证较弱认证用户较强认证禁止说明：访问控制策略中，口令设置的要求应至少满足中国移动帐号口令管理办法中的规定。下面将以此为依据制定手机支付系统访问控制方案。7.2 访问控制技术要求7.2.1 用户名/口令方式 功能说明用户名/口令认证中，服务器端需要保存的口令散列值比对进行认证。在用户初始化或每次口令更改过程中，为了避免字典攻击和密码重复使用导致的安全问题，都需要服务器为生成一个随机数salt，并对“salt+口令”的值进行散列，形成散列值。服务器端保存salt, 散列值对，如下图所示。+服务器存储文件内容随机salt值新口令Hash值随机salt值Hash值Hash用户进行认证时从文件中读出salt值，与用户输入的口令一起生成hash值，与系统中存储的hash值进行比对和验证。如下图所示。+服务器存储文件内容salt值输入口令Hash值salt值Hash值Hash比对用户名/口令认证方式的相关参数要求：参数说明HASH算法SHA1Salt长度4个字符HASH长度=16个字符 策略要求本系统中，用户通过远程进行身份认证过程中，要求口令不能以明文形式出现在网络上。另外，将用户名/口令访问控制方式的策略分为三类，要求如下（每类策略都给出了建议的用户类别，在实际的方案中可以根据具体的安全需求酌情调整）：l 高级策略（超级管理员）：口令策略说明口令强度长度：不低于8个字符构成：由大小写字母、数字及特殊符号等混合、随机组成口令有效期不高于30天尝试次数限制及处理方式失败尝试3次后，锁定用户，由管理人员（OS管理员）解除锁定口令保存salt+hash方式保存l 中级策略（普通管理员）：口令策略说明口令强度长度：不低于8个字符构成：由大小写字母、数字及特殊符号等混合、随机组成口令有效期不高于60天尝试次数限制及处理方式失败尝试6次后，锁定用户，由超级管理员解除锁定口令保存salt+hash方式保存l 低级策略（用户）：口令策略说明口令强度长度：不低于6个字符构成：由大小写字母、数字及特殊符号等混合、随机组成口令有效期不高于60天尝试次数限制及处理方式失败尝试6次后，锁定用户，由管理员（超级管理员或普通管理员）解除锁定口令保存salt+hash方式保存7.2.2 基于共享密钥的身份认证基于共享密钥的身份认证的前提是认证双方共享一对对称密钥，在交互过程中，通过加密和MAC验证方式实现对信息完整性的校验，同时实现对双方身份的验证，简单流程如下：(1) 客户端发送随机数给服务器；(2) 服务器采用对称密钥对包括客户端随机数在内的相关交互数据生成MAC验证码，传送给客户端；(3) 客户端采用对称密钥对MAC进行验证，同时实现对服务器身份的认证；(4) 服务器也采用同样的流程对客户端进行认证。在实际操作中，可以基于以上的机制对验证流程进行灵活的设计和变形，比如可以采用MAC+加密的方式（MAC和加密采用不同的密钥）进行通信等。7.2.3 USB key身份认证方式 功能说明基于证书的USB Key认证方式，需要首先在服务器存放管理员证书（见），USB Key存储对应的私钥。USB Key认证方式使用流程如下：(1) 用户登陆时，页面中的控件启动，检查USB Key 是否存在，并提示用户输入pin码，由USB Key验证pin码，如果pin码错误，则登陆失败；pin码验证成功则进入下一步认证过程。(2) 客户端向服务器发出一个验证请求，请求信息中包含USB Key ID。(3) 服务器接到此请求后生成一个随机数通过网络传输给客户端，并记录随机数。客户端将随机数使用私钥进行签名，传给服务器。(4) 服务器端首先使用USB Key的证书对应的公钥对签名数据进行认证，并核对随机数的正确性。如果通过，说明USB Key合法，登陆成功。 策略要求本系统中，USB Key访问控制方式的策略要求如下：口令策略说明PIN码强度长度：不低于6个字符PIN码有效期不高于60天7.2.4 短信动态口令方式 功能说明动态口令身份认证方式是通过手机获取动态口令的认证方式，其流程是：1） 用户注册过程中，服务器需要将用户ID和手机号捆绑2） 登录过程中，客户端向服务器发送登录请求3） 服务器随机生成动态口令（由随机数转换为动态口令），并通过SMS的方式发送到用户捆绑的手机上4） 用户在超时时间内在登录界面上输入手机上的动态口令，完成身份认证在实际应用中，该身份认证方式可以和用户名/口令方式结合使用，形成高强度的双因素认证方式。典型的动态口令和静态口令结合的认证方式如下图所示： 策略要求本系统中，动态口令访问控制方式的策略要求如下：口令策略说明动态口令强度长度：不低于6个字符超时时间不高于5分钟尝试次数限制及处理方式失败尝试6次后，暂停认证3分钟7.3 手机支付系统访问控制方案在本节的“实施原则”部分中，将手机支付系统中的各个平台的用户统一划分为三类，即超级管理员、普通管理员和用户，而在实际的系统中，各个平台的用户类型名称、权限划分等均可能不一致，为了便于后续的方案制定和开发人员做系统实现，需要统一用户模型，即将实际系统中的用户和标准用户的对应。下面介绍手机支付系统的用户模型。7.3.1 手机支付系统的用户模型手机支付系统中的用户模型如下表所示，后续的访问控制方案中，将根据用户类型提出要求，各个模块在实施访问控制方案过程中可以根据该模型中的用户对应关系发现特定用户的访问控制方案。系统平台用户类型用户细分说明帐户平台超级管理员超级操作员普通管理员普通操作员手机支付服务平台（包含前置模块、支付处理模块、支付清算模块、支付管理模块）超级管理员系统操作员系统安全管理员普通管理员业务操作员用户手机用户商户POS服务平台（包括POSP和PMS）超级管理员超级业务管理员二级业务管理员普通管理员普通业务管理员POS用户主管操作员操作员SIM卡应用管理平台超级管理员超级管理员用户应用提供商手机用户OTA平台超级管理员系统管理员菜单管理员业务管理员行业管理员普通管理员普通操作员用户手机用户卡管平台超级管理员应用管理员用户卡商省公司7.3.2 手机支付系统访问控制方案根据以上的实施原则，手机支付系统的各个系统模块的身份认证方案如下表所示，其中每种访问控制方式的具体技术要求参考“访问控制技术要求”中的说明。系统模块用户类型身份认证方式通过非可信网络访问通过可信网络访问帐户模块超级管理员N/Al 认证方式：用户名/口令+USB Keyl 策略要求：见“访问控制技术要求”中用户名/口令方式中的“高级策略”（以下简化为“高级策略”）和USB Key身份认证方式中的策略要求（以下简化为USB Key策略）普通管理员N/Al 认证方式：用户名/口令l 策略要求：见“中级策略”支付处理模块超级管理员N/Al 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略普通管理员N/Al 认证方式：用户名/口令l 策略要求：见“中级策略”用户（WWW）l 认证方式：用户名/口令+动态口令l 策略要求：见“低级策略”和动态口令策略N/A商户（WWW）l 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略手机用户（STK）l 认证方式：基于共享密钥的身份认证l 策略要求：手机用户（SMS）l 用户名/口令支付清算模块支付管理模块超级管理员N/Al 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略POSP超级管理员N/Al 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略普通管理员N/Al 认证方式：用户名/口令l 策略要求：见“中级策略”PMS超级管理员l 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略l 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略普通管理员l 认证方式：用户名/口令+动态口令l 策略要求：见“低级策略”和动态口令策略l 认证方式：用户名/口令l 策略要求：见“中级策略”POS模块用户N/Al 认证方式：用户名/口令l 策略要求：SIM卡应用管理模块超级管理员l 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略N/A应用提供商l 用户名/口令+动态口令l 策略要求：见“低级策略”和动态口令策略用户手机号认证OTA模块超级管理员l 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略N/A手机用户l 用户名/口令+动态口令l 策略要求：见“低级策略”和动态口令策略卡管模块超级管理员N/Al 认证方式：用户名/口令+USB Keyl 策略要求：见“高级策略”和USB Key策略普通管理员l 认证方式：用户名/口令l 策略要求：见“中级策略”卡商/省公司l 用户名/口令+动态口令l 策略要求：见“低级策略”和动态口令策略N/A8 通信安全通信安全指应用之间通过网络进行通信过程中需要考虑的安全措施，要求通过安全措施达到如下目标：l 通信数据加密l 通信数据完整性l 不可否认性（根据应用需求而定）8.1 实施原则实施原则通信安全的实施原则和建议如下表所示：通信接口安全防护级别说明安全要求优先级IF6高文件传输、安全远程登录对于文件传输和远程登录的需求，需要采用标准的应用层安全通信协议，其中文件传输，建议采用SFTP协议，远程登录建议采用SSH协议。强制IF16、IF19、IF20高WEB通信对于跨互联网的WEB通信，可根据需要采用HTTPS应用层安全协议，具体原则和建议如下：l 分离安全和非安全的内容：在网站目录结构设计过程中，需要明确地区分可公开访问区域和受限区域，分别存放可公开访问的网页和受限访问的网页（比如登录页面、包含信用卡号等敏感信息的网页等）。l 只对需要的网页采用HTTPS：HTTPS可以加密网页数据，并可对目标服务器做认证的情况。但是由于使用HTTPS对主机性能有一定影响，建议只对上述受限区域中的网页采用HTTPS传输。这样做，可以避免由于HTTPS的性能开销影响整个网站。l 使用HTTPS的建议：出于性能方面的考虑，对于必须使用HTTPS传输的情况，应使页面尺寸尽量小，并避免使用大尺寸的图片文件。强制IF0-IF7、IF11、IF12高后台系统间通信（局域网通信，性能要求）对于后台系统间的通信，采用SSL协议进行通信，实现双向身份认证和机密性、完整性强制IF15、IF17、IF19高SIM卡/手机终端与后台系统间的通信需要传输层标准协议（如：GSM 03.48），结合采用专用密码体系进行安全通信强制IF2228高手机支付系统与第三方系统或移动其它系统间的通信优先采用业内标准安全协议进行通信或与第三方协商定制专用安全协议强制8.2 通信安全技术要求通信安全是通过安全协议实现的，手机支付系统中因业务场景的不同以及业务需求的不同，主要应用到了如下5种安全协议，这些协议分别在传输层和应用层面为应用提供了安全通信保证：l TLS/SSLl HTTPSl SFTPl GSM 03.48l ISO8583+下面分别介绍这几种协议的技术要求。8.2.1 TLS/SSL手机支付系统中的TLS/SSL协议至少支持如下特性：l 规范：u 符合SSL V3.0和TLS V1.0规范l 身份认证：u 支持基于X.509V3证书的单向/双向身份认证，并可通过环境设置参数指定l 至少支持如下算法u 对称算法：l RC4（缺省算法）l AESl DES/3DESu 非对称算法：l RSA1024u 摘要算法：l 至少支持SHA1摘要算法SSL应用能够支持如下两种操作方式，并可以灵活配置确定具体使用方式：l 方式1：在线请求对方证书l 方式2：n 步骤1：从本地获取对方证书n 步骤2：如本地获取失败，在线请求对方证书关于TLS/SSL协议中的证书要求，见“非对称密码体系 - PKI”部分中对服务器证书的相关说明。8.2.2 HTTPS手机支付系统中需要提供安全WEB服务的情况下，可以采用HTTPS协议，该协议是HTTP+SSL的组合，具体说明如下：n URI格式：HTTPS通过HTTPS:/的方式调用，如：https:/ /n HTTP协议版本：HTTPS所基于的HTTP协议必须为HTTP1.1（或后续版本）。n SSL/TLS协议版本：符合SSL V3.0和TLS V1.0规范，见“TLS/TLS”部分的说明。n 服务器证书：采用HTTPS通信的WEB服务器，需要预先安装服务器证书，用于WEB Client对服务器的认证，及通信过程中的密钥协商。关于HTTPS协议中的证书要求，见“非对称密码体系 - PKI”部分中对服务器证书的相关说明。n HTTPS使用原则：参考手机支付系统安全总体技术要求中“