彻底告别私钥焦虑：深度解析 Sigstore Keyless 签名的底层原理

在软件供应链安全日益受到重视的今天，数字签名已成为验证软件包完整性和来源真实性的标配。然而，传统的签名方案（如 GPG）始终绕不开一个痛点：私钥管理。

私钥丢失了怎么办？私钥泄露了如何撤销？如何确保团队中的每个开发者都能妥善保管自己的密钥？Sigstore 项目推出的 Keyless（无密钥）签名技术，为这些问题提供了一个优雅的解法。

什么是 Keyless 签名？

首先要澄清一个误区：Keyless 并不是真的不使用密钥。在密码学层面，签名依然需要私钥。Keyless 的核心在于将长效私钥替换为短效、临时的私钥，并通过身份认证体系（OIDC）将签名者的身份与签名行为绑定。

简单来说，你不再需要手动生成和保存一个 my_private_key.pem 文件。取而代之的是，利用你已有的身份（如 GitHub 账号、Google 账号或 CI/CD 服务角色），在签名瞬间生成一对临时密钥，并在使用后立即销毁。

Sigstore 的三大支柱

要实现这一流程，Sigstore 依赖三个核心组件：

1. Fulcio (证书颁发机构)：一个免费且自动化的 CA。它负责根据 OIDC 令牌验证签名者的身份，并颁发有效期极短（通常只有几分钟）的 X.509 证书。
2. Rekor (透明度日志)：一个防篡改的、只增不减的账本。它记录所有的签名元数据和证书，任何人都可以审计。
3. Cosign (签名工具)：开发者直接使用的命令行工具，负责协调与 Fulcio、Rekor 的交互。

Keyless 签名的全过程解析

让我们拆解一下当你执行 cosign sign --keyless 时，背后究竟发生了什么：

1. 身份验证与 OIDC 流程

Cosign 首先会触发一个 OIDC（OpenID Connect）流程。

• 如果是在本地环境中，它会打开浏览器让你登录（如 GitHub）；
• 如果是在 GitHub Actions 等 CI 环境中，它会自动获取该环境的身份令牌（JWT）。
  这个令牌证明了“你是谁”（比如 user@example.com）以及“你来自哪里”（比如某个特定的 GitHub Repo 流程）。

2. 生成临时密钥对

Cosign 在你的本地内存中生成一对临时的公私钥对。注意，这对密钥从未落在磁盘上，且生存周期极短。

3. 申请证书（Fulcio 的介入）

Cosign 将临时公钥和 OIDC 令牌发送给 Fulcio。Fulcio 验证令牌有效后，会颁发一个包含你身份信息（Subject）的数字证书，并将该公钥绑定其中。这个证书的有效期通常只有 10 分钟。

4. 执行签名与上链（Rekor 的介入）

Cosign 使用本地内存中的临时私钥对软件产物（如 Docker 镜像）进行签名。
随后，Cosign 将签名、证书以及产物的摘要发送给 Rekor。Rekor 会将这些信息存入其透明度日志，并返回一个“签名时间戳证明”（SET）。

5. 销毁私钥

一旦签名任务完成并确认存入日志，Cosign 就会从内存中彻底抹除临时私钥。此时，世上再无对应的私钥，但你的签名已经生效。

验证：私钥销毁了，如何验证签名？

既然私钥已经没了，证书也过期了，那别人怎么验证你的镜像呢？

验证者不再检查“这个签名是否由某个长效私钥产生”，而是检查：

1. 证书的有效性：虽然证书过期了，但在 Rekor 记录的那个时间点，该证书是有效的。
2. 身份匹配：证书中的身份（如 https://github.com/owner/repo/.github/workflows/main.yml）是否符合预期。
3. 存在性证明：该签名是否真实存在于 Rekor 的透明度日志中。由于 Rekor 是不可篡改的，这保证了签名不是事后伪造的。

为什么这种模式更安全？

1. 消除了密钥丢失/泄露风险：没有长效私钥需要保管，也就没有了泄露的可能。
2. 默认的审计能力：所有的签名记录都在公共的 Rekor 日志中，这意味着如果有人冒充你的身份签名，你可以立即通过日志监控发现。
3. 降低管理成本：在大型组织中，不再需要维护复杂的 KMS（密钥管理系统）或进行繁琐的密钥轮换。

总结

Sigstore 的 Keyless 签名通过“身份即密钥”的思路，彻底颠覆了传统的软件签名模式。它将复杂的密码学操作封装在自动化的流程中，让普通开发者无需成为安全专家，也能为自己的代码提供金融级的安全保障。

对于正在构建云原生流水线的团队来说，拥抱 Keyless 签名不仅是提升安全性的选择，更是简化 DevOps 流程的必然趋势。