CC标准中安全架构的分析方法

2024-01-10 14:21

信息安全漏洞造成的负面影响已蔓延到信息社会的各个角落。本质上，IT产品的设计、实现缺陷以及运行环境的失效，是导致系统安全漏洞的根本原因，受技术能力的限制，这些缺陷往往由于隐蔽性较强，而无法在开发过程中被及时清除。信息安全测评是解决这个问题的重要手段，从ISO/IEC JTC1 SC27 WG3公布的信息来看，安全测评的意义已得到国际信息安全产业界的普遍认可。

当前，国际上主要采用CC(Common Criteria)，即通用准则标准进行产品安全测评，CC标准已在智能卡、网络基础设备、数据库及操作系统等形形色色的IT产品安全评估中得到广泛应用。随着CC安全评估产业的蓬勃发展，CC标准对信息安全的支撑作用也在日益凸显。在中国，等同于CC v2.3的中文版本GB/T18336标准已被采用了10余年。近年来，基于GB/T18336的测评业务量逐年攀升，安全测评证书不仅得到了开发商的重视，更成为行业产品选型的前提条件。

CC v3.1与前期版本相比有不少变化，在评估模型和测试要求方面的差异也很明显，为了依据CC v3.1正确地开展测评工作应首先深刻理解这些区别的含义。中国已于近期发布等同于CC v3.1的GB/T18336标准修订本，因而评估技术和方法也将发生一次较大的变化。

PART 1

CC评估模型

产品面临的潜在威胁与其自身的缺陷相关。通常，产品设计、开发、交付和运行的每个环节都可能会引入缺陷。因而，在所有这些环节中都应采用安全的工程实践方法，以完善产品设计和实现、开发和交付，以及运行环境的安全措施，并通过安全评估尽可能及时地消除所有缺陷，以此来抵抗潜在的威胁，下图描述了威胁抵抗模型。

CC标准描述了安全评估的基本模型。CC要求结合开发者自证及评估者他证的做法，来论证IT产品的安全措施是充分的、正确的，从而可以有效地抵抗已知的威胁。

PART 2

安全架构分析

一

安全架构与SFR的关系

根据CC评估模型，为了保护用户的资产不受侵害，TOE需要采用安全措施来应对威胁，安全措施将以SFR的形式来刻画。在TOE中，SFR正确执行所依赖的软硬件部分合称为安全功能(TOE security functionality，TSF)。从结构关系来说，TSF是TOE的组成部分，但是TSF的目的却是用于抵抗TOE运行环境中的威胁，保护TOE的功能和数据免遭破坏(或泄漏)。为便于讨论，本文将TSF中用于实现SFR的功能称为TSF内涵功能。一般地，一个仅包含TSF内涵功能的TOE可能无法实现安全目的，因为这些内涵功能本身也有被破坏或绕过的危险。本文将保护TSF内涵功能使其能发挥预期能力的功能体称为TSF元功能，因为任何TSF为了正确运行都需要这些功能的保护。TSF元功能可能由TSF自身实现，也可能由TOE的运行环境实现，甚至由二者合作完成。基于这种理解，TSF元功能有可能不是TSF的组成部分，这与TSF内涵功能不同。更进一步，TSF元功能可能无法通过功能测试来验证正确性，而必须依赖穿透性测试。下图对这种逻辑关系进行了描述。

在TSF元功能的保护下，TSF将具有一些安全属性。根据CC标准，这些安全属性主要体现为3个方面，即安全域分离、自保护以及不可旁路性。在CC v2.3等旧版本中，这些属性是通过TSF要求(而非安全保障要求)的形式给出的。但是，根据TSF元功能的定义，这些属性覆盖到TSF的各个具体的功能，实际上不便用SFR来刻画并通过TSF中的某个部分来实现，特别是对于那些通过环境来实现这些属性的情况。因此，CC v3.1将这些属性放到安全保障组件ADV_ARC中进行要求。为了说明这点，可以从下面这些安全属性的定义来讨论。

（1）安全域分离属性定义。TSF能为每个TOE内部运行的实体(如进程)定义安全域，以便所有实体只能访问自己运行域中的资源。通常，TSF在TOE的运行环境中，安全域是由运行环境来实现的(如Java运行环境对应用程序设立的软件防火墙机制可以限定任何应用只能访问自己的资源)。在此情况下，通过SFR进而TSF内涵功能来实现TSF域分离属性的目标并不合理。另一方面，倘若域分离功能真由某个TSF内涵功能实现，该内涵功能的安全域又只能依靠运行环境来实现了，这说明单独通过SFR和TSF内涵功能是无法实现域分离属性的。

（2）自保护属性定义。TSF能保护自己免遭外部实体的非法篡改。与安全域分离属性一样，TSF内涵功能单方面通常无法保护自身，因而需要通过外部环境的作用来配合实现。例如，TSF自保护属性可以通过功能或数据完整性机制来实现，在TSF每次启动前先运行这个机制，检验是否可以继续运行其他TSF功能。但实现这个机制的TSF内涵功能本身也需要保护，这也只能通过环境的TSF元功能来实现。

（3）不可旁路属性定义。外部实体不可绕过TSF的安全机制来访问TSF所保护的资源。显然，TSF只能保护其覆盖的功能或数据，但TSF并不会规定这些功能或数据是否只能通过TSF内涵功能来访问。另一方面，即便可以设计这样的TSF内涵功能，这个内涵功能的不可旁路性也需要通过环境中的TSF元功能来实现。

根据上述分析，TSF内涵功能和元功能有很大的不同，只有这两部分同时正常运行方能保证TOE的运行安全。因此，安全评估应确认这两部分的要求均能得到满足。

二

安全架构的论述和评估

根据ADV_ARC的要求，开发者应论述安全域分离、自保护和不可旁路这些属性是如何满足的。由节3.1的讨论，开发者实际上应描述TSF元功能采取了何种安全机制，以及这些机制是如何设计和实现的。如果从这些属性出发，逐个描述对应的安全机制，易使描述混乱。注意到ADV_ARC文档将作为脆弱性分析AVA_VAN活动的输入，因此论文中提出从攻击路径的角度来论述安全机制，即为了抵抗已知的攻击，论述各个安全机制是如何发挥作用的。以下将举例说明此观点，并提出具体的评估方法。

（1）缓冲区溢出攻击。对于有丰富逻辑指令(或通信)接口，或平台开放的TOE，攻击者可以发掘并利用TOE代码层面的缓冲区溢出漏洞进行攻击，以达到提权或获取敏感信息的目的(实际上是破坏安全域分离、自保护和不可旁路这3个属性)。由于缓冲区溢出漏洞可能出现在任何分配和操作数组的代码中，不便设立具体的安全功能要求，通过某个TSF内涵功能来抵抗此攻击。对此攻击最好是通过加强编码规范，排除数组或堆栈操作中存在的漏洞来防护。对此开发者和评估者的任务分别如下。

（a）开发者应在ADV_FSP中描述所有的TSF接口，特别是指令和通信接口；并在ADV_ARC文档中列出可能引发缓冲区溢出的位置，描述具体的编码和处理方法。

（b）评估者验证开发者编码规范的合理性。由于功能性测试主要是验证TSF功能的正确性，可能无法检测出相关漏洞，因此必须根据开发者的编码规范和具体的编码方法，设计针对性的穿透性测试用例来验证不存在缓冲区溢出的问题。

（2）侧信道攻击。算法运行过程的功耗、电磁辐射等信息可能被攻击者利用，以旁路TSF的访问控制功能获取密钥和敏感信息。防护侧信道攻击可从2个层面来考虑：局部防护措施通过修改算法流程、增加硬件噪声等来降低侧信道的信噪比，以提高攻击的复杂度；全局防护措施通过设计全新的算法，在某种假设模型下，证明其可以抵抗侧信道攻击。通常这2种防护机制都可以选择TOE内TSF的传送数据(FPT_ITT)、TOE内部传送(FDP_ITT)等安全功能组件，并通过TSF内涵功能来实现，但这些防护机制本身的不可旁路性却要通过其他TSF内涵或元功能来实现。对此开发者和评估者的任务分别如下。

（a）开发者应在ADV_FSP中描述密码算法调用接口以及可能的侧信息泄露(如芯片表面或电源)接口，并简要论述侧信道防护措施及其可能产生的效果(如信噪比值)，在ADV_TDS、ADV_IMP文档中描述防护措施的具体实现细节。在ADV_ARC文档中，开发者可以引用设计分解类文档的论述，以说明对密钥访问功能的不可旁路性是如何实现的，同时还要论述这些防护机制本身的不可旁路性是如何实现的。

（b）评估者应根据ADV_ARC文档的描述，分析侧信道防护机制是如何通过合作方式实现的。对于通过TSF内涵功能来实现的措施，需要开展功能性测试来验证其正确性；对于TSF元功能来实现的情况，将设计针对性的穿透性测试用例来验证其有效性。