条码支付技术安全指引0903.doc

《条码支付技术安全指引0903.doc》由会员分享，可在线阅读，更多相关《条码支付技术安全指引0903.doc（17页珍藏版）》请在三一办公上搜索。

1、中国支付清算协会标准PCAC 0002: 2014 条码支付技术安全指引2014-9-XX发布 2014-9-XX日实施 中国支付清算协会技术标准工作委员会 发布目 录前 言III1范围12规范性引用文件13术语和定义14应用系统架构25交易处理流程35.1交易分类说明35.2个人对商户付款主读35.2.1概述35.2.2交易模型35.2.3交易流程35.3个人对商户付款被读45.3.1概述45.3.2交易模型45.3.3交易流程 A45.3.4交易流程 B55.4个人对个人转账主读55.4.1概述55.4.2交易模型55.4.3交易流程55.5异常流程处理66系统安全66.1物理安全要求66

2、.2网络安全要求66.3主机安全要求66.4应用安全要求76.4.1通用安全76.4.2会话安全76.4.3常见攻击防范76.4.4数据安全及备份恢复87移动终端安全87.1人机交互安全87.1.1密码管理87.1.2移动终端交易异常处理87.2软件安全87.2.1条码生成87.2.2条码解析87.2.3数据有效性校验97.2.4页面回退清除敏感信息机制97.2.5反编译97.2.6防篡改97.2.7客户端完整性97.3数据安全97.3.1数据录入97.3.2数据访问97.3.3数据存储107.3.4数据传输107.4通信安全107.4.1网络通讯协议107.4.2安全认证107.4.3抗抵赖

3、117.5条码识读器117.6安全因子输入设备118受理终端安全119交易安全119.1敏感信息保护119.2交易过程安全129.2.1交易身份鉴别129.2.2交易报文安全129.2.3风险识别与干预129.2.4交易监控129.3用户教育1310密钥体系13前 言本指引由中国支付清算协会提出。本指引由中国支付清算协会技术标准工作委员会归口。本指引主要起草单位：中国支付清算协会、中国银行股份有限公司、中国工商银行股份有限公司、中国银联股份有限公司、中信银行股份有限公司、中国电信天翼电子商务有限公司、支付宝（中国）网络技术有限公司、深圳市财付通科技有限公司、易宝支付有限公司、新大陆科技集团、银

4、行卡检测中心、深圳市快付通金融网络科技服务有限公司。本指引主要起草人：蔡洪波、马国光、邢桂伟、于沛、陈志龙、吕涛、颜世杰、夏庆凡、丁豪、高晟凯、庄晓海、刘向辉、程志云、刘剑、方海峰、周俊、赵传飞、李丹丹、赵磊、许坚、刘峰、陈亮、王建新、魏博锴、伍向前、甄世泉、孟宏文、欧阳明、颜勇、张媛。本指引为首次发布。1 范围条码支付实际上是指条码技术在支付领域中的应用，其本质是以条码为信息载体，通过移动终端或受理终端直接或间接获取支付要素，并利用已有支付渠道完成交易的一种支付方式。本指引描述了条码支付交易涉及到的业务流程和应用安全，包括移动终端、商户系统与支付机构之间的交易模型和流程，及系统安全、终端安全

5、、交易安全和密钥体系。使用对象主要是与条码支付应用相关的设计、制造、管理、受理以及应用系统的研制、开发、集成和维护等相关部门（单位）。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB 4943.1-2011 信息技术设备 安全 第1部分：通用要求GB/T 20988-2007 信息安全技术 信息系统灾难恢复规范GB/T 22081-2008 信息技术 安全技术 信息安全管理实用规则GB/T 22239-2008 信息安全技术 信息系统安全等级保护基本要求GB/T

6、12905-2000 条码术语3 术语和定义下列术语和定义适用于本文件。3.1条码 bar code条形码(bar code)是将宽度不等的多个黑条和空白，按照一定的编码规则排列，用以表达一组信息的图形标识符。包括一维条码，二维条码等。3.2二维条码 2-dimensional bar code指在一维条码的基础上扩展出另一维具有可读性的条码，使用黑白矩形图案表示二进制数据，被设备识读和解码后可获取其中所包含的信息。二维条码一般在长度、宽度两个维度上均记载着数据。3.3条码识读器 bar code reader识读条码的设备。3.4主读 Active scan barcode指用户终端主动识读

7、条码的行为。3.5被读 Passive scan barcode指用户终端上条码被受理终端识读的行为。3.6移动终端 mobile device具有移动通讯、条码展示和识读能力的终端设备，包括手机、PAD等。3.7 受理终端 point of interaction参与条码支付的受理机具，具有条码展示或识读等功能，包括专用的条码支付受理设备，以及在原有POS或ATM等设备上进行扩展后能够处理条码展示或识读的设备。3.8条码支付系统 barcode payment system提供移动终端接入、商户系统接入、受理终端接入、条码信息管理、交易信息、结算数据处理等功能的系统。3.9商户系统 merc

8、hant system指商户端提供交易订单并和支付机构进行交互的系统。3.10账户管理系统 account management system为银行账户或第三方支付账户提供资金管理、结算等业务的系统。3.11安全因子 security factor指安全认证相关的信息，如密码，动态口令等。4 应用系统架构系统架构如下图所示：该系统架构定义条码支付各参与方之间的关系。参与方包括：用户、用户终端、商户系统、条码支付系统、账户管理系统。l 用户是支付过程中购买商品或服务的个人或企业。l 移动终端包含客户端程序、条码展示设备、条码识读器等。l 商户系统包含条码生成程序或者设备、条码展示设备、条码识读器

9、、交易处理系统等。l 条码支付系统包括条码的生成、条码处理、移动终端和商户系统的交易接入和交易处理等。l 账户管理系统为银行账户或第三方支付账户提供条码信息管理、资金管理、结算等业务的系统。本部分主要描述条码支付中移动终端、商户系统以及条码支付系统等实体之间的涉及到条码的业务环节，支付相关流程不在这里详细描述。根据业务的需求，支付可以从移动终端发起也可以商户系统发起。5 交易处理流程5.1 交易分类说明根据业务处理特点的不同，基于条码的支付业务主要可以分为个人对商户付款主读、个人对商户付款被读、个人对个人转账主读等。5.2 个人对商户付款主读5.2.1 概述个人用户通过移动终端识读代表商户订单

10、条码进行付款。5.2.2 交易模型个人对商户付款主读的业务模式，订单条码由条码支付系统生成，如图所示：5.2.3 交易流程步骤1: 生成商户条码（有 A 或 B 两种方案）步骤1A: 商户系统请求条码支付系统生成条码，条码支付系统返回条码，商户系统展示条码；步骤1B：商户系统生成条码；步骤2: 用户通过移动终端识读条码；步骤3: 用户通过移动终端向条码支付系统上传条码信息；步骤4: 条码支付系统返回付款信息给移动终端进行展示；步骤5: 用户在移动终端上完成付款信息，确认付款信息，输入安全因子，支付。5.3 个人对商户付款被读5.3.1 概述个人对商户收款被读指商户通过条码识读器识读个人条码实现

11、收款。5.3.2 交易模型个人对商户付款被读的业务模式，由商户侧发起支付，用户可通过移动终端或者商户系统进行交易确认，如图所示： A: 用户在移动终端进行交易确认B: 用户在商户系统进行交易确认5.3.3 交易流程 A步骤1: 生成用户条码（有 A 或 B 两种方案）方案1a: 移动终端向条码支付系统请求生成用户条码；方案1b: 移动终端本地生成用户条码；步骤2: 商户系统通过条码识读终端识读条码；步骤3: 商户系统上传条码信息到条码支付系统，发起支付；步骤4: 条码支付系统返回付款信息给移动终端进行展示；步骤 5 由支付机构根据风险控制的水平和要求进行选择步骤5: 用户在移动终端上完成付款信

12、息，确认付款信息，输入安全因子，请求支付。5.3.4 交易流程 B步骤1: 生成用户条码（有 A 或 B 两种方案）步骤1a: 移动终端向条码支付系统请求生成用户条码；步骤1b: 移动终端本地生成用户条码；步骤2: 商户系统通过条码识读终端识读用户条码，发起支付；步骤 3 由支付机构根据风险控制的水平和要求进行选择步骤3: 用户在商户系统上确认付款信息，输入安全因子；步骤4: 商户系统请求支付。5.4 个人对个人转账主读5.4.1 概述个人对个人转账主读指付款人通过移动终端识读收款人的账户条码实现转账。5.4.2 交易模型个人对个人转账主读的业务模式，由收款人发起支付。如图所示：5.4.3 交

13、易流程步骤1: 生成用户条码（有 A 或 B 两种方案）步骤1a: 收款人移动终端向条码支付系统请求生成用户条码；步骤1b: 收款人移动终端本地生成用户条码；步骤2: 付款人通过移动终端识读收款人的条码；步骤3: 付款人移动终端上传条码信息至条码支付系统；步骤4: 条码支付系统返回转账信息给付款人的移动终端；步骤5: 付款人在移动终端上完成转账信息，确认转账信息，输入安全因子，转账。5.5 异常流程处理l 商户系统与条码支付系统建立连接失败或无法发送请求报文，则提示商户系统失败或提示商户系统重试；l 移动终端与条码支付系统建立连接失败或无法发送请求报文，则通知移动终端提示用户失败或提示用户重试

14、；l 商户系统请求条码支付系统生成条码失败，则提示商户系统失败或提示商户系统重试；l 移动终端请求条码支付系统生成条码失败，则提示用户重试或者放弃；l 移动终端若不能识读条码，则提示错误或者提示重试或者流程结束；l 商户系统通过条码识读终端若不能识读条码，则提示错误或者提示重试或者流程结束；l 商户系统上传条码信息到条码支付系统失败，则提示商户系统失败或提示商户系统重试；l 移动终端上传条码到条码支付系统失败，则提示错误或者提示重试；l 条码支付系统收到移动终端不合法的请求报文，则丢弃该报文或通知移动终端；条码支付系统处理移动终端交易请求出错，则通知移动终端提示用户交易失败，通知商户系统提示交

15、易失败；l 条码支付系统收到商户系统不合法的请求报文，则丢弃该报文或通知商户系统；条码支付系统处理商户系统交易请求出错，则通知商户系统提示交易失败，通知移动终端提示用户交易失败；l 条码支付系统请求账户系统支付失败，则交易中止，或由条码支付系统发起冲正，通知移动终端提示用户交易失败，通知商户系统提示交易失败；6 系统安全6.1 物理安全要求按GB/T 22239-2008中第三级基本要求中的7.1.1执行。6.2 网络安全要求按GB/T 22239-2008中第三级基本要求中的7.1.2执行。6.3 主机安全要求按GB/T 22239-2008中第三级基本要求中的7.1.3执行。6.4 应用安

16、全要求6.4.1 通用安全按GB/T 22239-2008中第三级基本要求中的7.1.4执行；其中，7.1.4.2中e）和f)为增强要求。其他基本要求： GB/T 22239-2008中第四级基本要求中的8.1.4.3中的c)项； GB/T 22239-2008中第四级基本要求中的8.1.4.4中的a)项； 用户通过应用系统对交易资源进行访问时，应用系统应保证在被访问的资源与用户之间能建立一条安全的信息传输路径； 在移动互联网等开放网络环境中，建立交易连接之前，应采用密码技术进行会话初始化验证； 应对交易过程中的整个报文或会话过程进行加密； 不应在日志中记录敏感信息。增强要求： 采用符合国家密

17、码管理相关规定和标准的密码技术保证通讯过程中交易数据的完整性。6.4.2 会话安全会话应满足但不限于如下安全要求： 会话标识应唯一、随机、不可猜测； 会话过程中应维持认证状态，防止信息未经授权访问； 会话应设置超时时间，当空闲时间超过设定时间应自动终止会话； 会话结束后，应及时清除会话信息； 应采取措施防止会话令牌在传输、存储过程中被窃取。增强要求： 应用审计日志应记录暴力破解会话令牌的事件。6.4.3 常见攻击防范应对常见的攻击（如跨站脚本攻击、注入攻击、拒绝服务攻击等）进行有效防范，包括但不限于如下手段： 应在服务器端对提交的数据进行有效性检查（如对提交的表单、参数等进行合法性判断和非法字

18、符过滤等），或对输出的数据进行安全处理； 应具有防范暴力破解静态密码的保护措施，例如使用图形验证码等； 应进行代码审查，防范应用程序中不可信数据被解析为命令或查询语句等； 应开发安全的接口，如通过避免语句的完全解释或采用参数化接口等方式实现； 应采取有效措施防范针对服务器端的拒绝服务攻击； 应对文件的上传和下载进行访问控制，避免执行恶意文件或未授权访问。增强要求： 数据库应使用存储过程或参数化查询，并严格定义数据库用户的角色和权限； 应通过自动化工具（如弱点扫描工具、静态代码检测工具等）对应用程序进行检查； 基于浏览器的应用，应使用安全控件等措施以降低恶意软件窃取用户敏感信息的风险。6.4.4

19、 数据安全及备份恢复按GB/T 22239-2008中第三级基本要求中的7.1.5执行。7 移动终端安全7.1 人机交互安全7.1.1 密码管理密码管理需符合下列要求：支付密码应满足以下安全管理要求1)支付密码不能保存在移动终端本地；2)用户输入支付密码时，应提供即时加密功能；3)认证操作结束后立即清除缓存，防止信息泄漏。登录密码等其它密码应满足以下安全管理要求1)登录密码等其它密码不能明文保存在移动终端本地；2)用户输入登录密码等其它密码时，应提供即时加密功能；3)认证操作结束后立即清除缓存，防止信息泄漏。7.1.2 交易异常处理当交易出现异常时，客户端应向用户提示出错信息。7.2 软件安全

20、7.2.1 条码生成移动终端生成条码时应保障条码信息的真实性、完整性。7.2.2 条码解析移动终端对条码解析时应对条码完整性进行校验，保证条码信息的完整性。7.2.3 数据有效性校验客户端宜提供数据有效性校验功能，保证通过人机接口或通信接口输入的数据格式或长度等信息符合系统设定要求，如输入的资金金额、账户等信息应不含特殊字符。7.2.4 页面回退清除敏感信息机制客户端宜支持页面回退清除敏感信息的机制。7.2.5 反编译客户端宜采用反逆向工程保护措施，如客户端可采取代码混淆等技术手段，防范攻击者对客户端的反编译分析。7.2.6 防篡改客户端启动和更新时，宜进行真实性和完整性校验，防范客户端被篡改

21、。7.2.7 客户端完整性应对客户端程序进行签名，标识客户端程序的来源和发布者，保证客户所下载的客户端程序来源于所信任的机构。7.3 数据安全7.3.1 数据录入数据录入需符合下列要求：敏感数据安全显示对于密码等敏感数据，客户端不应明文显示。敏感数据防截获用户输入敏感数据时，宜采取安全措施保证敏感数据不被移动终端的其他设备或程序非授权获取。敏感数据防篡改用户输入敏感数据时，宜采取防篡改机制保证数据不被移动终端的其他设备或程序篡改。7.3.2 数据访问宜根据业务需要保证敏感数据仅供授权用户或授权应用组件访问。7.3.3 数据存储数据存储需符合下列要求：关键数据存储在满足法律、管理规定和业务需求的

22、前提下，客户端宜保留最少的用户敏感数据（如登录密码、软件证书、账户信息等），并限制数据存储量和保留时间。用户信息存储安全客户端不应保存用户支付信息（如支付密码等）及其密文。敏感信息显示客户端显示敏感信息时，宜屏蔽部分内容，如银行账号、身份证号等。残余信息保护客户端在使用过身份认证、交易等敏感信息后，应及时清除敏感数据。7.3.4 数据传输数据传输需符合下列要求：远程数据传输保密性安全因子等敏感数据通过公共网络传输时应采取加密措施，保证敏感数据传输的保密性。本地数据传输保密性安全因子等敏感数据在本地软件其他进程间传输时应采取加密措施，保证敏感数据传输的保密性。数据传输完整性交易数据在传输时，客户

23、端应采取安全措施（如MAC等）以确保交易数据的完整性。7.4 通信安全7.4.1 网络通讯协议网络通讯协议需符合下列要求：应在客户端与服务器之间建立安全的信息传输通道，宜进行双向认证，例如使用SSL/TLS或IPSEC等协议；如使用SSL协议，应使用3.0及以上相对高版本的协议，取消对低版本协议的支持；客户端到条码支付系统的对称算法、非对称算法、摘要算法应采用安全可靠的密码算法，应选择符合国家行业主管部门要求的算法。7.4.2 安全认证客户端的网络协议层应对条码支付系统进行身份认证。7.4.3 抗抵赖通过客户端发送的报文的关键要素宜进行数字签名，以确保支付内容的真实性和不可抵赖性。7.5 条码

24、识读器条码识读器应保证对条码解析的准确性；条码识读器应保证对条码识读解析结果表达的规范性；条码识读器应保证识读结果的私密性，避免条码信息泄露。7.6 安全因子输入设备商户系统如果涉及安全因子输入的相关场景，应具备一定的安全机制保证安全因子输入、处理过程的安全。动态密码类应加密后进行传输；商户系统不应保存账户登录密码和支付密码等安全因子，在传输过程中须加密传输；银行卡PIN输入设备应满足国家及金融行业相关规范的要求： 银行卡PIN输入设备硬件的基本安全应满足GB 4943.1-2011的要求； 银行卡PIN输入设备应符合JR/T 0091-2012的要求。8 受理终端安全受理终端应保证对条码解析

25、的准确性；受理终端应保证对条码识读解析结果表达的规范性；受理终端应保证识读结果的私密性，避免条码信息泄露。关于安全因子输入设备按7.5执行。对于在原有POS或ATM等设备上进行扩展后能够处理条码展示或识读的设备还应遵守国家及金融行业相关标准。9 交易安全9.1 敏感信息保护敏感信息保护需符合下列要求： 应保证条码中不存储或不明文存储任何与用户和账户相关（如支付密码）的敏感个人信息，避免敏感信息的泄露和被篡改。 用户账号及证件号码等敏感信息只能按业务要求进行保存和使用，显示时应进行屏蔽处理； 应保证交易隐私信息的保密性，如姓名、有效身份证件号码、联系方式、交易内容等。9.2 交易过程安全9.2.

26、1 交易身份鉴别交易身份鉴别需符合下列要求： 条码支付业务的使用用户应具备唯一的身份标识ID，保证对条码支付的操作能够被追溯到用户； 应建立条码支付网址的黑白名单验证和管理机制，在黑名单中直接拒绝，其它网址应进行风险提示。9.2.2 交易报文安全交易报文安全需符合下列要求： 应可防止对交易的重放攻击； 宜保证交易的抗抵赖性，包含但不局限于证书签名等技术手段； 在交易报文传输过程中应使用安全传输协议保证传输安全，包含但不限于SSL/TLS协议； 应用系统应保证在一段时期内同一商户交易、订单的唯一性； 应用系统应检查交易请求报文中记载的交易要素是否完整并符合业务规则，并拒绝不完整或者不符合业务规则

27、的交易请求； 应用系统应防止对支付成功的订单重复支付； 应对条码识别后的内容进行严格的安全校验，保证只有合法有效的条码才能进入后续支付流程； 动态条码应具备时效性，应对条码的使用时间和使用次数进行控制，超过时效性的条码应拒绝执行。9.2.3 风险识别与干预风险识别与干预需符合下列要求： 应采取必要措施，在交易过程中给予必要的支付风险提示。支付风险的提示可每次提示，也可在业务开通时给予提示； 支付机构从用户的账户管理机构获取的支付结果中应包含支付及风险防范相关的数据要素； 应对交易过程进行风险识别与干预，防范潜在的非法交易、欺诈交易。9.2.4 交易监控交易监控需符合下列要求： 应建立交易监控系统，能够甄别并预警潜在风险交易，例如套现、洗钱、欺诈等可疑交易，并生成风险监控报告； 应根据交易的风险特征建立风险交易模型，有效监测可疑交易，对可疑交易建立报告、复核、查结机制； 应对监控到的风险交易进行及时分析与处置； 应依据已识别并确认的风险数据，建立黑名单数据库。9.3 用户教育用户教育需符合下列要求： 应通过公开渠道向用户提供安全的包含条码支付功能的客户端程序； 应向用户宣传条码支付的安全知识，提高用户安全防范意识； 应在支付使用过程中向客户明确提示相关的安全风险和注意事项。10 密钥体系条码支付使用的密码算法应符合国家行业主管部门要求。