GB/T 31502-2015 信息安全技术 电子支付系统安全保护框架

OJ.U^tU

L80(SB

中华人民共和国国彖标准

GB/T31502—2015

信息安全技术

电子支付系统安全保护框架

Informationsecuritytechnology—

Securityprotectframeworkofelectronicpaymentsystem

2015-05-15发布2016-01-01实施

GB/T31502—2015

目次

前言ID

引言W

I范围1

2规范性引用文件1

3术语和定义1

4符号与缩略语2

4.1符号表示2

4.2缩略语3

5电子支付系统描述3

5.1电子支付系统模型3

5.2电子支付系统工作模式7

5.3受保护资产8

6安全问题定义10

6.1概述10

6.2威胁10

6.3组织安全策略（SOP）14

6.4假设（SAS）17

6.5安全问题定义理由17

7安全目的17

7.1概述17

7.2针对评估对象［TOE］的安全目的（OET）18

7.3针对评估对象［TOE］运行境的安全目的（OTE）18

8安全功能要求19

8.1概述19

8.2安全审计（FAU类）19

8.3通信（FCO类）32

8.4密码支持（FCS类）35

8.5用户数据保护（FDP类）35

8.6标识和鉴別（FIA类）40

8.7安全管理（FMT类）40

8.8TSF保护（FPT类）42

9安全保证要求43

10国家相关标准的部分依从性分析43

II组织安全策略示例43

附录A（资料性附录）电子支付系统的行为模型44

GB/T31502—2015

附录B（规范性附录）安全问题定义理由69

附录C（规范性附录）安全目的理由74

附录D（规范性附录）安全保证要求78

附录E（规范性附录）对国家相关标准的部分依从性分析80

附录F（资料性附录）组织安全策略示例：可疑交易预警规则82

参考文献87

n

GB/T31502—2015

、F■1,

刖s

本标准按照GB/T1.1-2009给出的规则起草。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。

本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口。

本标准起草单位:北京多思科技工业园股份有限公司、中国农业银行、中国金融电子化公司、国家信

息安全T程技术研究中心、东方集团网络信息安全技术有限公司、北京大秦兴宇电子有限公司、北京天

宏绎网络技术有限公司、北京科蓝软件系统有限公司、长城瑞通(北京)科技有限公司、重庆银行、南充市

商业银行。

本标准主要起草人:刘人力、李宽、沈敏锋、韩琳琳、吴义章、吴铮、刘运、文仲慧、沈昕立、康伟、张磊、

于敬新、崔新杰、罗勇、夏鹏轩、闫凤如、陈辉武、王庆元、左小波、邱岩、张春阳、黄光伟、邢呈礼、高艳芳、

王州府。

GB/T31502—2015

引言

本标准以国际通行的信息技术安全性评估准则为基础，结合我国现阶段电子支付系统的特点，按照

我国有关法律、法规和政令的要求，以自主可控为原则，为公共类电子支付系统的信息安全提供一个公

共框架;是进一步完善相关国家标准及行业标准的重要步骤；为构建、运行公共电子支付系统，提供

支撑。

IV

GB/T31502—2015

信息安全技术

电子支付系统安全保护框架

1范围

本标准在给出电子支付系统模型的基础上，为公共类电子支付系统的信息安全提供了一个公共框

架，主要包括安全问题定义、安全目的、安全功能需求和安全保障需求。

本标准适用于安全构建、运行公共类电子支付系统。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文

件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T18336.1信息技术安全技术信息技术安全性评估准则第1部分:简介和一般模型

GB/T18336.2信息技术安全技术信息技术安全性评估准则第2部分:安全功能组件

GB/T18336.3信息技术安全技术信息技术安全性评估准则第3部分:安全保障组件

3术语和定义

GB/T18336.1界定的以及下列术语和定义适用于本文件。

3.1

电子支付electronicpayment

采用数字化方式，在电子终端、信息传输通道以及相关系统的支持下，进行支付的行为。

3.2

支付通道transactionchannel

在电子支付交易过程中，电子支付凭据与支付终端以及支付终端与支付安全前置之间实现信息传

输的途径。

3.3

公共网络通道publicnetworkchannel

支持电子支付交易的公共网络基础设施。在电子支付领域通常简称为网络。

3.4

接触通道contactchannel

支持电子支付交易的实体直接连接方式。

3.5

电子支付凭据electronicpaymentcredential

在电子支付过程中，用以最终确定支付相关账户的凭据。

电子支付凭据可能是有载体的，也可能是无载体的，同一电子支付凭据可能记载在不同的载体中。

3.6

电子支付凭据载体electronicpaymentcredentialscarrier

记载电子支付凭据的介质。不同的电子支付凭据载体,其安全性是不同的。

GB/T31502—2015

3.7

电子支付凭据持有者electronicpaymentcredentialholder

合法拥有电子支付凭据的人。对电子支付凭据记录了持有者信息的，电子支付凭据持有者的信息

与电子支付凭据内部记录的信息应一致。

3.8

受理方accepter

向电子支付凭据持有者提供通道，并在需要时协助电子支付凭据持有者完成电子支付交易的机构。

3.9

受理方操作员operatorofaccepter

协助电子支付凭据持有者完成电子支付交易的人员，向受理方负责。

3.10

中介方intermediary

在电子支付交易中，按照付款方或收款方提岀的电子支付交易请求，代为完成资金转移者。

3.11

安全域securitydomain

在电子支付交易的过程中，遵守相同的安全策略的用户和系统的集合。

3.12

可信信道trustedchannel

为了支持安全功能策略，电子支付系统安全功能同远程可信IT产品进行所需信任通信的一种

手段。

3.13

可信路径trustedpath

为了支持安全功能策略，用户能同电子支付系统安全功能进行所需信任通信的一种手段。

3.14

电子支付系统安全保护securityprotectofelectronicpaymentsystem

对电子支付系统信息的保护及其相关的保护措施，保护电子支付信息在采集、传输和处理中免遭未

授权访问（保密性）、修改（完整性）和对授权用户的可用性，以及支持安全管理的可核查性和抗抵赖

性等。

在具备条件的情况下，对具有本标准所述电子支付系统特征的信息系统编制保护轮廓（Protection

Profile,以下简称：PP）和安全目标（SecurityTarget,以下简称：ST），将有助于有效评价该电子支付系

统的安全水平，发现潜在的风险，评估可能导致的损失，以便给出适宜的风险应对措施。

4符号与缩略语

4.1符号表示

本标准对受保护资产、安全问题、安全目的和安全需求均按可引用的单元进行了编码，以便于进行

引用和参照。编码采用了与安全功能要求和安全保证要求协调的方式，编码的首字母如表1所示。

2

GB/T31502—2015

表1类编码对象

编码对象编码首字母

受保护资产P

安全问题S

安全目的0

安全功能要求F

安全保障要求A

4.2缩略语

下列缩略语适用于本文件。

EPS：电子支付系统(ElectronicPaymentSystem)

IT：信息系统(InformationTechnology)

PIN：个人鉴別码(PersonalIdentificationNumber)

PP：保护轮廓(ProtectionProfile)

ST：安全目标(SecurityTarget)

TOE：评估对象(TargetofEvaluation)

TSF：T()E安全功能(TOESecurityFunctions)

TSP：TOE安全策略(TOESecurityPolicy)

5电子支付系统描述

5.1电子支付系统模型

5.1.1概述

本章给出了电子支付概念和电子支付系统模型，其中电子支付概念仅描述了一种典型状况，其目的

在于使本标准阅读者能较快和准确地理解模型，并将视角聚焦于电子支付系统中的安全保护问题。

5.1.2电子支付概念

在电子支付中，付款方与受理方交互，提出付款申请;受理方将获取的支付请求发送到电子支付服

务方；电子支付服务方完成相应的支付服务，并在必要时通过受理方转交或通知收款方。电子支付支撑

方提供账户管理、账务核算、安全措施与管理等功能，这些功能可能自某一方可以实现电子支付开始就

已经提供，但收款方、付款方与受理方的人员可能不需知悉。电子支付的概念如图1所示。

注1：图中的受理方应看做一个实体，为便丁理解，価作了分别连接的两个方框。

注2：收款方的受理方可能是隐含的，即实际上在电子支付服务方内部即完成了支付动作，收款方仅仅通过受理方

获得了通知。

图1电子支付概念图

3

GB/T31502—2015

5.1.3电子支付系统模型

在电子支付系统模型中，电子支付凭据、支付终端、支付安全前置、支付平台组成了电子支付系统,

通过与用户和相应支付后台交互工作，并在必要时使用认证中心提供的身份认证服务，以完成电子支付

交易。

电子支付系统模型如图2所示。其与电子支付的映射关系一般为：

a）付款方包括用户和电子支付凭据；

b）收款方可能包括用户和电子支付凭据，也可能仅为用户；

c）受理方包括支付终端和作为受理方操作员的用户；

d）电子支付服务方包括支付安全前置、支付平台；

e）电子支付支撑方包括支付后台和认证中心。

注1：图中用户是抽象的，为保持图的清晰性，未对角色及其操作的评估对象［TOE］组件进行进一步的划分。

注2：图中金融、中介、预存类支付安全前置、支付平台和支付后台都可能有多个受理方。

注3：图中的连接分为三类。用户与电子支付凭据载体和支付终端连接的点线表示人机交互；电子支付凭据载体

与支付终端以及支付终端与预存支付安全前炭的点划线表示近场或接触；实线表示公共网络，但不限制网络

连接的物理链路；双线箭头表示同一受理方TSF内部传送。图中画出的六边形网络是为了便于描述支付终

端、支付安全前置和认证中心的T作关系，并区别描述通过网络与通过近场或接触方式的连接。

注4：一个支付服务的提供实体，可仅支持图中的一种模式，也可同时支持图中的两种其至三种模式，即同时承担

儿种不同方式的受理方。

注5：电子支付凭据载体、支付终端、支付安全前置、支付平台所构成的电子支付系统，其整体构成了一个分布式的

评估对象［TOE］。

注6：用户、支付后台和认证中心是电子支付系统模型的边界条件，非评估对象实体。

注7：安全芯片町能涉及电子支付系统中的每一个组件，按照本标准给出的模型描述安全芯片所在的组件以及在

交互过程中安全芯片的作用，更易于理解安全芯片的功能、安全问题定义、安全目的、安全功能要求和安全保

证要求。

图2电子支付系统模型

4

GB/T31502—2015

5.1.4评估对象［TOE］实体

5.1.4.1电子支付凭据载体

电子支付凭据载体是通过技术手段，存储安全属性和包括电子支付凭据在内的用户数据，并能够支

持完成电子支付交易的介质。

注1：不同的电子支付凭据载体，其存储用户数据的方式、能力和安全属性不同。随现代电子技术和T•艺的高速发

展，新型电子支付凭据载体的存储和计算能力日新月异，其功能与安金性町能会出现颠覆性变化。

注2：在同一个交易中，可能需要电子支付凭据持有者的电子支付凭据载体，也可能还需要受理方操作员的电子支

付凭据载体。

示例：金融磁条卡、金融IC卡、金融SI）卡、金融SIM卡、动态密码器和USBKey是不同形式的电子支付凭据载体。

金融磁条卡因其存储方式、能力和安全属性的落后，已经在全世界公共电子支付领域逐渐被金融IC卡等带CPU的电子

支付凭据载体所替代。动态密码器在动态口令卡大规模应用后，出现了功能更强、更安全的接触型产品。第一代USB

Key已过渡到带操作界面的第二代，带键盘第三代和基于生物识别技术的智能USBKey也已出现。

5.1.4.2支付终端

支付终端是能读取或读写电子支付凭据载体、接受用户输入支付相关信息，发起电子支付的电子设

备。根据其安全识別可分为相对的专用支付终端和非专用支付终端，本标准T（）E之内的支付终端不

另说明的均为专用支付终端。非专用支付终端接入电子支付系统，需要包括电子支付凭据载体在内的

各种安全识别配合。

注1：根据支付终端的种类不同，用户可能仅是电子支付凭据持有者，也可能还包括受理方操作员。

注2：各类支付终端连接的支付安全前置种类不同，其物理层、数据链路层和网络层的实现模式亦不相同。

注3：类比专用支付终端的初始化，非专用支何终端接入电子支付系统吋需要数字证书认证。个人常用支付终端

可以绑定硬件。

示例：销售点终端（POS）、自动金融柜员机（ATM）是专用支付终端的例子；个人计算机（PC）、电视机顶盒（STB）、电

话支何终端、移动电话支付终端是非专用支付终端的例子，这些设备与电子支付无关的功能在本标准中不做描述。

5.1.4.3支付安全前置

支付安全前置是设置于支付平台前的安全接口，其主要功能为：

a）预防、减缓对支付平台和支付后台的攻击；

b）建立支付终端与支付平台之间的可信路径；

c）建立支付平台与其他支付安全前置之间的可信路径。

示例1：预防、减缓对支付平台和支付后台攻击的例子，包括，但不限于防火墙、入侵检测、防病毒系统；

示例2：在支付终端与支付平台之间建立可信路径的例子，包括，但不限于VPN。

支付安全前置可进一步划分为：

a）金融支付安全前置。接收来自支付终端的交易请求，也可能接收来自中介支付安全前置的交

易请求，与金融支付平台进行信息交互；

b）中介支付安全前置。接收来自支付终端的交易请求，与中介支付平台交互，并在需要时与金融

支付安全前置和［或］其他中介支付安全前置交互；

c）预存支付安全前置。接收来自支付终端的交易请求，与预存支付平台交互C

5.1.4.4支付平台

支付平台是电子支付的逻辑处理系统，接收支付终端通过支付安全前置发来的交易请求或交易记

录，向支付后台发出动账请求并接收处理结果，形成对电子支付交易的响应，通过支付安全前置发送支

付终端。

5

GB/T31502—2015

支付平台可进一步划分为：

金融支付平台。接收来自金融支付安全前置的交易请求，与金融支付后台进行信息交互。

1）中介支付平台。接收来自中介支付安全前置的交易请求，按照预定的规则，与中介支付后台交

互，并在需要时通过金融支付安全前置与金融支付平台交互，或通过其他中介支付安全前置与

其他中介支付平台交互；

2）预存支付平台。接收来自预存支付安全前置的交易请求，与预存支付后台交互。

注：中介支付平台可提供的交易双方的信用担保、降低网上交易风险、防止电子交易欺诈、增加网上交易成交率及

提供其他相应的增值服务未在标准中描述。

示例1：移动运営商、广电运营商、石油供应商、口来水公司、电力公司、公共交通部门、商业零售机构等商业机构均

可能建立专用的预存支付平台与预存支付后台，以实现对预付款卡服务的按约定计量单位的计价扣收。

示例2：有效识别、评估、监测、控制和报告风险的例子，包括，但不限于：操作风睑管理信息系统、可疑交易预警

系统。

5.1.5非评估对象［TOE］实体

5.1.5.1用户

用户是与电子支付系统交互以发起支付交易的实体，用户通过操作电子支付凭据载体与支付终端

完成支付交易。典型的用户包括：

a）电子支付凭据持有者。提供电子支付凭据,并在必要时在支付终端上输入完成电子支付交易

所需的信息，通过支付终端发起电子支付交易的用户；

b）受理方操作员。通过操作支付终端，按照业务规则初始化一个周期的电子交易境，在电子支

付交易时输入完成电子支付所需信息，通过支付终端发起电子支付交易的用户。对一些自助

终端，可能不需要受理方操作员的操作；

c）业务管理者。通过操作支付终端、支付安全前置、支付平台和支付后台，进行业务参数配置、业

务异常调整、账务核算、清分、清算、产生业务状况报表的用户；

d）系统管理者。通过操作电子支付凭据载体、支付终端、支付安全前置、支付平台、支付后台及其

运行境支撑设施,进行设备安装、维护、技术参数配置、设备运行境与状况监控，保证电子

支付系统正常运行的用户。

示例1：电子支付凭据持有者可能是持卡人、网上银行USBKey的持有人、手机银行动态密码器的持有人。

示例2：电子支付凭据持有者在支付终端上可能输入密码，也可能采集生物特征。

示例3：受理方操作员在支付终端上可能签到、输入交易金额，也可能进行终端的结算。

示例4：业务管理者可能在支付平台上输入指令，以获得电子支付交易状况统计表。

示例5：在支付过程中出现故障时，可能需要系统管理者的介入以正确完成支付行为。

5.1.5.2支付后台

支付后台是接收支付平台发出的动账请求并返回执行结果的系统。这种动账请求可能是单笔模式

的，也可能是批量模式的。支付后台分为：

a）金融支付后台。其特征为：

1）保存有付款方的法定货币账户余额和交易明细；

2）能够对付款方账户进行动账处理；

3）能够将电子支付交易发生额按照约定的规则分別存入收款方和电子支付相关方的账户；

4）具有按照金融支付平台的请求或在金融支付后台本身发现核算错误时，进行账务调整的

能力。

注1：经国家金融主管部门批准的金融机构才能设置金融支付后台。

6

GB/T31502—2015

注2：付款方的账户一般是电子支付凭据持有者的账户，收款方的账户一般是受理方的账户。除此之外的情况也

是可能的，但会増加交易的复杂性。

示例：本条描述的金融支付后台是一个广泛的概念。在实际交易中，付款方账户和收款方账户可能不属于同一个

银行，但金融后台能在其内部完成这样的账户资金转移。

b）中介支付后台。其特征为：

1）保存有付款方、收款方和电子支付相关方的账户；

2）具有对付款方账户的动账能力，且将发生额暂时计入收款方和电子支付相关方的能力；

3）具有根据电子支付交易序列，对暂时计入收款方和电子支付相关方的发生额进行清分的

能力；

4）具有根据电子支付交易序列，完成原支付交易的反向交易的能力；

5）具有根据电子支付交易序列，按照约定的规则对收款方账户进行动账的能力。

注1：经国家金融主管部门批准的第三方支付机构才能设置中介支付后台。这是一种非银行金融服务，但在某些

文献中，第三方支付服务也可能称作非金融支付服务。

注2：付款方的账户一般是电子支付凭据持有者的账户，收款方的账户一般是受理方的账户。除此之外的情况也

是可能的，但会増加交易的复杂性。

c）预存支付后台。其特征为：

1）保存有付款方账户；

2）具有根据电子支付交易，对付款方账户进行动账的能力；

3）具有根据电子支付交易序列，完成原支付交易的反向交易的能力。

注1：经国家主管部门批准的机构才能设置预存支付后台。这也是一种非银行金融服务，但目前还没完全纳入金

融管理，有部分与第三方支付服务重迭。

注2：付款方的账户一般是电子支付凭据持有考的账户。除此之外的情况也是町能的，但会增加交易的复杂性。

示例：加油卡、购电卡、市政交通一卡通的后台系统为预存支付后台。

5.1.5.3认证中心

认证中心是经国家主管部门批准设立的具有权威性和公正性的第三方信任机构，负责在需要时签

发和管理数字证书，提供身份认证服务。

注：电子支付机构内部设立的认证中心，不能满足公共电子支付系统抗抵赖性的完整需求。

5.2电子支付系统工作模式

电子支付系统包括两种丁作模式：

a）在线模式。用户在支付终端上对电子支付凭据载体进行读［或读写：］操作，在支付终端获取满

足特定电子支付交易的全部必要信息后，通过网络向支付安全前置发出交易请求，随后：

1）金融支付安全前置将信息发送到金融支付平台，金融支付平台进行逻辑处理，向金融支付

后台发出动账请求并获得结果后，通过金融支付安全前置向支付终端返回交易结果，完成

电子支付交易。

2）中介支付安全前置将信息发送到本中介支付平台，本中介支付平台进行逻辑处理，向本中

介支付后台发出动账请求，并：通过本中介支付安全前置、金融支付安全前置向金融支付

平台发出交易请求，由金融支付平台向金融支付后台发出动账请求，取得处理结果后返回

本中介支付平台；或［且］通过本中介支付安全前置，另一中介支付安全前置向另一中介支

付平台发出交易请求，由另一中介支付平台向另一中介支付后台发出动账请求，取得处理

结果后返回本中介支付平台。由本中介支付平台处理后产生对电子支付交易的响应，返

回支付终端,完成电子支付交易。

3）预存支付安全前置将信息发送到预存支付平台，预存支付平台进行逻辑处理，向预存支付

7

GB/T31502—2015

后台发出动账请求并获得结果后，通过预存支付安全前置向支付终端返回交易结果，完成

电子支付交易。

注1:在线模式(onlinemode)也称为联机模式，联线模式。

注2：一般来说，通过中介支付服务方进行电子支付需要多次交易组成的交易序列，方可达到电子支付的目标。

b)离线模式。用户在支付终端上对电子支付凭据载体进行读写操作以完成电子支付交易。

随后：

1)支付终端通过网络连接金融支付安全前置，将交易记录发送到金融支付平台，金融支付

平台进行逻辑处理，向金融支付后台发出动账请求并获得结果，并依据结果形成后继处

理信息。在适宜的时刻，金融支付平台通过金融支付安全前置向支付终端发送后继处理

信息。

2)支付终端通过网络或近场、物理通道连接预存支付安全前置，将交易记录发送到预存支

付平台，预存支付平台进行逻辑处理，向预存支付后台发出动账请求并获得结果，并依据

结果形成后继处理信息。在适宜的时刻，预存支付平台通过预存支付安全前置向支付终

端发送后继处理信息。

注：离线模式(offlinemode)也称为脱机模式。

示例：在离线模式下，止付名单(黑名单)就是一种后继处理信息。

电子支付系统的行为模型参见附录A。

5.3受保护资产

5.3.1描述目的

在本标准的后面各章中所描述的安全问题描述、安全EI的和安全需求，均为了保护5.3中所描述的

受保护的资产。

5.3.2用户数据［userdata］类(PUD)

5.3.2.1概述

用户数据［userdata］是指由用户产生或为用户产生的数据，这些数据不影响电子支付系统安全功

能的运行。

5.3.2.2业务配置数据(PUD_BCD)

电子支付凭据载体、支付终端、支付平台、支付后台的业务配置数据，与应用处理软件一同构成了业

务处理规则，至少是一些主要的业务处理规则。

示例：在使用卡号和密码登录网上银行时，每日转账的最高限额为一个业务配置数据。

5.3.2.3业务处理数据(PUD_BPD)

电子支付凭据载体、支付终端、支付平台、支付后台的业务数据,包括电子支付系统在运行时处理以

及由处理产生的各种业务信息。

注：业务处理数据可根据管理需要分为客户信息、账户信息、交易记录、业务统计与业务支持等信息。

示例1：电子支付凭据持有者和受理方操作员的姓名、证件种类与号码、联系电话都是电子支付相关方人员的客户

信息。

示例2：付款方账户的余额、可支付的限额均为电子支付相关方账户信息。

示例3：从交易中获取的硬件绑定标识、交易时间、交易金额、接入地区、登陆IP、转入/出机构等信息进行组合形成

预警监控规则.用于逐笔业务的实吋风险筛选，并确定预警、批准或拒绝交易请求。

8

GB/T31502—2015

5.3.2.4输入数据(PUD_IND)

电子支付交易过程中，人工输入的数据。

5.325传输数据(PUD_TSD)

传输数据包括：

a)电子支付凭据载体与支付终端之间传输的数据；

b)支付终端与支付平台之间传输的数据；

c)各支付服务方通过各自的支付安全前置传输的数据。

注：在支付服务方内交换的数据，例如同一服务方的支付平台和支付后台间交换的数据，或不同银行构成了一个金

融支付后台而在内部交换的数据，未作为电子支付系统的传输数据考虑。

示例：交易的业务报文是电子支付凭据载体与支付终端之间和支付终端与支付平台之间传输的数据。

5.3.3评估对象安全功能数据:TSFdata］类(PTD)

5.3.3.1概述

评估对象安全功能数据［TSFdata］是指由电子支付系统产生或为电子支付系统产生的数据，这些

数据可能会影响电子支付系统安全功能的运行。

5.3.3.2评估对象安全功能:TSF］受保护数据(PTD_PRD)

除系统的管理者和拥有者外，不允许改变内容但允许公开内容的数据。

注：不管是数据的非管理者用户还是数据的非拥有者用户，对评估对象安全功能［TSF］受保护数据的改变可能影

响该评估对象［TOE］的运行安全,但对这类数据的泄露是可接受的。

示例：用户和设备的标识数据(II))、用户或系统状态数据、设备和网络状态信息和配置设置、设备安全状态等均为

评估对象安全功能［TSF］受保护数据。

5.3.3.3评估对象安全功能:TSF］保密数据(PTD_COD)

除系统的管理者和拥有者外，既不允许改变内容也不允许公开内容的数据。

注：不管是数据的非管理者用户还是数据的非拥有者的用户，对评估对象安全功能［TSF］保密数据的改变和泄露

均可能影响该评估对象［TOE］的运行安全。

示例：用户和设备的鉴别数据、用户口令、审计记录数据、数字证书的私钥、访问控制表等均为评估对象:TOE］保

密数据。

5.3.4设计信息类(PDI)

5.3.4.1概述

设计信息类数据是指电子支付系统的设计、构建信息，这些信息可能会影响电子支付系统安全运

行,或可能会缩短电子支付系统能够安全运行的时间，或可能会减少电子支付系统安全运行的场合。

5.3.4.2组件设计信息(PDI_CDI)

在电子支付系统组件的设计过程中，设计的输入信息和期望的输出信息；

示例：设计规格说明、指令体系。

确认和验证设计出的组件实现了要求的功能、性能以及未实现未要求功能的方法及其数据；

示例：测试激励数据。

电子支付系统组件的设计过程中所涉及的物理元件、部件工艺、专用装备、测试设备的信息。

示例：芯片掩膜版＞ROM掩膜数据生成丁•具、物理验证境。

9

GB/T31502—2015

5.3.4.3应用设计信息(PDI_ADI)

应用设计信息是指电子支付系统的设计过程中，产生的为按需求进行应用设计涉及的设计信息。

示例：应用系统软件本身、安全功能策略数据、预个人化数据存储策略均为应用设计信息。

6安全问题定义

6.1概述

本章描述了电子支付系统可能面临的典型安全问题，针对由不同的组件构成的电子支付系统以及

应用在不同场合的电子支付系统，在制定PP和ST时，应对本标准提出的典型安全问题进行分析，并补

充在特定情况下可能出现的安全问题。

为了全面和易于理解地描述典型安全问题，并在编写不同组件的PP和ST时便于参照标准中的内

容，本标准对不同组件面临的典型安全问题，采用的描述方式为：

——完全等同的，采取不分组件的文字描述方式；

——不完全等同的，采用分组件的文字描述方式；

——除明确说明外，对各典型安全问题的描述未隐含相互引用关系。

6.2威胁

6.2.1描述方式

电子支付系统涉及三大类威胁：对用户数据的威胁，对安全功能数据的威胁，对设计信息的威胁。

描述威胁采用的统一格式:威胁主体(涉及：能力［知识与技术、工具］),威胁到的资产，威胁的负面作用。

在本标准中没有给出威胁主体的描述，在5.3“受保护资产”中已对威胁到的资产给出了相应的描述，因

此可以如表2描述威胁：

表2威胁

数据类型受保护数据威胁

用户数据业务配置数据(PUD_BCD)未经授权的泄露

[userdata]未经授权的变更

业务处理数据(PUD.BPD)未经授权的泄露

未经授权的变更

输入数据(PUI)_INI))伪造

未经授权的变更

抵赖

传输数据(PUI)_TSD)伪造

未经授权的变更

抵赖

安全功能数据［TSFdata］受保护的数据(PTD_PRD)伪造

未经授权的变更

保密数据(PTD_COD)伪造

未经授权的泄露

未经授权的变更

设计信息(PDI)组件设计信息(PDI.CDI)伪造

未经授权的泄銘

未经授权的变更

应用设计信息(PDI_ADI)伪造

未经授权的泄露

未经授权的更改

10

GB/T31502—2015

6.2.2对用户数据［userdata］的威胁(STU)

6.2.2.1对业务配置数据的威胁(STU_BCD)

6.2.2.1.1未经授权的泄露(STU_BCD.1)

电子支付系统的业务配置数据，包括记载在软件代码中的业务配置数据、记载在数据库或文件系统

中的业务配置数据或动态由配置管理软件发送到电子支付系统的业务配置数据，可能由于攻击者的恶

意攻击或开发人员的疏漏,遭到未授权的泄霜。

示例：客户进行动账交易时由电子支付系统下传的随机验证码规则过于简单被推算出来，即为未授权的泄露。

6.2.2.1.2未经授权的变更(STU_BCD.2)

电子支付系统的业务配置数据，可能由于攻击者的恶意攻击或开发人员的疏漏，遭到未授权的变

更，变更的方式可能包括更改原有的数据、删除原有数据或增加新的数据。

示例：客户进行动账交易时提交给电子支付系统的交易数据被截获并改变交易报文的主要内容，即为未经授权的

变更。

6.2.2.2对业务处理数据的威胁(STU_PBD)

6.2.2.2.1未经授权的泄露(STU_PBD.1)

电子支付系统的业务处理数据，可能由于攻击者的恶意攻击或开发人员的疏漏，遭到未授权的

泄露。

示例：电子支付系统的业务处理数据所在的存储空间可能在被释放和重新分配之前未完金清除，导致业务处理数

据的泄漏。

6.2.2.2.2未经授权的变更(STU_PBD.2)

电子支付系统的业务处理数据，可能由于攻击者的恶意攻击或开发人员的疏漏，遭到未授权的变

更，变更的方式可能包括更改原有的数据、删除原有数据或增加新的数据。

6.2.2.3对输入数据的威胁(STU_IND)

6.2.2.3.1伪造(STU_IND.1)

电子支付系统的输入数据，可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作，遭到

伪造。

示例：在商户操作员没有在POS输入数据的情况下，POS认为接受到了输入数据，即为一种伪造。

6.2.2.3.2抵赖(STU_IND,2)

电子支付系统的输入数据，可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作或恶意操

作，遭到抵赖，抵赖的方式可能是输入方不承认输入过数据，也可能是接收方不承认接收到过数据。

示例：在商户操作员在POS输入数据的情况下，POS认为没有接受到输入数据.即为一种抵赖。

6.2.2.3.3未经授权的变更(STU_IND.3)

电子支付系统的输入数据，可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作，遭到未

授权的变更。

示例：个人计算机接受到的输入数据与网上银行用户输入的数据不一致，且这种不一致并非电子支付系统在构造

时设定的数据变换，即为一种未授权的变更。

11

GB/T31502—2015

6.2.2.4对传输数据的威胁(STU_TSD)

6.2.2.4.1伪造(STU_TSD.1)

电子支付系统的传输数据，可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作，遭到

伪造。

示例：在ATM经过金融支付安全前置向金融支付平台发出请求的情况下，在金融支付平台尚未向ATM返冋响

应信息时,ATM接收到了响应信息，即为一种传输数据的伪造。

6.2.2.4.2未经授权的变更(STU_TSD.2)

电子支付系统的传输数据，可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作，遭到未

授权的变更。

示例：支付平台接受到的传输数据与个人计算机发出的数据不一致，且这种不一致并非电子支付系统在构造时设

定的数据变换，即为一种未授权的变更。

6.2.2.4.3抵赖(STU_TSD.3)

电子支付系统的传输数据，可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作或恶意操

作，遭到抵赖，抵赖的方式可能是发送方不承认发送过数据，也可能是接收方不承认接收到过数据。

6.2.3对评估对象安全功能数据［TSFdata］的威胁(STP)

6.2.3.1对评估对象安全功能［TSF］受保护数据的威胁(STP_PRD)

6.2.3.1.1伪造(STP_PRD.1)

电子支付系统的评估对象安全功能［TSF］受保护数据，可能由于攻击者的恶意攻击或开发人员的

疏漏，遭到伪造。

示例：在ATM经过金融支付安全前置向金融支付平台发出请求的情况下，在金融支付平台尚未向ATM返回响

应信息吋，ATM接收到了响应信息，且响应信息的鉴别码能够为ATM确认，即为一种评估对象安全功能:TSF］受保护

数据的伪造。

6.2.3.1.2未经授权的变更(STP_PRD.2)

电子支付系统的评估对象安全功能［TSF］受保护数据，可能由于攻击者的恶意攻击或开发人员的

疏漏,遭到未授权的变更。

示例：当支付平台的交易记录带有鉴别码时，在未经过操作的交易修改交易记录的情况下，未通过允许的操作修改

了鉴別码，且再通过允许的操作进行鉴別码的确认河可以通过，即为一种评估对象安全功能［TSF］受保护数据的未经授

权的变更。

6.2.3.2对评估对象安全功能［TSF］保密数据的威胁(STP_COD)

6.2.3.2.1未经授权的泄露(STP_COD.1)

电子支付系统的评估对象安全功能［TSF］保密数据，可能由于攻击者的恶意攻击、开发人员的疏漏

或用户的误操作，遭到未经授权的泄露。

示例1：存储于中介支付平台的用户名称与密码明文的泄露，即为一种评估对象安全功能［TSF］保密数据的未经

授权的泄露。

示例2：在网上电子支付交易中，在互联网上通过明文传输用户账户的口令，即为一种TSF保密数据的未经授权的

泄露。

12

GB/T31502—2015

示例3：当组件是IC卡芯片时，可能通过未授权使用新的或未发行的IC卡芯片而非法获得IC卡芯片信息，也可能

会利用相关命令，尤其是测试和调试命令来获取IC卡芯片安全功能数据或敏感的用户数据，这些命令在智能卡生命周

期的以往某些阶段是必要的，但在现阶段是被禁止的。

示例4：当组件是IC卡芯片时，攻击者町能实施密码攻击或穷举攻击危及IC卡芯片的安全功能。这种攻击可能

用到一些加密函数、编码/解码函数或随机数发生器。攻击者的目标是发现密码算法中的脆弱性或通过穷举来发现密钥

和输人数据。

6.2.3.2.2伪造(STP_COD.2)

电子支付系统的评估对象安全功能［TSF］保密数据，可能由于攻击者的恶意攻击或开发人员的疏

漏，遭到伪造。

示例1：在中介支付平台A与金融支付平台B之间约定以加密方式交换支付信息时，若在中介支付平台A未向金

融支付平台B发起请求报文，而金融支付平台B接收到请求报文，且经过解密能正确解析报文时，即为一种评估对象安

全功能［TSF］数据的伪造。

示例2：假定中介支付平台A采用证书手段对其客户的交易进行加密，且证书应为某第三方机构发放，若中介