NBDE（网络绑定磁盘加密）技术

NBDE介绍

网络绑定磁盘加密 (NBDE)与磁盘加密紧密结合。为什么公司或个人要加密磁盘？如果您不想看到您的公司或私人数据被泄露，您应该对包含机密数据的磁盘进行加密，作为附加的安全措施。

磁盘加密有两种用例：

1. 当硬件设备（不安全的服务器、笔记本电脑等）被盗或丢失时，磁盘加密可以降低数据泄露的风险。这通常不会对具有物理安全性的企业级数据中心构成威胁。
2. 第二个用例与企业级数据中心相关：迟早，由于缺陷或从技术角度来看磁盘已经过时，需要更换磁盘。此外，为获得扩展存储而进行的更换在组织中也很常见。在磁盘生命周期结束时可能会发生数据泄漏，因为更换的磁盘根本无法擦除，并且在具备所需知识的情况下，有机会访问数据，至少是部分数据。擦除当前磁盘需要花费大量时间（通常是用零覆盖它们，即使是随机数据也是如此）。加密磁盘可以简单地丢弃，而不需要擦除或物理销毁。

Linux 中磁盘加密的标准是LUKS （Linux 统一密钥设置）。正常使用LUKS 加密设备意味着输入磁盘解密密码。因此，LUKS 无法扩展，因为必须在系统启动时手动输入密码，这对于数据中心来说是不行的。

NBDE 可在系统启动时自动解锁磁盘，从而防止手动干预输入密码。这允许加密物理机和虚拟机上的硬盘驱动器卷，而无需在重新启动计算机时手动输入密码。这使得 NBDE 成为为 LUKS 添加扩展功能的完美技术，尤其是对于在不同类型的设备上使用加密磁盘并希望在无需手动干预的情况下自动执行系统启动过程的组织。这是数据中心等大型环境中的关键要求。

NBDE技术

NBDE 通过网络安全、匿名地将加密密钥绑定到外部服务器或一组服务器。这不是密钥托管，因为客户端不存储加密密钥或通过网络传输它，但除此之外，NBDE 的行为类似。

NBDE 遵循客户端-服务器架构，基于两个主要组件：

• Tang ：运行在服务器上的软件。它基于 HTTP 上的 JSON。假设它在受控环境（通常是数据中心内的专用网络）中运行，并为 Clevis（客户端）提供 HTTP 端点以连接并获取密钥。它基于McCallum-Relyea密钥交换，具有以下特点：

  • 它基于Diffie-Hellman算法+集成加密方案。
  • 加密密钥不会离开客户端（充当私钥）。

• U形夹：充当客户端的软件。它运行在需要对磁盘进行加密并自动解锁的设备上。Clevis 提供的自动解密基于不同的“引脚”，这些“引脚”是使用不同技术提供这种自动解密的插件。可用的引脚有：

  • 唐：它提供了真正的NBDE 。它允许通过 HTTP 连接到 Tang 服务器。
  • tpm2 ：机器上的安全加密处理器
  • sss ：用于组合配置（例如：使用两个或更多 Tang 服务器实现高可用性）

Clevis 和 Tang 是提供 NBDE 的通用客户端和服务器组件。红帽企业 Linux 将这些组件与 Linux 统一密钥设置磁盘格式 (LUKS) 结合使用来加密和解密根和非根存储卷，并完成网络绑定磁盘加密。

当客户端启动时，它会尝试通过执行加密握手来联系一组预定义的 Tang 服务器。如果它可以到达 Tang 服务器，则节点可以构造其磁盘解密密钥并解锁磁盘以继续启动。如果节点因为网络中断或服务器不可用而无法访问 Tang 服务器，则该节点无法引导并继续无限期重试，直到 Tang 服务器再次可用为止。由于密钥有效地绑定到节点在网络中的存在，因此尝试访问静态数据的攻击者必须能够获得节点上的磁盘以及对 Tang 服务器的网络访问权限。

如前所述，NBDE 最重要的特征之一是它使用 McCallum-Relyea 密钥交换。下一节将更详细地描述这种交换的工作原理。

McCallum-Relyea 密钥交换

McCallum-Relyea 密钥交换是密钥托管的替代方法，允许重新生成解密密钥而无需检索密钥。该算法是Diffie-Hellman 密钥交换算法的高级版本。该算法的前半部分工作原理与 Diffie-Hellman 交换类似，但共享密钥仅用于额外计算。它使用附加随机变量进行计算。客户端对服务器保持完全匿名，并且在客户端和服务器之间传输随机数据时绝对不需要加密。
McCallum-Relyea 密钥交换分两个步骤进行：

1. 配置：当通过 Clevis 软件将包含加密磁盘的节点配置为使用 Tang 服务器解锁时，客户端和服务器之间将执行密钥交换，而秘密客户端密钥不会离开该节点。
   服务器生成私钥S和公钥s的密钥对。然后它公布公钥 s。客户端还创建一个包含私钥 C 和公钥 c 的密钥对。
   之后，客户端使用服务器公钥 s 和自己的私钥 C 创建对称密钥 K。
   但在这种情况下，客户端不会公布其公钥 c，这意味着只有客户端才能导出 K 。客户端将 K 写入 LUKS 槽之一。一旦客户端存储了 K，它就会丢弃 K 及其私钥 C，这意味着客户端无法再导出 K，至少在没有服务器帮助的情况下是这样。
   下图说明了这个过程：

2. 恢复：当包含加密磁盘的设备启动或安装时，Clevis 客户端必须通过从服务器恢复所需信息来生成密钥。客户端生成新的密钥对e，并为服务器生成消息密钥。根据从服务器返回的信息，客户端可以导出 K。一旦导出 K，Clevis 就会将此密钥传递到正常的磁盘安装过程 (dmcrypt) 中以安装卷，而无需等待手动输入密码。

下图说明了密钥重新生成过程：

根据之前的开通和恢复流程，需要注意的是：

• 在配置期间，仅需要服务器公钥。此公钥并非专用于通过网络启动的 Clevis 客户端。它可以由 Clevis “离线”使用，或者在无法访问 Tang Server 的配置过程中使用。
• 服务器上没有状态。不传输解密密钥，这意味着不涉及托管。
• 所有传输的数据（s、x、y）对于窃听者来说要么是公开的，要么毫无意义，因此不需要 TLS 或其他通道加密。

NBDE 与密钥托管比较

上一节详细介绍了 McCallum-Relyea 密钥交换的工作原理及其提供的特性。由于 McCallum-Relyea 密钥交换是 NBDE 的核心，下表可以直接将其与密钥托管交换方法的好处进行比较：

功能	密钥托管	NBDE
针对单磁盘失窃的保护	✅	✅
针对整个服务器偏移的保护	✅	✅
加密密钥永远不会通过网络传输	❌	✅
无需客户端-服务器传输加密	❌	✅
红帽支持	❌	✅
使用 Ansible 角色实现自动化	❌	✅
OpenShift 支持	❌	✅
由 Libguestfs 支持	❌	✅
由斯特拉蒂斯支持	❌	✅

使用NBDE更适合自动远程磁盘解锁，因为：

1. McCallum-Relyea 密钥交换是一种更安全的机制（加密密钥永远不会传输到网络）。
2. McCallum-Relyea 密钥交换简化了此类场景的部署，因为它不需要对客户端和服务器之间的流量进行加密以进行磁盘解锁。
3. 有多种不同的技术（OpenShift、Ansible、Libguestfs 或 Stratis）集成了 NBDE 的使用。这类技术通常不可用于密钥托管，或者即使可以，其实施也要复杂得多。

NBDE配置

本文档无意详细描述如何配置 NBDE。请参阅以下 RHEL 产品文档以获取详细指导：

• 安装客户端软件 Clevis 。必须在每个具有需要自动解锁的加密磁盘的系统上正确安装 Clevis 客户端软件。
• 安装服务器软件，唐。必须在将成为部署一部分的每个系统上安装并启动 Tang 服务器。
• 配置客户端以绑定到 Tang 服务器。每个客户端都必须进行适当配置，以便在启动过程中使用一个或多个 Tang 服务器进行密钥检索。
  在涉及多个客户端和服务器的大型部署的情况下，更喜欢使用NBDE Ansible 角色。

钥匙轮换

密钥轮换是一种长期维护 NBDE 环境安全的机制。当可能发生数据泄漏时（例如设备被盗的情况），建议进行密钥轮换。还应定期进行轮换，轮换周期取决于不同方面，例如：

• 特定部署的安全约束
• 钥匙尺寸
• 机构内部政策

密钥轮换涉及三个操作：

• 在服务器上生成新密钥，轮换现有的活动密钥。新生成的密钥将是要公布的密钥。
• 将客户端重新绑定到新生成的密钥。客户端将继续使用隐藏的轮换密钥，但强烈建议重新绑定以使用新生成的密钥。
• 删除服务器上的旧密钥。一旦所有 U 形夹客户端都用新密钥重新设置密钥，旧密钥就可以从服务器中删除。请谨慎执行此操作，因为在所有 NBDE 加密节点完成密钥更新之前删除旧密钥会导致这些节点依赖于任何其他已配置的 Tang 服务器。如果不存在其他服务器，则无法自动解锁。总之，仅当所有客户端都已反弹到新密钥时才能删除旋转密钥。否则可能会发生数据丢失。
  以下方案显示了密钥轮换操作中涉及的不同阶段：
  

密钥轮换操作涉及不同的步骤，这些步骤在某种程度上是手动的，因此容易出错。但是， NBDE Ansible 角色允许正确执行密钥轮换操作，自动执行前面的每个步骤，并确保所有必需的操作均按正确的顺序成功执行。

NBDE 场景

可以使用部署所需的参数来整理 NBDE 场景，这些参数是：

• 周边安全
• 负载均衡
• 地理冗余

简单的 NBDE 场景

一个非常简单的场景包括一个或仅几个客户端和一台 Tang 服务器：

这种场景非常有限，仅建议用于非常小的测试部署或概念验证，因为它会遇到不同的故障点：

• 内部网络中断
• 唐服务器中断

带负载均衡的NBDE场景

与前一场景相比，更高级的场景包含一个或多个客户端和多个具有负载平衡功能的 Tang 服务器，以在它们之间分配流量：

这种场景不像以前那样受到限制，对于无法部署地理冗余网络的小型组织来说可能是一个很好的切入点。可能的故障点可能是：

• 内部网络中断

这种情况需要使用 SSS pin 针对不同的 Tang 服务器配置 Clevis。

具有冗余网段的NBDE场景

具有冗余网段的场景可以通过包含重复的网段来修复先前部署上的故障点：

这种情况还涉及针对所有 Tang 服务器配置 Clevis。网络设计人员将通过使用 SSS 引脚在 Clevis 客户端和所有 Tang 服务器之间配置负载平衡。

NBDE 部署可以配置多种网络拓扑，具体取决于所涉及的使用类型和组织。可以分析不同的要求（例如负载平衡或备份）并适应特定的部署要求。

NBDE 灾难恢复注意事项

本节介绍 NBDE 部署中可能发生的几种潜在灾难情况以及应对每种情况的程序：

• 客户端机器丢失：
  使用 Tang 服务器解密其磁盘分区的集群节点的丢失并不是一场灾难。机器是否被盗、遭受硬件故障或其他丢失情况并不重要 - 磁盘已加密并且被认为是不可恢复的。
  但是，如果被盗，Tang 服务器的密钥轮转和所有剩余节点的密钥重新密钥会明智地进行，从而确保磁盘即使在随后获得 Tang 服务器访问权限的情况下仍无法恢复。
  要从这种情况中恢复，请重新安装或更换节点。

• 客户端网络连接丢失：
  与单个节点的网络连接丢失将导致该节点无法自动启动。
  如果您计划的部署可能会导致网络连接丢失，则可以向现场操作员提供密码以供手动使用，然后轮换密钥以使其失效。
  节点中缺少网络访问可合理影响该节点正常工作的能力以及启动能力。即使节点可以通过手动干预启动，缺乏网络访问也会使其实际上毫无用处。

• 网段丢失：
  在多个网段均包含一台或多台 Tang 服务器的场景中，丢失网段导致 Tang 服务器暂时不可用会产生以下后果：

  • 如果其他服务器可用，配置的节点将继续正常启动。
  • 在恢复网络段前，新节点无法建立它们的加密密钥。在这种情况下，请确保与远程地理位置的连接以获得高可用性和冗余。这是因为当您安装新节点或重新加密现有节点时，您在该操作中引用的所有 Tang 服务器都必须可用，或者在配置期间必须提供 Tang 服务器公钥的副本以及 IP Tang 服务器的地址。

• Tang 服务器丢失：
  具有相同密钥材料的负载平衡服务器组中单个 Tang 服务器的丢失对于客户端来说是完全透明的。
  与同一 URL 关联的所有 Tang 服务器（即整个负载均衡集）的临时故障可以视为与某个网段丢失相同。只要另一个预配置的 Tang 服务器可用，现有客户端就能够解密其磁盘分区。只有其中一台服务器重新上线后，新客户端才能注册。
  您可以通过重新安装服务器或从备份中恢复服务器来缓解 Tang 服务器的物理丢失。确保密钥材料的备份和恢复过程得到充分保护，防止未经授权的访问。

• 关键材料的泄露：
  Tang 服务器上单个密钥材料的泄露（例如 Tang 服务器或相关数据的物理盗窃）需要立即轮换密钥。具体来说，执行以下操作：

  • 为包含受影响材料的任何 Tang 服务器更新密钥。
  • 使用 Tang 服务器更新所有客户端的密钥。
  • 销毁原始密钥材料。

仔细评估可能导致任何给定节点上的主加密密钥遭到泄露的密钥材料的任何泄露。理想情况下，使服务器脱机并对其磁盘执行完全重新加密。在同一物理硬件上重新格式化和重新安装虽然需要更长的时钟时间，但更容易，并且可以更严格地自动化和测试。

总结

本文详细介绍了 NBDE 技术及其使用的密钥交换算法：McCallum-Relyea。它还详细说明了为什么与其他解决方案（例如密钥托管）相比，NBDE 是一种更好的自动解锁加密磁盘的密钥检索解决方案。

参考

[1] OpenShift Container Platform：关于磁盘加密技术

[2] RHEL 8 安全强化：第 13 章。使用基于策略的解密配置加密卷的自动解锁

[3]使用系统角色的 RHEL 9 管理和配置任务：第 16 章。使用 nbde_client 和 nbde_server 系统角色