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

已发布的 RFD 301 RFD 301 有人看到我的密钥了吗？：机架级安全性的密钥层次结构策略 此 RFD 可以由以下组访问： [ public ] 国家发布的 RFD 301 作者 Andrew J. Stone 更新的背景和目的 氧化物机架内有许多不同类型的秘密。在系统的基础上，我们将 DeviceId 和 Alias 密钥存储在 RoT 上，并分别用于平台身份和测量签名以进行证明 [RFD 36]。这些密钥以及用于验证临时 Diffie-Hellman 协议的第三个 RoT 托管密钥对为雪橇提供了为应用层消息形成安全链轮会话的能力 [RFD 238]。这些链轮会话使每个雪橇能够以点对点的方式机密地共享信息，其中消息的完整性受到保护，端点的真实性及其运行软件的证明得到保证。为了提供机架级安全保证，使攻击者无法带走部分雪橇或驱动器并恢复任何有用的信息，我们设计了信任仲裁 [RFD 238]。信任法定人数背后的主要保护机制是 Shamir 秘密共享。共享的机架级秘密，用作其他用于保护静态存储的密钥的密钥派生源。机架秘密由经销商进程分割成 N 个唯一的密钥共享，并通过链轮会话与 N 个信任仲裁成员的唯一平台身份一起分发给每个引导代理。这些平台身份被烘焙到 RoT 上的公钥证书中，以允许验证实体是否是他们所说的人。分发此信息后，引导代理可以与其他引导代理建立链轮连接，验证组中的成员身份（通过交换的证书），并从其他代理检索 K-1 共享，以便它们可以从 K 共享重建机架秘密。重要的是，如果没有获得K股，就无法得知有关机架秘密的信息。如 [RFD 238] 中所述，各个共享未加密地存储在每个底座的 M.2 驱动器上。攻击者必须窃取至少 K 个驱动器才能重建机架秘密，如果物理访问期间没有大量时间和中断，这是不可行的。将来，我们计划在信任根 (RoT) 的帮助下“密封”这些秘密，以便它们仅在 sled 启动时解密。密封意味着攻击者必须窃取 K 整个雪橇并能够启动它们以恢复机架秘密。 K 雪橇的重量使得休闲攻击者望而却步。有了这个机架秘密，我们就有了一个共享秘密，只有当组中足够多的 N 个雪橇插入同一机架并且彼此足够信任以相互分配共享时，该共享秘密才可用。从这个共享秘密中，我们可以为每个单独的 U.2 设备派生或包装单独的加密密钥，并为内部服务独立派生机架级根证书。此 RFD 的目的是识别： 哪些数据受到机架秘密的保护？该数据的时间生命周期是多少？该数据的空间局部性是什么？它是特定驱动器/底座/机架/集群的本地吗？哪些物理或逻辑限制阻止加密数据被移动？用于保护该数据的密钥层次结构是什么？哪些密钥保护哪些数据？哪些密钥源自哪些秘密和密钥？哪些密钥被包装（由其他密钥加密）？密钥是如何派生或包装的（密钥时间表）？如果密钥泄露会发生什么？这些问题对于我们机架的安全至关重要，考虑到我们对当前解决方案的经验以及更多的时间来思考和实施强化和扩展我们的态势所需的解决方案，我们的决定可能会发生变化。不过，就目前而言，该 RFD 必须提供足够强大的答案，以便我们能够最好地保护我们的静态数据，并在不久的将来实现我们的其他安全目标。叶子窥视 我们的机架级密钥层次结构从根部的机架秘密开始。信任法定人数的每个成员都可以了解足够的份额来重新计算机架秘密。机架秘密本身不是密钥，因此我们必须通过密钥派生函数 (KDF) 从中派生密钥，该函数可用于机架所需的各种目的。如果没有更多关于系统中哪些数据实际上受到密钥保护的信息，就很难确定我们派生出哪些密钥，从这些密钥派生出哪些密钥，以及它们中的任何一个可能包含哪些密钥。为了帮助构建我们的密钥层次结构并填充树中的内部节点，我们将首先列出机架内要保护的数据、将使用哪些唯一密钥来保护该数据以及我们希望从这些密钥获得的安全保证。建立叶密钥后，我们可以向后工作以填充密钥层次结构的其余部分。下表显示了数据