中国银联移动支付技术规范_第1卷-第2部分-移动终端支付应用软件安全规范

注 ICS 中 国 银 联 股 份 有 限 公 司 企 业 标 准 Q/CUP Q/CUP 037.1.2—2011 中国银联移动支付技术 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 第 1 卷：基础规范 第 2 部分 移动终端支付应用软件安全规 范 Mobile Payment Specifications Volume 1 Basic Specifications Part 2 Secure Specification of Payment Software in Mobile Terminal 2011-06-16 发布 2011-06-16 实施 中国银联股份有限公司 发布 Q/CUP 037.1.2—2011 I 目 次 1 范围 ................................................................................ 1 2 规范性引用文件 ...................................................................... 1 3 支付应用软件的结构和定义 ............................................................ 1 4 支付应用软件的安全要求 .............................................................. 7 Q/CUP 037.1.2—2011 II 前 言 《中国银联移动支付技术规范》共分为四卷： —— 第 1 卷：基础规范 —— 第 2 卷：智能卡支付技术规范 —— 第 3 卷：移动互联网支付技术规范 —— 第 4 卷：短信支付技术规范 本部分为第1卷的第2部分。 本部分包含了对移动终端支付应用软件安全功能方面的规定。 本部分由中国银联股份有限公司提出。 本部分起草单位： 中国银联股份有限公司、中国工商银行、中国农业银行、中国银行、中国建设 银行、交通银行、邮政储蓄银行、招商银行、中信银行、中国光大银行、中国民生银行、兴业银行、浦 东发展银行、深圳发展银行、广东发展银行、华夏银行、北京银行、上海银行、北京银联金卡科技有限 公司、中国金融电子化公司、银联数据服务有限公司、上海柯斯软件有限公司、北京同方微电子有限公 司、上海华虹集成电路有限责任公司、北京握奇数据系统有限公司、东信和平智能卡股份有限公司、金 雅拓科技上海有限公司、北京华大智宝电子系统有限公司、成都中联信通科技有限公司、福建联迪商用 设备有限公司、联通华建网络有限公司、上海翰鑫信息科技有限公司、亿达信息技术有限公司等。 本部分主要起草人：柴洪峰、徐燕军、康建明、徐晋耀、单长胜、于晓滨、鲁志军、李伟、谭颖、 李洁、吴水炯、齐宁、何朔、史大鹏、廖志江、周新衡、童益柱、李同勋、杨夏耘、申莉、曾诤、李竹、 边罡、麦博奇、杨志勇、王超、钱菲、袁捷、郑元龙、李言平、唐邦富、陈明垓、卢文青、惠锦华、罗 俊、梁万山、张晗、于卫国、李一凡、吴俊、罗雯、丁义民、王晓丹、邹重人、谢辉、张志茂、雷霆、 陈波、张江涛、徐伟、郭伟、罗海云、李峰、李茁、陈跃、罗劲、赵亮、倪国荣、刘风军、肖波、嵇文 俊、陈孜、诸中林。 Q/CUP 037.1.2—2011 1 中国银联移动支付技术规范 第 1 卷 基础规范 第 2 部分 移动终端支付应用软件安全规范 1 范围 本部分适用于需要支持支付业务（包括处理订单）的移动终端支付应用软件，包括：手机客户端、 支付控件、WAP支付网站、智能卡程序等。对于仅支持商圈浏览等关联业务，不直接集成支付功能的应 用软件，不属于本部分的规定范围。 本部分适用于支付应用软件的设计、开发、集成、维护、运营单位，及为其提供支持或服务的相关 单位（如为支付应用软件提供证书服务的安全认证机构）。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的 修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 的各方研究 是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。 ETSI TS 131 102 Universal Mobile Telecommunications System (UMTS); Characteristics of the USIM application (3GPP TS 31.102 version 6.9.0 Release 6) ETSI TS 102 223 Smart Cards; Card Application Toolkit (CAT) (Release 7) ETSI TS 101 181 Digital cellular telecommunications system (Phase 2+) Security mechanisms for SIM application toolkit ISO/IEC 7816-4 Identification cards - Integrated circuit cards - Part 4：Organization, security and commands for interchange GPCardSpec_v2.2: Global Platform 3 支付应用软件的结构和定义 3.1 概述 基于移动终端的支付应用软件包括在移动终端上运行的客户端软件，以及在智能卡上运行的智能卡 支付软件，两种软件在移动终端上可以共存。移动终端上的客户端支付软件可以独立使用，也可以结合 智能卡一起使用，当结合智能卡一起使用时，应用所需的安全认证或加密/解密等功能由智能卡来完成。 智能卡支付软件可以独立执行，交互展示界面在终端上实现。根据支付应用软件的运行环境不同区分为 两类：基于移动终端操作系统的支付软件（以下简称客户端支付软件）和基于智能卡操作系统的支付软 件（以下简称智能卡内嵌支付软件）。对于客户端支付软件，根据不同业务模式可以使用智能卡进行安 全认证，也可以不使用智能卡进行安全认证，因此根据是否使用智能卡，可再划分为基于智能卡的客户 端支付软件和无智能卡的客户端支付软件。 图1是基于智能卡的客户端支付软件示意图。当支付应用存在SE中时，客户端支付软件主要用于功 能展示，提供人机界面和输入输出接口；当支付应用存在客户端软件中时，应用所需要的安全认证或签 名的具体实现则由SE提供支撑。 Q/CUP 037.1.2—2011 2 图 1 基于智能卡客户端支付软件示意图 图2是无智能卡的客户端支付软件示意图。支付应用存在移动终端系统中，应用所需要的安全认证 或签名的具体实现则由客户端软件提供支撑。 Q/CUP 037.1.2—2011 3 图 2 无智能卡客户端支付软件示意图 图3是智能卡内嵌支付软件示意图，智能卡本身作为SE存在，所有的支付应用全部存在智能卡中， 应用所要求的安全认证或签名也由智能卡支撑。 NFC BP/AP 钱包充值、 余额查询 Host OS 远程支付 钱包应用 远程支付 应用 SE …… 应用管理 7816 SWP/S2C/I2C 移动终端界面 标识数据流向 图 3 基于智能卡内嵌支付软件示意图 本章对上述三类支付应用软件的整体结构及各部分主要功能进行规定。 Q/CUP 037.1.2—2011 4 3.2 基于智能卡客户端支付软件架构 移动终端支付应用软件运行在手机操作系统中，与智能卡进行交互、与后台系统建立通讯连接，整 体架构如图4所示: 图 4 整体架构 —— 应用软件层 应用软件层是最终用户直接使用的一层，其能够为用户提供各种形式的图形用户界面。应用层应支 持客户端/服务器模式、浏览器/服务器模式的应用软件形式，并为最终用户提供移动支付/远程支付功 能。 —— 与应用相关的网络协议层 与应用相关的网络协议层，主要根据应用层的调用，为上层提供与应用相关的网络服务。与应用相 关的网络协议层可采用目前国际标准的网络服务协议如Web、Wap等，也可根据客户端软件的需求进行定 制协议开发。 —— 与应用无关的网络协议层 与应用无关的网络协议层，主要为上层提供最基础的网络协议服务，包括各种安全通信协议SSL、 TLS、WTLS等，也可根据上层应用的需求提供定制性的专用网络协议。 —— 安全协议层 安全协议层是保障客户端提供移动支付安全的核心基础架构。其衔接应用层与设备层，将应用对安 全的需求通过安全协议层进行实现。安全协议层接口的规范，应能够与符合PKCS15规范的安全设备进行 无缝的对接，便于各安全软件及硬件的平滑接入。 —— 硬件驱动层 硬件驱动层负责对安全协议层屏蔽软硬件区别，并为其提供基础的设备访问及软硬件资源使用的功 能。硬件驱动层中使用的安全硬件或软件，对于安全协议层应是透明不可见的。硬件驱动层还应满足设 备资源稳定可靠的访问。 —— 操作系统层 操作系统层是客户端软件运行的基础平台。基于移动终端操作系统的客户端软件操作系统层，应支 持主流的智能手机平台，包括Windows Phone、iOS、Symbian、Android等，在多种操作系统上接入安全 硬件并向上层提供相关服务。 —— 物理设备层 物理设备层是安全移动支付的硬件基础服务层，为上层提供PKI安全认证及加解密服务等多种功能。 物理设备层设备的文件结构，应符合PKCS15规范，便于多种设备、多种应用的灵活接入。 Q/CUP 037.1.2—2011 5 3.3 无智能卡客户端支付软件架构 无智能卡的客户端软件支付主要包括WAP支付和客户端软件支付。 3.3.1 基于移动终端浏览器的支付软件架构 基于移动终端浏览器的支付方式是基于移动终端浏览器以网页方式实现支付功能，支付软件主体包 括移动终端浏览器和服务端网站。移动终端浏览器运行在移动终端上并实现了相应网络协议，服务端网 站是支付服务提供方开发并运营的提供支付业务的平台，整体架构如图5所示: 图 5 整体架构 —— 应用软件层 应用软件层是最终用户直接使用的一层，其能够为用户提供各种形式的图形用户界面。应用层应支 持浏览器/服务器模式的应用软件形式，并为最终用户提供移动支付/远程支付功能。 —— 与应用相关的网络协议层 与应用相关的网络协议层，主要根据应用层的调用，为上层提供与应用相关的网络服务。与应用相 关的网络协议层可采用目前国际标准的网络服务协议如WAP等，也可根据客户端软件的需求进行定制协 议开发。 —— 与应用无关的网络协议层 与应用无关的网络协议层，主要为上层提供最基础的网络协议服务，包括各种安全通信协议WTLS、 SSL等，也可根据上层应用的需求提供定制性的专用网络协议。 —— 操作系统层 操作系统层是客户端软件运行的基础平台。基于移动终端操作系统的客户端软件操作系统层，应支 持主流的智能手机平台，包括Windows Phone、iOS、Symbian、Android等，在多种操作系统上接入安全 硬件并向上层提供相关服务。 3.3.2 客户端支付软件架构 客户端支付软件运行在手机操作系统中，与移动支付接入平台系统建立通讯连接，整体架构如图6 所示: Q/CUP 037.1.2—2011 6 图 6 整体架构 —— 应用软件层 应用软件层是最终用户直接使用的一层，其能够为用户提供各种形式的图形用户界面。应用层应支 持客户端/服务器模式、浏览器/服务器模式的应用软件形式，并为最终用户提供远程支付功能。 —— 安全协议层 安全协议层是保障客户端提供移动支付安全的核心基础架构，将应用对安全的需求通过安全协议层 进行实现。 —— 与应用相关的网络协议层 与应用相关的网络协议层，主要根据应用层的调用，为上层提供与应用相关的网络服务。与应用相 关的网络协议层可采用目前国际标准的网络服务协议如Web等，也可根据客户端软件的需求进行定制协 议开发。 —— 与应用无关的网络协议层 与应用无关的网络协议层，主要为上层提供最基础的网络协议服务，包括各种安全通信协议SSL、 TLS、WTLS等，也可根据上层应用的需求提供定制性的专用网络协议。 —— 操作系统层 操作系统层是客户端软件运行的基础平台。基于移动终端操作系统的客户端软件操作系统层，应支 持主流的智能手机平台，包括Windows Phone、iOS、Symbian、Android等，在多种操作系统上接入安全 硬件并向上层提供相关服务。 3.4 基于智能卡内嵌支付软件架构 移动终端支付应用软件运行在智能卡操作系统中，通过移动终端操作系统对智能卡发送支持标准 APDU指令完成应用流程的交互。整体架构如图7所示： 图 7 整体架构 Q/CUP 037.1.2—2011 7 —— 应用界面层 应用界面层是与用户直接交互的功能层，基于客户端软件为用户以菜单的模式提供移动支付应用。 根据用户需求，应用层可以支持OTA（Over－the－Air Technology）技术实现应用软件空中下载及升级 服务。 —— 传输协议层 传输协议层负责将应用界面层的菜单命名，转化成符合安全硬件通讯规范的数据命令，并打包传输 给负责解析的卡片操作系统层。 —— 卡片操作系统层 卡片操作系统层是基于菜单模式客户端软件安全服务的核心软件架构，负责解析所有应用指令并进 行处理，提供基础的安全服务。 —— 安全硬件层 安全硬件层是基于客户端软件安全服务的硬件基础，为上层应用提供基础的认证及加解密硬件资 源。 —— 智能卡设备层 智能卡层，处于安全硬件下层，负责处理除安全应用之外的所有电信链路数据。 4 支付应用软件的安全要求 4.1 概述 不同类型的支付应用软件载体不同，使用环境不同，对软件的安全要求也有不同，在整个软件的生 命周期过程中需要确保各个环节的安全，对面临的各类威胁能采取相应的安全措施。 4.2 基于智能卡客户端支付软件的安全要求 客户端支付软件从开发、安装到运行以及失效过程中，整个生命周期涉及到各种各样的参与方，在 复杂的情况下，需要确保不同的实体、实体与实体间的利益不受影响，安全不受威胁。 4.2.1 开发并维护安全的支付软件 —— 确保所有的应用组件都安装了最新的安全补丁，相关补丁应在发布后的一个月之内被安装。 —— 在业界最佳实践的基础上开发软件应用，并将信息安全与整个软件开发生命周期相结合。 —— 对所有软件配置的修改，都必须按照变更控制过程进行。 —— 对于所有的 Web 应用开发需要基于安全编码指南，例如开放 Web 应用安全项目（OWASP）指南。 复审订制的应用代码以识别编码漏洞,软件开发流程中通常会出现的编码漏洞包括： ● 无效输入 ● 失效访问控制（例如，用户 ID 的恶意使用） ● 失效的身份认证和会话管理（对于账户凭据和会话 Cookie 的使用） ● 跨站脚本攻击（XSS 或 CSS） ● 不安全存储 ● 拒绝服务攻击（DoS） ● 不安全的配置管理 适当的补丁指那些已经通过充分的评估和测试、被确定不会与现有的安全配置相冲突的补丁。对于 内部开发的应用，采用标准的开发流程和安全编码技术可以减少大量的漏洞。 4.2.2 客户端支付软件的安装 —— 确保安装最新版本的客户端支付软件，并在安装包完整、安全的前提下进行。 —— 空中方式下载安装或更新客户端支付软件时需要采用安全报文，保证软件传输过程的机密性、 完整性。 Q/CUP 037.1.2—2011 8 4.2.3 后台系统的安全要求 客户端支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法性。 4.2.4 客户端支付软件的用户安全要求 为每一个具有访问权限的用户分配唯一的ID，以保证对于关键数据和支付软件的操作能够被追溯到 已知的、被授权的用户。 —— 使用唯一的用户名来鉴别用户，此后才允许他们访问应用组件或敏感数据； —— 除了分配唯一的 ID，至少采样下列方式的一种方法以鉴别所有合法用户： ● 口令 ● 令牌设备 ● 生物特征 —— 针对高风险业务，采用双因子身份认证机制； —— 加密所有密码，无论是在传输过程中或存储在任何应用组件中； —— 采用适当的密码管理策略： ● 在执行口令重置前认证用户身份； ● 口令最小长度不低于六个字符； ● 如果一个会话空闲的时间超过一定时长，要求用户再次输入口令以重新激活终端应用； ● 采用一种或几种有效的方法防止密码的暴力猜解，合适的方法可以包括但不限于： 设置密码验证次数的限制，指对登录失败次数设置合理上限，超限可以采取账号锁定等措 施； 提升密码复杂度，例如在设置密码过程中要求用户将密码设置为包含两类以上不同字符 等。 4.2.5 客户端支付软件的数据安全要求 4.2.5.1 数据录入 输入认证/支付密码等敏感信息时，需采取技术措施防止密码盗取，并不得在移动终端界面上显示 明文。 4.2.5.2 数据访问 根据业务需要限制对智能卡中敏感数据的访问。此项要求是为了保证敏感数据仅供授权用户或应用 组件访问。 4.2.5.3 数据存储 —— 支付软件应保留最少的用户敏感数据，限制数据存储量和保留时间，达到恰好能满足业务、 法律和 管理规定 工会经费管理规定网络安全管理规定设计变更管理规定工程设计变更管理规定设备使用管理规定 需要的程度。 —— 禁止在身份认证结束后存储敏感认证数据，如银行卡磁道信息、卡号、密码、CVN2 等（即使 经过加密）。 —— 提交账户信息时，通过采用下列之一或多种方法，使 PAN 不可读： ● 强壮的单向散列函数（散列索引） ● 截断（删除或省略字符串的头部或尾部） ● 密码本（密码本必须被安全保存） ● 强壮的加密机制，并结合相应的密钥管理流程和管理程序 —— 显示 PAN 时应参照银联卡 POS 屏蔽相关管理规定，除对前 6 位和后 4 位予以显示外，其余所 有卡号字段均予以屏蔽。 Q/CUP 037.1.2—2011 9 4.2.5.4 数据传输 在易被攻击者截获、篡改和重定向的网络上传输敏感信息时必须加密。 使用强壮的加密算法和安全协议，例如安全套接字层（SSL）/传输层安全（TLS）和IP安全协议（IPSEC） 来保护敏感数据在开放/公共的网络上的传输。开放/公共网络的例子包括Internet、WiFi、全球移动通 信系统（GSM）和通用分组无线业务（GPRS）等。 通过无线网络传输支付卡信息时，使用IPSEC VPN 或SSL/TLS进行传输加密。不要仅仅依赖WEP保护 无线网络的机密性和访问权限。 客户端支付软件和本地其他实体间的数据传输需要采用数字签名和加密等安全方式，确保数据不被 监听和篡改。 4.2.6 客户端支付软件和智能卡的交互安全 客户端支付软件和智能卡应采用技术手段进行双向认证,确保客户端支付软件和智能卡的合法性。 客户端支付软件应确保与智能卡交互的安全性，防止对读取的智能卡数据的非授权访问。 4.3 无智能卡客户端支付软件的安全要求 4.3.1 WAP 支付软件的安全要求 4.3.1.1 开发并维护安全的支付软件 移动终端浏览器一般已安装在移动终端系统，无需支付服务方重新开发提供。支付服务方需要开发 并维护服务端网站，服务端网站的开发应基于相关安全编码指南，避免通常会出现的编码漏洞，包括但 不限于：  无效输入  失效访问控制（例如，用户 ID 的恶意使用）  失效的身份认证和会话管理（对于账户凭据的使用）  跨站脚本攻击（XSS 或 CSS）  拒绝服务攻击（DoS） 4.3.1.2 后台系统的安全认证 基于移动终端浏览器的支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法 性。 4.3.1.3 用户安全要求 为每一个具有访问权限的用户分配唯一的ID，以保证对于关键数据和支付软件的操作能够被追溯到 已知的、被授权的用户。 —— 使用唯一的用户名来鉴别用户，此后才允许他们访问应用组件或敏感数据； —— 除了分配唯一的 ID，至少采用下列方式的其中一种方法以鉴别所有合法用户： ● 口令 ● 令牌设备 ● 生物特征 —— 针对高风险业务，采用双因子身份认证机制； —— 采用适当的密码管理策略： ● 在执行口令重置前认证用户身份； ● 口令最小长度不低于六位； ● 如果一个会话空闲的时间超过一定时长，要求用户再次输入口令； ● 采用一种或几种有效的方法防止密码的暴力猜解，合适的方法可以包括但不限于： Q/CUP 037.1.2—2011 10 设置密码验证次数的限制，指对登录失败次数设置合理上限，超限可以采取账号锁定等措 施； 提升密码复杂度，例如在设置密码过程中要求用户将密码设置为包含两类以上不同字符 等。 4.3.1.4 数据安全 4.3.1.5.1 数据录入 输入认证/支付密码等敏感信息时，需采取技术措施防止密码盗取，并不得在移动终端界面上显示 明文。 4.3.1.5.2 数据访问 根据业务需要限制对敏感数据的访问。此项要求是为了保证敏感数据仅供授权用户或应用组件访 问。 4.3.1.5.3 数据存储 支付软件应保留最少的用户敏感数据，限制数据存储量和保留时间，达到恰好能满足业务、法律和 管理规定需要的程度。 4.3.1.5.4 数据传输 在易被攻击者截获、篡改和重定向的网络上传输敏感信息时必须加密。 使用安全协议，例如WTLS协议来保护敏感数据在开放/公共的网络上的传输。开放/公共网络的例子 包括Internet、WiFi、全球移动通信系统（GSM）和通用分组无线业务（GPRS）等。 4.3.2 客户端支付软件的安全要求 无智能卡客户端支付软件主要包括开发包和独立应用两种形式，其中开发包形式主要指以开发包软 件的形式提供给商户或其他内容提供方并内嵌到其自有的客户端软件中，用户在这种类型的商户客户端 中可以直接进行支付；独立应用形式主要指需要用户预先在终端中安装该客户端应用，在支付时激活该 客户端应用进行支付。 4.3.2.1 开发并维护安全的支付软件 —— 在业界最佳实践的基础上开发软件应用，并将信息安全与整个软件开发生命周期相结合。 —— 对所有软件配置的修改，都必须按照变更控制过程进行。 —— 对于所有的 Web 应用开发需要基于安全编码指南。例如开放 Web 应用安全项目（OWASP）指南。 复审订制的应用代码以识别编码漏洞。软件开发流程中通常会出现的编码漏洞包括： ● 无效输入 ● 失效访问控制（例如，用户 ID 的恶意使用） ● 失效的身份认证和会话管理（对于账户凭据和会话 Cookie 的使用） ● 跨站脚本攻击（XSS 或 CSS） ● 不安全存储 ● 拒绝服务攻击（DoS） ● 不安全的配置管理 适当的补丁指那些已经通过充分的评估和测试、被确定不会与现有的安全配置相冲突的补丁。对于 内部开发的应用，采用标准的开发流程和安全编码技术可以减少大量的漏洞。 Q/CUP 037.1.2—2011 11 4.3.2.2 客户端软件的安装 无智能卡客户支付软件的安装可以由移动设备自带，也可以由用户自行下载安装。 4.3.2.3 客户端支付软件的分发 —— 确保安装最新版本的客户端支付软件，并在安装包完整、安全的前提下进行。 —— 空中方式下载安装或更新客户端支付软件时需要采用安全报文，保证软件传输过程的机密性、 完整性。 4.3.2.4 软件合法性验证和风险管理 采取有效手段统一管理客户端软件及支付插件，在交易过程中对软件进行验证，保证支付软件调用 的合法性。同时，对风险较高的交易，通过技术手段进行管理。验证和管理手段手段包括但不限于以下 手段： ——为每个客户端软件设置一个合法的唯一编号，由其所属的后台系统统一分配，并设定其有效期。 后台系统对发起交易的客户端软件进行合法性验证。 ——对监控到有风险的交易或商户，后台系统应该对插件进行有效的风险控制，对有非法交易的支 付插件应该通过设置禁止其交易。交易和商户的风险评估由业务风险规则另行规定。 4.3.2.5 后台系统的安全要求 客户端支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法性。 4.3.2.6 客户端支付软件的用户安全要求 为每一个具有访问权限的用户分配唯一的ID，以保证对于关键数据和支付软件的操作能够被追溯到 已知的、被授权的用户。 —— 使用唯一的用户名来鉴别用户，此后才允许他们访问应用组件或敏感数据； —— 除了分配唯一的 ID，至少采用下列方式的一种方法以鉴别所有合法用户（相关业务规则规定 的低风险场景除外，可不要求每笔交易都采用用户端强鉴别措施）： ● 口令 ● 令牌设备 ● 生物特征 —— 针对高风险业务，采用双因子身份认证机制，包括但不限于短信验证码等方式，如采用验证 码方式，需要对验证码有效时间进行设置，以保证验证码的安全认证效果； —— 加密所有密码，无论是在传输过程中或存储在任何应用组件中； —— 采用适当的密码管理策略： ● 在执行口令重置前认证用户身份； ● 口令最小长度不低于六个字符； ● 采用一种或几种有效的方法防止密码的暴力猜解，合适的方法可以包括但不限于： Q/CUP 037.1.2—2011 12 设置密码验证次数的限制，指对登录失败次数设置合理上限，超限可以采取账号锁定等措 施； 提升密码复杂度，例如在设置密码过程中要求用户将密码设置为包含两类以上不同字符 等。 —— 如果一个会话空闲的时间超过一定时长，要求用户再次输入口令以重新激活终端应用。 4.3.2.7 客户端支付软件的数据安全要求 4.3.2.7.1 数据录入 输入认证/支付密码等敏感信息时，需采取技术措施防止密码盗取，技术手段可包括但不限于以下 方式： ——用户所输入的客户端登陆密码、银行卡密码等敏感信息不得在移动终端界面上显示明文； ——密码等敏感信息采用软键盘方式输入； ——敏感信息输入后需要立即采用健壮的算法加密； ——利用图形校验码等方式防止暴力攻击； ——对于反复尝试并输入错误密码超过一定次数的，进行软件登录和支付交易控制，必要时可根据 业务规则予以交易阻断。 4.3.2.7.2 数据访问 根据业务需要限制对敏感数据的访问。此项要求是为了保证敏感数据仅供授权用户或应用组件访 问。 4.3.2.7.3 数据存储 —— 支付软件应保留最少的用户敏感数据，限制数据存储量和保留时间，达到恰好能满足业务、 法律和管理规定需要的程度。 —— 禁止在身份认证结束后存储支付密码等敏感数据，如银行卡磁道信息、卡号、密码、CVN2 等 （即使经过加密）。 —— 提交账户信息时，通过采用下列任一途径，使 PAN 不可读： ● 强壮的单向散列函数（散列索引） ● 截断（删除或省略字符串的头部或尾部） ● 密码本（密码本必须被安全保存） ● 强壮的加密机制，并结合相应的密钥管理流程和管理程序 —— 显示 PAN 时采用隐蔽措施（最多只显示最前 6位和最后 4位数字）。 4.3.2.7.4 数据传输 在易被攻击者截获、篡改和重定向的网络上传输敏感信息时必须加密。 使用强壮的加密算法和安全协议，例如安全套接字层（SSL）/传输层安全（TLS）和IP安全协议（IPSEC） 来保护敏感数据在开放/公共的网络上的传输。开放/公共网络的例子包括Internet、WiFi、全球移动通 信系统（GSM）和通用分组无线业务（GPRS）。 通过无线网络传输支付卡信息时，使用WiFi保护访问（WPA或WPA2）技术，IPSEC VPN 或SSL/TLS 进行传输加密。不要仅仅依赖WEP保护无线网络的机密性和访问权限。 客户端支付软件和本地其他实体间的数据传输需要采用安全的方式，确保数据不被监听和篡改。 Q/CUP 037.1.2—2011 13 4.4 基于智能卡内嵌支付软件安全要求 基于智能卡的支付软件从开发、安装到运行过程中，有各种各样的主体或实体参与到其中，因此基 于智能卡的支付软件的安全不仅局限于软件本身，还涉及到支付软件的环境安全。支付软件的安全是为 了将商业风险控制在可接受的范围内，维护各个实体的合法利益。 4.4.1 智能卡支付软件的开发 智能卡支付软件应该由支付应用提供方开发，保证其合法性、完整性、不可攻击性。需要存放在安 全环境中，保证软件不被非法泄露。 智能卡支付软件需要根据应用需求设计不同的访问级别。 4.4.2 智能卡支付软件的安装、更新 —— 安装、更新 智能卡支付软件的安装及个性化需要具有操作权的操作员在支付应用的安全域下执行，或者在具有 委托权限的安全域下安装执行。 空中方式下载安装或更新智能卡支付软件时需要采用安全报文，保证软件传输过程的机密性、完整 性。 智能卡支付软件需要安装在不被外界访问的存储空间。 —— 密钥、证书管理 智能卡支付软件中涉及到密钥管理、证书管理，其安全要求参考第一卷第3部分。 ——版本维护及升级管理 对智能卡支付软件的修改、升级，需要由支付应用提供方或者委托信任的第三方实施，并负责版本 维护以及软件升级的管理。 4.4.3 后台系统 智能卡支付软件应该采用技术手段与后台系统进行相互认证，确保后台系统的合法性。 4.4.4 用户身份 访问智能卡支付软件中敏感应用时需要通过校验口令等手段验证用户身份合法性。 对于上传到后台系统的数据需要携带标识用户身份的信息，供后台系统验证用户身份的合法性。 4.4.5 支付软件运行 4.4.5.1 运行的基本条件 智能卡支付软件需要通过合法的AID选择才可以访问。 一个支付应用不能访问另一个支付应用，除非应用本身预置为共享状态。 智能卡支付软件的操作不应该影响支付应用在POS终端上执行。 4.4.5.2 软件界面 用户从移动终端键盘或屏幕输入口令等敏感数据，需采取技术措施防止密码盗取，并不得在终端界 面上显示明文。在移动终端操作系统安全的情况下，保证用户输入数据过程中，输入的数据不能被移动 终端的其他设备监听或获取，也不能对输入的数据进行篡改。 Q/CUP 037.1.2—2011 14 4.4.5.3 数据的存储 用户输入的敏感数据需要采用安全的方式存储。 支付软件运行过程中生成的敏感数据不能传出卡外实体，产生的临时敏感数据需要存放在RAM中， 一旦支付软件运行结束，必须清除。 支付软件运行过程中生成的交易日志需要采用安全的方式存储。 4.4.5.4 传输协议层 支付软件需要支持安全的传输方式，通过加密、MAC、RC、签名等方式保护传输的数据短信，保证 传输数据的机密性和完整性。 对短信报文中的敏感数据需要采用特有密钥加密，保证在第三方平台的不可见性。 不同支付软件采用不同空中传输密钥，要求传输密钥一次一密。 支付软件和移动终端上其他实体间的数据传输需要采用安全的方式，确保数据不被监听和篡改。 4.4.5.5 智能卡操作系统层 为满足智能卡支付软件的安全要求，智能卡操作系统层的安全要求参考第3部分移动支付智能卡多 应用安全标准。