3. 密钥管理与身份：短期密钥对、OIDC身份认证、无密钥签名原理
在传统软件供应链中，签名密钥的长期存储、轮换与泄露风险是核心痛点。Sigstore 通过引入 短期密钥对（Ephemeral Key Pair）、OIDC 身份认证 与 无密钥签名（Keyless Signing） 机制，从根本上消除了长期密钥的管理负担。本章将深入剖析这三项技术的原理与协作流程。
3.1 短期密钥对：签名即销毁
短期密钥对是 Sigstore 无密钥签名的底层密码学基础。每次签名操作都会在客户端本地生成一对全新的密钥，签名完成后私钥立即被销毁，公钥则通过证书绑定到用户身份后上传至透明日志。
核心优势： 私钥生命周期极短（通常仅持续数秒），即使签名客户端被攻破，攻击者也无法获取历史私钥来伪造过去的签名。
| 特性 | 传统长期密钥 | Sigstore 短期密钥对 |
|---|---|---|
| 私钥生命周期 | 月 / 年 | 秒 / 分钟 |
| 存储方式 | HSM / 文件 / 环境变量 | 内存（签名后销毁） |
| 泄露影响 | 可伪造历史所有签名 | 仅影响单次签名 |
| 轮换策略 | 手动或半自动 | 无需轮换（每次自动生成） |
3.2 OIDC 身份认证：身份即密钥
Sigstore 使用 OpenID Connect（OIDC） 将签名者的数字身份（如邮箱、GitHub 账号、Google 账号）直接绑定到签名证书上。用户无需预先注册或管理密钥材料，身份认证由受信任的 OIDC 提供商（如 GitHub、Google、Microsoft）完成。
支持的 OIDC 提供商
| 提供商 | 身份类型 | 典型使用场景 |
|---|---|---|
| GitHub | GitHub Actions / 用户 | CI/CD 流水线自动签名 |
| Google 账号 | 开发者本地签名 | |
| Microsoft | Azure AD / 个人账号 | 企业身份集成 |
| GitLab | GitLab CI / 用户 | GitLab 流水线签名 |
OIDC 令牌内容： 令牌中包含
sub（用户唯一标识）、email、iss（签发者）等声明。Sigstore 的 Fulcio 证书颁发机构会验证这些声明的签名，并将其嵌入证书的 SAN（Subject Alternative Name）字段。
3.3 无密钥签名原理：完整流程拆解
无密钥签名（Keyless Signing）是 Sigstore 的核心创新。它将短期密钥对、OIDC 身份认证、Fulcio 证书颁发和 Rekor 透明日志整合为一个原子操作。用户只需执行一条命令，即可完成签名并生成可公开验证的证据。
无密钥签名步骤详解
- 生成短期密钥对： 客户端（cosign）在本地生成 ECDSA P-256 密钥对。
- 获取 OIDC 令牌： 客户端通过浏览器或环境变量向 OIDC 提供商请求身份令牌。
- 构造证书签名请求（CSR）： 客户端将公钥与 OIDC 令牌打包为 CSR，发送至 Fulcio CA。
- Fulcio 签发证书： Fulcio 验证 OIDC 令牌的有效性，签发包含用户身份的短期 X.509 证书。
- 签名制品： 使用短期私钥对制品进行签名，生成签名载荷。
- 上传至 Rekor： 将证书、签名和制品摘要上传至 Rekor 透明日志，获取日志索引。
- 存储签名： 将签名、证书和日志索引与制品一同存储（如 OCI 仓库）。
安全注意事项： OIDC 令牌具有时效性（通常 10 分钟），Fulcio 证书有效期通常为 10 分钟。如果签名流程中断，需要重新获取 OIDC 令牌。建议在 CI/CD 环境中使用 GitHub Actions 的 OIDC 令牌自动注入，避免手动交互。
3.4 无密钥签名 vs 传统签名
| 对比维度 | 传统签名 | Sigstore 无密钥签名 |
|---|---|---|
| 密钥管理 | 需要安全存储私钥 | 无需管理私钥 |
| 身份绑定 | 通过证书链或信任锚 | 通过 OIDC 身份直接绑定 |
| 验证方式 | 需要公钥或根证书 | 通过 Rekor 透明日志 |
| 密钥泄露风险 | 高（长期密钥） | 低（短期密钥） |
| 用户注册 | 需要 PKI 注册流程 | 无需注册，使用现有 OIDC 账号 |
通过短期密钥对、OIDC 身份认证与无密钥签名三者的结合，Sigstore 将软件签名的安全门槛从“管理密钥”降低为“拥有身份”。任何拥有 GitHub、Google 或 Microsoft 账号的开发者，都可以在数秒内完成可公开验证的签名，而无需接触任何长期密钥材料。