mPOS受理终端安全要求手册

mPOS受理终端安全评估送检指南（附件3）银行卡检测中心第1页共19页mPOS受理终端安全要求手册1.mPOS受理终端描述mPOS受理终端生产商：mPOS受理终端标识产品名/编号：硬件版本A：用‘x’表示12345678910111213141516171819202122232425固件版本：应用程序版本：在这个表格后面附加设备规格说明（包括设备照片）用以突出设备的特性。照片应该包含设备外部和内部结构，内部照片应该足以显示设备的各个组件。mPOS受理终端标识中的可选变量A硬件版本-要求使用变量“x”（注意：同样也适用于固件版本号）“x”位置所选择位置的”x”说明1主版本号2辅版本号3辅版本号mPOS受理终端安全评估送检指南（附件3）银行卡检测中心第2页共19页2.安全要求2.1mPOS支付软件安全要求核心-所有的上位机支付应用都必须满足下列要求：2.1.1账户信息安全保护受理终端（mPOS）应对账户信息进行安全保护。账户信息保护要求参见《银联卡收单机构账户信息安全管理标准》（银联风管委【2013】9号）和《银联卡账户信息与交易数据安全管理规则》（银联风管委【2006】6号）。其中，完整磁道信息、PIN、卡片验证码、卡片有效期等敏感数据应被安全加密和解密，在受理终端和后台系统的硬件加密模块之外不得以明文形式出现，应保证数据在处理和传输过程中不被泄露、窃取和篡改。受理终端应对IC卡关键数据进行加密保护，使得上位机无法获取相关数据的原始信息。任何设备和系统均不得存储敏感账户信息（即使已经加密），账户信息只用于完成当前合法银联卡交易，不得用于任何其他用途。符合不符合不适用2.1.2交易信息安全保护除卡号、PIN、磁道信息、有效期、卡片验证码等交易信息（参见银联风管委【2013】9号和【2006】6号相关风险要求）之外，还应保证交易金额、交易类型、商户代码、交易流水号等关键交易信息在处理和传输过程中不被篡改。符合不符合不适用2.1.3交易真实性对交易报文的来源进行鉴别，保证交易真实性，防止信息伪造和重放攻击。符合不符合不适用2.1.4数据传输安全受理终端采用开放协议与上位机交互的，应保证传输数据的安全。符合不符合不适用2.1.5通讯网络安全要求上位机与后台系统间数据不应以明文形式传输，应采用强壮的加密算法和安全协议，例如：安全套接字层（SSL3.0及以上的版本）/传输层安全（TLS1.0及以上版本）或IP安全协议（IPSEC），或采用交易信息全报文加密（此全报文加密应由受理终端完成）等形式，以保护数据在开放/公共网络上的传输。应安全存储相关证书和密钥，防止泄露。符合不符合不适用2.1.6协议弱点评估厂商应进行弱点评估，以确保安全协议不包含可利用的弱点。符合不符合不适用2.1.7重放及异常检测受理终端、相关应用和系统应能抵御重放攻击，防止加密数据和交易报文被重用。符合不符不适mPOS受理终端安全评估送检指南（附件3）银行卡检测中心第3页共19页合用2.1.8位置信息模块保护要求如果防移机模块集成在受理终端上，在要求攻击分值小于14的情况下，任何渗透防移机通讯模块从而附加、替换和修改防移机通讯模块的软件或硬件，以获取或修改任何敏感数据的攻击都是不可行的。符合不符合不适用2.1.9位置信息保护要求受理终端或上位机应支持地理位置信息获取和上送能力。地理位置信息上送时，应保证其真实性和完整性，如果防移机模块集成在受理终端，则应在系统自检时对防移机模块执行自检。符合不符合不适用2.1.10安全提示终端应提供相关机制，确保交易过程中流程关键环节（如：交易金额及交易类型确认，密码输入等）和交易结果能安全、有效地向持卡人和收银员进行强制提示，确认后才可进行下一步操作。符合不符合不适用2.1.11方案评估针对mPOS设计技术安全解决方案范例，作为《中国银联mPOS通用技术安全要求》的补充，为终端、上位机支付应用软件和后台系统的设计及开发提供参考。《中国银联mPOS通用技术安全要求》侧重软硬件设备本身的安全要求，本文档方案范例侧重整体应用流程安全及其过程中各部分的安全操作。符合不符合不适用2.2支付应用安全要求核心-所有的上位机支付应用都必须满足下列要求：2.2.1应用软件的需求安全分析针对软件的需求进行信息识别和风险评估，制定安全目标以及最低BUG标准。符合不符合不适用2.2.2应用软件系统软件设计威胁建模包括系统架构概述、分解应用程序、识别风险、识别漏洞等。主要从以下几个方面实行：——针对功能分析数据流——针对数据流分析威胁——确认是否有相应的漏洞——改进安全设计，形成规范文档符合不符合不适用2.2.3应用软件的开发应用软件的开发需要保证开发过程的安全性，并将信息安全纳入整个软件开发生命周期。应用软件和客户端的开发应避免由软件漏洞引发的安全风险。支付应用程序必须能够在安全的网络环境中进行实施。支付应用软件开发厂商应为客户提供培训资料，定期对培训资料进行更新，并进行必要的培训。符合不符合不适用2.2.4应用软件的测试支付应用软件发布给客户之前应进行严格测试，以确定不存在安全规范4.1所述的及新发现的安全威胁和漏洞。符合不符合不适用2.2.3应用软件的发在支付应用程序启用或发布给客户之前，应清除无用信息。应用软件的发布版本应由配置管理人员进行生成、发布和登记。符不不mPOS受理终端安全评估送检指南（附件3）银行卡检测中心第4页共19页布应用提供者与应用发布机构之间在传输应用程序源代码及数据时需要建立安全通道保证数据传输的机密性和完整性。支付应用程序不应该使用或者请求不必要和不安全的服务、协议。采取有效措施保证应用程序的发布渠道的安全。合符合适用2.2.4应用软件的变更软件供货商在对所有软件产品进行变更时必须遵循变更控制程序，以确保变更不会影响系统的功能及安全性。2.2.7应用软件的下载、安装与更新当需要远程下载（获得）应用时，需采用有效安全防护措施。符合不符合不适用2.2.6应用软件的自检应用软件启动时应执行自检程序，检查软件运行时所必须的条件，确保软件自身和所处运行环境的安全性。符合不符合不适用2.2.7合法性认证和风险控制应用软件与后台系统应具备合法性认证机制，通过签名验签等密码技术手段与后台系统进行双向认证，确保后台系统和应用软件的合法性，建立一条安全的信息传输信道。保持应用软件认证状态，防止未授权信息更改认证状态，并设置认证超时时间。符合不符合不适用2.2.8审计功能应用软件应具备记录所有用户访问日志的功能，便于进行适当的审计和监控。在完成安装时应开始记录所有用户（特别是具有管理权限的用户）的访问，并且能将每次活动情况追踪至相应的个人。支付应用软件的日志记录功能应能自动启动，或可由用户自行启用，并应在相关指导文档中要求用户不得停用日志。应用软件可在安装时或相关指导性文档中告知用户将记录的审计信息，并在软件卸载时由用户选择清除或自动清除该信息。符合不符合不适用2.2.11用户标识具有访问权限的使用者应具备唯一的身份标识ID，保证对于支付软件的操作能够被追溯到用户。应用软件应使用唯一的识别ID来鉴别用户，通过后方可允许他们访问应用组件。符合不符合不适用2.2.12一般用户验证机制应使用唯一的用户ID并至少采用以下一种方法验证用户身份：——用户提供所知验证信息，例如密码或口令等；——用户提供所持验证设备，例如令牌设备或智能卡等；——用户提供身份描述，例如生物特征等。符合不符合不适用2.2.13双因素验证机制对于软件客户端支付和浏览器结合支付插件支付的模式，应用软件应对账户交易或账户信息访问提供双因素验证机制符合不符合不适用2.2.14重验证机制在执行密码重置前应对用户身份进行重新验证。如果一个会话空闲的时间超过一定时长，应要求用户重新进行身份验证后才可启动应用。符合不符不适mPOS受理终端安全评估送检指南（附件3）银行卡检测中心第5页共19页合用2.2.15验证信息（密码）保护应对密码在传输和存储过程中进行加密保护，并采用适当的密码管理策略。应设置合理的密码复杂度要求。应设置密码可重复使用的次数限制。若设置初始密码，应强制用户在首次登录后修改初始密码。对于禁止的用户应立即撤销其访问权限。对于超过一定期限未使用应用软件的用户账户应予以冻结，用户再次登录时应启用相关用户身份信息审核程序。应用程序不应要求或使用任何群体、共享或通用账户和密码。符合不符合不适用2.2.16失败的验证应用程序应对用户无效验证次数进行限制，采取合理措施对超限账号进行控制。符合不符合不适用2.2.17账户信息的存储如需要储存持卡人数据，则应对储存数量和保留时间进行限制。对已储存但超出规定的保留要求的持卡人数据应进行手动或自动的安全清除（至少每季度进行一次）。显示PAN时对其进行适当掩盖，采用有效方法使得任何地方存储的PAN不可读。任何情况下均不应储存敏感数据。客户端支付软件不得访问终端中非业务必需的文件和数据。符合不符合不适用2.2.18账户信息的输入如通过其他硬件（包括外接设备、智能卡等）输入设备内存储的账户信息数据，应保证这些数据为安全加密后的密文信息，在硬件与软件交互过程中不被泄露、窃取和篡改。如通过应用软件输入账户信息数据时，需采取技术措施降低信息被盗取风险，并对输入后的敏感数据进行加密。符合不符合不适用2.2.19账户信息的传输应用软件与后台间的交易报文，应采用数字证书全报文（或关键数据域）签名和验签，保证报文的真实性和不可抵赖性。交易时应验证商户端证书的有效性、匹配性。应确保敏感数据加密后才可由应用软件输出。如果支付应用软件通过电子邮件、实时通信、聊天等方式传送PAN，则应确保PAN的不可读性或者对其进行加密处理后再进行传输。用于加密的密钥必须要符合银联对密钥的管理要求。符合不符合不适用2.2.20残余信息保护应确保已被应用程序逻辑删除或释放的信息（尽管仍在系统中，并可以被恢复，但用户不可访问）不可被其他应用程序或其自身再次使用。符合不符合不适用2.2.21回退支付过程中如遇支付失败或在支付业务完成前如用户进行撤销操作，应返回到支付前的有效状态。符合不符合不适用2.2.22传输数据的完整性应具备对传输数据的鉴别机制，确保发出数据的完整性；应具备对接收数据的验证机制，确保接收数据的完整性。符合不符合不适用2.2.23传输数据的保应对传输的数据进行保密性保护，在对资源进行动态分配管理中，不应引起信息的泄露。符不不mPOS受理终端安全评估送检指南（附件3）银行卡检测中心第6页共19页密性合符合适用2.2.24原发抗抵赖应确保信息的发送者不能否认曾经发送过该信息。应确保接收信息的主体在数据交换期间能获得证明信息原发的证据，证据可由该主体或第三方主体验证，可采用选择性原发安全证明和强制性原发安全证明。符合不符合不适用2.2.25接收抗抵赖应确保信息的接收者不能否认接受过该信息。应确保发送信息的主体在数据交换期间能获得证明该信息被接收的证据，证据可由该主体或第三方主体验证，可采用选择性接收证明和强制性接收证明。符合不符合不适用2.2.26网络传输基本要求在易被攻击的网络上传输敏感数据时应进行数据加密处理。符合不符合不适用2.2.27网络安全指南和安全评估支付服务提供者、应用开发商等相关方应提供必要的网络安全指南并进行相应评估措施。符合不符合不适用2.2.28实体间通信安全要求如客户端支付软件需要与本地其他实体间（例如：其他应用软件等）进行数据传输，则交易信息应采用数字签名和加密等安全方式进行传输，确保数据不被监听和篡改。符合不符合不适用2.2.29数据加密或解密应使用对称加密算法、非对称加密算法对交易敏感信息包括支付交易中的认证信息、交互信息和敏感信息进行加密保护。符合不符合不适用2.2.30密钥加密或解密可使用对称加密算法、非对称加密算法用于不安全信道的密钥分发。几种常见的加密情况：用对称密码给对称密钥加密；用非对称密码给对称密钥加密；用对称密码给非对称密钥加密。符合不符合不适用2.2.31安全散列（消息摘要）可以使用哈希算法进行数据完整性验证、数字签名的消息摘要等