FIPS 140-2 与FIPS 140-3的差异-3

在上一篇关于迁移到FIPS 140-3的系列博客第2部分中将ISO/IEC 19790/ISO/IEC 24759各章节的差异点过了一遍，包括密码模块规范、密码模块接口、角色、业务和身份认证。在这篇博客中，将讨论运行环境、物理安全、其他攻击的消减、以及软件/固件安全（这是FIPS 140-3中的新章节）。我们还将讨论它们如何映射到现有FIPS 140-2需求，并重点讨论某些差异以及对密码模块厂商的影响。
如果熟悉FIPS 140-2，那么你很可能了解篡改留痕（tamper evidence）、完整性检查或者CC（Common Criteria）对OS的要求，以及在某些情况下的故障注入测试。因为在某种程度上你已经接触了物理安全，运行环境，或其他攻击的消减。这三节分别对应FIPS 140-2的4.5、4.6和4.11节，以及ISO/IEC 19790的7.7、7.6和7.12节。

物理安全

FIPS 140-2和FIPS 140-3中的物理安全部分非常相似，都有相同的三个加密模块实施例：单芯片、多芯片嵌入（Multiple-chip embedded,）和多芯片分离（Multiple-chip standalone）。但是，有一些细微的变化以及一些新的内容。
最明显的差异之一是“半透明（translucent）”一词的使用。根据定义，半透明含义是“允许透过光线，但不允许透过细节形状。” FIPS 140 -3 的7.7.2小节讲到，SL2级要求“篡改留痕（tamper-evident ）的材料、涂层或外壳[07.19]要么不透明，要么对可见光（比如：光波长范围的400 nm - 750 nm）呈半透明，以防止模块内关键区域的运行信息被收集。目前，“可见光”的定义在FIPS 140-2 IG 5.1中曾提出，因此，很高兴看到新标准给出了清晰的定义。然而，从解释需求的角度，我们相信IG 5.1可能会继续存在。它对SL2级要求哪些组件可见，那些不可见作出了重要的澄清。
相对于FIPS 140-2，FIPS 140-3（ISO 19790 第7.7.2小节）中可见的一个额外变化是篡改留痕封条（tamper evident seals）的使用。SL3级如果使用这种封条，那么封条必须有唯一编号或者独立标识（例如：唯一编号的证据条或者唯一标识的全息封条）。这可能意味着需要采购新的封条。并非所有SL3级物理安全的密码模块都要用封条来满足篡改留痕的要求，但是我们认为这是读者需要知晓的一个变化。
最后，在FIPS 140-2的4.5小节，只有SL4级要求才提到术语EFP（环境失效保护，Environmental Failure Protection）和EFT（环境失效测试，Environmental Failure Testing）。EFT用特定方法来提供合理的保证，以确保密码模块的安全性不会受到温度和电压波动的影响。FIPS 140-3的新方面是，所有加密模块物理实施例现在都要求包含EFP特性或在SL3级进行EFT测试。为了通过SL3级的验证，硬件制造商很可能面临一些额外的负担。但厂商仍然还有在EFP或EFT之间做选择的灵活性。从验证的角度看，SL3级要求证明厂商已经实现EFP或EFT（因此，我们认为这在很大程度上是文档工作）
SL4级要求模块必须实现EFP并抵御故障诱导（fault induction，译注1）。除文档要求之外，EFP特性必须经过测试实验室的验证。故障诱导的消减技术和消减指标要按照附录B的要求（待发布）文档化。回顾FIPS 140-2标准，故障诱导在“4.11 其他攻击的消减”一节有所提到。在开发该标准时，还没有涉及到可测试的安全要求。既然FIPS 140-3中给出了可测试的安全要求，那么在SL4级中就要求抵御故障诱导。这就过渡到内容的下一部分：”7.12 其他攻击的消减“。
译注1：
故障诱导（fault induction）是通过让密码模块产生故障执行出错，从而达成跳过某些重要的校验、运算步骤的目的。故障诱导跟故障注入（fault injection）的某些手法可能相同，但也可能不同。而且故障诱导目的性更强，不但希望密码模块执行出错，还希望它能按照预期的方式出错。

其他攻击的消减

与FIPS 140-2类似（故障诱导测试除外），本节是对由加密模块实现的特定攻击消减措施的全面概括，该模块在标准的其他部分没有显式定义测试需求。本节还将用于解决附录F中没有提到的非侵入（Non-Invasive）式安全需求。附录F我们将在另一篇文章中介绍。
举证责任在很大程度上仍是一项文档工作(见ISO 19790的B.2.12节)，但在SL4级文档还得说明测试方法和消减技术的有效性。所以，如果想为你的炫酷和突破性的安全特性获得额外加分，那么准备好用确凿有力的证据来支持它吧。

运行环境：告别CC的适用性

与它的前身相比，本部分(FIPS 140-2标准中的4.6)经历了相当大的改革。在SL1和SL2上，我们在操作系统底层的软件和固件模块（AS6.05、AS6.06、AS06.08）上看到了许多相同的需求，操作系统必须提供进程隔离并防止不受控的CSP（关键安全参数Critical Security Parameter）访问。然而，我们也看到“有限的（limited）”和“不可修改的（non-modifiable）”环境定义已经被加入对固件的要求（AS06.05 到 AS06.08），“可修改的”环境定义被加入对软件的要求（AS06.05 到 AS06.29）。之前固件和软件的定义放在IG 1.3, 1.16和1.17中。

固件供应商

目前可以置身事外，谈到完整性的时候自然会涉及他们。
这里最值得注意的变化是在不参照CC（Common Criteria）的情况下按照SL2级要求验证软件模块的可能性。以前，软件厂商基于CC程序验证操作系统的能力很有限，这是由于附录B的要求和被批准的PP（保护轮廓）间存在冲突。对于SL2级加密模块，需要在EAL2或更高级别对操作系统进行验证。然而，NIAP早就放弃了依据EAL对产品的验证，转而采用基于PP的评估方法。2015年，附录得到了急需的更新，现在直接对应NIAP批准的通用操作系统和移动设备基础的PP。
操作系统的成功验证仍然很大程度上依赖于操作系统厂商。虽然一些主要的参与者(苹果、微软、三星等)已经这样做了，但仍有绝大多数操作系统没有按照NIAP的要求进行验证。

在FIPS 140-3中，这一要求已不复存在。但现在还不要开香槟庆祝，第7.6节介绍了一系列实际上符合NIAP PP需求的新需求。在SL2级，底层环境需要支持基于角色的访问控制、身份的标识和认证以及审计，这可能会给软件厂商带来一些麻烦。
概括起来，就是（经测试通过的）对模块和模块的SSP（敏感安全参数Sensitive Security Parameter）、明文数据、审计数据等的访问控制必须被实施。操作系统的身份标识和认证机制必须满足7.4.4节的要求。此外，模块必须利用OS审计功能来捕获以下审计事件（带有时间戳）：

对SSP和模块数据的访问
对CO（Crypto Officer）功能的不合法的输入
角色管理（如果已实现）
任何对CO功能的使用
对身份认证数据的访问请求
所有对I&A（身份标识&认证）机制的使用
CO角色的明确假设
操作系统也必须能够审计：
对审计记录的读/写访问
对模块数据或SSP的文件系统访问
角色管理
身份认证数据管理
所有对可信通道的使用

厂商的证据还必须参考有关上述安全机制的管理指南，因此，如果您还没有这样做，那么是时候拿出手册了!
简而言之，对于那些希望用软件模块通过SL2级认证的人来说，这会有一个全新的机会。但尽管这些要求可能不像CC评估那么严格，仍有许多保障活动需要满足。并且很可能需要对模块进行一些代码更改，以便利用底层OS对应的安全特性。不幸的是，对于希望实现软件SL3级的厂商来说，这是不可能的，因为软件仅限于通过SL2级认证。不过，值得庆幸的是，在SL1级中，上述要求几乎不存在。

软件/固件安全-有新要求还是更多同类要求?

在FIPS 140-3中，我们看到了7.5节“软件/固件安全”的介绍。顾名思义，这适用于固件和软件模块，硬件模块的固件和软件组件，或者一个混合模块中的独立硬件组件中的固件组件。
本节的前几个需求讨论使用已批准的完整性技术进行固件/软件完整性测试。本节接着讨论固件/软件加载测试。这些听起来很熟悉，对吧？这是因为我们以前在FIPS 140-2 DTR：AS06.08、AS09.22、AS09.23、AS09.24、AS09.34、AS09.35和AS09.36中见过这些要求。

虽然这看起来是一个“比较新”的部分，有来自两个不同的FIPS 140-2小节（4.6运行环境和4.9自检）的相关需求，但这显然不只是一些标准的整理工作。首先，我们马上在AS05.05中看到了一个新的许可：“软件/固件完整性检测必须应用于模块本身或另一个经过验证的以批准模式运行密码模块。”一段时间以来，这一直是一种可以接受的做法，但从未在标准中正式说明。这为加密库提供了一些灵活性，因为加密库在自己执行测试时可能存在某些限制。

我们还看到AS05.05要求认可了IG 1.9引入的软件/混合实施例并增加了一些说明，但也稍稍带来了一些新变化。以前，对于所有级别，16bit错误检测码都可用于基于固件的模块。现在，EDC（错误检测码error detection code）可用于固件或软件，但仅限于SL1级且模块由硬件组成时。如果密码模块仅由硬件实现，那么显然这些要求将再不适用。这里的关键要点是，在SL1级EDC仍可以接受，但仅适用于硬件模块或混合模块的独立硬件组件内的固件和软件。

对于软件和固件模块，或混合模块中的软件和固件，这有一个新的转折——SL1级要求这些模块必须实现“经批准的完整性技术”。听起来是不是很熟悉？这是因为它是我们之前在FIPS 140-2中见过的语言，FIPS 140-2将其定义为“经批准的消息验证码或数字签名算法”。然而，经批准的完整性技术定义已发生变化。ISO/IEC 19790现在将其定义为“经批准的哈希、消息认证码或数字签名算法”。所以，虽然你不一定要使用一个密钥算法（如SL1级的HMAC或ECDSA），但至少需要在固件模块的完整性检查中用SHA替换CRC-32。

下一个重大变化是AS05.17规定：现在SL2级要求所有模块必须在模块的软件或固件上包含HMAC或数字签名。而SL3和SL4级要求模块必须在软件或固件上实施数字签名（AS05.20）保护。对于独立硬件组件中的固件或软件（如果是混合固件或混合软件模块的一部分）则例外。例如，如果ASIC是混合模块的一部分，则ASIC所需的固件可以通过EDC进行测试。不用说，对SL2和SL3级固件模块要求HMAC或数字签名的这一变化，表明针对设备厂商要求的显著变化。
此外，AS05.10要求完整性检测期间产生的所有临时数值在测试完成后要被清零（zeroize）。这也代表了一个重大的新变化，因为在FIPS 140-2中，以前只涉及对明文CSP清零。
正如我们在前一篇文章中所解释的，AS05.06引入了组合与分开的消息认证码和数字签名的概念。根据固件或软件映像的构建方式，厂商可能会使用其中一种手段。无论如何完成，完整性检测都必须能够通过AS05.11定义的模块接口（HMI、SFMI、HSMI或HFMI）来按需调用，这也是在我们之前的文章中定义的。
接下来，我们看到FIPS 140-3将认可并纳入IG 9.7。此IG处理AS05.13中描述的相同的软件/固件加载测试。特别是，它指出如果正在加载的软件或固件映像是用已验证模块映像进行完全替换或覆盖，则此测试不适用（具有SL2级物理安全的固件模块除外）。

固件/软件安全方面的其他一些值得注意的事项:

第15条要求SL2级模块只能包含编译后的二进制文件，不包含源代码、目标代码或JIT编译的代码。
第16条要求SL2级模块必须禁用任何允许检查可执行代码的调试接口。
简而言之，虽然它看起来像一个全新的章节，但大多数厂商应该熟悉大部分需求，因为它们实际上是对4.6 运行环境和4.9 自检中一些现有要求的增强。这些章节的一些内容明显违背FIPS 140 - 2标准，在不同级别要求的完整性检测类型，以及它如何适用于不同的软件和固件组件，超出CSP之外的扩展清零要求、按需的完整性检测，通过“绑定”（bound）模块进行完整性检测，以及需要何种运行检测。对于许多厂商来说，特别是固件模块，很可能发生的一件事就是得修改代码。