JR-T 0156-2017 移动终端支付可信环境技术规范.pdf
- 文档编号:14660824
- 上传时间:2023-06-25
- 格式:PDF
- 页数:42
- 大小:1.13MB
JR-T 0156-2017 移动终端支付可信环境技术规范.pdf
《JR-T 0156-2017 移动终端支付可信环境技术规范.pdf》由会员分享,可在线阅读,更多相关《JR-T 0156-2017 移动终端支付可信环境技术规范.pdf(42页珍藏版)》请在冰点文库上搜索。
ICS35.240.40A11中华人民共和国金融行业标准JR/T01562017移动终端支付可信环境技术规范Mobileterminalpaymenttrustedenvironmentspecification2017-12-11发布2017-12-11实施中国人民银行发布JR/T01562017I目次前言.III引言.IV1范围.12规范性引用文件.13术语和定义.14缩略语.25移动终端支付可信环境概述.25.1整体框架.25.2REE.35.3TEE.35.4SE.35.5外部设备.36可信执行环境.36.1概述.36.2可信OS.56.3安全启动.56.4安全存储.56.5加解密服务.66.6密钥体系.66.7访问控制.86.8TUI.96.9TA应用管理.106.10TA跨平台应用中间件(可选).106.11可信虚拟化(可选).127通信要求.147.1REE与TEE的通信要求.147.2TEE与数据采集设备的通信安全.147.3TEE与SE的通信安全.148数据安全.158.1数据安全保护功能.158.2内部数据安全要求.159安全单元.1610客户端支付应用.16JR/T01562017II10.1概述.1610.2TEE外部接口安全性要求.1610.3其他要求.1711外部设备.1711.1安全目标.1711.2安全要求.1712移动终端支付可信环境生产要求.1812.1概述.1812.2管理要求.1812.3网络要求.1812.4机房及系统要求.1812.5密钥管理要求.1912.6硬件加密设备要求.1913移动终端支付可信环境安全分级分类.1913.1安全能力级别总则.1913.2REE基础安全能力要求集合.2013.3TEE安全能力要求集合.2013.4SE安全能力要求集合.21附录A(规范性附录)检测规范.22附录B(规范性附录)检测规范扩展部分.33附录C(资料性附录)手机银行应用场景.35JR/T01562017III前言本标准按照GB/T1.12009给出的规则起草。
本标准由中国人民银行科技司提出。
本标准由全国金融标准化技术委员会(SAC/TC180)归口。
本标准负责起草单位:
中国人民银行科技司、中国金融电子化公司。
本标准参加起草单位:
北京移动金融产业联盟、华为技术有限公司、中国人民银行广州分行、中国人民银行西安分行、中国银联、中国工商银行、中国农业银行、中国银行、中国建设银行、交通银行、支付宝(中国)网络技术有限公司、财付通支付科技有限公司、北京中金国盛认证有限公司、中金金融认证中心有限公司、银行卡检测中心、中钞信用卡产业发展有限公司、北京握奇数据股份有限公司、恒宝股份有限公司、展讯通信有限公司、北京中清怡和科技有限公司、北京小米科技有限责任公司、北京飞天诚信科技有限公司、北京豆荚科技有限公司。
本标准主要起草人:
李伟、李兴锋、邬向阳、杨倩、聂丽琴、班廷伦、黄本涛、王禄禄、魏博锴、陈卫东、吴一兵、李承康、胡沐创、薛高、魏猛、胡达川、王小璞、常新苗、郭伟、谭颖、周思捷、吴永强、曾凯、安思宇、刘春彤、骆雄武、朱大磊、左爵希、何伟明、杜亮、辛业、辛知、叶轩、种衍雪、王兆国、付小康、张健、熊帅、王鑫、李欧、汪小八、郭丽娟、石玉平、赵李明、刘觅、刘航、常莹、金光日、刘立军、朱鹏飞、张志坚、韩鹏。
JR/T01562017IV引言随着移动智能终端的普及和移动互联网快速发展,用户对移动金融接受程度和使用频率逐步提高,移动金融安全性如何得到有效保障成为有待解决的重要问题。
推进移动终端支付可信环境相关标准制定有助于提升移动终端支付环境安全、推动金融与信息技术融合发展,对于行业健康持续发展及防范电信欺诈有着重要的指导意义。
JR/T015620171移动终端支付可信环境技术规范1范围本标准规定了移动终端支付领域可信环境的整体框架、可信执行环境、通信安全、数据安全、客户端支付应用等主要内容。
本标准适用于开展移动支付相关业务时对移动终端可信环境提出相关技术要求,也适用于移动终端支付可信环境的设计、开发、测试以及相关产品的评价等,智能POS终端可参照执行。
2规范性引用文件下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件,仅所注日期的版本适用于本文件。
凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
GB/T32915信息安全技术二元序列随机性检测方法JR/T0089.2中国金融移动支付安全单元第2部分:
多应用管理规范JR/T0092中国金融移动支付客户端技术规范JR/T0098.3中国金融移动支付检测规范第3部分:
客户端软件JR/T0098.5中国金融移动支付检测规范第5部分:
安全单元(SE)嵌入式软件安全3术语和定义下列术语和定义适用于本文件。
3.1可信环境trustedenvironment个人移动终端上基于硬件和软件结合的安全技术,为移动支付相关业务提供的运行环境。
3.2移动终端mobileterminal具有移动通讯能力的终端设备,通常指智能手机、平板电脑等。
3.3回放保护分区(RPMB)replayprotectedmemoryblock一种可防回滚、防重放攻击的安全存储区,该区域除指定RPMB服务接口外不应通过其他方式访问。
3.4可信OStrustedoperatingsystem一个受可信硬件资源隔离保护的操作系统,该系统可为上层应用提供安全存储、加解密、生物特征识别等多种基础安全服务。
JR/T0156201723.5可信用户接口(TUI)trusteduserinterfaceTEE为TA提供的与用户输入/输出设备安全交互的界面,保证TA与用户交互的敏感数据免受其他应用或恶意软件的攻击。
4缩略语下列缩略语适用于本文件。
eSE嵌入式安全单元(embeddedSecureElement)inSE内置安全单元(integratedSecureElement)OTA空中下载技术(Over-the-Air)RBG随机比特生成器(RandomBitGenerator)REE富执行环境(RichExecutionEnvironment)TA可信应用(TrustedApplication)TEE可信执行环境(TrustedExecutionEnvironment)TSM可信服务管理(TrustedServiceManagement)TUI可信用户接口(TrustedUserInterface)5移动终端支付可信环境概述5.1整体框架移动终端支付可信环境框架如图1所示,一般包括REE、TEE与SE三部分应用运行环境,并共存于同一个终端上。
根据终端提供的硬件隔离机制,分别为REE、TEE与SE提供各自所属的硬件资源,包括CPU、RAM、ROM、FLASH、总线接口与I/O控制器等,并基于所属硬件资源分别控制各自所属外部设备,如触摸屏幕、键盘、摄像头、NFC、指纹、虹膜设备等。
移动终端支付可信环境检测要求见附录A、附录B。
移动操作系统(如Android、iOS)REE可信OSTEE卡片操作系统SE应用软件层系统软件层硬件层支付应用可信虚拟化层钱包应用其他应用认证TA支付TA其他TAPBOC应用公交应用其他应用CPURAMROMFLASH总线I/O控制器外部设备屏幕键盘摄像头NFC指纹虹膜图1移动终端支付可信环境框架示意图JR/T015620173通过业务使用场景不同,REE、TEE与SE在软件上各成相对独立的体系,从功能上,REE、TEE、SE逐级降低;从安全上,REE、TEE、SE逐级提高。
通过REE、TEE、SE三者之间的可控相互访问机制,为移动终端支付提供功能与安全上的全方位服务体系。
5.2REE移动终端上直接面向用户提供支付、通信、娱乐、游戏、社交等各种各样功能的富执行环境,总体目标是以服务用户为主,注重便利、开放、功能强大的用户体验。
其组成主要包括:
应用软件层:
包括各类应用,如手机银行、手机钱包等;系统软件层:
移动操作系统,提供摄像头、FLASH、USB、触摸屏、蓝牙等相关驱动程序,并基于此向上提供一整套的系统服务、应用服务与管理框架,方便各种类型应用的开发与部署,其中对于支持TEE的终端,应提供访问TEE的通信驱动和TEE外部API,支持其上运行的应用访问TEE应用。
5.3TEE与REE相隔离的安全区域,通过一组硬件和软件的组合,保证各种敏感数据在其中被安全传输、存储、处理,保证TA执行的机密性、完整性和数据访问权限端到端的安全。
TEE的实现可以基于不同的技术,其组成主要包括:
应用软件层:
包括各种安全相关的可信应用,一般与对应REE应用相结合,为用户提供既便捷又安全的用户体验,可信应用以机构部署为主,如指纹、支付、身份认证等应用;系统软件层:
充分利用硬件资源(如CPU、RAM、FLASH、SPI总线等)的可信性,实现受硬件隔离的系统执行环境,具备安全计算及其所属各种安全设备运行的资源调用能力,可提供下述功能:
安全加解密、安全存储、可信用户接口、可信身份认证等各种系统服务;系统和应用安全的密钥体系;与REE、SE、外部设备的安全通信机制,并提供相应的访问控制;提供可信虚拟化层,可支撑多个可信OS并存与运行。
5.4SE移动终端上的高安全运行环境,可在硬件与软件层面上防御各种恶意攻击,运行在其上的应用具备高安全性需求,如eSE、inSE。
其组成主要包括:
应用软件层:
包括安全应用,如金融、公交、社保、电信等,应用采用预置或在TSM控制下安全获取与部署,通过SE开展金融安全的应用场景可参考附录C;系统软件层:
运行一种可验证的卡片操作系统,主要提供安全加解密、密钥存储等功能。
5.5外部设备可以被TEE控制和使用,用于扩展TEE功能的移动终端元器件,包括但不限于触摸屏、摄像头、指纹模块、蓝牙模块、NFC芯片等。
从安全角度考虑,外部设备可划分为专享外设和共享外设。
6可信执行环境6.1概述6.1.1总体架构JR/T015620174可信执行环境总体架构见图2。
图2可信执行环境总体架构图6.1.2安全目标可信执行环境的安全目标如表1所示:
表1可信执行环境安全目标及描述安全目标描述安全目标描述启动安全安全启动从可信代码开始,通过签名校验方法来保证信任链的传递,TEE启动过程的完整性通过上一阶段签名校验来保证。
存储安全通过硬件的隔离和系统的控制,保护高安全性数据的存储安全,如用户数据、设备数据等。
通信安全通过加密、隔离、认证等方式,对终端内不同实体间的通信通道、终端同外界的通信通道的数据传输进行安全性保护。
访问控制通过访问权限的设置等方式保证功能和数据不被非法访问或者不恰当的访问。
系统配置通过软硬件结合的安全措施保证终端的安全配置不被更改并具备相应的提示机制。
运行安全通过对固件、密钥、永久数据等数据的保护策略保证TEE自身的安全性,为运行在其上的可信应用提供安全保护。
应用管理通过生命周期管理、访问验证等措施保证对运行在其上的可信应用进行安全管理。
6.1.3硬件安全要求JR/T0156201756.1.3.1防止物理攻击TEE应具有一定的防物理攻击能力,物理攻击方式包括但不限于非侵入式攻击、半侵入式攻击,如旁路攻击、错误注入攻击等。
6.1.3.2安全调试应对设备调试接口进行相应的管控,只能通过授权控制的模式对内部敏感数据进行访问。
6.2可信OS6.2.1可信OS内核组成提供了OS基本核心功能,包括进程调度管理、时间管理、进程间通信管理、中断管理、内存管理、外设驱动管理等。
提供了OS的系统级功能,包括用户态和内核态的可操作性定义、系统调用访问控制和权限管理、可信应用隔离和管理等。
6.2.2可信OS基础服务提供系统级的安全服务,见表2。
表2可信OS基础服务服务名称功能简述服务名称功能简述安全存储提供基于文件操作的存储功能及接口,包含文件创建、打开、关闭、写入、读取、删除、重命名等。
加解密提供密码算法功能及接口,包含摘要算法、信息验证码算法、对称加解密算法、非对称加解密算法、随机数算法、密钥衍生等。
安全时间提供获取TEE系统时间和REE系统时间等时钟接口。
TA管理提供TA的下载、安装、更新、删除等功能。
SE服务提供与SE之间的操作及相关通讯接口。
生物特征识别提供生物特征提取、模板存储和比对,以及针对比对结果的访问控制等功能。
REE监测提供对REE安全性的监测。
TUI提供可信的用户交互接口。
6.3安全启动安全启动过程是指通过签名验证方法来检验TEE启动过程的每一个阶段,以确保TEE中运行软件镜像的完整性,防止对软件进行未被授权修改或恶意修改。
安全启动代码应进行完整性验证,当验证通过后执行安全启动过程。
安全启动过程保证了TEE的安全功能被正确地初始化,并且这个初始化过程不受REE恶意应用的攻击,同时保证固件的版本符合TEE版本更新策略。
同时,安全启动也伴随着一个信任链,即整个过程开始于一个可信代码(即这个代码的完整性受到保障)或者信任根,之后在执行其他代码之前都要验证其真实性。
对于在安全启动过程中哪些代码需要被验证本部分不做具体定义。
安全启动的代码可以通过OTA以代码镜像的方式进行更新。
为了保证代码更新的安全性,在更新代码之前应验证更新镜像的真实性和完整性。
6.4安全存储JR/T0156201766.4.1功能要求TEE应提供安全存储功能,例如将数据存储在安全存储器中,或对数据进行加密存储。
安全存储应提供以下基本功能:
创建、打开、关闭、写入、读取、删除、重命名等。
6.4.2安全要求安全存储应满足如下安全要求:
保证所保存数据的机密性、可用性、一致性和原子性;数据只能由数据管理者访问;安全存储所使用密钥应由根密钥衍生;保证安全存储所使用密钥的机密性和完整性;安全存储所使用密钥只能由密钥管理者访问和处理。
6.5加解密服务6.5.1功能要求加解密服务提供密码算法接口,使得应用可以通过该服务接口执行密码运算。
密码运算应符合6.6.1.10的要求。
6.5.2安全要求加解密服务应符合表3所示的要求。
表3加解密算法安全要求算法算法安全要求安全要求摘要算法应使用SHA256及以上强度算法。
对称密码算法AES算法的密钥长度应为128bit及以上。
3DES算法的密钥长度应为128bit及以上。
非对称密码算法RSA算法的密钥长度应为2048bit及以上。
椭圆曲线算法的密钥长度应为224bit及以上。
DSA算法的密钥长度应为2048bit及以上。
ECDSA算法的密钥长度应为224bit及以上。
随机数生成器应符合GB/T32915规范的规定。
6.6密钥体系6.6.1密钥管理6.6.1.1概述密钥包括根密钥、设备密钥、业务密钥。
密钥生命周期的管理包括密钥生成、使用和销毁。
6.6.1.2随机数生成随机数生成方式,应遵循GB/T32915中的相关规定。
6.6.1.3密钥生成JR/T015620177TEE应根据指定的密钥算法生成对称密钥和非对称密钥。
被生成的业务密钥包括:
用于保护数据的数据加密密钥和用于保护其他密钥的密钥加密密钥。
6.6.1.4密钥导入通过安全方式导入到TEE安全存储区域中的密钥,应使用密钥加密密钥进行保护。
6.6.1.5根密钥根密钥是移动终端密钥体系的根,应符合以下要求:
根密钥应使用硬件保护或硬件隔离技术保证安全性;硬件隔离的根密钥产生因子只可由独立的处理器运算生成;硬件保护的根密钥产生因子不可被任何软件访问,由通用处理器运算生成并进行扰乱保护;硬件隔离和硬件保护的根密钥应和REE隔离,不可被REE直接访问;根密钥不可直接从硬件中读和写;只有具备系统权限的可信应用可使用根密钥衍生出其他密钥。
6.6.1.6设备密钥及设备身份证书设备密钥应符合以下要求:
应由根密钥在TEE中产生,或者随机生成后以密文形式注入设备的安全存储区域;可用于保护业务密钥,保证信任链的传递;可用于设备身份证明。
设备身份证书应符合以下要求:
应在TEE或SE中产生,或者在出厂前预置;应保存在TEE或者SE环境中;可用于设备身份证明。
6.6.1.7数据加密密钥数据加密密钥长度应至少保证128bit。
数据加密密钥应使用RBG方法随机生成,密钥的强度应至少等同于128bit的AES密钥强度。
6.6.1.8密钥加密密钥密钥加密密钥的长度应至少保证128bit。
强度应不弱于数据加密密钥。
密钥加密密钥宜基于口令的密钥衍生方式生成,或者用RBG方法生成,或者利用其他密钥来组合生成。
6.6.1.9密钥销毁程序运行时产生的明文密钥数据(密钥加密密钥、会话密钥等),在生命周期结束后应进行销毁,清除密钥的目标源和存储位置,销毁所有不再需要的明文密钥材料。
销毁方式分以下几种情况:
对于易失性闪存,销毁应通过单一的用RBG生成的伪随机数或全0直接覆写,并随后进行一次读验证;对于非易失性EEPROM(电可擦只读存储器),销毁应通过单一的用RBG生成的伪随机数直接覆写,并随后进行一次读验证;对于其他非易失性闪存,销毁应通过单一的用全0直接覆写,或一个块擦除,并随后进行一次JR/T015620178读验证;对于除了闪存和EEPROM的非易失性存储器,销毁应通过三次或更多次覆写,每次用不同的随机数。
6.6.1.10密码算法应支持国家密码管理机构认可的商用密码算法。
6.6.2密钥存储6.6.2.1密钥可用性TEE应为设备密钥和业务密钥提供安全存储能力,防止未经授权的应用对密钥访问。
6.6.2.2密钥保密性功能要求:
TEE应保护密钥的安全性,密钥不应明文存储。
一般安全要求:
密钥加密存储在TEE的安全存储区域内。
增强安全要求:
密钥加密存储在RPMB区域或者SE中。
6.6.2.3密钥完整性TEE应为所有的数据加密密钥和密钥加密密钥提供完整性保护。
6.7访问控制6.7.1概述访问控制包括以下三种类型:
TA对客户端应用的访问控制:
即限制未被授权的客户端应用访问TA;TA间的访问控制:
即限制未被授权的TA访问其他TA;TEE基础服务的访问控制:
即限制未被授权的TA使用基础服务。
6.7.2功能要求访问控制对TEE的功能要求如下:
TEE应维护一组访问规则,当某个客户端应用访问运行在TEE上的某个TA时,TEE应根据这些访问规则来判断本次访问是否被允许;TA应维护一组访问规则,当被其他TA访问时,被访问的TA可根据这些访问规则来判断本次访问是否被允许;TEE应维护一组基础服务访问规则,当某个TA调用基础服务时,TEE应根据这些访问规则来判断本次调用是否被允许。
6.7.3安全要求6.7.3.1TA对客户端应用的访问控制访问控制要求如下:
TEE应能识别运行于REE之上的各个客户端应用,并获得客户端应用的标识;TEE应保证访问控制规则的机密性和完整性;TEE应能处理访问控制规则发生冲突的情况;JR/T015620179访问控制规则导入移动终端的过程应是安全可信的。
6.7.3.2TA间的访问控制安全要求如下:
TEE应提供接口,使被访问的TA能够获得访问TA的标识;TEE应保证TA的标识在同一个终端上是唯一的、不可伪造的。
6.7.3.3TEE基础服务的访问控制对TEE的安全要求如下:
TEE应对SE访问基础服务实施访问控制;TEE应对生物特征采集设备的基础服务实施访问控制;访问控制规则导入移动终端的过程应是安全可信的。
6.8TUI6.8.1功能要求一般情况下,用户安全交互涉及的输出要求包括:
显示文本、图像等;进行LED、声音等指示。
输入要求:
接受键盘输入信息;接受触摸屏输入信息;接受生物识别信息,例如指纹等。
为满足如上用户交互的要求,TUI会调用移动终端上的相关部件来进行用户交互,这些部件包括但不限于移动终端上的话筒、键盘、触摸屏、LED指示灯、指纹传感器等。
6.8.2安全要求一般要求:
TUI所调用的部件处于工作状态时,不能接收REE的访问请求,并且不能接收通知事件;当相关部件控制权属于TUI时,应由TEE来决定是否将这些部件的控制权交给REE;TUI应包含安全指示器,通过安全指示器呈现的安全指示信息使用户可识别当前显示的是TEE的界面,而不是REE的界面;TEE应为用户提供设置通用安全指示信息的接口,通用安全指示信息可以是文字、图片、声音等,通用安全指示信息可被TEE中所有TA访问;在用户进行通用安全指示信息设置时,TEE应首先判断终端当前是否处于安全状态,处于安全状态,才允许执行配置流程,安全状态检测应包括:
检测终端是首次启动;检测终端TEE尚未个人化;检测终端未取得系统中唯一超级用户权限(检测终端未被Root);检测终端未安装来源非法或无法判断来源是否可信的应用。
增强要求:
TEE应为用户提供设置个性化安全指示信息的接口,个性化安全指示信息只可以被TEE中特定的TA访问。
JR/T01562017106.9TA应用管理6.9.1功能要求TA应用管理主要是对TA生命周期进行管理,应包括但不限于安装、更新、锁定、解锁以及卸载,过程应保证原子性。
状态转换应由TA管理服务器触发,或者直接在TEE上触发。
TA安装:
应把TA应用加载到TEE指定的安全存储区,并创建可执行文件。
TA安装可以通过预置或OTA两种方式。
TA更新:
应安装一个新版本的TA应用到原有版本应用的安全存储区,并保留原有版本应用的数据。
TA更新过程可通过OTA方式实现。
TA锁定(可选):
应将TA的生命周期状态更新到锁定状态,在这种状态下TA无法使用,也不能被管理,直到其被解除锁定状态为止。
TA解锁(可选):
应将TA的生命周期状态更新到锁定状态以外其他活动状态,在这种状态下TA应用正常运行。
TA卸载:
应将指定TA从TEE的可操作应用列表中移除,并且释放包括TA可执行文件数据在内的所有和TA有关的数据。
6.9.2安全要求TA应用生命周期的配置转换有效提升TA应用和数据操作的安全性,包括安装、更新、锁定和解锁、卸载四个过程。
安装过程安全要求:
预置安装,在TEE启动过程中,TEE应验证TA的完整性、合法性,并安全加载到安全内存中运行;OTA安装,OTA安装应包含下载和安装两个过程,在下载过程中应对应用加密和签名处理以保证TA机密性、完整性和可用性,在安装过程中TEE应验证TA完整性、合法性,并安全加载到安全内存中运行。
更新过程安全要求:
OTA更新,对于包分发模式,应通过客户端应用或REE系统进行更新;对TA独立分发模式,应通过TA管理服务器进行更新;TA更新安全要求应和TA安装安全要求一致。
锁定和解锁过程安全要求:
在TA应用升级更新时,可以将其从正常状态迁移到锁定状态,从而确保应用升级更新时候数据的一致性和完整性,在升级更新完毕后再将其恢复为原始活动状态继续运行;锁定和解锁过程,其状态应是持久状态,确保其不会受到终端断电的影响,并且从其他状态到此状态的迁移也应是原子的,确保TA及其数据状态在状态转换过程中保持一致。
卸载过程安全要求:
应保证不残留任何应用相关的信息,尤其是应用数据等敏感信息。
6.10TA跨平台应用中间件(可选)6.10.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- JR-T 0156-2017 移动终端支付可信环境技术规范 JR 0156 2017 移动 终端 支付 可信 环境 技术规范