OpenSSL 3.0.0 设计（一）｜介绍、术语与架构

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

蚂蚁集团开发工程师
负责国产化密码库 tongsuo 的开发和维护**专注于密码学、高性能网络、网络安全等领域

本文 4830 字 阅读 13 分钟

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

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

由于文章篇幅较长，今天发布的是介绍、术语和架构三部分内容，后续内容将随每周推送完整发布，请持续关注铜锁公众号。

1►介绍

这份文件概述了 openssl 3.0 的设计，它是在 1.1.1 版本之后的又一个版本。阅读本文需要您已经熟悉名为“openssl 战略架构”的文件，并具备对 openssl 1.1.x 的工作知识。

openssl 3.0 版本对大多数现有应用程序影响很小；几乎所有性能良好的应用程序都只需重新编译即可。

openssl 3.0 中的大部分改动都是内部架构重组，以促进建立一个可长期支持的加密框架，从而更好地将算法实现与算法 api 分离开来。这些结构性改动还有助于提高 openssl fips 密码模块 3.0 的可维护性。

在 openssl 3.0 中，目前标记为弃用 （deprecated） 的 api 不会被移除。

在 openssl 3.0 中，许多额外的低级函数将被标记为弃用 （deprecated） 的 api。

openssl 3.0 将同时支持应用程序具有处于 fips 模式 （使用 openssl fips 密码模块 3.0） 和非 fips 模式的 tls 连接。

有关 3.0 版本的更多最新信息，请参考 https://www.openssl.org/docs 上的链接。

2►术语

以下术语按字母顺序在本文中使用，简要定义如下：

• 算法 （algorithm） ：有时称为密码算法，是执行一组操作 （如加密或解密） 的方法。我们使用这个术语时是抽象的，通常通过名称 （例如“aes-128-cbc”） 来表示一个算法。

• 算法实现 （algorithm implementation） ：有时简称为实现 （implementation） ，是算法的具体实现。这主要以代码形式表示为一组函数。

• cavs 是密码算法验证系统。这是一种工具，用于测试密码实现是否符合 fips 标准。

• cmvp 是密码模块验证程序。这个过程验证密码实现是否符合 fips 标准。

• evp 是由 libcrypto 实现的一系列 api，使应用程序能够执行密码操作。evp api 的实现使用 core 和 provider 组件。

• core 是 libcrypto 中的一个组件，使应用程序能够访问 provider 提供的算法实现。

• csp 是关键安全参数 （critical security parameters） 。这包括在未经授权的披露或修改的情况下可能损害模块安全性的任何信息 （例如私钥、密码、pin 码等） 。

• 显式获取 （explicit fetch） 是一种查找算法实现的方法，应用程序通过显式调用来定位实现并提供搜索条件。

• fips 是联邦信息处理标准 （federal information processing standards） 。这是由美国政府定义的一组标准。特别是 fips 140-2 标准适用于密码软件。

• fips 模块是经过 cmvp 验证符合 fips 标准的密码算法实现。在 openssl 中，fips 模块以 provider 的形式实现，并以可动态加载模块的形式提供。

• 隐式获取 （implicit fetch） 是一种查找算法实现的方法，应用程序不会显式调用来定位实现，因此会使用默认的搜索条件。

• 完整性检查 （integrity check） 是在加载 fips 模块时自动运行的测试。模块会对自身进行校验，并验证是否被恶意修改。

• kas 是密钥协商方案 （key agreement scheme） 。它是两个通信方协商共享密钥的方法。

• kat 是已知答案测试 （known answer tests） 。它是用于对 fips 模块进行健康检查的一组测试。

• libcrypto 是 openssl 实现的一个共享库，为应用程序提供各种与密码学相关的功能。

• libssl 是 openssl 实现的一个共享库，为应用程序提供创建 ssl/tls 连接的能力，可以作为客户端或服务器。

• 库上下文 （library context） 是一个不透明结构，保存库的“全局”数据。

• 操作 （operation） 是对数据执行的一类函数，如计算摘要、加密、解密等。一个算法可以提供一个或多个操作。例如，rsa 提供非对称加密、非对称解密、签名、验证等。

• 参数 （parameters） 是一组与实现无关的键值对，用于在 core 和 provider 之间传递对象数据。例如，它们可以用于传输私钥数据。

• post 指的是 fips 模块的上电自检 （也称为开机自检） ，在安装、上电 （即每次为应用程序加载 fips 模块时） 或按需运行。这些测试包括完整性检查和 kat。如果 kat 在安装时成功运行，则在上电时不需要再次运行，但始终执行完整性检查。

• 属性 （properties） 用于 provider 描述其算法实现的特性。它们还用于应用程序查询以查找特定实现。

• provider 是提供一个或多个算法实现的单元。

• provider 模块是以可动态加载模块形式的 provider。

3►架构

架构应具备以下特性：

• 公共服务 （common services） 是应用程序和 provider 共用的构建模块，例如 bio、x509、secmem、asn.1 等。

• provider 实现密码算法和支持服务。一个算法可能由多个操作组成 （例如 rsa 可能有“加密”、“解密”、“签名”、“验证”等） 。同样，一个操作 （例如“签名”） 可以由多个算法实现，比如 rsa 和 ecdsa。provider 包含了算法的密码原语实现。此版本将包括以下 provider：

  a. 默认 provider （default） ，包含当前非遗留 （non-legacy） 的 openssl 密码算法；这将作为内置部分 （即 libcrypto 的一部分） 。

  b. 遗留 provider （legacy） ，包含旧算法的实现 （例如 des、mdc2、md2、blowfish、cast） 。

  c. fips provider，实现 openssl fips 密码模块 3.0；可以在运行时动态加载。

• core 使应用程序 （和其他 provider） 能够访问 provider 提供的操作。core 是定位操作的具体实现的机制。

• 协议实现，例如 tls、dtls。

本文档中有许多关于“evp api”的引用。这指的是“应用级别”的操作，例如公钥签名、生成摘要等。这些函数包括 evp_digestsign、evp_digest、evp_mac_init 等。evp api 还封装了执行这些服务所使用的密码对象，例如 evp_pkey、evp_cipher、evp_md、evp_mac 等等。provider 为后者集合实现了后端功能。这些对象的实例可以根据应用程序的需求隐式或显式地绑定到 provider 上。下面的 provider 设计部分将详细讨论。

架构具有以下特点：

• evp 层是对 provider 中实现的操作的薄封装，大多数调用会直接传递，几乎没有预处理或后处理过程。

• 将提供新的 evp api，以影响 core 如何选择 （或查找） 要在任何给定 evp 调用中使用的操作的实现方式。

• 以与实现无关的方式在 libcrypto 和 provider 之间传递信息。

• 将弃用遗留 api （例如不通过 evp 层的低级密码 api） 。存在针对非遗留算法的遗留 api （例如 aes 不是遗留算法，但 aes_encrypt 是遗留 api） 。

• openssl fips 密码模块将作为动态加载的 provider 实现，它将是自包含的 （即只能依赖于系统运行时库和核心提供的服务） 。

概念组件视图

openssl 架构中的概念组件概述如下图所示。请注意，图中组件的存在并不意味着该组件是公共 api 或用于直接访问或使用的最终用户的组件。

新的组件 （在先前架构中不存在） 如下所示：

• core：这是一个基本组件，将对操作 （如加密） 的请求连接到提供该操作的 provider。它提供了定位实现指定操作的算法的能力，给定一组实现必须满足的属性。例如，加密算法的属性至少包括“fips”。

• 默认 provider （default provider） ：实现了一组默认算法。

• fips provider：实现了经过 fips 验证的一组算法，并通过核心提供访问。这包括以下支持服务：

• post：上电自检，包括：

    · kat：已知答案测试

    · 完整性检查

• 低级实现 （low level implementations） ：实际实现密码原语的一组组件，以满足 fips 规定的自包含要求。

• 遗留 provider （legacy provider） ：提供了旧算法的实现，将通过 evp 级别的 api 暴露出来。

• 第三方 provider （3rd party providers） ：最终，第三方可能会提供自己的 provider。第三方 provider 与任何其他 provider 一样，实现了一组算法，可以通过 core 访问，并对应用程序和其他 provider 可见。

• 空 provider （null provider） ：一个什么都不做的 provider，这对于测试正确使用库上下文非常有用。

• 基础 provider （base provider） ：用于密钥序列化的 provider。fips provider 需要它，因为它本身不包含加载密钥的方法。基础 provider 也嵌入在默认 provider 中。

打包视图

上述概念组件视图中描述的各个组件在物理上打包为：

• 可由用户使用的可执行应用程序
• 供应用程序使用的库
• 供 core 使用的可动态加载模块

openssl 3.0 将提供多种不同的打包选项 （例如一个名为 libcrypto 的单一库，包含除 fips provider 之外的所有内容，以及所有 provider 作为单独的可动态加载模块） 。

哪些可动态加载模块被注册、使用或可用可以在运行时进行配置，以下图示根据物理打包描述了架构：

本版本引入的物理打包如下：

• fips 模块：该模块包含了实现了一组经过 fips 验证的算法，并通过 core 可访问的 fips provider。fips provider 即 openssl fips cryptographic module 3.0。

  我们不会试图阻止用户出错，但我们会考虑典型用户的使用情况和“安全性”。默认情况下，将构建并安装 fips provider。

  我们将能够执行安全检查，以检测用户是否以对 fips 有影响的方式修改了源代码，并在未提供覆盖选项的情况下 （尽力而为） 阻止构建 fips provider。

  我们需要确保存在一种机制，使最终用户能够确定他们对 fips 模块的使用是否符合正式验证的允许用途。

  fips 模块的版本将与基础 openssl 版本号对齐，验证时的版本号取决于该版本。并非所有 openssl 发布版本都需要更新 fips 模块。因此，当发布新的 fips 模块版本时，其版本号可能存在间隔或跳跃，与之前版本相比。

• legacy 模块：该模块包含了旧版算法的实现。

最初的计划是使用 provider 的封装来构建引擎 （engines） ，以便在将 engine 指针传递给某些函数时，使其像往常一样工作，并在充当默认实现时作为 provider。在开发过程中的调查显示，这种方法存在问题的边缘情况。目前的解决方法是，当进行 evp 调用时，目前存在两个代码路径。对于引擎 （engines） 的支持，使用“遗留密钥”的旧代码。长期计划是从代码库中删除引擎 （engines） 和遗留代码路径。一旦删除引擎 （engines） ，任何作为引擎 （engines） 编写的内容都需要重新编写为 provider。

下周我们将带来 "core 和 provider 设计" 部分内容，等不及的小伙伴，可以查看铜锁语雀中的全篇文档哦:https://www.yuque.com/tsdoc/ts/openssl-300-design#ap9lt

铜锁/tongsuo star 一下✨： https://github.com/tongsuo-project/tongsuo