有人看到我的钥匙了吗？机架级安全的密钥层次策略

假设一个静态集群，我们现在有一个机架秘密，可以从 K 个密钥共享中计算出来并用于派生子密钥。在下面的示例中，K = 2，这样我们就可以保持图表较小。机架秘密保护机架解锁后使用的系统中的每个密钥。有两种机制可以获取层次结构中的下一个密钥： 我们已经使用密钥派生从机架秘密派生任何主要子密钥。但它也可用于从密钥派生密钥。密钥包装只是获取密钥并对其进行加密。每个都有其优点和缺点。密钥派生很好，因为您不必将派生密钥存储在磁盘上。你可以重新生成它们。问题在于，如果派生密钥发生变化，任何下游派生密钥现在也会发生变化。密钥包装很好，因为如果包装器密钥发生轮换，下游密钥不必更改。这对于加密存储上的大量数据特别有用。您不希望仅仅因为父密钥被轮换而被迫解密然后重新加密。密钥包装的缺点是您现在必须将包装（加密）的密钥存储在磁盘上的某个位置。如果在多个地方使用同一个密钥，则必须复制它。对于信任仲裁，我们有一个特殊的问题：当添加或删除节点时，我们会生成新的共享。虽然可以通过新共享维护相同的机架秘密和密钥派生，但随着时间的推移，它的安全性会降低，因为一次检索机架秘密并保存它的任何单个恶意节点现在都可以恢复任何现有驱动器上的任何数据或将来生成的任何数据。虽然这始终是一个问题，但我们更愿意在已知妥协的情况下允许机架秘密的轮换。因此，我们总是在信任仲裁（重新配置）或其他密钥共享轮换的每次更改时生成新的机架秘密。这样，即使机架上的所有现有数据都受到损害，如果移除受损害的底座，至少不会有新的数据受到损害。现在我们对我们的安全目标了解多少？我们希望： 尽可能多地从机架秘密中派生密钥，以限制存储打包密钥的需要 允许机架秘密轮换，以便可以缓解机架秘密泄露的情况 对每个 U.2 驱动器使用唯一的加密密钥，以便在一个密钥泄露的情况下，其他密钥也不会泄露。确保发生重新配置后，新的（空）底座无法访问旧底座中未与其共享的任何静态数据。考虑到这些目标，我们的限制是什么？我们必须： 当机架密钥轮换时，能够更改每个 U.2 驱动器的 ZFS 包装器密钥。这需要同时知道新旧包装密钥。考虑到以下事实：鉴于密钥轮换的分布式性质，并非所有雪橇都会同时知道何时提交新的重新配置以及何时更改包装器密钥。认识到新配置的提交以及新的机架秘密可能会在多次“错误启动”之后发生，其中新的重新配置被分发到多个雪橇但未提交。第一个约束是我们对磁盘加密的一般使用所带来的。后两个约束来自重新配置问题的分布式性质，并在[RFD 238]中详细阐述。第二个约束使得不可能在提交期间分发新的密钥共享，因为在雪橇提交到新纪元之后，它应该只使用新的机架秘密，因此它可能必须向尚未获悉它已提交的雪橇请求新的密钥共享。在提交期间不分发密钥共享还有其他安全原因，这些原因在 [RFD 238] 中得到了进一步充实。因此，给定两阶段提交协议（[RFD 238]），我们必须在准备消息中分发新份额。第三个约束使得在得知 ZFS 加密包装器密钥后不可能立即更改，因为派生这些密钥的新机架秘密可能永远不会被提交。如果没有提交的机架机密，则无法检索重新计算机密并重新派生 ZFS 加密包装器密钥所需的共享。考虑到这些目标和限制，我们重申，作为新旧组成员的任何雪橇都必须同时访问新旧提交的机架秘密。这是必要的，以便他们能够为每个 U.2 设备派生 ZFS 加密包装器密钥，以便他们可以更改密钥。为了简化重新配置协议，并限制旧机架秘密的暴露，我们也只希望允许雪橇为当前提交的配置分发密钥共享。上述要求和愿望是紧张的，因此我们必须创造性地处理这种情况。解决这一困境的最直接方法是通过经销商进行重新配置。如 [RFD 238] 中所述，我们对每个编号