信息安全技术智能卡安全技术要求（EAL4+）

信息安全技术智能卡安全技术要求（EAL4+）

国家标准 GB/T36950一2018 信息安全技术 智能卡安全技术要求(E.AL4+ Informationsecurityteehnology一 Seeuritytechmiealrequirementsofsmartcard(EAL4+ 2018-12-28发布 2019-07-01实施 国家市场监督管理总局 发布 币国国家标准化管理委员会国家标准
GB/36950一2018 目 次 前言 引言 范围 2 规范性引用文件 术语和定义 缩略语 5 智能卡描述 5.1总体结构 5.2密码算法 5.3环境 6 安全问题定义 6.1综述 6.2资产 6.3威胁 6.！组织安全策略 6.5假设 安全目的 智能卡安全目的 7.2环境安全目的 安全要求 8.1安全功能要求 8.2安全保障要求 基本原理 19 9.1安全目的基本原理 19 9.2安全要求基本原理 22 参考文献 24
GB/36950一2018 前 言 本标准按照GB/T1.1一2009给出的规则起草 请注意本文件的某些内容可能涉及专利 本文件的发布机构不承担识别这些专利的责任 本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口 本标准起草单位:住房和城乡建设部IC卡应用服务中心、中外建设信息有限责任公司、深圳航信德 诚科技有限公司、深圳市华旭科技开发有限公司、深圳市德卡科技股份有限公司、信息产业信息安全测 评中心、上海华虹集成电路有限责任公司、恩智浦()管理有限公司,英飞凌集成电路(北京)有限公 司、上海复旦微电子集团股份有限公司、中钞信用卡产业发展有限公司、恒宝股份有限公司、捷德( 信息科技有限公司、北京亿速码数据处理有限责任公司、上海浦江智能卡系统有限公司,东信和平科技 股份有限公司、中山达华智能科技股份有限公司、山东华冠智能卡有限公司、天津环球磁卡股份有限公 司福建索天信息科技股份有限公司、北京智芯微电子科技有限公司、卫士通信息产业股份有限公司,福 州数码视讯智能卡有限公司、江西省洪城一卡通投资有限公司 本标准主要起草人:霍珊珊、张永刚,刘健、董晶晶、尚治宇,王冠华、陈超华,股骏、杨敬源,陈勇 王宝鹅,梁少峰,方树平、丁晓明、畅江、黄显明,李岳,段宏阳,黄小鹏、娄亚华、刘振禹、纪鸿殊 王晓雨、 江斌.付青琴、王会波,陈为明、谈素云
GB/T36950一2018 引 言 随着智能卡应用范围的不断扩大,应用环境复杂度也在不断提高,进而要求智能卡具有更强的安全 保护能力 本标准的EAL4十是在EAL4的基础上将AVA_VAN.3增强为AVAVAN.4 IN
GB/36950一2018 信息安全技术 智能卡安全技术要求(EAL4+) 范围 本标准规定了智能卡安全技术要求,包括智能卡描述、安全问题定义、安全目的、安全要求和基本原 理等技术要求 本标准适用于智能卡产品的测试.评估,也可用于该类产品的研制和开发 规范性引用文件 下列文件对于本文件的应用是必不可少的 凡是注日期的引用文件,仅注日期的版本适用于本文 件 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 GB/T18336.1一2015信息技术安全技术信息技术安全评估准则第1部分;简介和一般模型 GB/T18336.2一2015信息技术安全技术信息技术安全评估准则第2部分:安全功能组件 GB/T18336.32015信息技术安全技术信息技术安全评估准则第3部分:安全保障组件 GB/T221862016信息安全技术具有中央处理器的IC卡芯片安全技术要求 术语和定义 GB/T18336.1-2015界定的术语和定义适用于本文件 3.1 集成电路imtegratelcireuit 采用一定工艺;将电阻.电容,晶体管互连,用于执行运算处理或存储功能的电子元器件 3.2 智能卡smartcard 具有中央处理器的集成电路卡 注:从数据传输方式上可分为接触式智能卡和非接触式智能卡 缩略语 下列缩略语适用于本文件 APDU:应用协议数据单元(ApplicationProtocolDataUnit) 芯片操作系统(chipoperatingsystem) COS EAL Assurancelevel 评估保障级(CEiadlation C:集成电路(IntegratedCircuit TOE:评估对象(TargetofEvaluation) TSF:评估对象安全功能(TOESecurityFunetion) USB通用串行总线(UniversalSerialBus)
GB/T36950一2018 5 智能卡描述 5.1总体结构 智能卡总体结构及运行环境,如图1所示 智能卡的安全性包括芯片、嵌人式软件、应用接口三个 层面,芯片安全是物理基础,嵌人式软件安全是充分利用芯片的安全特性,建立完整的安全机制、安全体 系,应用接口安全是运用芯片,嵌人式软件构建的安全机制、安全体系,满足特定应用需求,兼顾安全性 与便利性 在对智能卡的安全性进行考虑时,除了要求其组成部分芯片和COS分别满足相关技术要求 外,还应从整体性上综合考虑安全性和防护措施,以保证整个系统的安全 应用接口1 ----- 应用接口N 通过智能卡终端 使用TOE 智能卡嵌入式软件 用户 通过 能 管理 智能卡芯片支撑嵌入式软件的运行 卡终端 T ToE智能卡 智能卡芯片 管理员 图1 智能卡总体结构 总体结构说明如下 具有中央处理单元的IC卡芯片;包括中央处理单元、随机存取存储器、非易失性存储器、I/0 a 接口(接触式、非接触式或其他类型接口,如USB接口、随机数发生器、密码算法协处理器和 安全防攻击电路(如用于防止物理探测、环境压力威胁的硬件模块 嵌人式软件;管理芯片硬件资源和数据.并实现对应用功能的支持 该软件通常存放在底层芯 b 片硬件的非易失性存储器中,通过芯片的通信接口与智能卡终端设备交换信息,以响应用户发 起的数据加密、数据签名及鉴权认证等应用请求 嵌人式软件由负责处理芯片硬件接口,实现 文件管理,安全管理,通信处理和应用处理等功能的模块组成,其中安全管理模块提供安全配 置、安全事务处理及密码支持等功能,以便为其他模块的安全执行提供支持 应用接口;运用嵌人式软件提供的功能和安全机制,以实现对特定应用功能的支持 5.2密码算法 密码算法可由软件或者硬件实现 智能卡中使用的密码算法和密钥管理应遵循智能卡相关国家标 准、行业标准和国家密码主管部门的规定 5.3环境 智能卡即便暴露在非标准环境,也应能够进人到一种安全的运行状态 环境影响因素包括温度、电 压、频率或外部能量场等 6 安全问题定义 6.1综述 智能卡是硬件与软件的结合体,其安全性应从硬件及软件,应用三个层面上来考虑,也就是从芯片 层面,COs层面和应用层面来综合考虑
GB/36950一2018 6.2资产 6.2.1组成 资产应由ToE直接保护的安全相关的信息或资源组成,可分为由用户创建并使用的用户数据以 及由TOE创建并使用的TOE数据 为保护上述资产,智能卡开发和生产阶段使用的各种信息和工具,也需要保护 需要保护的资产应包括: 智能卡嵌人式软件; aa 智能卡存储和处理的用户数据(例如嵌人式软件所使用的数据); b 智能卡存储和处理的安全功能数据(例如安全属性、鉴别数据、访问控制列表、密钥等 c d 智能卡的逻辑设计信息、物理设计信息; 特定的安全芯片开发辅助工具(例如掩膜数据生成工具) 支持嵌人式软件开发的信息(例如开发资料和开发平台); 与测试和特征有关的数据; g h)初始化数据与预个人化数据; 其他与特定功能有关的重要资产(例如智能卡产生的随机数). 6.2.2用户数据 用户数据应包括 a D.APP_CODE:下载到智能卡内的应用和库的代码,需要受到保护以免遭未经授权的修改; b) D.APP_c_DATA;应用程序的保密性敏感的数据,如对象包含的数据、包的静态字段、当前执 行方法的局部变量、操作数栈的位置,需要受到保护以免遭未经授权的暴露; D.APP_LDATA:应用程序的完整性敏感的数据,如卡号,交易记录、对象包含的数据、包的静 态字段、当前执行方法的局部变量以及操作数栈的位置等,需要受到保护以免遭未经授权的 修改 dD.PIN;任何终端用户的PIN,需要受到保护以免遭未经授权的暴露和修改 D.APP_KEYs;应用拥有的密钥,如充值密钥、消费密钥,需要受到保护以免遭未经授权的暴 e 露和修改; D.ISD_KEYs;发行商主密钥、应用提供商密钥、应用维护密钥等,需要受到保护以免遭未经授 f 权的暴露和修改 6.2.3系统数据 系统数据应包括 D.CARD_MNGT_DATA:智能卡管理数据,如应用的标识符、特权、生命周期状态、存储资源 aa 的限额等,需要受到保护以免遭未经授权的修改 b D.Es_CODE;嵌人式软件框架部分的代码,需要受到保护以免遭未经授权的修改 D.ES_DATA:嵌人式软件执行必要的内部运行时的数据区,如栈帧、程序计数器、对象的类、 为数据分配的长度以及任何用于链接数据结构的指针等,需要受到保护以免遭未经授权的暴 露和修改; d D.SEC_DATA;嵌人式软件运行时安全数据,如用于标识已安装的应用程序、当前选择的应用 程序、每个对象的拥有者以及执行的当前上下文的AID,需要受到保护以免遭未经授权的暴露 和修改 D.APIL_DATA;应用编程接口的私有数据,如私有字段的内容,需要受到保护以免遭未经授权 的暴露和修改;
GB/T36950一2018 D.Es_KEYs;当下载文件到智能卡内时使用的密钥,需要受到保护以免遭未经授权的暴露和 修改; D.CRYPTo;运行时密码计算使用的密码数据,如生成密钥的种子,需要受到保护以免遭未经 g 授权的暴露和修改 6.3威胁 6.3.1智能卡运行相关威胁 6.3.1.1 分类 在智能卡生命周期中,ToE可能会受到各种各样的攻击 他们中有些是无意识的行为,例如在交 易过程中可能出现的一些误操作;有些是蓄意的,例如使用非法智能卡作弊、截取并篡改交易过程中所 交换的信息等行为 根据各种攻击所采用的手段和攻击的对象的不同,智能卡大体存在以下五类威胁: 物理威胁 a b 逻辑威胁; c 与访问控制相关的威胁; d 有关密码功能的威胁; 各种其他威胁 e 6.3.1.2物理威胁 智能卡运行物理威胁如下 a 对智能卡的物理探测(T.P_Probe) 攻击者可能对智能卡实施物理探测,以获取智能卡的设计信息和操作内容 物理探测可能是利用智能卡失效性分析和采用半导体逆向工程技术来从智能卡中获取数据 这种 探测可能包括对电气功能的探测,由于这种探测需要直接接触智能卡内部,所以仍把它归为物理探测 攻击者的目的是获取诸如硬件安全机制访问控制机制、鉴别系统、数据保护系统、存储器分区,以及密 码算法程序等设计细节 弄清软件设计中诸如初始化数据、个人化数据、口令或密钥等也是他们的目 标 智能卡可能会在为上电或已上电状态下受到探测攻击并且在遭受这样的攻击后可能会处于无法操 作状态 b) 对智能卡的物理更改(T.P_Alter) 攻击者可能对智能卡实施物理更改,以获取智能卡的设计信息和操作内容,或者消弱、旁路安全功 能,以及修改安全功能数据,从而非法使用智能卡 对智能卡的更改可能利用智能卡失效性分析或采用半导体逆向工程技术来实现 攻击者的目的是 通过物理更改,识别硬件安全机制,访问控制机制、鉴别系统、数据保护系统、存储器分区,以及密码算法 程序等设计细节;识别软设计中诸如初始化数据、个人化数据、口令或密钥等的位置、状态、运行规律也 是他们的目标 更进一步的目标可以是,通过物理更改,消弱或旁路智能卡中的安全机制以获取受保护的敏感信 息、修改或操纵调试阶段的锁定操作、初次使用标记、卡使用锁定、锁定功能配置、卡锁定标志、卡终止标 志等,以便非法使用、伪造智能卡 6.3.1.3逻辑威胁 智能卡运行逻辑威胁如下 信息泄露(T.INF-LEAK a 攻击者可以利用智能卡使用期间泄露的信息暴露安全功能数据,信息泄露可能是正常操作固有的 或者是由攻击者导致的
GB/36950一2018 功耗、电磁辐射、I/0特性、时钟频率的变化或所需处理时间的变化等都有可能造成信息的泄露 这可理解为一个隐蔽的传输途径(侧信道),实际上与操作参数的测量密切相关 这些泄漏信息攻击者 可通过接触式(如功耗)或非接触式(如电磁辐射和时间变化)的信号测量,得到与正在执行的操作有关 的信息,进而采用信号处理和统计分析等技术获得密钥等敏感信息 b)缺陷插人(T.FlI_Ins) 攻击者可能通过反复地插人选定的数据,并观察相应的输出结果,从而获得智能卡安全功能或用户 相关的信息 这种威胁的特点是有目的选择和控制输人数据,而不是随机选择或控制 通过插人选定的数据并 观察输出结果的变化,是对密码设备的一种常见攻击手段,这种手段也可用于对智能卡的攻击 其目的 是通过观察智能卡如何对选定的输人做出响应来获取与安全功能或用户相关的信息 这种威胁的特点 是有意选择和控制输人数据,而不是随机选择数据或控制输人输出操作中的物理特性 错误输人(T.Inv_Inp 攻击者可能通过引人无效的输人数据来危及智能卡的安全功能数据的安全 错误输人操作形式包括错误的格式.索要的信息超过记录范围,试图找到并执行无正式书面文件的 这样的输人可能在正常使用过程中的任意时间发生,包括访问授权前 命令 其结果是该攻击可能会 危及安全功能,在操作中产生可利用的错误或者泄漏所保护的数据 d)未授权程序装载(T.Ua_L.oad) 攻击者可能利用未授权的程序探测或修改智能卡安全功能代码及数据 每个授权角色都有特定的权限仅用于下载指定的程序 未授权程序可能包括在正常操作期间不希 望执行的合法程序,也可能包括用于有意刺探或修改智能卡安全功能的未授权装载程序 6.3.1.4与访问控制相关的威胁 智能卡运行中与访问控制相关的威胁如下 非法访问(T.Access) a 使用者或攻击者可能在未经信息或资源的拥有者或责任者许可的条件下对信息或资源进行访问 授权角色都有特定的权限来访问智能卡的信息,如果访问超出规定权限,会导致安全相关信息的 暴露 b)使用被禁止的生命周期功能(T.Lc_Ftn 攻击者可能会利用相关命令,尤其是测试和调试命令来获取智能卡安全功能数据或敏感的用户数 据,这些命令在智能卡生命周期的以往某些阶段是必要的.但在现阶段是被禁止的 这些命令在操作执行的特殊阶段是不必要的或被禁止的 例如在操作阶段使用测试命令或调试命 令来显示内存或执行其他功能 6.3.1.5有关密码功能的威胁 智能卡运行有关密码功能的威胁如下 密码攻击(T.Crypt_Atk) aa 攻击者可能实施密码攻击或穷举攻击危及智能卡的安全功能 这种攻击可能用到一些加密函数,编码/解码函数或随机数发生器、攻击者的目标是发现密码算法 中的脆弱性或通过穷举来发现密钥和输人数据 攻击者的目的在于暴露智能卡的安全功能数据从而危 及用户敏感数据的安全 b)随机数的缺陷(T.RND 由于被提供的随机数嫡值的不足,攻击者可以预测或获取在某些情况下借助的智能卡辅助工具所 产生的随机数的信息
GB/T36950一2018 6.3.1.6各种其他威胁 智能卡运行的其他威胁如下 环境压力(T.Envy_Strs) a 攻击者可通过将智能卡暴露在被操纵的环境压力下,来达到向安全功能数据引人错误的目的 将集成电路暴露在超出其使用范围的情况下,将导致其故障或安全临界元素的失败,从而达到允许 操纵程序或数据的目的 这种情况可能是正常参数的极值(高或低)如温度、电压,时钟频率,也可能是 不正常的环境如外部能量场,如激光、电磁射线等 该攻击的目的在于产生一个直接的错误导致智能卡 进人非法工作状态,以一定概率达到非法操纵的目的;或者诱导智能卡产生可用于安全分析如算法分 析)的错误,得到智能卡所保护的敏感信息,从而导致敏感信息泄漏,甚至伪造智能卡 b克隆(T.Clon) 攻击者可能克隆部分或全部智能卡的功能以开发进一步的攻击手段 攻击者可能通过对智能卡本身的详细观察来获取克隆部分或全部智能卡所必需的信息 攻击者通 过开发智能卡的物理模型来实验其不同的功能和处理过程,从而实现进一步的攻击以达到成功暴露安 全功能数据和敏感用户数据的目的 6.3.2智能卡管理相关威胁 智能卡管理的相关威胁如下 智能卡别重放(T.REPlLAY) a) 攻击者通过重新使用授权用户以前完成(或部分完成)的操作可以刺探智能卡的安全 重放已完成或部分完成的操作企图绕过安全机制或暴露安全相关的信息;例如攻击者可以尝试发 送它在先前会话中截获的APDU命令到智能卡;攻击者也可以使用以前传送到他的身份验证信息以暴 露或修改存储在智能卡中被其他应用目前使用的信息;例如攻击者可以利用曾经有效的身份验证信息 但不再有效,如旧的PIN值或密钥 b)暴力搜索(T.BRUTEFORCE) 攻击者可搜寻整个用户可访问的数据空间以便获得TOE的相关敏感数据 可以重复传输调用)APDU命令(API方法)以尝试暴力提取诸如密钥或PIN秘密 重复使用请 求范围有效的命令以暴露尽可能多的数据空间.例如.攻击者可能利用不同形式的输人系统地试验 6.4组织安全策胳 6.4.1密码管理(P.CryptoManagement) 密码的使用应符合国家标准及行业或组织的信息技术安全标准或规范,并符合下列要求 私钥由cOS内部管理,使用cOs文件访问指令不得访问到私钥文件,不应以任何形式读取私 a 钥,私钥在任何时刻都不得以任何形式出现在智能卡外部 b 签名密钥对生成应由COS内部生成,COSs内部不得保留用于生成密钥对的素数 6.42标识数据管理(P.IdDataManaement) 智能卡的生产、测试等过程应具备标识TOE的能力 6.4.3芯片硬件选型(P.ChipSeleetiom ToE采用的芯片应至少满足GB/T221862016中EAL4级相关要求
GB/36950一2018 6.5假设 6.5.1 人员(A.Personne 假设智能卡使用人员遵循一套安全的流程,严格遵照智能卡用户指南及安全建议的要求使用智能 卡的安全规则和安全功能 智能卡开发、测试,生产等各阶段的操作人员均能按安全的流程进行操作 智能卡发卡机构的操作人员均能按安全的流程进行发卡操作 6.5.2外部数据管理(A.outData_anagement 假设在智能卡之外的数据和密钥以一种安全的方式进行管理 关于智能卡设计描述(如芯片结构、设计信息、开发及测试工具、实现代码及相关文档、初始化数 据,个人化数据以及所有者身份等敏感信息将被发行者或其他智能卡之外的数据库存储 由于使用智能卡可能引人外部的密钥,如共享密钥,假设这些密钥的产生,分发、维护和销毁等都是 安全的 ommChannel 6.5.3通信信道(A.Co 假定ToE与智能卡终端之间的通信信道是安全可靠的 典型的实现方式是通过共享密钥、公/私 钥对,或者利用存储的其他密钥来产生会话密钥 假设当这些安全连接建立以后,就可以认为智能卡与 智能卡终端之间的通信信道是足够安全的 由于智能卡终端的安全功能失效造成的攻击不在本标准的 讨论范围 6.5.4应用程序A.App_Prwgram) 假定在ToE中安装应用程序的流程符合规范,且合法安装的应用程序不包含恶意代码 6.5.5电源和时钟(A.Pwr_Cloek) 电源和时钟来自智能卡终端,正常的交易进程中电源和时钟都可能被中断或复位 安全目的 7.1智能卡安全目的 7.1.1标识数据存储(o.ldData_Storage 智能卡应具备在非易失性存储器中存储初始化数据和预个人化数据的能力 7.1.2用户标识(O.LUlser_Identifieatiom 智能卡应明确地标识出可使用各种逻辑接口的用户 7.1.3用户鉴别(o.User_Authenticeation) 用户应通过鉴别过程才可访问或使用智能卡中的用户数据和安全功能数据 7.1.4防重放攻击(o.Replay_Preventiom) 智能卡应提供安全机制以抵御重放攻击,如采用只可一次性使用的随机因子需具备一定的信息 嫡)等措施
GB/T36950一2018 7.1.5残留信息清除(o.kesiduallnfo_Clearaee 智能卡应确保重要的数据在使用完成后会被删除或被安全处理,不会留下可被攻击者利用的残留 数据信息 当应用程序被删除时,与其相关的所有敏感数据应一同被删除 7.1.6信息泄露防护(o.InfoLeak_Preention) 智能卡应提供控制或限制信息泄漏的方法,使得通过测量功耗、电磁辐射,时耗等信息的变化情况 无法或难以获得用户数据和安全功能数据 7.1.7数据访问控制(o.DataAce_Control 智能卡应对在系统内部的用户数据和安全功能数据实施访问控制措施,防止在未授权情况下被访 问、修改或删除 文件的创建、修改、删除和访问权限应与需求方的安全策略一致 7.1.8状态恢复(O.StatusRecovery 智能卡在检测到故障后应将工作状态恢复或调整至安全状态,防止攻击者利用故障实施攻击 7.1.9生命周期功能控制(o.Lifeeyce_Control 智能卡应对自身安全功能的可用性进行生命周期阶段划分,或进行权限控制,以防止攻击者滥用这 些功能进行攻击(如下载模式下的某些功能应在智能卡交付后关闭) 智能卡应能够抵御这种结合物理攻击和逻辑攻击的联合攻击 7.1.10密码安全(o.Crypto) 智能卡应以一个安全的方式支持密码功能,其使用的密码算法应符合国家、行业或组织要求的密码 管理相关标准或规范 在任何情况下,密码数据应存储于智能卡的安全保护区域内,使智能卡提供的安 全防护等措施发挥作用 当智能卡所使用的密码算法均由芯片实现,则应将此安全目的移至环境安全 目的中 7.2环境安全目的 7.2.1人员(oE.Personnel 智能卡的设计、开发、生产和交付等生命周期阶段中涉及的特定人员能严格地遵守安全的操作规 程,以保证智能卡在生命周期过程中的安全性 7.2.2通信信道(oE.CommChannel 智能卡与智能卡终端之间的通信路径是可信的,能为通信过程提供保密性和完整性保障 7.2.3应用程序(oE.App_Program) 安装应用程序到智能卡的流程应规范,且合法安装的应用程序不应包含恶意代码 在应用程序安 装到智能卡之前,需要通过相应的卡外实体的检测,以保证应用程序没有被篡改 7.2.4智能卡硬件(OE.Smi nartcardHardVare 智能卡硬件能够抵抗物理攻击、环境压力操纵攻击和侧信道攻击等
GB/36950一2018 7.2.5外部数据管理(oE.OutDataL_Management) 应对在智能卡外部存储的相关数据(如智能卡的设计信息、开发及测试工具、实现代码及相关文档、 初始化数据、管理性密钥等)进行保密性和完整性处理,并采取安全的管理措施 安全要求 8.1安全功能要求 8.1.1标识与鉴别 标识与鉴别应包括 用户属性定义(FIA_ATD.l 智能卡安全功能应为每个用户保存其安全属性,如;用户标识.PIN或密钥用户角色等 b 标识的时机(FIA_UID.1 在用户被标识之前,智能卡安全功能应允许智能卡代表用户实施安全功能控制的指定动 作,如:读取标识信息操作等; 只有在用户已被成功标识后,智能卡才能代表用户执行所有其他受智能卡安全功能控制 的动作 鉴别的时机(FIA_UAU.1) 在用户被鉴别之前,智能卡安全功能应允许智能卡代表用户实施安全功能控制的指定动 作,如:读取标识信息操作等; 只有在用户已被成功鉴别后,智能卡才能代表用户执行所有其他受智能卡安全功能控制 的动作 受保护的鉴别反馈 在鉴别前和鉴别过程中,智能卡安全功能应不提供任何敏感信息给用户 鉴别失败处理(FIA_AFL.1 智能卡安全功能应能够对鉴权事件相关的不成功鉴别尝试进行检测; 当达到或超过规定的不成功鉴别尝试次数时,智能卡安全功能将采取相应动作 8.1.2用户数据保护 用户数据保护应包括: a 子集访问控制(FDP_ACC.1 智能卡安全功能应对安全功能策略覆盖的主体、客体和它们之间的操作执行用户数据访问控 制策略 b 基于安全属性的访问控制(FDP_ACF.1 智能卡安全功能应基于安全属性或确定的安全属性组对客体执行用户数据访问控制 策略; 智能卡安全功能应通过对受控客体采取受控操作来管理访问的规则,以决定受控主体与 受控客体间的操作是否被允许; 如适用,智能卡安全功能应基于安全属性明确授权主体访问客体的规则明确授权主体访 问客体; 如适用,智能卡安全功能应基于安全属性明确拒绝主体访问客体的规则明确拒绝主体对 客体的访问
GB/T36950一2018 子集信息流控制(FDP_IFC.1 智能卡安全功能应对包含在安全功能策略中的主体、信息和导致受控信息流人流出受控主体 的操作执行信息流控制策略 d 子集残余信息保护(FDP_RIP.1 智能卡安全功能应确保至少以下资源的任何先前信息内容,在再次被使用时,其任何先前信息 内容已经被清除 1) APDU缓冲区 22 密码运算缓冲区; 33 临时对象释放 8.1.3密码支持 密码应支持 密钥生成(FCS_CKM.1 a 智能卡安全功能所使用的密钥均应是根据符合相关标准的密钥生成算法和特定密钥长度来产 生的密钥 密钥分发(FCs.CKM.2) b 开发者应根据满足相关标准的特定密钥分发方法来分发密钥 密钥访问(FCsCKM.3) 智能卡安全功能应根据符合相关标准的特定密钥访问方法来执行密钥访问 密码运算(FCs.coP.1) d 智能卡安全功能应根据符合相关标准的密码算法和密钥长度来执行密码运算 密钥销毁(FCsCKM.4 开发者应根据满足相关标准的特定密钥销毁方法来销毁密钥 8.1.4安全管理 安全管理应包括 安全功能行为的管理(FMT_MOF.1) a 智能卡安全功能应仅限于已标识的授权角色对可管理的功能具有确定其行为、禁止,允许,修 改其行为的能力 安全属性的管理(FMT_MSA.1 b 智能卡安全功能应执行访问控制策略或信息流控制策略,仅限于已标识了的授权角色对安全 属性进行改变默认值、查询、修改、删除或其他等操作 静态属性初始化(FMT_MSA.3) 智能卡安全功能应执行访问控制策略或信息流控制策略,以便为用于执行安全功能策略 的安全属性提供受限的默认值; 智能卡安全功能应允许已标识了的授权角色为生成的客体或信息规定新的初始值以代替 原来的默认值 TSF数据的管理(FMT_MTD,1 d 智能卡安全功能应仅限于已标识了的授权角色能够对安全功能数据进行改变默认值,查询、修 改、删除、清空或其他操作 TSF数据限值的管理(FMT_MTD.2 智能卡安全功能应仅限于已标识了的授权角色对安全功能数据限值进行管理,如:不成功 鉴别尝试次数闵值; 10
GB/36950一2018 当智能卡安全功能数据达到或超过了指明的限值时,安全功能将采取相应的动作 管理功能规范(FMT_SMF.1 智能卡安全功能应能够执行安全管理功能列表指明的各项管理功能 安全角色(FMT_SMR.1 g 智能卡安全功能应能够对已授权的角色进行维护; 22 应能够把用户和角色关联起来 8.1.5安全功能保护 安全功能保护应包括 失效即保持安全状态(FPT_FLs.1y a 智能卡安全功能在失效发生时应保持一种安全状态,如传输数据时掉电、自检失败,存储器空 间分配或访问错误等 功能恢复(FPT_RCV.4 智能卡安全功能应确保涉及恢复.复位.,掉电或撒消操作完成之前的情况的安全功能有如下特 性,即功能或者成功完成,或者针对指明的失效情景恢复到一个前后一致且安全的状态 重放检测(FPT_RPI.1 智能卡安全功能应能够对确定实体的重放攻击进行检测,如重用先前的合法鉴别数据进 行认证等; 22 智能卡安全功能在检测到重放时应执行相应的安全功能 物理攻击抵抗(FPT_PHP.3 智能卡安全功能应能够通过自动响应以抵抗对智能卡物理元器件的物理篡改和物理探测攻 击,如智能卡逆向分析以及其他各种物理侵害,SPA/DPA、高阶DPA、EMA攻击、环境压力 故障注人)攻击,测试特性的重激活或利用,以保证智能卡自身的安全功能正常执行 TSF测试(FPT_TST.1 智能卡安全功能应在初始化启动期间(每一次上电时,运行一套自检功能以证明TSF操 作的正确性; 智能卡安全功能应为授权用户提供验证TSF数据完整性的能力 22 智能卡安全功能应为授权用户提供验证所存储的TSF可执行代码完整性的能力 3 8.2安全保障要求 8.2.1ST引言(ASE_INT.1) ST引言应包括: 开发者行为元素;ASE_INT.1.1D开发者应提供sT引言 aa 内容和形式元素应包福 b AsE_INT.1.1csT引言应包含ST参照号,ToE参照号,ToE概述和TOE描述 1) ASE_INT.1.2csT参照号应唯一标识sT; 33) ASE_INT.1.3CTOE参照号应标识TOE; 4 AsE_INT.l.4CTOE概述应概括TOE的用法及其主要安全特性; 5 ASE_INT.1.5CTOE概述应标识TOE类型 6 AsE_INT.1.6CTOE概述应标识任何TOE要求的非TOE范围内的硬件/软件/固件; 77 AsE_INT.1.7CTOE描述应描述TOE的物理范围; 8 ASE_INT.1.8CTOE描述应描述TOE的逻辑范围 1
GB/T36950一2018 评估者行为元素应包括: 1) AsE_INT.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求 2)ASE_INT.1.2E评估者应确认TOE参考、TOE概述和TOE描述是相互一致的 8.2.2安全目的(ASE_OB.2) 安全目的应包括 开发者行为元素 a 1) ASE_OB.2.1D开发者应提供安全目的的陈述; 2 AsE_OB.2.2D开发者应提供安全目的的基本原理 b 内容和形式元素: 1) AsE_OB.2.1C安全目的的陈述应描述TOE的安全目的和运行环境安全目的; 22 AsE_OB.2.2C安全目的基本原理应追溯到TOE的每一个安全目的,以便于能追溯到安 全目的所对抗的威胁及安全目的实施的组织安全策略 3 AsE_OB.2.3C安全目的基本原理应追溯到运行环境的每一个安全目的,以便于能追溯 到安全目的所对抗的威胁、安全目的实施的组织安全策略和安全目的支持的假设， 4 ASE_OBJ.2.4C 安全目的基本原理应证实安全目的能抵抗所有威胁 AsE_OB.2.5C安全目的基本原理应证实安全目的执行所有组织安全策略 5 AsE_oB.2.6C安全目的基本原理应证实运行环境安全目的支持所有的假设 6 评估者行为元素:AsE_oB2.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.3符合性声明(ASE_ccL.1) 符合性声明应包括 开发者行为元素 a 1ASEcCL.1.1D开发者应提供符合性声明 ASE_CCL.1.2D开发者应提供符合性声明的基本原理 2) 内容和形式元素: b ASE_CCL.1.1csT的符合性声明应包含GB/T18336一2015(所有部分)符合性声明,并 应标识出ST和ToE声明符合性遵从的GB/T18336一2015(所有部分)的版本; ASE_CCL.1.2CsT的符合性声明应描述ST和GB/T18336.2一2015的符合性,无论是 与GB/T18336,2一2015相符或是与GB/T18336,.2一2015的扩展部分相符; ASE_CCI.1.3C符合性声明应描述ST和GB/T18336.3一2015的符合性,无论是与 3 GB/T18336.32015相符或是与GB/T18336.3一2015的扩展部分相符; 4 ASE_CCL1.4C符合性声明应与扩展组件定义是相符的 ASE_CCL.1.5C符合性声明应标识ST声明遵从的所有PP和安全要求包: 5 6 ASE_CCL1.6C符合性声明应描述ST和包的符合性,无论是与包的相符或是与扩展包 相符 ASE_CCL.1.7C符合性声明的基本原理应证实TOE类型与符合性声明所遵从的PP中 的TOE类型是相符的 ASE_CCL.1.8C符合性声明的基本原理应证实安全问题定义的陈述与符合性声明所遵从 的PP中的安全问题定义陈述是相符的 AsE_CCIL1.9C符合性声明的基本原理应证实安全目的陈述与符合性声明所遵从的Pp 中的安全目的陈述是相符的 12
GB/36950一2018 0)ASE_CCLl.10C符合性声明的基本原理应证实安全要求的陈述与符合性声明所遵从的 PP中的安全要求的陈述是相符的 评估者行为元素:ASE_CCLl.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.4扩展组件定义(ASEECD.1) 扩展组件定义应包括: 开发者行为元素: ASE_ECD.1.1D开发者应提供安全要求的陈述 1) AsE_ECD.1.2D开发者应提供扩展组件的定义 内容和形式元素 b 1) ASE_ECD.1.1cC安全要求陈述应标识所有扩展的安全要求:; 2 AsE_ECD.1.2C扩展组件定义应为每一个扩展的安全要求定义一个扩展的组件; AsE_ECD.1.3C扩展组件定义应描述每个扩展的组件与已有组件,族和类的关联性; 3 AsE_ECD.l.4C扩展组件定义应使用已有的组件,族、类和方法学作为陈述的模型; 4 AsE_ECD.1.5c扩展组件应由可测量的和客观的元索组成,以便于证实这些元素之间的 5 符合性或不符合性 评估者行为元素 1 AsE_ECD.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求; 22 ASE_ECD.1.2E评估者应确认扩展组件不能利用已经存在的组件明确的表达 8.2.5推导出的安全要求(ASEREQ.2 推导出的安全要求应包括 开发者行为元素 1) ASE_REQ.2.1D开发者应提供安全要求的陈述 22 AsE_REQ.2.2D开发者应提供安全要求的基本原理 b)内容和形式元素: 1ASEREQ.2.1c安全要求的陈述应描述安全功能要求和安全保障要求; A ,SE_REQ.2.2C应对安全功能要求和安全保障要求中使用的所有主体、客体、操作,安全 22 属性、外部实体及其他术语进行定义 AsE_REQ.2.3C安全要求的陈述应对安全要求的所有操作进行标识 3 ！ AsE_REQ.2.4C所有操作应被正确地执行; 应满足安全要求同的依赖关系,或者安全要求基本原理应证明不需要满 5 ASE_REQ.2.5C 足某个依赖关系; AsE_REQ.2.6C安全要求基本原理应描述每一个安全功能要求可追溯至对应的TOE安 全目的; 77 ASEREQ.2.7C安全要求基本原理应证明安全功能要求可满足所有的TOE安全目的 8 AsE_REQ.2.8C安全要求基本原理应说明选择安全保障要求的理由; 9 ASE_REQ.2.9C安全要求的陈述应是内在一致的 评估者行为元素:AsE_REQ,2.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.6安全问题定义ASE_SPD.1 安全问题定义应包括: 13
GB/T36950一2018 开发者行为元素;ASE_SPD.1.1D开发者应提供安全问题定义 a D)内容和形式元素: ASE_SPD.1.1C安全问题定义应描述威胁; 1) 22) ASE_SPD.1.2C所有的威胁都应根据威胁主体、资产和敌对行为进行描述; 33 ASE_SPD.1.3C安全问题定义应描述组织安全策略; ！ ASE_SPD.1.4C安全问题定义应描述TOE运行环境的相关假设 评估者行为元素:ASESPD.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.7ToE概要规范(ASE_ISS.1 TOE概要规范应包括 a 开发者行为元素:ASE_TSS.1.ID开发者应提供TOE概要规范 b内容和形式元素;ASE_TsS.1.1CTOE概要规范应描述TOE是如何满足每一项安全功能要 求的 评估者行为元素: AsE_Tss.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求 1 2)ASE_TSs.1.2E评估者应确认ToE概要规范与ToE概述、TOE描述是一致的 8.2.8安全架构描述(ADV_ARC.1 安全架构描述应包括 开发者行为元素 a ADV_ARC.1.lD开发者应设计并实现ToE,确保TsF的安全特性不可旁路 1) 2) ADV_ARC.1.2D开发者应设计并实现TsF,以防止不可信主体的破坏; 3)ADv_ARC.1.3D开发者应提供TSF安全架构的描述 内容和形式元素 b ADV_ARC.1.1C安全架构的描述应与在ToE设计文档中对SFR执行的抽象描述的级 1 别一致 ADV_ARC.1.2C安全架构的描述应描述与安全功能要求一致的TSF安全域; 22 3) ADV_ARC.1.3C安全架构的描述应描述TSF初始化过程为何是安全的 4)ADV_ARC.1.4C安全架构的描述应论证TSF可防止被破坏; 5) ADV_ARC.1.5C安全架构的描述应论证TSF可防止SFR-执行的功能被旁路 评估者行为元素:ADV_ARC.1.1E评估者应确认提供的信息符合证据的内容和形式要求 8.2.9完备的功能规范Av_FSP.4) 完备的功能规范应包括: 开发者行为元素 a 1) ADV_FSP.4.ID开发者应提供一个功能规范; 2)ADV_FSP.4.2D开发者应提供功能规范到安全功能要求的追溯 b 内容和形式元素: ADV_FSP.4.1C功能规范应完全描述TSF:; 1) 22) ADV_FSP.4.2C功能规范应描述所有的TSFI的目的和使用方法; 33 ADV_FSP.4.3C功能规范应识别和描述每个TSFI相关的所有参数; 4)ADV_FSP.4.4C对于每个SFR执行TSFI,功能规范应描述TSF相关的所有行为; 14
GB/36950一2018 5 ADV_FSP.4.5C功能规范应描述可能由每个TSFI的调用而引起的所有直接错误消息 6 ADV_FSP.4.6C功能规范应论证安全功能要求到TSFI的追溯 评估者行为元素: ADVv_FSP.4.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求 22 ADV_FSP.4.2E评估者应确定功能规范是安全功能要求的一个准确且完备的实例化 8.2.10TSF实现表示(ADv_IMIP.1 TSF实现表示应包括: 开发者行为元素: ADV_IMP.1.1D开发者应为全部TSF提供实现表示 2)ADV_IMP.1.2D开发者应提供TOE设计描述与实现表示实例之间的映射 b 内容和形式元素: ADv_IMP1.1C实现表示应按详细级别定义TsF,且详细程度达到无须进一步设计就能 1 生成TsF的程度" ADv_IMP1.2C实现表示应以开发人员使用的形式提供 22 ADv_IMP.1.3CToE设计描述与实现表示示例之间的映射应能证明它们的一致性 33 评估者行为元素ADv_IMP1.lE对于选取的实现表示示例,评估者应确认提供的信息满足 证据的内容和形式的所有要求 8.2.11基础模块设计(ADv_IDs.3) 基础模块设计应包括 开发者行为元素 a l)ADv_TDs.3.1D开发者应提供TOE的设计; ADv_TDs.3.2D开发者应提供从功能规范的TsFI到ToE设计中获取到的最低层分解 的映射 b)内容和形式元素 1)ADV_TDS.3.1C设计应根据子系统描述rOE的结构 ADv_TDs.3.2C设计应根据模块描述TSF; 22) 33) ADv_TDs.3.3C设计应标识TSF的所有子系统; 4 ADv_TDs.3.4C设计应描述每一个TSF子系统; 5) ADv_TDS.3.5C设计应描述TSF所有子系统间的相互作用 6 ADv_TDS.3.6C设计应提供TSF子系统到TSF模块间的映射关系 ADV_TDs.3.7C设计应描述每一个SFR执行模块,包括它的目的及与其他模块间的相 7) 互作用: ADV_TDs.3.8C设计应描述每一个SFR-执行模块,包括它的安全功能要求相关接口,其 他接口的返回值、与其他模块间的相互作用及调用的接口; ADV_TDs.3.9C设计应描述每一个SFR-支撑或SFR无关模块,包括它的目的及与其他 模块间的相互作用; 0)ADVv_TDS.3.10C映射关系应论证TOE设计中描述的所有行为能够映射到调用它的 TSFI 评估者行为元素: ADv_TDs.3.1E评估者应确认提供的信息满足证据的内容与形式的所有要求; 22 ADV_TDS,3.2E评估者应确定设计是所有安全功能要求的正确且完全的实例 15
GB/T36950一2018 8.2.12操作用户指南(AGD_oPE.1 操作用户指南应包括: 开发者行为元素;:AG;D_OPE.1.ID开发者应提供操作用户指南 a b)内容和形式元素: 1 AGD_OPE.1.1C操作用户指南应对每一种用户角色进行描述,在安全处理环境中应被控 制的用户可访问的功能和特权,包含适当的警示信息; 22 AGD_OPE1.2C操作用户指南应对每一种用户角色进行描述,怎样以安全的方式使用 TOE提供的可用接口; 3 AGD_OPE.1.3C操作用户指南应对每一种用户角色进行描述,可用功能和接口,尤其是 受用户控制的所有安全参数,适当时应指明安全值 4 AGD_OPE.1.4C操作用户指南应对每一种用户角色明确说明,与需要执行的用户可访问 功能有关的每一种安全相关事件包括改变TsF所控制实体的发全特性， AGD_oPE.1.C操作用户指南应标识ToE运行的所有可能状态(包括操作导致的失败 或者操作性错误),他们与维持安全运行之间的因果关系和联系; AGD_oPE.1.6C操作用户指南应对每一种用户角色进行描述,为了充分实现ST中描述 的运行环境安全目的所应执行的安全策略; AGD_OPE.1.7c操作用户指南应是明确和合理的 77 评估者行为元素:AGD_OPE.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.13准备程序(AGD_PRE.1 准备程序应包括 开发者行为元素:AGD_PRE.1.1D开发者应提供TOE,包括它的准备程序 a b)内容和形式元素 lAGD_PRE.1.1C准备程序应描述与开发者交付程序相一致的安全接收所交付TOE必需 的所有步骤; AGD_PRE.1.2C准备程序应描述安全安装TOE以及安全准备与sT中描述的运行环境 安全目的一致的运行环境必需的所有步骤 评估者行为元素 c 1)AGD_PRE.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求; 2 AGD_PRE.1.2E评估者应运用准备程序确认TOE运行能被安全的准备 8.2.14生产支持和接受程序及其自动化(AIc_CMc.4) 生产支持和接受程度及其自动化应包括: 开发者行为元素 a 1) ALC_CMC.4.1D开发者应提供TOE及其参照号; ALC_CMC.4.2D开发者应提供CM文档; 2 33) ALC_CMC.4.3D开发者应使用CM系统 b 内容和形式元素: ALC_CMC.4.1C应给TOE标记唯一参照号; 1 22 ALC_CMC.4.2CCM文档应描述用于唯一标识配置项的方法 3)AL.C_CMC.4.3CCM系统应唯一标识所有配置项; 16
GB/36950一2018 ALC_CMC.4.4CCM系统应提供自动化的措施使得只能对配置项进行授权变更 5 ALC_CMC.4.5CCM系统应以自动化的方式支持TOE的生产; 6) ALc_cMC.4.6ccM1文档应包括cM计划 7)AL.c_CMC.4.7cCM计划应描述CM系统是如何应用于ToE的开发的 ALC_CMC.4.8CCM计划应描述用来接受修改过的或新创建的作为TOE组成部分的配 8 置项的程序; 9 ALC_CMC.4.9C证据应论证所有配置项都正在CM系统下进行维护; 0)AL.C_CMC.4.10C证据应论证CM系统的运行与CM计划是一致的 评估者行为元素:ALC_CMC.4.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.15问题跟踪CM覆盖(ALc_CMIs.4 问题跟踪CM覆盖应包括 开发者行为元素:ALC_CMS.4.1D开发者应提供ToE配置项列表 a b)内容和形式元素; lAL.c_CMs,4.1c配置项列表应包括.ToE本身、安全保障要求的评估证据、rOE的组成 部分,实现表示和安全缺陷报告及其解决状态; ALc_CMS,4.2C配置项列表应唯一标识配置项 22 33 ALC_CMS.4.3C对于每一个TSF相关的配置项,配置项列表应简要说明该配置项的开 发者 评估者行为元素;AlC_CMS,4.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.16交付程序(ALc_DEL..1) 支付程序应包括: 开发者行为元素: I)ALC_DEL.1.lD开发者应将把TOE或其部分交付给消费者的程序文档化 2)ALc_DEL.1.2D开发者应使用交付程序 内容和形式元素;AIc_DEL.1.1C交付文档应描述,在向消费者分发TOE版本时,用以维护 b 安全性所必需的所有程序 评估者行为元素:ALC_DEL.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 安全措施标识(AL.c_Ds.1)y 8.2.17 安全措施标识应包括 开发者行为元素;ALC_DVS.1.lD开发者应提供开发安全文档 aa b 内容和形式元素:ALC_DVS.1.1C开发安全文档应描述在TOE的开发环境中,保护TOE设 计和实现的保密性和完整性所必需的所有物理的、程序的、人员的及其他方面的安全措施 评估者行为元素: ALc_DVs.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求; ALC_DVs.1.2E评估者应确认安全措施正在被使用 8.2.18开发者定义的生命周期模型(AIC_LCD.1 开发者定义的生命周期模型应包括 17
GB/T36950一2018 开发者行为元素 a 1) ALC_L.CD.1.1D开发者应建立一个生命周期模型,用于ToE的开发和维护 2)ALC_LCD.1.2D开发者应提供生命周期定义文档 D)内容和形式元素: Al.C_LCD.1.1C生命周期定义文档应描述用于开发和维护TOE的模型 2)Al.C_LCD.1.2C生命周期模型应为TOE的开发和维护提供必要的控制 评估者行为元素:AI.C_ICD.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.19明确定义的开发工具(ALC_TAT.1 明确定义的开发工具应包括 a 开发者行为元素: 1) ALC_TAT.1.lD开发者应标识用于开发TOE的每个工具; 2)ALC_TAT.1.2D开发者应在文档中描述每个开发工具所选取的实现依赖选项 b 内容和形式元素: ALC_TAT.1.IC用于实现的每个开发工具都应是明确定义的" 1 2)AL.cTAT.1.2C每个开发工具的文档应无歧义地定义所有语句和实现用到的所有协定 与命令的含义; ALc_TAT.1.3C每个开发工具的文档应无歧义地定义所有实现依赖选项的含义 33 评估者行为元素:AL.c_TAT.1.1E评估者应确认所提供的信息满足证据的内容和形式的所有 要求 8.2.20覆盖分析(ATE_cow.2 覆盖分析应包括 开发者行为元素;:ATE_cov.2.1D开发者应提供对测试覆盖的分析 a 内容和形式元素 b) 1)ATE_cov.2.1C测试覆盖分析应论证测试文档中的测试与功能规范中TSF接口之间的 对应性; ATE_coV2.2C测试覆盖分析应论证已经对功能规范中的所有TSF接口都进行了测试 22 评估者行为元素:ATE_COV.2.1E评估者应确认所提供的信息满足证据内容和形式的所有 要求 8.2.21测试;安全执行模块(ATE_DPr.2 测试;安全执行模块应包括: 开发者行为元素:ATE_DPT.2.1D开发者应提供测试深度分析 a b) 内容和形式元素: lATE_DPT.2.1C深度测试分析应论证测试文档中的测试与TOE设计中的TSF子系统、 SFR执行模块之间的一致性; 22 ATE_DPT.2.2C测试深度分析应论证TOE设计中的所有TSF子系统都已经进行过 测试 ATE_DPT.2.3C测试深度分析应论证TOE设计中的SFR执行模块都已经进行过测试 3 评估者行为元素:ATE_DPT.2.1E评估者应确认所提供的信息满足证据内容和形式的所有 要求 18
GB/36950一2018 8.2.22功能测试(ATE_FUN.1 功能测试应包括: 开发者行为元素: l)ATEFUN.1.1D开发者应测试TSF,并文档化测试结果; 2)ATE_FUN.1.2D开发者应提供测试文档 b)内容和形式元素: 1ATE_FUN.1.1c测试文档应包括测试计划、预期的测试结果和实际的测试结果; ATE_FUN.1.2c测试计划应标识要执行的测试并描述执行每个测试的方案,这些方案应 22 包括对于其他测试结果的任何顺序依赖性; ATE_FUN.1.3C预期的测试结果应指出测试成功执行后的预期输出; 3 ATE_FUN.1.4C实际的测试结果应和预期的测试结果一致 4 评估者行为元素;ATE_FUN,1.1E评估者应确认所提供的信息满足证据内容和形式的所有 要求 8.2.23独立测试一抽样(ATE_IND.2) 独立测试一抽样应包括 开发者行为元素:ATEIND.2.1D开发者应提供用于测试的TOE b)内容和形式元素: l)ATE_IND.2.1CTOE应适合测试; 2)ATE_IND.2.2C开发者应提供一组与开发者TsF功能测试中同等的一系列资源 评估者行为元素 1ATE_IND.2.1E评估者应确认所提供的信息满足证据的内容和形式的所有要求 2) ATE_IND.2.2E评估者应执行测试文档中的测试样本,以验证开发者的测试结果; 33 ATE_IND.2.3E评估者应测试TSF的一个子集以确认TSF按照规定运行 8.2.24系统的脆弱性分析(AVA_VAN.4 系统的脆弱性分析包括: a 开发者行为元素:AVAVAN.4.1D开发者应提供用于测试的TOE b 内容和形式元素:AVA_VAN.4.1CTOE应适合测试 评估者行为元素: AVA_VAN.4.1IE评估者应确认所提供的信息满足证据的内容和形式的所有要求 1 2)AVA_VAN.4.2E评估者应执行公共领域的调查以标识ToE的潜在脆弱性; AVA_VAN.4.3E评估者应针对TOE执行独立的、系统的脆弱性分析去标识TOE潜在 33 的脆弱性,在分析过程中使用指导性文档,功能规范、ToE设计、安全结构描述和实现 表示; AVA_VAN.4.4E评估者应基于已标识的潜在脆弱性实施穿透性测试,确认ToE能抵抗 4 具有中等攻击潜力的攻击者的攻击 基本原理 g.1安全目的基本原理 表1说明了智能卡的安全目的能应对所有可能的威胁、假设和组织安全策略 19
GB/T36950一2018 表1威胁,组织安全策略,假设与安全目的的对应关系 安全目的 品 安全问题定义 国 T.,PProbe T.P_Alter T.INF-LEAK TFiLms T.Inv_Inp T.Ua_l.oad T.Access T.LcFtn _Atk T.Cr rypt- T.RND T.Envstrs TClo T.REPLA T.BRUTEFORCE P.Crypto_Management P.IdData_Management P.ChipSelection A.Personnel A.OutData_Management A.Comm_Channel A.App_Program 具体包括下列要求 a T.Ua_L.oadl 为了抵御非法程序攻击,通过o.User_ldentification,o.User_Authentieation确保下载应用程序 前,用户应已被明确标识并进行了安全鉴别;O.DataAcc_Control确保对数据实施了访问控制管理,以 防止非法程序绕过访问控制措施读取或修改数据;另外,OE.App_Program确保应用程序的开发过程 不会包含恶意代码且下载过程能以一种安全的规程进行 b)T.INF-LEAK 针对攻击者利用TOE执行过程中泄露的功耗、电磁辐射及时耗等侧信道信息而发起的侧信道等 信息泄露攻击,o.InfoLeak_Prevention要求ToE应具有抵抗或缓解此类攻击的能力 oE.smartcard Hardware可确保硬件平台能够抵御侧信道攻击,因而保证由硬件平台实现的密码算法在此攻击下的 安全性 20
GB/36950一2018 T.Fl_Ins、T.Inv_Inp c 故障注人攻击可通过分析TOE的运行故障以获取敏感数据信息或滥用TOE的安全功能,为此， O.Status Recovery确保当故障发生时ToE工作状态可恢复或调整至安全状态,而不泄露有利于攻击 者的故障信息 OE,Smartcard_Han 可确保硬件平台能够抵御故障引人攻击,因而保证由硬件平 ardware 台实现的密码算法在此攻击下的安全性 d)T.Le-_Ftn 攻击者利用生命周期功能滥用而造成对TOE的安全威胁,可通过O.Lifeeycle_Control控制特定 生命周期的特定指令和功能,通过对TOE生命周期各阶段进行管理来防止此类攻击 e T.P_Probe、T.P_Alter 物理操纵攻击是攻击者利用芯片失效性分析和半导体逆向工程技术,对芯片实施物理剖片和探测， 以获取存储与芯片内的数据信息 OE.SmartceardLHardware可确保硬件平台能够抵御物理操纵攻击 f T.Access 为了抵御使用者或攻击者可能在未经信息或资源的拥有者或责任者许可的条件下对信息或资源进 行访问,通过O.User_Authentication确保在访问之前,用户应已被明确标识并进行了安全鉴别 T.REPIAY、T.BRUTE-FORCE g 为了抵御攻击者可能刺探或搜索智能卡鉴别数据,通过o.Replay_Prevention确保相关鉴别数据 不能被重复利用 h)T.EnvStrs 通过o.Status_ecovery对环境状态的检测,来确保可能导致敏感信息泄漏的外部环境操纵攻击 T.Clonm i 通过o.ResidualInfo_Clearance对密钳数据的及时进行销毁,防止重要数据资源释放或销毁后再 被访问,以确保敏感信息泄露导致克隆的发生 jP.Crypto_Management、T.Crypt_Atk 强调了使用国家或行业的密码标准和规范的要求,o.Crypto直接满足了这一组织安全策略要求 可确保在设计和开发过程中正确使用这些标准 k)P.IdData_Management 对智能卡嵌人式软件的开发和个人化等过程应具备标识ToE的能力提出要求,这一策略可直接 由O.ldDataStorage安全目的来满足 P.Chip_Selection D 确立了TOE应采用至少通过EAL4十测评的安全芯片,提出OE.Smartcard_Hardware确保芯片 可抵抗物理攻击、环境干扰攻击、侧信道攻击等,以至少达到EAL4十安全要求 mT.RND,A.Comm_Channel 应确保TOE与智能卡终端之间的通信信道是安全可靠的,OE.Comm_Channel提供了环境安全目 的,确保通信路径是可信的 n)A.App_Program 该假设对安装在智能卡嵌人式软件之上的应用程序本身及其安装流程的安全性提出了条件,OE App_Program提供了针对性的环境安全目的,可满足该假设条件 A.OutData_Management o 该假设对安全功能数据在TOE外部存储和管理的安全性提出了要求,OE.OutData_Management 提供了针对性的环境安全目的,可确保外部存储和管理TSF数据的措施是安全的 A.Personnel p 该假设对TOE用户的使用安全性提出了要求,OE.Personnel环境要求确保操作人员需要在经过 培训后严格地遵守安全的操作规程,因此可以满足这一假设 21
GB/T36950一2018 9.2安全要求基本原理 表2说明了安全要求的充分必要性基本原理,即每个安全目的都至少有一个安全要求(包括功能要 求和保障要求)组件与其对应,每个安全要求都至少解决了一个安全目的,因此安全要求对安全目的而 言是充分和必要的 表2安全功能组件与安全目的的对应关系 安全目的 安全功能组件 FCSCKM.1 :CsCKM." FCS_CKM.3 FCsCKM.4 FCS_COP.1l FDPAcc.1 FDP_ACF.1 FDP_IFCc.1 FDP_RIP.1 FIAAFL.1 FIA_ATD.l FIA_UAU.1 FIA_UD.1 FMT_MOF.1 FMT_MSA.l FMT_MSA.3 MT_MTD. FMT_MTD.2 FMT_sMF. FMT_SMR. FPTFLs.1 FPT_RCV.4 FPT_RP1 FPT_PHP.3 FPTTST.1 22
GB/36950一2018 具体包括下列要求 O.IdD; a ata_Storage FMT_MTD.1可满足对智能卡嵌人式软件初始化及预个人化等数据中的标识信息进行安全存储 并防止在使用阶段被修改的要求 bo.User_Identification 安全标识的安全目的可由FIA_ATD.1、FIA_UID.1通过维护用户的安全属性及对每个用户身份 的成功标识获得满足 o.User_Authentieationm 通过FIA_AFL1、FIA_ATD.1、FIA_UAU.1、FMT_SMR.1对鉴别机制的实现及与角色的关联进 行要求;并通过FCS_CKM.1、FCS_CKM.3、FCs_COP.1对安全鉴别实现方式所使用的密码相关机制 进行要求 d)0.Replay_Prevention 通过FPT_RPL.1对鉴别数据的重要数据实体防重放进行要求 O.ResidualInfo_Clearance e 通过Fcs_CKM.4对密钥数据的销毁进行要求,并通过FDP_RIP1对重要数据资源释放或销毁后 提出不可再被访问的要求.以满足残余信息清除的目的 f O.Infoleak_Prevention 通过FDP_IFC.1,FPT_PHP.3保证用户数据和TsF数据在计算过程及内部传输过程中不会泄露 能被攻击者利用的有效信息,以此来满足TOE抵抗侧信道等信息泄露攻击的安全目的 g O.DataAce_Control 通过FDPACc.1,FDPACF1要求对TOE内部的用户数据实施访问控制管理,防止未授权的访 问;FIA_UAU.1,FIA_UD.1要求用户在执行安全功能前需进行正确的标识并通过安全鉴别;FMT MOF.1,FMT_MsA.1,FMT_MSA.3,FMT_MTD.1和FMT_MTD.2要求对安全属性等安全功能数据 及安全功能进行授权管理以防止未授权访问 在上述安全功能要求组件的配合下将可实现数据保护的 安全目的 h)O.Status_Recovery 通过FPT_FLS.1,FPT_RCV.4对发生异常后的功能恢复及安全状态保持情况提出要求,FPT TST.1要求对安全功能的正确性和相关数据的完整性进行自检,这些组件可满足检测到故障后调整至 安全状态的目的 O.Lifeeyele_Control 通过FIA_UAU.1、FMT_SMR.1要求TOE用户在不同生命周期阶段中应按角色进行鉴别才能实 施相应操作,并通过FMT_SMF.1要求对特定生命周期阶段具有特定指令及操作的要求,来共同满足 生命周期控制的安全目的 O,Crypto 通过FCs_CKM.1、FCs_CKM.2、FCs_CKM.3和FCS_COP.1对密码相关操作进行要求可满足密 码安全的安全目的 23
GB/T36950?2018 [1]SsmartCardOpenPlatformProteeionProfleVersion2.1ITSseeurityCertifeation CenterKorea2010.KECS-PP-0097a2008. SeurityIcPlatformProtetionProfle,Versionl.015.06.2o07Registeredandcerifed byBundesamtfurSicherheitinderInformationstechnikBSIunderthe BS-PP-0035. rdference 24

智能卡安全技术要求：保障信息安全的重要手段

根据GB/T36950-2018标准，智能卡的EAL4+等级是目前最高的安全等级之一，具有以下安全技术要求：

• 加密算法：智能卡应该支持多种加密算法，并且在使用过程中需要满足密码学原理，以确保数据传输的机密性与完整性。
• 身份验证：智能卡应该采用双因素身份验证机制，通过密码、生物特征等多种方式进行身份验证，从而防止冒充和非法访问。
• 物理安全性：智能卡应该具有良好的物理安全性，包括防水、防尘、防摔、防电磁干扰等，以确保在恶劣环境下的可靠性和稳定性。
• 应用安全：智能卡应该采用多应用分离技术，在不同的应用之间实现隔离，从而防止数据泄露和恶意攻击。

智能卡作为信息安全技术的重要组成部分，具有着非常重要的应用前景。首先，在金融、电子商务、医疗等各个领域中，智能卡已经成为了实现身份认证、交易授权、数据存储等功能的核心设备。

其次，在政府、军事等领域中，智能卡也发挥着重要作用。例如，在军队中，智能卡可以用于士兵的身份识别、武器装备的管理等方面，从而提高管理效率和工作效率。

最后，在未来，随着科技的不断进步和应用场景的不断扩大，智能卡的应用范围将会更加广泛，并且在安全技术方面的要求也将会愈加严格。因此，智能卡安全技术的研究和发展具有非常重要的意义。

总之，智能卡作为一种重要的信息安全技术手段，对于保障信息安全起着至关重要的作用。在未来，我们应该继续加强对智能卡安全技术的研究和开发，不断提高智能卡的安全性和可靠性，以满足社会各个领域对于信息安全的需求。

信息安全技术智能卡安全技术要求（EAL4+）的相关资料

和信息安全技术智能卡安全技术要求（EAL4+）类似的标准

GB/T31507-2015

信息安全技术智能卡通用安全检测指南

2022/10/28 7:47:29 现行

GB/T33242-2016

数字城市智能卡应用技术要求

2022/9/27 9:04:57 现行

GB/T33738-2017

手机支付基于2.45GHzRCC（限域通信）技术的智能卡技术要求

2022/9/24 8:20:41 现行

GB/T33737-2017

手机支付基于2.45GHzRCC（限域通信）技术的智能卡测试方法

2022/9/24 8:02:08 现行

GB/T35101-2017

信息安全技术智能卡读写机具安全技术要求（EAL4增强）

2022/9/3 18:21:53 现行

GB/T36950-2018

信息安全技术智能卡安全技术要求（EAL4+）

2022/8/7 22:05:33 现行