4. Cosign 核心原理：密钥对生成与管理、签名与验证流程、透明日志（Rekor）的作用
Cosign 是 Sigstore 项目中的签名工具，专为容器镜像和软件制品提供免密钥管理（Keyless）或密钥对（Key-Pair）两种签名模式。本章聚焦其核心原理，涵盖密钥对生命周期、签名/验证的数学流程，以及透明日志 Rekor 如何提供不可篡改的审计证据。
4.1 密钥对生成与管理
Cosign 支持两种身份模型：静态密钥对（适用于 CI/CD 自动化）和动态密钥（Keyless）（适用于开发者临时签名）。本节先讲解静态密钥对的生成与管理。
4.1.1 密钥对生成
使用 cosign generate-key-pair 命令生成一对 ECDSA-P256 密钥：
# 生成私钥（cosign.key）和公钥（cosign.pub）
cosign generate-key-pair
# 输出示例：
# Private key written to cosign.key
# Public key written to cosign.pub生成的私钥使用 AES-256-GCM 加密存储，Cosign 会提示用户输入加密口令（Password）。公钥以 PEM 格式明文存储，可直接分发给验证方。
4.1.2 密钥管理最佳实践
| 管理维度 | 推荐做法 | 风险说明 |
|---|---|---|
| 私钥存储 | 使用 KMS（如 AWS KMS、GCP Cloud KMS）或硬件安全模块（HSM） | 文件泄露可导致任意签名伪造 |
| 口令强度 | 至少 16 位随机字符，包含大小写字母、数字和特殊符号 | 弱口令可被暴力破解私钥 |
| 密钥轮换 | 每 90 天轮换一次，旧密钥保留在验证白名单中至少 30 天 | 不轮换增加密钥泄露窗口期 |
| 公钥分发 | 通过安全通道（如 Git 仓库签名、Web 公开密钥）分发 | 公钥被篡改会导致验证信任链断裂 |
Keyless 模式提示： 对于临时签名场景（如开发者本地构建），推荐使用 Cosign 的 Keyless 模式。该模式通过 OIDC 身份令牌（如 GitHub、Google、Microsoft）动态生成短期密钥对，签名后立即丢弃私钥，无需管理长期密钥。
4.2 签名与验证流程
Cosign 的签名流程将容器镜像的摘要（Digest）与签名数据绑定，并上传至 OCI 仓库。验证流程则通过公钥或 Keyless 身份恢复签名者信息，并校验数据完整性。
4.2.1 签名流程（Key-Pair 模式）
- 计算镜像摘要： 对镜像 Manifest 进行 SHA-256 哈希，得到
sha256:<digest>。 - 签名摘要： 使用私钥对摘要进行 ECDSA 签名，生成签名数据（Signature Payload）。
- 构造签名对象： 将签名数据、公钥标识（Key ID）、签名时间戳打包为 OCI 制品。
- 上传签名： 将签名对象以
<镜像名>:sha256-<digest>.sig的 Tag 推送到同一 OCI 仓库。
# 签名命令示例
cosign sign --key cosign.key <registry>/<image>:<tag>
# 签名成功后，仓库中会多出一个签名 Tag：
# <registry>/<image>:sha256-abcdef123456.sig4.2.2 验证流程
- 拉取签名对象： 根据镜像摘要定位并拉取对应的
.sigTag。 - 提取公钥： 从签名对象中获取公钥标识，或由验证方直接提供公钥文件。
- 校验签名： 使用公钥对签名数据进行 ECDSA 验签，确认签名由对应私钥生成。
- 比对摘要： 重新计算当前镜像的 SHA-256 摘要，与签名对象中的摘要进行比对，确保镜像未被篡改。
# 验证命令示例
cosign verify --key cosign.pub <registry>/<image>:<tag>
# 验证通过输出：
# Verification for <registry>/<image>:<tag> --
# The following checks were performed on each of these signatures:
# - The cosign claims were validated
# - The signatures were verified against the specified public key
关键校验点： 验证流程必须同时检查签名有效性和摘要一致性。仅校验签名但忽略摘要比对，攻击者可通过替换镜像内容绕过验证。
4.3 透明日志（Rekor）的作用
Rekor 是 Sigstore 的透明日志系统，为所有签名操作提供不可篡改的审计追踪。它将签名元数据（包括签名者身份、签名时间、镜像摘要）记录在 Merkle Tree 中，任何人都可以查询和验证。
4.3.1 Rekor 的核心功能
| 功能 | 说明 | 对安全的价值 |
|---|---|---|
| 签名时间戳 | 记录签名发生的精确时间（RFC 3161 时间戳） | 防止签名者事后否认（Non-Repudiation） |
| Merkle Tree 证明 | 每个签名条目对应一个 Merkle 叶子节点，提供包含性证明 | 确保签名记录未被删除或篡改 |
| 公开可查询 | 任何人都可通过 Rekor API 查询签名记录 | 实现透明审计，降低信任门槛 |
| 与 Keyless 集成 | Keyless 模式自动将签名记录写入 Rekor | 即使私钥已丢弃，仍可通过 Rekor 追溯签名者身份 |
4.3.2 Rekor 在签名流程中的位置
下图展示了 Cosign 签名与验证流程中 Rekor 的参与方式：
4.3.3 Rekor 查询示例
使用 rekor-cli 或 Cosign 内置命令查询签名记录：
# 查询特定镜像的 Rekor 记录
cosign verify --rekor-url https://rekor.sigstore.dev \
<registry>/<image>:<tag>
# 通过 Rekor API 直接查询
curl -s https://rekor.sigstore.dev/api/v1/log/entries?logIndex=12345 | jq .
注意： 默认 Rekor 实例由 Sigstore 社区维护（rekor.sigstore.dev）。对于生产环境，建议部署私有 Rekor 实例，确保日志数据的可控性和隐私合规性。
4.4 本章小结
- 密钥对管理： Cosign 支持静态密钥对和 Keyless 模式，静态密钥对需遵循 KMS 存储、定期轮换、安全分发等最佳实践。
- 签名与验证： 签名流程将镜像摘要与私钥绑定生成签名对象；验证流程通过公钥验签和摘要比对确保镜像完整性。
- Rekor 透明日志： 提供不可篡改的签名审计追踪，支持时间戳证明、Merkle Tree 包含性证明和公开查询，是 Sigstore 信任链的核心组件。