tkhq/qos

# QuorumOS [](https://github.com/tkhq/qos/blob/main/LICENSE) [](https://github.com/tkhq/qos/actions/workflows/stagex.yml) [](https://github.com/tkhq/qos/actions/workflows/pr.yml) ## 关于 QuorumOS 是一个计算层，用于在现代云规模的可信执行环境（"TEE"，也称为 "enclave"）中运行应用程序。该操作系统的架构基于这样一个原则：即必须由一定阈值的参与者协调来配置包含敏感应用程序逻辑和机密材料的安全计算环境；没有任何单一参与者可以单方面配置环境或机密材料。 具体而言，QuorumOS 设计为通过证明 enclave 配置、重构 Quorum Key（法定人数密钥），然后启动单个 enclave 应用程序来在 enclave 中启动，该应用程序可以利用 Quorum Key 来加密和认证数据。 关于环境配置的共识通过 Manifest（清单）文档进行协调，该文档描述了（除其他事项外）enclave 镜像配置、应用程序 CLI 参数、公共 Quorum Key 以及法定人数集合。在引导过程中，一定阈值的 Quorum Members（法定人数成员）通过带外方式根据 Manifest 证明 enclave 的配置，然后发布各自的 Quorum Key 份额。有关详细信息，请参阅 [provisioning](#provisioning) 部分。 Quorum Key 本身可由 QuorumOS 和 enclave 应用程序用于加密和认证数据。 QuorumOS（"QOS"）是一个最小化、不可变且确定性的 Linux unikernel（单内核），面向各种可信执行环境，适用于需要高安全性和可审计性的用例。 有关如何在 Turnkey 中使用它的更多信息，请参阅 [The Turnkey Whitepaper](https://whitepaper.turnkey.com/)，更具体地说是：[Foundations](https://whitepaper.turnkey.com/foundations)。 ## 开发 ### 要求 - 10GB+ 可用 RAM - Docker 26+ - GNU Make ### 复现构建 QuorumOS 是使用 [StageX](https://codeberg.org/stagex/stagex) 构建的，这是一个新的确定性 Linux 发行版。StageX 提供可复现的构建，并保证此仓库中人类可读的源代码与构建系统生成的机器可执行产物之间存在一对一的、不可变的关系。 此仓库生成确定性的 OCI 容器镜像。QuorumOS 操作系统被打包以便在 Nitro EIF（Enclave Image File）内执行。此打包过程是确定性的，并作为 [`qos_enclave`](./src/qos_enclave) 的一部分完成。关联的 [Containerfile](./src/images/qos_enclave/Containerfile) 包含构建 `nitro.eif` 文件以及包含 PCR 测量值的 `nitro.pcrs` 的指令集。 要生成 `qos_enclave` OCI 容器镜像，请运行： ``` make out/qos_enclave/index.json ``` 如果您需要从中提取文件，可以使用 [docker](https://docs.docker.com/get-started/get-docker/) 和 [skopeo](https://github.com/containers/skopeo) 来实现： ``` # 创建一个名为 qos_enclave.tar 的归档，标签为 "qos-enclave:latest" skopeo copy oci:./out/qos_enclave:latest docker-archive:qos_enclave.tar:qos-enclave:latest # 将 tar 加载到本地 docker docker load < qos_enclave.tar # 创建容器但不运行它（输出一个 container ID） docker create qos-enclave:latest # 在本地复制文件以供检查 docker cp CONTAINER_ID:/nitro.pcrs nitro.pcrs # 查看 PCR 值 cat nitro.pcrs b26733f9... PCR0 b26733f9... PCR1 21b9efbc... PCR2 ``` 这些 PCR 值可以与 [AWS 远程证明](https://docs.aws.amazon.com/enclaves/latest/user/set-up-attestation.html#pcr012) 的内容进行比对。 ### 提交 PR 在合并 PR 之前，我们的 linter（代码检查工具）和单元测试必须通过。 在 [StageX](https://codeberg.org/stagex/stagex)（容器化）中运行它们： ``` make lint # apply standardized code formatting make test # run unit tests locally ``` 在本地运行它们（需要本地安装 Rust）： ``` make -C src lint make -C src test ``` 所有测试必须通过。 PR 还需要通过 `build-linux-only` 作业（`pr` 工作流的一部分）。有 3 个 crate 被排除在 Rust 工作区之外：`qos_system`、`qos_aws` 和 `init`。这些 crate 被排除是因为它们仅在 Linux 上构建。如果您不直接使用这些 crate，通常只有在 `qos_core` 的依赖项发生变化时才需要更新它们。仅限 Linux 的 crate 各自都有自己的 lockfile（锁定文件），为了使确定性构建正常工作，该文件需要保持最新。要更新锁定文件，您需要一个 Linux 构建环境。进入 Linux 构建环境后，您可以运行 `make build-linux-only`，这会在必要时更新锁定文件；然后应提交任何更新的锁定文件。 ## 发布 此项目使用 [`release-plz`](https://github.com/release-plz/release-plz)。使用以下命令安装它： ``` cargo install --locked release-plz ``` 安装完成后，您可以在本地尝试发布，以查看发布 PR 的内容： ``` release-plz update ``` ### 发布流程 当 PR 合并到 main 分支时，如果发布 PR 尚不存在，release-plz 会自动打开一个，或者更新现有的发布 PR。 发布 PR 由 github-actions 机器人打开并标记为 `release`。预期由**人工**仔细检查此 PR，并在必要时手动将任何修复推送到发布 PR（通常是：对 CHANGELOGs 的外观更改）。 一旦发布 PR 被合并，就会触发 release-plz 的 `release` 工作流，所有 crate 都会自动发布。 **切勿**在标准 PR 中手动 bump（提升）crate 版本，让 release-plz 为您处理此事并编辑已打开的发布 PR！ ### 手动重新触发发布 如果在发布过程中出现问题并且您想重试，您可以打开一个标记为 `release` 且分支名为 `release-plz-****` 的 PR 以再次启动发布工作流（`release` 标签是触发工作流所必需的，而分支名称前缀是 release-plz 确定 PR 是否为发布 PR 的方式——请参阅 [此链接](https://release-plz.dev/docs/config#the-release_always-field)） ## 平台 | 平台 | 目标 | 状态 | 验证启动方法 | |----------------------------|:------:|:--------:|:----------------------:| | Generic/Qemu | generic | working | Safeboot 或 Heads | | AWS Nitro Enclaves | aws | working | Nitro 证明 API | | GCP Confidential Compute | gcp | research | vTPM 2.0 证明 | | Azure Confidential VMs | azure | research | vTPM 2.0 证明 | ## 组件 ### Enclave（飞地） - 托管用于监听 Host（主机）的服务器 - 包含 quorum key 生成、启动和运行 Enclave App 的逻辑 - 参见 crate [`qos_core`](./src/qos_core/) ### Host（主机） - 托管 nitro enclave 的 EC2 实例 - 拥有与 nitro enclave 通信的客户端 - 拥有用于接收来自外部世界请求的服务器 - 参见 crate [`qos_host`](./src/qos_host/) #### Client（客户端） - 任何向主机发出请求的事物 - 参见 crate [`qos_client`](./src/qos_client/) ## 关键术语 ### Quorum Key（法定人数密钥） 一组用于身份验证、公钥加密和静态数据加密的 3 个密钥。它们源自单个种子。有关详细信息，请参阅 [QOS Key Set Specification](./src/qos_p256/SPEC.md)。Quorum Key 应仅能在 enclave 内部重构。此外，Quorum Key 的完全配置标志着证明流程的结束，此时 QuorumOS 转向启动指定的 enclave 应用。在 enclave 之外的静态存储中，该密钥旨在使用 shamir's secret sharing（Shamir 秘密共享）跨份额存储。请注意，密钥份额始终旨在加密存储到 Personal Key（个人密钥），绝不以明文存储。 ### Operator（操作员） 可以是 [Manifest Set](#manifest-set) 和/或 [Share Set](#share-set) 成员的实体。操作员使用 [QOS Key Set](./src/qos_p256/SPEC.md) 中的 P256 Signing 和 P256 HPKE 方案。 ### Quorum Sets（法定人数集合） 有三种类型的法定人数集合： ### Manifest Set（清单集合） 可以批准 manifest 的成员集合。在典型的实例配置流程中，Manifest Set 将批准 Manifest 的详细信息，然后 Share Set 成员可以信任具有 Manifest Set 阈值批准的 manifest。这在 Share Keys 和 Manifest Keys 之间创建了逻辑职责划分，从而能够实现更好的密钥使用实践，并使组织能够单独扩展配置流程的各个部分。 ### Share Set（份额集合） 每个成员都持有 Quorum Key 份额从而通过证明然后发布其份额来配置 enclave 的成员集合。在发布份额时，这些成员还将提供 manifest 的签名。签名记录在 manifest envelope（清单信封）中，以便留下审计线索。这样，第三方可以检查哪些份额集合成员实际参与了配置 quorum key。 ### Patch Set（补丁集合） 可以批准对运行中 enclave 进行实时配置补丁的成员集合。 ### Manifest Key（清单密钥） 属于 manifest set 的一部分的密钥。此密钥用于批准（签名）manifests。 ### Share Key（份额密钥） 属于 Share Set 的一部分的密钥。这是 genesis 服务（生成服务）将份额加密到的密钥。 ### Patch Key（补丁密钥） 属于 Patch Set 的一部分的密钥。这是签名实时配置更改的密钥。 ### Ephemeral Key（临时密钥） 由 QuorumOS 实例在启动后立即生成的非对称密钥。一旦 Quorum Members 能够验证 QuorumOS 实例的完整性，他们就会将其 Quorum Key 份额加密到 Ephemeral Key 并提交给实例进行重构。 ### Manifest（清单） 包含启动 QuorumOS 实例的静态配置的文件。Manifest 的组成在启动过程中得到证明。所有 Quorum Members 都将通过签名来同意 Manifest（如果提交的 manifest 签名少于阈值签名，QuorumOS 应拒绝该 manifest）。 ### Node（节点） 运行 QuorumOS 的单机计算实例。 ### Namespace（命名空间） 一组运行相同 Enclave App 并使用相同 Quorum Key 的 QuorumOS 节点。一个 Namespace 包含许多具有相同 Quorum Key 和 enclave app 的活动节点。其中一些节点可能使用不同的 Manifest 和同一 enclave app 的不同版本。 ### Pivot / Enclave App（切换 / Enclave 应用程序） QuorumOS 完成启动后切换到的应用程序。此应用程序的二进制哈希和 CLI 参数在 Manifest 文件中指定。 ## 配置 当有效的 Manifest 加载到 QuorumOS 后，实例将立即生成一个 Ephemeral Key。此密钥特定于特定的单台机器，并且在成功验证 manifest 文件中包含的机器镜像和元数据后，将被 Quorum Members 用于将其份额发布到机器中。 在将其份额发布到机器之前，Quorum Members 使用各种加密证明和社交协调来确定使用给定机密配置特定的 QuorumOS 实例是否合适。 在成功验证证明输出后，每个成员都会将其份额加密到 Ephemeral Key。一旦实例收集到阈值份额，它将使用 Shamir’s Secret Sharing 重构 Quorum Key。 ### 远程证明 远程证明的目的是证明环境正在运行特定的软件。对于 AWS Nitro Enclaves，enclave 可以唯一地向 Nitro Security Module (NSM) 请求包含 enclave 详细信息的证明文档。此文档由 Nitro Attestation PKI 签名，并回溯到 AWS Nitro Attestation PKI Root。 如 [AWS 文档](https://docs.aws.amazon.com/enclaves/latest/user/verify-root.html) 中所定义，实例可以请求 Nitro Security Module (NSM) 代表其生成证明文档。此外，证明文档包含两个可由 enclave 本身修改的字段。证明文档请求包含 Ephemeral Key 和 manifest 的哈希，以便 Share Set 成员可以验证数据是否正确。 在使用 Quorum Key 配置命名空间之前，Share Set 将使用针对 enclave 的证明过程的输出来验证 enclave 是否正在运行预期版本的 QuorumOS，以及该实例是否以预期方式配置，从而保证有资格配置该 Quorum Key。 继续阅读有关使用 nitro enclaves 进行证明的内容： - - - ## Enclave 数据流 Nitro enclaves 拥有单个套接字用于与其父 EC2 实例通信。当 QuorumOS 最初启动时，它开始监听 [socket server](./src/qos_core/src/server.rs) 以接收通过与 EC2 实例的单个 VSOCK 连接发送的 [`ProtocolMsg`s](./src/qos_core/src/protocol/msg.rs)（enclave 服务器的路由逻辑在 [此处](./src/qos_core/src/protocol/mod.rs)）。enclave 服务器仅支持与 VSOCK 连接另一端的 EC2 实例上的客户端进行简单的请求/响应通信。 为了仅与 QuorumOS enclave 服务器通信，我们有 [`qos_host`](./src/qos_host/src/lib.rs)，这是一个简单的 HTTP 服务，允许 `GET` 健康检查和 `POST` `ProtocolMsg`s。 我们期望 Enclave Apps 将拥有自己的主机（app host），该主机将通过同一个套接字与 enclave 服务器通信。Enclave App 预期使用简单的请求/响应模式和任意消息序列化。与应用程序的通信由 QuorumOS enclave 服务器代理；因此，对于 app host 要与应用程序通信，它必须向 QuorumOS enclave 服务器发送 `ProtocolMsg::ProxyRequest {: Vec }`，然后 enclave 服务器将通过 unix 套接字仅将 `data` 发送给应用程序。应用程序将向 enclave 服务器响应原始数据，然后 enclave 服务器将使用 `ProtocolMsg::ProxyResponse { data: Vec }` 向 app host 响应。 我们期望 EC2 实例既拥有用于启动 enclave 和进行健康检查的 QuorumOS host，也拥有用于应用程序特定通信的 app host。 下图显示了上述应用程序数据流。该图提到 gRPC 只是作为应用程序调用者用于与 app host 通信的协议的一个任意示例。  [Excalidraw link](https://app.excalidraw.com/s/6bemxcXUAIE/251cQGJS1by)

标签：Enclave, Linux内核, QuorumOS, SIEM 集成, TEE, Unikernel, 不可变基础设施, 云计算, 区块链基础设施, 去中心化, 可信执行环境, 可视化界面, 启动安全, 多方安全计算, 安全操作系统, 密钥分片, 机密计算, 网络安全, 规则引擎, 请求拦截, 远程证明, 通知系统, 阈值加密, 隐私保护