译｜王祖熙 （花名：金九 )

蚂蚁集团开发工程师

负责国产化密码库 Tongsuo 的开发和维护

专注于密码学、高性能网络、网络安全等领域

本文 9658 字 阅读 20 分钟

本文翻译 OpenSSL 官网文档：https://www.openssl.org/docs/OpenSSL300Design.html

Tongsuo-8.4.0 是基于 OpenSSL-3.0.3 开发，所以本文对 Tongsuo 开发者同样适用，内容丰富，值得一读！

由于文章篇幅较长，今天带来的是 《FIPS模块》 部分内容，已发布文章《介绍、术语与架构》、《Core 和 Provider 设计》可看发表记录。后续内容将随每周推送完整发布，请持续关注铜锁！

FIPS 模块

这是一个经过 FIPS 140-2 验证的加密模块，它是一个只包含经过 FIPS 验证/批准的加密算法的 Provider，非 FIPS 算法将由默认 Provider（而不是 FIPS 模块）提供。

该模块是可以动态加载的，不支持静态链接。

FIPS 模块本身不会有 "FIPS 模式"，可以使用 FIPS Provider 的 OpenSSL 将具有与 FIPS-Module-2.0.0 兼容的"模式"概念。

FIPS 模块版本编号

版本将为 FIPS-Module-3.0。

任何后续的修订版本将以与先前发布类似的方式进行标记，例如 3.0.x。

对于更改通知或重新验证，FIPS 模块的版本号将更新以匹配当前的 OpenSSL 库版本。

检测 FIPS 边界内的变更

为了进行验证，我们需要检测是否有任何相关的源代码发生了变化。

可以使用一个脚本来对 C 源代码进行标记化处理，就像 C 预处理器一样，但还要教会它忽略源代码中的某些部分：

• 系统的#include指令。
• 在 FIPS 模式下被条件排除的代码（如下文中所述的条件代码）。

（提醒：C 预处理器可以将所有非换行空白字符合并，并在每个标记之间留下标准的单个空格，对于此目的，注释被视为空白字符）

标记化处理的结果可以通过校验和进行处理，该校验和存储在与源代码文件相对应的文件中，并最终进行版本控制。

该过程大致如下（并非完全相同，这只是一个代码示例，用于展示整个过程）：

    for f in $(FIPS_SOURCES); do
        perl ./util/fips-tokenize $f | openssl sha256 -r
    done | openssl sha256 -hex -out fips.checksum

还会有一些机制来提醒我们有关变化的信息，以便我们可以采取适当的措施。例如：

    git diff --quiet fips.checksum || \
        (git rev-parse HEAD > fips.commit; scream)

关于 scream 的具体操作尚待确定。

更新 fips.checksum 应该作为正常的 make update 的一部分进行，这是通常用于更改和检查版本控制文件的方法，OpenSSL 的持续集成已经运行了此命令，以确保没有遗漏任何内容，并且如果有内容被更改，将中断构建过程，运行make update也是正常的 OpenSSL 发布流程的一部分。

如何对已签名校验和的更改做出反应

尽管发生了变更，但我们仓库中的校验和更改本身并没有什么大不了的，它只是提醒我们需要额外关注 FIPS 源代码。

有两种可能的情况：

1. 当即将发布新版本，并且 fips.checksum 不再包含上一个经过验证的源代码的校验和时，将 FIPS 源代码发送给实验室，并开始更新验证流程。
2. 在发布新版本的同时，fips.checksum 不再包含上一个经过验证的源代码的校验和时，将 FIPS 源代码（包括 diff 文件和变更列表）发送给实验室，并启动相应的更新验证流程。

已验证的校验和列表将在其他地方列出（稍后确定具体位置）。

编译

对于每个 FIPS Provider 的源文件，我们计算该文件的校验和，并将其与 fips.checksum 中收集的校验和进行比对，如果存在不匹配，将拒绝编译。

FIPS 模式

FIPS 模块仅包含经过 FIPS 验证的密码算法，任何 FIPS 模式的“切换逻辑”将位于 FIPS 模块边界之外 - 这将由“fips”属性处理。

与 FIPS 模式相关的条件代码在单独的部分中讨论。

以下的 FIPS API 将继续可供应用程序使用（为了保持一致性，使用了与 1.1.1 版本中相同的名称）：

• int FIPS_mode_set(int on)

确保当前全局属性设置中设置了“fips=yes”（当 on != 0 时），或者未设置“fips”（当 on == 0 时）。这还将尝试使用属性“fips=yes”获取 HMAC-SHA256 算法，并确保它成功返回。

• int FIPS_mode(void)

如果当前的全局属性字符串包含属性“fips=yes”（或“fips”），则返回1，否则返回0。

我们可以检查当前是否有提供 FIPS 算法的 Provider 可用，并稍微以不同的方式处理。

• int FIPS_self_test(void)

如果 FIPS_mode() 返回true，则运行 KATs。

完整性测试将不在此处涵盖，如果我们决定提供它，它将是一个单独的函数。

成功时返回1，失败或没有 OpenSSL FIPS Provider 时返回0。

注意：这些函数只能在 OpenSSL FIPS Provider 的上下文中运行，而不能在其他任何 FIPS Provider的上下文中运行。这些是过时的遗留接口，应使用EVP_set_default_alg_properties()函数进行非遗留配置。

角色和身份认证

有两个隐含的角色 - 密码官（CO）和用户。这两个角色都支持相同的服务，唯一的区别是 CO 负责安装软件，该模块不应支持用户身份验证（对于1级而言不是必需的），所有这些都可以在安全策略中解释，而无需编写具体的代码。

有限状态模型（FIPS 140-2第4.4节）

需要定义一个状态机。

我们将需要以下状态：

• 自检状态 - 初始化、运行、自检、错误、关闭（可能还包括后触发状态）
• 错误状态 - 如果自检失败，模块应返回该操作的错误。可以尝试清除错误并重复操作，如果失败仍然存在，模块应进入错误状态，这可以是一个硬错误状态，其中所有加密操作都失败，或者是一个功能降级状态，其中失败的组件仅在使用时返回错误。

触发自检失败的方式包括：

1. 1. 连续测试（生成密钥对的成对测试（签名/验证）和从熵源比较测试中验证输入到 DRBG 的随机数不相同）。
   2. DRBG 健康测试 - 这可以始终在 RNG 中引发错误（而不是设置全局错误状态）。
   3. 安装、启动或按需的 POST 完整性测试失败。
   4. 启动或按需的 POST KAT 失败。

将提供一个内部 API 来设置上述情况的失败状态。

状态机

在状态机中未显示的状态以虚线表示。进入和离开错误状态的边缘以虚线表示，以表明不希望遍历这些边缘。

| 状态模型由这些状态组成：1. 电源关闭（Power Off）：FIPS 模块未加载到应用程序中，共享库不在内存中。

1. 电源开启（Power On）：FIPS 模块已被应用程序加载，并且共享库在内存中。默认入口点构造函数将被启动。
2. 初始化（Initialisation）：调用OSSL_provider_init。
3. 完整性检查（Integrity Check）（POST 完整性）：模块对自身进行校验，并验证其是否被恶意更改。（在 FIPS 提供程序的 OSSL_provider_init() 期间运行）。
4. 自检（Self Test）（POST KAT）：FIPS 模块在安装期间执行其自检，或者在通过 API 调用进行按需自检。
5. 运行（Running）：FIPS 模块处于正常运行状态，可以使用所有 API，并进行连续测试。
6. 错误（Error）：FIPS 模块进入错误状态，调用所有加密 API 将返回错误。
7. 关闭（Shutdown）：FIPS 模块正在被终止并从使用应用程序中卸载。

状态之间的边缘关系如下：

1. 从电源关闭（Power Off）到电源开启（Power On）：此转换由操作系统在将共享库加载到应用程序时执行。
2. 从电源开启（Power On）到初始化（Initialisation）：当调用共享库的构造函数时发生此转换。
3. 从电源开启（Power On）到关闭（Shutdown）：如果无法调用构造函数或构造函数失败，将触发此转换。
4. 从初始化（Initialisation）到完整性检查（Integrity Check）：此转换在初始化代码完成后发生，计算模块完整性校验和，并与预期值进行比较。
5. 从初始化（Initialisation）到错误（Error）：如果初始化代码在启动自测之前遇到错误，将触发此转换。
6. 从完整性检查（Integrity Check）到运行（Running）：对于所有启动过程中完整性检查成功的情况，发生此转换。
7. 从完整性检查（Integrity Check）到自测（Self Test）：在安装过程中，如果完整性检查成功，发生此转换。
8. 从完整性检查（Integrity Check）到错误（Error）：如果完整性检查失败，将触发此转换。
9. 从运行（Running）到关闭（Shutdown）：当 FIPS 模块最终化时发生此转换。
10. 从运行（Running）到错误（Error）：如果连续测试中的任何一个失败，将触发此转换。
11. 从运行（Running）到自测（Self Test）：应用程序手动启动自测时触发此转换。不重新运行完整性检查。
12. 从自测（Self Test）到运行（Running）：自测通过时发生此转换。
13. 从自测（Self Test）到错误（Error）：如果自测失败，将触发此转换。
14. 从关闭（Shutdown）到电源关闭（Power Off）：当 FIPS 模块从应用程序的内存中卸载时发生此转换。
15. 从错误（Error）到关闭（Shutdown）：当 FIPS 模块最终化时发生此转换。

如果可能的话，我们应该尽量在运行状态下注册算法，任何进入运行状态的转换都应该允许注册/缓存密码算法，而任何进入错误或关闭状态的转换都应该清除 libcrypto 中的所有缓存算法，通过采用这种方法，我们可以避免在所有密码工厂函数中检查状态，这样可以避免为自我测试（手动启动时）提供特殊情况访问权限，同时阻止外部调用者的访问。

服务

FIPS模块提供以下服务。

• 显示状态。如果“运行”状态处于活动状态，则返回1，否则返回0。
• 密码服务，如HMAC、SHS、加密。请参阅附录3-算法。
• 自检（按需执行）- libcrypto 中提供了一个名为FIPS_self_test()的公共 API来访问此方法。所使用的方法必须与初始化时触发的方法相同，安全策略将指明只有在没有其他密码服务运行时才能访问此方法。
• 密钥清零。请参阅 CSP/Key 清零。

这些服务仅在运行状态下运行，在任何其他状态下尝试访问服务将返回错误，如果自检失败，则任何尝试访问任何服务的操作都应返回错误。

自测试

自测试包括上电自测试（POST）和运行时测试（例如，确保熵不会重复作为 RNG 的输入）。

POST 包括模块完整性检查（每次运行使用 FIPS 的应用程序时运行）以及算法 KAT（可以在安装时运行一次）。

POST 测试在调用 FIPS 模块的OSSL_provider_init()入口点时运行。

为了按照正确的顺序实现完整性测试和 KAT，模块需要访问以下数据项：

1. 库的路径；
2. 库内容的 HMAC-SHA256（或包含该值的文件的路径）；
3. 指示库已安装并通过 KAT 的指示器；
4. 该指示器的 HMAC-SHA256。

这些值将成为可以通过OSSL_PROVIDER对象和相关的OSSL_PARAM getter获取的参数的一部分。将使用一个“更安全”的获取值函数来获取这些值，该函数不会展开环境变量等。此外，还需要传递用于访问和返回库内容的函数（可能是基于 BIO 的，通过将 Core 传递给模块的调度表中的少量 BIO 函数来实现），以便模块可以生成自己的库摘要。

新的 OpenSSL“fips” 应用程序将提供安装（运行 KAT 并输出配置文件数据）和检查（检查配置文件中的值是否有效）的功能。

模块的默认入口点（DEP），即 Linux 库中的 “.init” 函数，将设置一个模块变量（可能是状态变量），在OSSL_provider_init()中将检查此变量，并且如果设置了（通常会设置），则验证文件中的值。这个两步过程满足了 FIPS 要求，即 DEP 确保测试运行，但允许我们在正常运行时初始化模块的其余部分时实现这些测试。

作为构建过程的一部分，必须将 FIPS 模块的完整性校验和保存到文件中，这可以通过脚本完成，它只是使用已知固定密钥对整个 FIPS 模块文件进行 HMAC_SHA256 运算的结果，如果库已签名，则必须在应用签名之后计算校验和。

至少具有112位的固定密钥将嵌入到 FIPS 模块中，用于所有 HMAC 完整性操作，这个密钥也将提供给外部构建脚本。

出于测试目的，即使其中一个或多个测试失败，所有活动的 POST 测试也会运行。

完整性校验和的位置

完整性校验和将在安装过程中保存到一个单独的文件中，默认情况下，该文件将与 FIPS 模块本身位于相同的位置，但可以配置为位于不同的位置。

已知答案测试

KAT 的目的是对密码模块进行健康检查，以识别在电源周期之间的模块的严重故障或变化，而不是验证实现是否正确。

FIPS 140-2 IG 的规则指定了需要测试每个已支持的算法（不是每个模式），如果一个算法作为另一个测试的组成部分进行了测试，则不需要单独的测试，以下是需要进行测试的算法列表：

• 加密/解密算法

• • AES_128_GCM2
  • TDES_CBC

• 哈希算法

• • SHA1
  • SHA256 在其他地方已经要求测试
  • SHA512
  • SHA3-256

• 签名/验证测试

• • DSA_2048
  • RSA_SHA256（使用PKCS #1 v1.5填充）
  • ECDSA P256

• 任何支持的 DRBG 机制的 DRBG 健康测试

• • CTR（AES_128_CTR）
  • HASH - SHA256
  • HMAC - SHA256

• 派生测试（计算Z）

• • ECDSA P256
  • ECDH
  • KDF（密钥派生函数）
  • KBKDF（用于 TLS 的 HKDF）

注意：完整性测试使用 HMAC-SHA-256，因此不需要单独进行 HMAC 测试。

接口访问

为了方便修改和更改运行的自测试，自测试应该是数据驱动的，POST 测试在注册任何方法之前运行，但方法表仍然可以间接使用，仍然需要较低级别的 API 来设置密钥（参数、公钥/私钥），密钥加载代码应该在一个单独的函数中进行隔离。

需要一个初始化方法来为高级函数设置所需的依赖项，例如在执行基本调用之前可能需要调用 set_cpuid。

应为摘要、密码、签名、DRBG、KDF、HMAC 提供不同类型的自测试 API。

传递给这些测试的参数是 KAT 数据。

安全强度

SP 800-131A rev2 在某些日期之后禁止使用特定的算法和密钥长度，这些项目与安全强度相关联。

允许具有至少112位安全强度的算法。

对于签名验证，为了遗留目的，允许使用安全强度至少为80且低于112的算法。

这两个值可以在FIPS模块中定义和执行，也可以在安全策略文档中更简单地处理。

可以通过公共API定义这些最小值，并允许设置它们。

还应添加目标安全强度的概念，该值将在密钥生成算法中使用，这些算法通过其标准指定了目标安全强度参数。

SP800-56A & 56B

这些标准包含密钥协商协议，为了测试这些协议，加密模块需要包含以下低级原语。

• 计算密钥方法 - 这些已经存在。（例如 DH_compute_key()）。
• 密钥生成 - （目前缺少 RSA FIPS 186-4 密钥生成）。
• 密钥验证 - （大部分已经实现）。

FIPS 186-4 RSA 密钥生成

• 已经编写了 RSA 密钥生成的初始代码（https://github.com/openssl/openssl/pull/6652）；

尚未完成的工作是将其整合到 FIPS 模块中，OpenSSL FIPS Provider 将具有强制密钥大小限制的逻辑；

• 对于 RSA、DSA 和 ECDSA 密钥对生成，需要进行成对一致性测试（条件自检）。由于在密钥生成过程中无法确定密钥的用途，FIPS 140-2 IG 规定相同的成对测试可以用于签名和加密两种模式；
• 不允许使用 1024 位的 RSA 密钥生成；
• 密钥生成算法具有目标安全强度的概念。例如，RSA 的密钥生成代码需要进行以下检查：

if (target_strength < 112
    || target_strength > 256
    || BN_security_bits(nbits) < target_strength)
    return 0;

DH 密钥生成

• DH 密钥生成 - 可能需要将其拆分为符合标准步骤的形式。目前它是一个相当复杂用时也用于验证的整体函数。

密钥验证

• RSA SP 800-56B 密钥验证 - 公钥、私钥和密钥对的检查已添加到 PR＃6652，符合标准的要求；
• 需要检查 DH 密钥验证是否符合标准；
• EC 密钥验证符合标准要求；
• AES-XTS 模式需要进行扭曲密钥检查。

对于KAS DH参数，支持两种类型：

1. 已批准的安全素数群如下：

（其中 g=2，q=(p-1)/2，priv=[1, q-1]，pub=[2, p-2]）

TLS：(ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192)

IKE：(modp-2048, modp-3072, modp-4096, modp-6144, modp-8192)

只有上述安全素数可以进行验证-其他任何素数都应该失败。

安全素数可用于至少112位的安全强度，可能需要进行 FIPS 特定的检查以验证群组。

2. FIPS 186-4 参数集仅用于向后兼容性，安全强度仅为112位。群组为 FB (2048, 224) 和 FC (2048, 256)。这需要保存种子和计数器以进行验证。

如果需要同时支持两种类型，则需要不同的密钥验证代码。

现有的DH_Check()需要进行 FIPS 特定的检查来验证批准的类型。

密钥生成对于两者来说是相同的（安全强度和私钥的最大位长度是输入）。

DSA 在 FIPS 186-4 中定义为 “FFC”，DSA 密钥生成/密钥验证可以重新设计，以更好地匹配标准步骤，这将有助于密钥验证，并且如果需要，可以在 DH 情况下进行重用。

GCM IV 生成

对于 FIPS 模块，AES GCM 有与唯一密钥/IV 对相关的要求，即：

• 加密时密钥/IV 对必须是唯一的；
• IV 必须在 FIPS 边界内生成；
• 对于 TLS，IV 的计数部分必须由模块设置，模块必须确保当计数用尽时返回错误；
• 对于给定的密钥（对于任何 IV 长度），认证加密函数的总调用次数必须小于 ；
• 模块断电不应导致 IV 的重复使用。

IV 生成将使用随机构造方法（来自SP 800-38D），其中包括一个自由字段（将为 NULL）和一个随机字段，随机字段将使用一个能提供至少96位熵强度的 DRBG，该 DRBG 需要由模块进行种子生成。

现有代码需要修改，以便在init()阶段未设置 IV 时生成 IV，然后可以使用do_cipher()方法在需要时生成 IV。

int aes_gcm_cipher()
{
    ....
    /* old code just returned -1 if iv_set was zero */
    if (!gctx->iv_set) {
        if (ctx->encrypt) {
           if (!aes_gcm_iv_generate(gctx, 0))
               return -1;
           } else {
               return -1;
           }
        }
    }
}

生成代码如下所示：

#define AES_GCM_IV_GENERATE(gctx, offset)                   \
    if (!gctx->iv_set) {                                    \
        int sz = gctx->ivlen - offset;                      \
        if (sz <= 0)                                        \
            return -1;                                      \
        /* Must be at least 96 bits */                      \
        if (gctx->ivlen < 12)                               \
            return -1;                                      \
        /* Use DRBG to generate random iv */                \
        if (RAND_bytes(gctx->iv + offset, sz) <= 0)         \
            return -1;                                      \
        gctx->iv_set = 1;                                   \
    }

生成的 IV 可以通过EVP_CIPHER_CTX_iv()方法获取，因此不需要使用 ctrl id。

理想情况下，在 FIPS 模式下尝试设置 GCM IV 参数将导致错误。实际上，可能仍然有一些应用程序需要设置 IV，因此建议将其指定为安全策略项。

安全策略还需要说明以下内容：（参见 FIPS 140-2 IG A.5）

• 当电源断开然后恢复时，应建立一个新的用于 AES GCM 加密的密钥；
• 使用相同密钥的总调用次数必须小于；
• 场景1：IV 生成符合 TLS 协议；
• 场景2：使用 NIST SP 800-38D（第8.2.2节）的 IV 生成方法。

CSP/Key 清零

当不再需要临界安全参数（CSP）时，我们必须将其全部设置为零，这可能会在不同的上下文中发生：

• 临时的 CSP 副本可能是栈或堆分配的，并且将在其使用范围内的相关函数中被清零；
• 一些 CSP 将与 OpenSSL 对象（如 EVP_PKEY 或 EVP_CIPHER_CTX）关联，具有与之相关联的生命周期，在这种情况下，当这些对象被释放时，CSP 将在该点被清零。在某些情况下，对象可能会被复用（例如，EVP_CIPHER_CTX 可以用于多个加密操作），在这种情况下，对象中仍存在的任何 CSP 将在其重新初始化为新操作时被清零。
• 一些 CSP（例如内部 DRBG 状态）可能会在加载 OpenSSL FIPS 模块的整个时间内存在，在这种情况下，状态将封装在 OpenSSL 对象中。所有 OpenSSL Provider（包括 FIPS 模块 Provider）都具有注册“卸载”函数的能力，该函数在关闭 OpenSSL 时（或因其他原因卸载模块）时将被调用，该卸载函数将释放（因此将清零）包含 CSP 的对象。
• 根据 FIPS 140-2 IG 4.7 的规定：仅用于执行 FIPS 140-2 第4.9.1节上电测试的密码模块使用的密码密钥不被视为 CSP，因此不需要满足 FIPS 140-2 第4.7.6节的清零要求。

OpenSSL FIPS 模块将包含其自己的标准OPENSSL_cleanse()函数的副本来执行清零操作，这是使用特定于平台的汇编语言实现的。

DRBG

在旧的 FIPS 模块中存在以下 API，可能需要重新添加：

• FIPS_drbg_health_check：按需运行 DRBG KAT 测试，我们需要使其可用。
• FIPS_drbg_set_check_interval：设置运行 DRBG KAT 测试之间的间隔（生成调用的次数）。这似乎不是必需的，这些测试在上电时运行，但后续不需要运行，但这个调用对于故障测试很有用。

推导函数

根据 FIPS 140-2 IG 14.5 中的第2点要求，CTR DRBG 将无条件支持派生函数，如果禁用派生函数，当前的代码在重新生成种子时会出现问题。此外，如果没有派生函数，需要从实验室获得额外的理由支持。

测试要求

• 在uninstantiate()函数中需要证明内部状态已被清零；
• 故障测试需要一个函数，使 DRBG 始终产生相同的输出。

其他需要考虑的事项

除了下面描述的熵之外，还需要考虑以下几点：

• 应考虑实施 NIST SP 800-90C 10.1.2 中的熵扩展；
• 需要更好的 DRBG 选择机制，以在可用的 DRBG 之间进行选择；
• 支持预测抵抗，即在请求时尝试从我们的来源收集更多熵。
• 我们需要弄清楚 DRBG 层将是什么样子，代码的很大一部分需要放在 FIPS 模块内。目前，此代码访问 EVP 功能，而这些功能可能不会在模块内部公开。例如，drbg_ctr_init() 从 NID 解析 EVP_CIPHER，然后设置一个 EVP_CIPHER_CTX。

熵

对于所有平台，操作系统将提供熵。对于某些平台，还可以使用内置的硬件随机数生成器，但这将引入额外的验证需求。

对于类 UNIX 系统，将使用系统调用getrandom、getentropy或随机设备/dev/random作为熵源，优先考虑使用系统调用。可以替代/dev/random的其他强随机设备包括：/dev/srandom和/dev/hwrng。请注意，/dev/urandom、/dev/prandom、/dev/wrandom和/dev/arandom在没有额外的证明的情况下不能用于 FIPS 操作。

在 Windows 上，将使用BCryptGenRandom或CryptGenRandom作为熵源。

在 VMS 上，将使用各种系统状态信息作为熵源。请注意，这将需要证明和分析以证明源的质量。

对于 iOS，将使用 SecRandomCopyBytes 生成具有密码学安全性的随机字节。

FIPS 仅允许将一个熵源归因于模块，因此 FIPS 模块将完全依赖于前述的操作系统源，不会使用其他来源，例如 egd、硬件设备等。

完成熵解决方案的工作

需要将 DRBG 健康检测添加到随机框架中，以检查输入到 DRBG 的种子材料，检查的目的是确保没有连续的两个种子材料块是相同的，该检查在所有熵源被合并在一起后进行，如果检查失败，则 DRBG 的种子重新生成操作将永远失败。我们可以定义使用的块大小为64位，这是在意外接收到重复块的概率（）和从操作系统中获取过多熵量之间的平衡（因为第一个块会被丢弃），其他明显可用的块大小包括128位和256位。

使用后，初始数据块必须被清零和丢弃。

GCM的初始化向量（IV）

FIPS 140-2 IG A.5 的最新更新指出，如果模块声称为 GCM 生成随机 IV，则需要提供证明，我们需要证明模块能够从操作系统获取所需的96位熵，如果使用阻塞调用操作系统的随机性源，并且至少使用这么多熵素材作为 DRBG 的种子材料，那么这应该不是无法解决的问题。

FIPS 模块边界

一旦进入 FIPS 模块提供的算法，在任何其他的加密操作中我们必须仍然保持在 FIPS 模块内部。根据 FIPS 规则，允许一个 FIPS 模块使用另一个 FIPS 模块。然而，在3.0设计中，为了简化起见，我们假设不允许这样做。例如，EVP_DigestSign*实现同时使用签名算法和摘要算法，我们不允许其中一个算法来自 FIPS 模块，另一个来自其他 Provider。

所有 Provider 在初始化时都被分配一个唯一的OSSL_PROVIDER对象，当 FIPS 模块被要求使用某个算法时，它会验证该算法的实现OSSL_PROVIDER对象是否与自己的OSSL_PROVIDER对象相同 （即传递给OSSL_provider_init的对象），例如，考虑使用 RSA 和 SHA256 的EVP_DigestSign*的情况，两个算法都会通过 Core 在 FIPS 模块外部进行查找，RSA 签名算法是第一个入口点，"init" 调用将被传递给要使用的 SHA256 算法的引用，FIPS 模块的实现将检查与其被要求使用的 SHA256 实现关联的OSSL_PROVIDER对象是否也在 FIPS 模块边界内，如果不是，则 "init" 操作将失败。下面的图示从 FIPS 模块的角度说明了这个操作。

请注意，在 FIPS 模块内部，我们使用了EVP的概念（如EVP_MD_CTX、EVP_PKEY_CTX等）来实现这一点，这些是 libcrypto 中 EVP 实现的副本，FIPS 模块没有与 libcrypto 进行链接，这是为了确保完整的操作都在 FIPS 模块的边界内进行，而不调用外部的代码。

ASN.1 代码

ASN.1 DER （Distinguished Encoding Rules） 用于：

• 序列化密钥和参数
• 序列化由两个值 r 和 s 组成的 DSA 和 ECDSA 签名
• 编码放置在 RSA PKCS#1 填充中的签名摘要 OBJECT IDENTIFIER（OID）
• 序列化 X.509 证书和证书撤销列表（CRL）
• 其他 PDU，如 PKCS #7/CMS、OCSP、PKCS #12 等。

FIPS 模块不会包含 ASN.1 DER 编码器/解析器的副本，也不会要求任何 Provider 对由 OpenSSL 实现的算法执行 ASN.1 序列化/反序列化。

所有 ASN.1 序列化/反序列化操作将在 libcrypto 中执行，复合值的密钥、参数和签名结构将作为项数组越过 Core/Provider 边界，使用 附录 2 - 参数传递 中定义的公共数据结构进行传递。

用于 RSA PKCS#1 填充的编码摘要 OID 将预先生成（与旧 FIPS 模块使用 SHA_DATA 宏相同）或根据需要使用简单函数生成，这个函数仅为 PKCS #1 填充支持的小型摘要集合生成编码的 OID，这些摘要 OID 在“OID 树”下的一个公共节点下，验证填充时将获取预期摘要的编码 OID，并将其字节与填充中的字节进行比较；不需要进行 DER 解析/解码。

下周我们将带来 "代码维护、FIPS 测试" 部分内容，等不及的小伙伴，可以戳下方“阅读原文”，查看铜锁语雀中的全篇文档哦！