【行业标准】 中国金融移动支付 检测规范 第5部分：安全单元（SE）嵌入式软件安全

ICS35.240.40
中华人民共和国金融行业标准
JR/T0098.5—2012
中国金融移动支付检测规范
第5部分：安全单元（SE）嵌入式软件安全China financial mobile payment-Test specifications-Part 5:Embedded software security of secure element (SE2012-12-12发布
中国人民银行
2012-12-12实施
前言：
2规范性引用文件
3术语和定义：
4缩略语
5测试条件
6SE嵌入式软件安全检测.
7SE多应用平台安全检测
8移动支付SE规格符合性检测
附录A（规范性附录）
附录B（资料性附录）
参考文献
SE嵌入式软件安全要求
多应用平台安全与嵌入式软件SFRs参照JR/T0098.5—2012
JR/T 0098.5—2012
《中国金融移动支付检测规范》标准由以下8部分构成：第1部分：移动终端非接触式接口：第2部分：安全芯片：
第3部分：客户端软件：
第4部分：安全单元（SE）应用管理终端第5部分：安全单元（SE）嵌入式软件安全第6部分：业务系统：
第7部分：可信服务管理系统；
第8部分：个人信息保护。
本部分为该标准的第5部分。
本部分按照GB/T11-2009给出的规则起草本部分由中国人民银行提出。
本部分由全国金融标准化技术委员会（SAC/TC180）归口。本部分负责起草单位：中国人民银行科技司、中国人民银行金融信息中心、中国金融电子化公司。本部分参加起草单位：北京银联金卡科技有限公司（银行卡检测中心）、中金国盛认证中心、工业和信息化部计算机与微电子发展研究中心（中国软件评测中心），上海市信息安全测评认证中心、信息产业信息安全测评中心、北京软件产品质量检测检验中心、中钞信用卡产业发展有限公司、上海华虹集成电路有限责任公司、上海复旦微电子股份有限公司、东信和平智能卡股份有限公司、大唐微电子技术有限公司、武汉天喻信息产业股份有限公司、恩智浦半导体有限公司。本部分主要起草人：李晓枫、陆书春、潘润红、杜宁、李兴锋、张雯华、刘力慷、刘志刚、聂丽琴、李晓、尚可、郭栋、熊文韬、宋、宏达、王冠华、胡一鸣、张晓、平庆瑞、张志茂、陈君、彭美玲、李微、陈吉、程恒。
JR/T0098.5—2012
随着移动支付新业务、新产品、新管理模式的不断涌现，以客户需求为主导的移动支付业务出现了不断交融和细化的趋势，不同机构、不同部门、不同业务之间的信息交换和信息共享变得越来越频繁。SE作为移动支付客户端安全部件，负责对交易关键数据进行安全存储和运算，SE联入式软件的安全直接影响到移动支付系统的安全性。标准本部分针对SE嵌入式软件安全功能及安全保证要求提出通用性检测指导，并对SE的多应用平台安全特性提供参考用检测案例。前者供SE嵌入式软件评估与检测单位参考，后者供SE嵌入式软件设计、制造单位进行产品设计生产参考-iiKacaQiaikAca=
1范围
中国金融移动支付检测规范
JR/T0098.5—2012
第5部分：安全单元（SE）嵌入式软件安全由于移动支付对多应用的支持，SE嵌入式软件需考实现多应用平台以支持SE内容动态管理。相应地，SE嵌入式软件安全包括：SE多应用平台安全和SE应用安全。此外，由于移动支付SE需配合实现不同的移动支付商业模式，其平台软件应实现移动支付所需的特定基本服务、辅助安全域设置、安全通道协议等。
本部分规范的第6章旨在针对移动支付SE嵌入式软件安全功能及安全保证要求提出通用性检测指导；第7章针对SE多应用平台安全特性设计了相关的检测案例；第8章根据针对SE的特定配置需求，给出相关的规格符合性测试指导，SE多应用平台软件与上层应用无关，多应用平台安全用以保障SE多应用管理相关的安全属性，其安全检测应参照标准本部分的SE多应用平台安全检测规范：SE应用包括金融支付应用和非金融支付应用，其安全检测需根据标准本部分的第6章，配合具体业务功能进行制定：移动支付SE定制规范涉及的内容因影响到移动支付SE的安全性及联网通用性应参照标准本部分的移动支付SE规格符合性检测规范进行相应的检测。
本部分的使用对象主要为从事SE嵌入式软件设计、制造、评估与检测单位。SE的发行机构也可参考本部分以获得对移动支付SE产品安全风险的进一步工解，以协助产品选型和风险控制过程2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T18336信息技术安全技术信息技术安全性评估准则JR/T0025.12中国金融集成电路（IC）卡规范第12部分：非接触式IC卡支付规范JR/T0097-2012中国金融移动支付可信服务管理技术规范JR/T0089.2-2012中国金融移动支付安全单元第2部分：多应用管理规范3术语和定义
下列术语和定义适用于本文件。3.1
持卡者验证方法cardholder verificationmethod（CVM)）用于确保当前持卡者即合法持卡者的方法。3.2
授权管理者 controlling authority借助强制性的数据鉴别模式的确认，拥有对SE内容进行管理控制权限的角色。JR/T0098.5—2012
DAP数据块DAPblock
如载文件中用于对加载文件数据块进行可信性验证的部分3.4
DAP验证 DAP verification
安全域对加载文件的可信性进行验证的机制。3.5
委托管理delegatedmanagement
由认证后的应用提供方来执行的、预先授权的对SE内容进行改变的行动，3.6
可执行加载文件executable loadfile实际存在于SE上的包含一个或多个应用的可执行代码（可执行模块）的容器，它既可以保存在只读内存中，也可以作为加载文件数据块快的映像在可变内存中生成3.7
可执行模块executablemodule
可执行加载文件中包含一个单独应用的可执行代码：3.8
internal communication channel内部通信信道
TOE各分离部分间的通信信道。
internal TOE transfer
TOE内部传送
在TOE各分离部分之间交换数据
TSF间传送inter-TSFtransfer
在TOE与其它可信IT产品的安全功能之间交换数据。3.11
发行者安全域issuersecuritydomain（IsD）负责对SE管理者（通常是SE发行方）的管理，安全，通信需求进行支持的SE上首要实体3.12
生命周期状态 life cycle stateSE或SE内容在生命周期中的某个特定状态。3.13
加载文件loadfile
rKacadiaiKAca
JR/T0098.5—2012
传送加载到多应用SE上的某种文件，包含了加载文件数据块以及一个或者多个DAP数据块（DAPBlock）
消息鉴别码messageauthentication code(MAC)经由对称加密转换得到的数据码，用于确保原始数据来源的合法性和数据自身的一致性。3.15
平台环境OPEN
拥有平台注册表的SE上的核心管理实体。OPEN的主要职能包括：向应用提供APL命令转发，应用选择，逻辑通道管理以及SE内容管理。3.16
组织安全策略organizational security policies一个组织为其运转而强制推行的一个或多个安全规则、过程、规范和指南。3.17
个人化personalization
SE发行者职责的最后流程，通过该流程配置SE、装载安全参数和设置密钥。个人化流程结束后SE就可以完全操作并可发到最终用户手中。3.18
平台platform
芯片上操作系统、运行时环境和平台软件的总称、3.19
预个人化数据pre-personalizationdata所有由软件开发者提供并由IC制造方存放至非易失性存储器里的数据3.20
收条receipt
SE根据SE发行方要求出具的一个加密值，用来作为一个委托管理操作已经执行的证据。3.21
recognitiondata
识别数据
由SE制造方定义并在SE生命周期的制造和测试阶段存放于非易失性存储器的数据，用于追溯使用。3.22
runtimeenvironment
运行时环境
为SE上的多应用操作提供安全运行环境的核心功能，它是SE管理器的一个补充。3.23
安全属性
securityattribute
JR/T0098.5—2012
用于执行TSP的，主体、用户，客体、信息或资源的特征。3.24
安全通道 secure channel
为SE外部实体和SE之间的信息交换提供某种安全保障的通信机制，3.25
安全通道协议
secure channel protocol
安全通信协议和相关安全服务的统称3.26
安全通道会话secure channelsession应用会话期间建立的一种特殊会话。开始于安全通道的初始化，结束于安全通道的终结或者应用会话或SE会话的终结。
安全域security domain（SD)
负责对某个SE外部实体（例如SE发行方、应用提供方、授权管理者）的管理、安全：通信需求进行支持的SE内部实体。
安全功能（SF）securityfunction（SF）为执行TSP中一组紧密相关的规则子集而必须依赖的TOE的一个或多个部分。3.29
安全功能策略(SFP)
)segurityfunctionpolicy(SFP）由一个SF执行的安全策略。
SE管理器SEmanager
负责对SE及SE上资源进行管理的SE嵌入式软件组件的统称，包括：平台环境，发行者安全域、持卡者验证方法服务提供方等等。
安全目的 security objective
意在对抗特定的威胁或满足特定的组织安全策略和假设的一种陈述。3.32
安全要求securityrequirements安全要求包括安全功能要求SFR(SecurityFunctionalRequirements）和安全保证要求SAR(SecurityAssuranceRequirements)。
rKacadiaiKAca-
安全目标（ST）securitytarget（ST)）作为一个既定TOE的评估基础使用的一组安全要求和规范3.34
辅助安全域
supplementary securitydomain(SSD)发行者安全域之外的其它安全域。3.35
评估对象（TOE）
target of evaluation (TOE)
作为评估主体的一个IT产品或系统以及相关的指导性文档。3.36
TOE安全功能（TSF）
TOE security function (TSF)
正确执行TSP所必须依赖的所有TOE硬件、软件和固件的集合3.37
TOE安全功能接口（TSFI）TOEsecurityfunctioninterface（TSFI）JR/T0098.5—2012
一组接口：不管是交互式（人机接口）的，还是编程式（应用编程接口）的，TSF通过这些接口访问调配TOE资源，或者通过它们从TSF中获取信息。3.38
)TOE securitypolicy(TSP)
TOE安全策略（TSP）
规定在一个TOE中如何管理，保护和分配资产的一组规则。3.39
型 TOE security policy modelTOE安全策略模型
TOE所执行的安全策略的一种结构化表示3.40
令牌token
SE发行方出具的一个加密值，用来作为一个委托管理操作已经被授权进行的证据3.41
送transfers outsideTSFcontrolTSF控制外传送
与不受TSF控制的实体交换数据。3.42
可信信道
trusted channel
种手段，通过该手段一个TSF能同远程的一个可信IT产品进行具有必要的信任的通信以支持TSP3.43
trusted path
可信路径
JR/T0098.5—2012
一种手段，通过该手段一个用户能同一个TSF进行具有必要信任的通信以支持TSP。3.44
TSF数据
TSFdata
可能会影响TOE操作的、TOE产生的或为TOE产生的数据。3.45
TSF控制范围(TSC)
TSFseopeofcontrol(TSC)
可与TOE或在TOE中发生的，并服从TSP规则的交互的集合。4缩略语
以下符号和缩略语适用于本部分。cC
测试条件
Common Criteria
EvaluationAssuranceLevel
Information Technology
Protection Profile
Security Assurance RequirementsSecurityFunction
Security Function Policy
SecurityFunctionalRequirementsStrength of Function
Security Target
Target of Evaluation
TSF Scope of Control
TOE SecurityFunctions
TSFInterface
TOE SecurityPolicy
通用准则
评估保证级
信息技术
保护轮摩
安全保证要求
安全功能
安全功能策略
安全功能要求
功能强度
安全目标
评估对象
TSF控制范围
TOE安全功能
TSF接口
TOE安全策略
默认环境条件（温度、湿度等）是指常温20士3~℃，相对湿度在20%-80%RH之间。如无特殊说明，后续案例均采用此环境条件。
6SE嵌入式软件安全检测
6.1嵌入式软件安全概述
根据GB/T18336相关内容，移动支付SE嵌入式软件简满足的安全功能要求及安全保证要求见规范性附录A.1。
6.2SE嵌入式软件安全检测
6.2.1安全功能检测
rKacadiaiKAca-bZxz.net
6.2.1:1FAU类：安全审计
6.2.1.1.1安全告警（FAU_ARP.1）检测目的：验证SE具备安全告警功能。JR/T0098.52012
测试过程：审查厂商提交的文档，验证商已声明SE具备安全告警功能。模拟潜在的安全侵害如改变工作电压、扰乱时钟频率以及穷举PIN等，验证当检测到侵害时TSF应采取动作作为响应，防止安全侵害。
通过标准：当检测到可能的安全侵害时，TSF采取相应的动作作出响应，防止安全侵害。6.2.1.1:2审计列表生成（FAUGEN.1）检测目的：验证SE具备审计列表生成功能。测试过程：审查厂商提交的文档，验证厂商已声明SE具备审计列表生成功能。模拟审计事件，便SE生成审计记录，然后读出生成的审计记录，验证结果是否包含必要的信息。通过标准：安全功能应能为下述可审计事件生成审计记录：在评估对象初始化操作、其它专门定义的可审计事件审计级别之内的所有可审计事件。如：安全功能在初始化操作中记录的审计记录，包括：
a)IC制造日期和序列号；
b)操作软件标识和发布日期。
6.2.1.1.3潜在侵害分析（FAUSAA.1）检测目的：验证SE具备依据规则触发审计事件的能力测试过程：审查厂商提交的文档，验证商已声明SE依据规则触发审计事件。模拟各种审计事件触发条件，验证SE是否依据规则触发审计事件。通过标准：安全功能支持用预定的一系列规则去监控审计事件，并根据这些规则指示出对安全策略的潜在侵害。
6.2.1.1:4：可选择的审计（FAU_SEL1）检测目的：验证SE具备删除或添加审计规则的能力。测试过程：审查厂商提交的文档，验证广商已声明依据特定属性删除或添加的审计规则。尝试头SE添加或删除审计规则，审计规则的修改依据特定的属性进行通过标准：安全功能可以根据以下属性包括或从以下一套被审计事件中排除可审计事件：客体身份、用户身份、主体身份、主机身份、事件类型。6.2.1.1.5受保护的审计踪迹存储（FAU_STG.1）检测目的：验证SE具备保护审计记录的能力。测试过程：审查厂商提交的文档，验证厂商已声明为审计记录提供适当的权限保护：对SE内存储的审计记录进行读取、修改和删除操作，验证SE为审计记录提供的权限保护有效。通过标准：安全功能可保护所存储的审计记录，避免未授权的删除和修改，6.2.1.1.6在审计数据可能丢失情况下的行为（FAUSTG.3）检测目的：验证在审计记录超限时，SE能确保交易完整性。测试过程：审查厂商提交的文档，验证厂商已声明在审计记录超限时，SE能确保交易的完整性。模拟审计记录超限的情景，如审计区溢出等，验证SE提供适当的控制措施，以保证交JR/T 0098.5—2012
易的完整性。
通过标准：如果审计踪迹超过预定的限制，安全功能采取相应的行为，确保交易的完整性。6.2.1.2FCS类：加密支持
6.2.1.2.1密钥生成（FCS_CKM.1)检测自的：验证SE密钥生成算法和长度符合安全要求。测试过程：审查厂商提交的文档，验证厂商声明的密钥生成算法和长度符合安全要求。执行SE的密钥生成功能，验证密钥生成的算法和长度是否与厂商声明一致，并且符合安全要求，通过标准：安全功能将根据符合相关标准的特定密钥生成算法和特定密钥长度来产生密钥。6.2.1.2.2密钥分发（FCSCKM.2）检测目的：验证SE的密钥分发方式符合要求。测试过程：审查厂商提交的文档，验证厂商已声明SE的密钥分发方式符合要求。执行密钥分发命令，尝试分发密钥，验证SE的密钥分发方式与厂商声明一致，只允许按照规定的安全方式进行分发
通过标准：安全功能将根据符合相关标准的特定密钥分发方法来分发密钥。6.2.1.2.3密钥访问（FCS_CKM.3）检测自的：验证SE的密钥访问方式符合要求测试过程：审查厂商提交的文档，验证厂商声明SE的密钥访问方式符合要求。执行可能的读写命令，尝试访间SE内存在的密钥，验证SE的密钥访间方式与厂商声明一致，只允许通过适当的方式访间
通过标准：只有在核心模块的控制下才能读到并还原密钥，不能将密钥送到密码运算单元之外的任何地方。
6.2.1.2.4密码运算（FCS_COP,1)检测目的：验证SE离码算法符合要求并具有正确性测试过程：审查厂商提交的文档，验证厂商已声明SE密码算法符合要求。执行密码算法相关的命令，将输出结果与期望结果比较，验证SE的密码算法是否符合要求。通过标准：SE的密码算法符合相关要求，输出结果与期望值一致。6.2.1.2.5密钥销毁（FCS_CKM.4）检测具的：验证SE密钥销毁机制的有效性测试过程：审查厂商提交的文档，验证厂商已声明SE密码销毁安全功能。执行密钥销毁操作，验证已安全销毁不再需要的密钥，不会有敏感信息泄露。通过标准：安全功能可根据符合相关标准的一个特定的密钥销毁方法来销毁密钥，已销毁密钥信息不可获得。
6.2.1.3FCO类：通信
6.2.1.3.1强制性原发证明（FCO_NRO.2）检测目的：强制性原发证明机制的有效性测试过程：审查厂商提交的文档，验证厂商已声明实现强制性原发性证明机制。执行信息传送，验8
iiKacaQiaiKAca-
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。