09F003-手机支付系统安全技术规范-应用(业务)分册V1.0.0.docx

中国移动通信CHINAMOBI1.E中国移动通信企业标准QB-F-OO3-2009中国移动手机支付系统平安技术规范应用(业务)分册SecurityTechnoIogySpecificationofMobiIepaymentserviceApplication(Service)Part版本号：2009-3-13实施2009-3-13发布中国移动通信集团公司发布前言IV1 范围12 规范性引用文件13 术语、定义和缩略语13 .1术语14 .2缩略语24 应用（业务）平安模型25 对称密码体系36 非对称密码体系46.1 实施原则46.2 证书方案5证书分类与格式要求5证书申请/颁发要求6证书管理8证书应用方案97 访问限制141.1 1实施原则141.2 访问限制技术要求15用户名/口令方式15基于共享密钥的身份认证16USBkey身份认证方式17短信动态口令方式171.3 手机支付系统访问限制方案18手机支付系统的用户模型19手机支付系统访问限制方案208 通信平安228.1 实施原则实施原则228.2 通信平安技术要求23T1.S/SS1.23S24SFTP24GSM03.4825ISO8583+268.3 通信平安方案279 可用性299.1实施原则实施原则299.2可用性方案30数据备份30应用进程监控31业务流程异样处理32灾备及相关限制措施3210平安审计331. .1实施原则实施原则3410. 2平安审计技术要求3411. 3平安审计方案35管理操作审计35业务流程审计36应用/业务异样审计37审计日志的管理3811 防攻击/防病毒3811.1 实施原则实施原则3811.2 防攻击/防病毒技术要求39应用层攻击和病毒防范39访问量限制3911.3 防攻击/防病毒方案4012 编制历史40附录-A远程支付业务流程审计明细表41附录-B现场支付业务流程审计明细表45依据手机支付的业务要求，本标准针对手机支付系统的应用（业务）方面提出了相关的技术规范，是构建手机支付系统应用层平安体系的依据。本标准主要包括以下几方面内容：应用（业务）平安模型、对称密码体系、非对称密码体系、访问限制、通信平安、可用性、平安审计、防攻击/防病毒等内容。本标准是手机支付业务系列标准之一。本标准的附录A和附录B为标准性附录。本标准由中移技（2009）67号文件印发。本标准由中国移动通信集团数据部提出，集团公司技术部归口。本标准起草单位：中国移动通信有限公司探讨院本标准主要起草人：任晓明、刘斐、郭漫雪、周智、粟栗、柏洪涛、刘海龙、魏来、李征、朱本浩、张雨廷、黄更生、曹一生1范围本技术要求对中国移动手机支付系统的应用平安，包括访问限制、数据平安存储、通信平安、可用性要求、平安管理、防攻击/防病毒等方面的技术要求。本技术要求，原则上在中国移动通信集团内部运用，用于在手机支付服务系统的建设，为集团公司和省公司供应技术依据。适用于GSM/GPRS/EDGE/3G网络环境。2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后全部的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，激励依据本标准达成协议的各方探讨是否可运用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。1QB-D-003-2005中国移动网络平安总体技术要求V中国移动通信有限公司QB-F-001-2009中国移动手机支付系统平安总体技术要求中国移动通信有限公司3中国移动手机支付业务总体技术要求-总册及远程支付分册中国移动通信有限公司4中国移动手机支付业务总体技术要求-现场支付版中国移动通信有限公司5中国移动日志集中管理与审计系统功能及技术规范中国移动通信有限公司6中国移动内部限制手册中国移动通信有限公司7QB-F-002-2009手机支付系统平安技术规范-基础设施分册中国移动通信有限公司8PCI_DSSVI.1PCISecurityStandardsCouncil9中国移动帐号口令管理方法中国移动通信有限公司3术语、定义和缩略语下列术语、定义和缩略语适用于本标准:3.1术语说明术语机密性信息未被非授权的用户或实体获得的状态完整性信息没有被非授权更改或破坏不行否认性一种确保通信参加方不能否认所参加的通信过程的机制可用性依据系统设计的要求，系统或资源在任何时候应当为授权用户所供应的可访问和可运用的特性平安审计对系统中各类事务、操作进行记录和检查以确保与平安策略相一样的过程访问限制对用户和系统与其它系统和资源通信和交互进行限制的机制身份认证确保用户与其声明的身份一样的过程数字签名针对被爱护的数据对象采纳密码算法计算的一段数据，用于数据对象的接收方验证数据的来源和完整性可信网络窃听、篡改、DoS攻击等风险很小的网络，如VPN、IP专网等非可信网络存在窃听、篡改、DOS攻击等风险或风险较大的网络平安域一个逻辑范围或区域，统一区域中的信息资产具有相同或相近的平安属性X.509由ITU-T(IS0/1Ee)针对公钥证书和属性证书框架提出的标准。3.2缩略语应用(业务)平安模型缩略语英文全称中文含义IDSIntrusionDetectionSystem入侵检测系统IPSIntrusionPreventionSystem入侵防卫系统VPNVirtualPrivateNetwork虚拟专用网SS1.SecureSocket1.ayer平安套接层T1.STransport1.ayerSecurity传输层平安PKlPublicKeyInfrastructure公开密钥基础设施DOSDenialofService拒绝服务攻击DDOSDistributedDenialofService分布式拒绝服务攻击IiAHighAvailability高可用性IPSecIPSecurityIP平安CACertificationAuthority证书机构MACMessageAuthenticationCode消息认证码AC1.AccessControl1.ist访问限制列表在手机支付系统平安总体技术要求中定义了如下图所示的平安模型，本文档将主要介绍应用平安层的技术要求与规范。在应用平安层中须要供应的平安功能，包括密码体系、访问限制、通信平安、可用性、平安审计、防攻击/防病毒等，说明如下： 密码体系：系统的加解密、完整性保证措施及相关的密钥管理机制，具体包括对称密码体系和非对称密码体系（PKI） 访问限制：对移动手机支付业务中的各种应用进行访问限制 通信平安：通信过程中的平安，包括加密、不行否认性、完整性等 可用性：各种保证应用的可用性的措施 平安审计：包括应用层的平安审计功能 防攻击/防病毒：对各类攻击和病毒的防范措施下面对以上所述平安功能分别说明.【说明】:下列各个部分“实施原则”均与手机支付系统平安总体技术要求中的“实施原则”相一样,如有冲突,以手机支付系统平安总体技术要求为准。5对称密码体系手机支付系统中对称密码体系定义了如下类型的对称密钥，简洁说明如下:密钥类型应用说明手机支付业务密钥完成手机支付各业务流程所须要的相关的各类密钥，包括消费、充值、限制和维护密钥等POS服务系统密钥POS与POS服务系统之间通信所采纳的密钥，包括密钥加密密钥和工作密钥等PSAM卡密钥PSAM卡的卡片和应用管理和消费操作相关的各类密钥，包括卡片/应用限制和维护密钥以及消费密钥等OTA密钥OTA相关的各类密钥，包括业务下载密钥、RAM密钥和RFM密钥等用户卡密钥用户卡平安域相关的各类密钥，用于与OTA等平台通信过程中建立平安信道对以上各类密钥的层次结构、管理要求（包括、生成、传输、保存等），可参考如下系列规范： 手机支付系统密钥管理技术规范一手机支付业务分册 手机支付系统密钥管理技术规范POS服务系统分册 手机支付系统密钥管理技术规范一PSAM卡分册 手机支付系统密钥管理技术规范-OTA分册 手机支付系统密钥管理技术规范-用户卡分册6非对称密码体系6.1 实施原则本系统中的非对称密码体系指基于非对称加/解密算法（如：RSA算法）的密码体系及相关的应用模式，比如基于X.509证书的各类应用，本系统采纳数字证书进行的操作包括数字签名、密钥协商等操作。本系统中，非对称密码体系主要应用于如下方面： WEB服务器认证：WEBClient通过S访问WEBServer,通过Server的证书进行服务器认证，SerVer证书由第三方CA签发 应用（服务器）间认证与平安通信：采纳SS1.协议，通过服务器证书进行双向身份认证，服务器证书由中国移动CA签发 用户的强身份认证（USBKey）：采纳证书做身份认证，证书由中国移动CA签发 如下各类实体间的业务（企业间的数字签名等）： 金融机构系统-手机支付系统 商户系统-手机支付系统 业务平台-手机支付系统 等等在以上的应用领域中，对证书的要求如下： 证书类型：包括服务器证书（服务器的身份认证）、企业证书和管理员证书 证书管理：包括证书的申请、签发、更新、注销等功能，由CA完成（中国移动CA或第三方CA）o6.2证书方案6.2.1 证书分类与格式要求手机支付系统中，所应用的数字证书包括三类，即：服务器证书、企业证书和管理员证书，下面对三种证书的格式要求赐予说明（以下格式中仅列出了在本系统中对证书格式的基本信息要求，即必需供应的信息域，其它可扩展的格式内容未列出）。6.2.1.1 服务器证书服务器证书主要用途如下： 对服务器身份的认证 在各服务器之间建立平安通道（SS1.）过程中的密钥协商等服务器证书的格式要求如下:内容值备注版本X.509v3颁发者O=ChinaMobileCommunicationsCorp.OU=CAServicesCN=ChinaMobileServerCA该域依据所运用CA的不同而不同主体O=ChinaMobileCo.,1.td.CN=IP地址/域名1、对于后台服务器之间通信的服务器证书，该域为服务器的IP地址2、对于WEB服务器证书，则该域为服务器的域名证书有效期2年算法SHA1WithRSAEnctyption基本限制扩展CA=False6.2.1.2 商户（企业）证书商户（企业）证书的主要用途如下： 其它平台对商户身份的认证 商户在与其它平台交互过程中进行数字签名（不行否认性）商户证书的格式要求如下:内容值备注版本X.509v3颁发者O=ChinaMobileCommunicationsCorp.OU=CAServicesCN=ChinaMobileEnterpriseCA该域依据所运用CA的不同而不同主体O=XXXCo.,1.td.CN二商户名称证书有效期2年或者更长算法SHAIWithRSAEnctyption基木限制扩展CA=False6.2.1.3 管理员证书管理员证书的主要用途如下： 其它平台对管理员身份的认证 管理员操作的不行否认性保证管理员证书的格式要求如下:内容值备注版本X.509v3颁发者O=ChinaMobileCommunicationsCorp.OU=CAServicesCN=ChinaMobilePersonalCA该域依据所运用CA的不同而不同主体O=ChinaMobileCo.,1.td.CN=管理员名称证书有效期2年或者更长算法SHA1WithRSAEnctyption基本限制扩展CA=FaIse6.2.2 证书申请/颁发要求手机支付系统中，对于不同类型的证书，申请流程要求不同，对于各类数字证书的申请与颁发须要依据如下要求进行：6.2.2.1服务器证书的申请手机支付系统中的核心服务器均配置了加密机，该类服务器的证书采纳加密机管理，加密机供应相应的证书操作接口（签名、验签等），相关的证书申请流程如下图所示：其中，配置加密机的服务器证书申请操作如下：1、首先由加密机生成公私钥对2、从加密机中导出公钥，并按CA的要求生成证书恳求（包含公钥）3、发送证书恳求至CA4、CA签发证书5、将证书导入加密机未配置加密机的服务器申请证书操作依据CA供应的标准方式进行，本规范中不做具体规定。6.2.2.2管理员证书的申请手机支付系统中管理员证书以USBKey承载，其申请流程如下图所示:CA匚二）生成公私钥对O产生私钥保护口令发送公钥和证书申请签发管理员证书二导入证书其中，主要操作如下：1、由USBKey生成公私钥对2、从USBKey中导出公钥，并按CA的要求生成证书恳求（包含公钥）3、发送证书恳求至CA4、CA签发证书5、将证书导入USBKey6.223企业证书的申请企业证书包括中国移动企业证书和其它企业的证书，对于其它企业申请证书，则可以参考CA的相关申请流程进行，本规范中不做规定。对于中国移动企业证书主要用于同其它企业的服务交互过程中的签名等操作，该证书也采纳加密机管理，其申请流程与服务器证书的申请流程相同。6.2.3证书管理手机支付系统中对证书相关私钥的保存、证书的存储与访问、证书的更新以及证书作废等管理要求如下表所示：管理要求管理要求优先级私钥的保存 服务器证书对应的私钥须要采纳加密机保存 管理员证书对应的私钥采纳USBKey保存 中国移动企业证书对应的私钥采纳加密机保存强制证书的存储与访问 服务器证书在服务器系统中保存，在交互中传递给对方 管理员证书在USBKey中保存，在交互中传递给对方 中国移动企业证书在服务器中保存，在在交互中传递给对方强制证书的更新证书更新须要依据证书申请/颁发流程申请新的证书强制证书作废证书作废后，须要报告到CR1.服务器，CA供应CR1.接口强制证书验证过程中，可以到CR1.检查证书是否作废可选证书查询CA须要供应证书的查询服务强制6.2.4证书应用方案6.2.4.1对服务器的认证在下表中列出了手机支付系统中须要采纳数字证书对服务器进行身份认证的通信双方实体以及采纳证书做身份认证的相关要求。通信双方证书应用优先级PC客户端-OTAWEBPortal对于须要采纳S的状况（参考“通信平安”部分中对采纳S的建议）客户端须要对服务器单向认证：1、依据“非对称密码体系-PK,部分中的证书申请流程为服务器申请服务器证书，并在服务器中安装2、在PC客户端内置颁发服务器证书CA的根证书3、PC客户端采纳服务器证书对服务器做单向身份认证（承载协议为T1.S/SS1.,详见“通信平安”部分的说明）强制PC客户端-前置模块（WEBPortal）强制OTA模块-SIM卡应用管理模块服务器之间的双向认证：1、依据“非对称密码体系-PKI”部分中的证书申请流程为服务器申请服务器证书，并在服务器或加密机中安装2、在每个服务器上内置对方服务器的证书对应CA的根证书3、通信双方服务器分别采纳对方服务器证书做双向身份认证（承载协议为T1.S/SS1.,详见“通信平安”部分的说明）强制OTA模块-卡管模块支付处理模块-帐户模块前置模块（WEBPortal）-SIM卡应用管理模块支付处理模块（前置模块）商户系统支付处理模块（前置模块）业务平台支付处理模块-（前置模块）-金融机构系统要支持与金融机构协商确定的通信协议强制支付处理模块（前置模块）-BOSS说明:本接口涉及到支付系统与BOSS/一级BOSS/SCP之间的通信,须要支持与相关部门协商共同制定相关规范,本规范中建议采纳数字证书的认证方式（基于SS1.协议）,说明如下,服务器之间的双向认证：1 .依据“非对称密码体系-PKI”部分中的证书申请流程为服务器申请服务器证书，并在服务器或加密机中安装2 .在每个服务器上内置对方服务器的证书对应CA的根证书3 .通信双方服务器分别采纳对方服务器证书做双向身份认证（承载协议为T1.S/SS1.,详见“通信平安”部分的说明）可选支付处理模块（前置模块）-级BoSS可选支付处理模块-（前置模块）-SCP可选支付处理模块-（前置模块）-网管可选支付处理模块-（前置模块）-手机支付二线客服可选6.2.4.2用户的强身份认证-USBKey在下表中列出了手机支付系统中须要采纳数字证书做管理员身份认证的的相关要求。用户证书应用优先级以下各平台应用管理员（超级管理员）： 手机支付服务平台 帐户平台 POS服务平台 SlM卡应用管理平台 OTA平台 卡管平台1、通过.2节所述的证书申请流程，申请了管理员证书，并在USBKey中安装2、在管理员登录服务器过程中采纳USBKey做身份认证，具体要求详见“访问限制”部分的说明强制6.2.43数字签名为了满意交互双方对交互信息的不行否认性要求,可以采纳数字签名机制,发出信息（恳求信息或响应信息）的一方对信息签名，一方面可以保证信息的完整性，同时可以为对方供应不行否认性保证。手机支付系统中须要采纳企业证书做数字签名的场景主要指支付系统和合作伙伴（金融系统、商户等）之间交互过程，其中包括如下两类： 手机支付系统与金融机构系统之间的交互 手机支付系统与商户系统之间的交互下表列出了以上两类交互过程中须要采纳企业签名的交互接口，及须要签名的信息，具体的信息格式参考各个业务平台的设备规范和接口规范:说明:本文档仅列出必须要求签名的最小信息集合,同时本文档仅对须要签名的信息做描述性说明,具体的数据类型和组织方式以设备规范和接口规范为准。业务流程接口名称证书应用需签名的信息说明优先级手机支付系统与金融机构系统之间的交互充值银行卡绑定接口绑定信息：银行系统（或网银）对绑定信息签名 交易名称：充值银行卡绑定 交易日期/时间：当前日期时间 交易信息：银行号、银行名称、银行卡类型、银行卡号、手机号码、证件类型、证件号码强制响应：支付处理平台对响应签名 交易名称：充值银行卡绑定响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制充值银行k解绑接口（移动发起）绑定恳求：支付处理平台对恳求签名 交易名称：绑定恳求 交易日期/时间：当前日期时间 交易信息：银行号、银行名称、银行卡类型、银行卡号、手机号码、证件类型、证件号码强制绑定响应：银行系统对响应签名 交易名称：绑定响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制资金转入（充值）接口扣款恳求：支付处理平台对恳求签名 交易名称：扣款恳求 交易日期/时间：当前日期时间 交易信息：银行号、银行名称、银行卡号、充值金额、充值时间、手机号码强制扣款响应：银行系统对扣款响应签名 交易名称：扣款响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制冲正恳求：支付处理平台对恳求签名 交易名称：冲正恳求 交易日期/时间：当前日期时间 交易信息：原交易信息中的：银行号、银行名称、银行卡号、充值金额、充值时间、手机号码强制冲正响应：银行系统对扣款响应签名 交易名称：冲正响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制资金转出（提现）接口（包括重发）提现恳求：支付处理平台对恳求签名 交易名称：提现恳求 交易日期/时间：当前日期时间 交易信息：银行号、银行名称、银行卡号、转出金额、转出时间、手机号码、用户姓名强制记账胜利：银行系统对响应签名 交易名称：记账胜利 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制前置模块和商户系统之间的交互下订单接口下发订单：商户系统对订单信息签名 交易名称：下发订单 交易日期/时间：当前日期时间 交易信息：商户编号、支付金额、手机号码、渠道、流水号、订单号强制订单响应：支付处理平台对响应签名 交易名称：订单响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制支付结果接口支付胜利通知：支付处理平台对通知签名 交易名称：支付胜利通知 交易日期/时间：当前日期时间 交易信息：商户编号、支付金额、手机号码、订单号强制支付胜利通知响应：商户系统对响应签名 交易名称：支付胜利通知响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制订单取消接口订单取消恳求：商户系统对取消恳求签名 交易名称：订单取消恳求 交易日期/时间：当前日期时间 交易信息：原订单号、原交易流水号、原交易批次号、商户编号、渠道、流水号强制取消响应：支付处理平台对取消响应签名 交易名称：订单取消响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制订单支付撤销接口订单撤销恳求：商户系统对撤销恳求签名 交易名称：订单撤销恳求 交易日期/时间：当前日期时间 交易信息：原订单号、原交易流水号、原交易批次号、商户编号、渠道、流水号强制撤销响应：支付处理平台对撤销响应签名 交易名称：撤销响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制订单支付退货接口退货恳求：商户系统对退货恳求签名 交易名称：退货恳求 交易日期/时间：当前日期时间 交易信息：原订单号、原交易批次号、原交易流水号、原交易时间、商户编码、流水号强制退货响应：支付处理平台对退货响应签名 交易名称：退货响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制预授权接口预授权订单：商户系统对预授权订单签名 交易名称：预授权订单 交易日期/时间：当前日期时间 交易信息：手机号码、预授权金额、商户编号、渠道、流水号强制结果通知：支付处理平台对结果签名 交易名称：结果通知 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制预授权完成接口预授权完成恳求：商户系统对预授权完成恳求签名 交易名称：预授权完成恳求 交易日期/时间：当前日期时间 交易信息：用户手机号码、商户编号、预授权号、预授权完成金额、流水号强制支付胜利：支付处理平台对支付胜利响应签名 交易名称：支付胜利 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制预授权撤销接口预授权撤销恳求：商户系统对预授权撤销恳求签名 交易名称：预授权撤销恳求 交易日期/时间：当前日期时间 交易信息：用户手机号码、商户编号、预授权号、流水号强制响应：支付处理平台对响应签名 交易名称：响应 交易日期/时间：当前日期时间 交易信息：恳求中的交易信息 操作结果：胜利/失败强制冲正接口冲正恳求：商户系统对恳求签名 交易名称：冲正恳求 交易日期/时间：当前日期时间 交易信息：被冲正交易流水号强制冲正响应：支付处理平台对响应签名 交易名称：冲正响应 交易日期/时间：当前日期时间 交易信息：被冲正交易流水号 操作结果：胜利/失败强制对账接口对账恳求：商户系统对恳求签名交易名称：对账恳求交易日期/时间：当前日期时间强制对账响应：支付处理平台对响应签名 交易名称：对账响应 交易日期/时间：当前日期时间 操作结果：胜利/失败强制7访问限制7.1实施原则下表列出了本系统中可供选择的访问限制方式及其级别划分和相关认证强度的说明:身份认证方式说明平安强度USBKey认证通过USBKey进行签名和身份验证等（基于非对称密码体制）。强基于短信的动态口令+静态口令静态口令+动态口令（通过手机短信发送），也属于双因素认证，但该方式中动态口令通过明文发送，其强度有所降低。强基于共享密钥的身份认证通过对称加密算法进行身份认证。较强用户名/口令采纳用户名+口令的方式实现认证过程。弱/较弱手机支付系统平安总体技术要求中所提出的实施原则如下表所示:'问方式权限级犷通过非可信网络访问通过可信网络访问超级管理员强认证强认证一般管理员强认证较弱认证用户较强认证禁止说明:访问限制策略中,口令设置的要求应至少满意中国移动帐号口令管理方法中的规定。下面将以此为依据制定手机支付系统访问限制方案。7.2访问限制技术要求7.2.1 用户名/口令方式7.2.1.1 功能说明用户名/口令认证中，服务器端须要保存的口令散列值比对进行认证。在用户初始化或每次口令更改过程中，为了避开字典攻击和密码重亚运用导致的平安问题，都须要服务器为生成一个随机数salt,并对“salt+口令”的值进行散列，形成散列值。服务器端保存salt,散列值对，如下图所示。用户进行认证时从文件中读出SaIt值，与用户输入的口令一起生成hash值，与系统中存储的hash值进行比对和验证。如下图所示。用户名/口令认证方式的相关参数要求:参数说明HASH算法SHAlSalt长度4个字符HASH长度>=16个字符7.2.1.2 策略要求本系统中，用户通过远程进行身份认证过程中，要求口令不能以明文形式出现在网络上。另外，将用户名/口令访问限制方式的策略分为三类，要求如下（每类策略都给出了建议的用户类别，在实际的方案中可以依据具体的平安需求酌情调整）：高级策略（超级管理员）：口令策略说明口令强度长度：不低于8个字符构成：由大小写字母、数字及特别符号等混合、随机组成口令有效期不高于30天尝试次数限制及处理方式失败尝试3次后，锁定用户，由管理人员（OS管理员）解除锁定口令保存salt+hash方式保存中级策略（一般管理员）：口令策略说明口令强度长度：不低于8个字符构成：由大小写字母、数字及特别符号等混合、随机组成口令有效期不高于60天尝试次数限制及处理方式失败尝试6次后，锁定用户，由超级管理员解除锁定口令保存salt+hash方式保存低级策略（用户）：口令策略说明口令强度长度：不低于6个字符构成：由大小写字母、数字及特别符号等混合、随机组成口令有效期不高于60天尝试次数限制及处理方式失败尝试6次后，锁定用户，由管理员（超级管理员或一般管理员）解除锁定口令保存salt+hash方式保存7.2.2 基于共享密钥的身份认证基于共享密钥的身份认证的前提是认证双方共享一对对称密钥，在交互过程中，通过加密和MAC验证方式实现对信息完整性的校验，同时实现对双方身份的验证，简洁流程如下:客户端发送随机数给服务器:(2) 服务器采纳对称密钥对包括客户端随机数在内的相关交互数据生成MAC验证码，传送给客户端；(3) 客户端采纳对称密钥对MAC进行验证，同时实现对服务器身份的认证；(4) 服务器也采纳同样的流程对客户端进行认证。在实际操作中，可以基于以上的机制对验证流程进行敏捷的设计和变形，比如可以采纳MAC+加密的方式(MAC和加密采纳不同的密钥)进行通信等。7.2.3 USBkey身份认证方式7.23.1 功能说明基于证书的USBKey认证方式，须要首先在服务器存放管理员证书(见)，USBKey存储对应的私钥。USBKey认证方式运用流程如下：(1) 用户登陆时，页面中的控件启动，检查USBKey是否存在，并提示用户输入Pin码，由USBKey验证pin码，假如pin码错误，则登陆失败；Pin码验证胜利则进入下一步认证过程。(2) 客户端向服务器发出一个验证恳求，恳求信息中包含USBKeyID。(3) 服务器接到此恳求后生成一个随机数通过网络传输给客户端，并记录随机数。客户端将随机数运用私钥进行签名，传给服务器。(4) 服务器端首先运用USBKey的证书对应的公钥对签名数据进行认证，并核对随机数的正确性。假如通过，说明USBKey合法，登陆胜利。7.232策略要求本系统中，USBKey访问限制方式的策略要求如下:口令策略说明PIN码强度长度：不低于6个字符PIN码有效期不高于60天7.2.4短信动态口令方式1.1.1 .1功能说明动态口令身份认证方式是通过手机获得动态口令的认证方式，其流程是:1)用户注册过程中，服务器须要将用户ID和手机号捆绑2）登录过程中，客户端向服务器发送登录恳求3）服务器随机生成动态口令（由随机数转换为动态口令），并通过SMS的方式发送到用户捆绑的手机上4）用户在超时时间内在登录界面上输入手机上的动态口令，完成身份认证在实际应用中，该身份认证方式可以和用户名/口令方式结合运用，形成高强度的双因素认证方式。典型的动态口令和静态口令结合的认证方式如下图所示:髀态口令骗证动态口令脸证1.1.2 .2策略要求本系统中，动态口令访问限制方式的策略要求如下:口令策略说明动态口令强度长度：不低于6个字符超时时间不高于5分钟尝试次数限制及处理方式失败尝试6次后，暂停认证3分钟1.1.3 3手机支付系统访问限制方案在本节的“实施原则”部分中，将手机支付系统中的各个平台的用户统一划分为三类,即超级管理员、一般管理员和用户，而在实际的系统中，各个平台的用户类型名称、权限划分等均可能不一样，为了便于后续的方案制定和开发人员做系统实现，须要统一用户模型，即将实际系统中的用户和标准用户的对应0下面介绍手机支付系统的用户模型。7.3.1 手机支付系统的用户模型手机支付系统中的用户模型如下表所示，后续的访问限制方案中，将依据用户类型提出要求，各个模块在实施访问限制方案过程中可以依据该模型中的用户对应关系发觉特定用户的访问限制方案。系统平台用户类型用户细分说明帐户平台超级管理员超级操作员一般管理员一般操作员手机支付服务平台（包含前置模块、支付处理模块、支付清算模块、支付管理模块）超级管理员系统操作员系统平安管理员一般管理员业务操作员用户手机用户商户POS服务平台（包括POSP和PMS）超级管理员超级业务管理员二级业务管理员一般管理员-般业务管理员POS用户主管操作员操作员SIM卡应用管理平台超级管理员超级管理员用户应用供应商手机用户OTA平台超级管理员系统管理员菜单管理员业务管理员行业管理员一般管理员一般操作员用户手机用户卡管平台超级管理员应用管理员用户卡商省公司7.3.2 手机支付系统访问限制方案依据以上的实施原则，手机支付系统的各个系统模块的身份认证方案如下表所示，其中每种访问限制方式的具体技术要求参考“访问限制技术要求”中的说明。系统模块用户类型身份认证方式通过非可信网络访问通过可信网络访问帐户模块超级管理员N/A 认证方式：用户名/口令+USBKey 策略要求：见“访问限制技术要求”中用户名/口令方式中的“高级策略”（以下简化为“高级策略”）和USBKey身份认证方式中的策略要求（以下简化为USBKey策略）一般管理员N/A 认证方式：用户名/口令 策略要求：见“中级策略”支付处理模块超级管理员N/A 认证方式：用户名/口令+USBKey 策略要求：见“高级策略”和USBKey策略一般管理员N/A 认证方式：用户名/口令 策略要求：见“中级策略”用户（WWW） 认证方式：用户名/口令+动态口令 策略要求：见“低级策略”和动态口令策略N/A商户（WWW） 认证方式：用户名/口令+USBKey 策略要求：见''高级策略”和USBKey策略手机用户（STK） 认证方式：基于共享密钥的身份认证 策略要求：手机用户（SMS）用户名/口令支付清算模块支付管理模块超级管理员N/A 认证方式：用户名/口令+USBKey 策略要求：见“高级策略”和USBKey策略POSP超级管理员N/A 认证方式：用户名/口令+USBKey 策略要求：见“高级策略”和USB