3. 制品签名原理：数字签名基础、哈希算法、非对称加密、签名与验签流程
在自动化流水线中集成 IDP 制品签名链路，核心是理解数字签名如何保证制品的完整性与来源真实性。数字签名并非对原始制品直接加密，而是通过哈希算法提取摘要，再使用非对称加密对摘要进行签名。本节将拆解这一技术栈的底层原理与标准流程。
3.1 数字签名基础
数字签名是一种电子签名，利用密码学技术实现以下三个目标：
- 完整性：制品在传输或存储后未被篡改。
- 认证性：确认签名者的身份（私钥持有者）。
- 不可否认性：签名者无法否认自己签署过该制品。
数字签名不隐藏制品内容，而是附加一段签名数据，供接收方验证。在 IDP 场景中，签名通常由 CI/CD 流水线中的签名服务（如 Sigstore、JWT 签名器）完成，验签则由部署策略或策略引擎执行。
关键概念： 数字签名 ≠ 加密。签名使用私钥生成，公钥验证；加密使用公钥加密，私钥解密。两者密钥对用法相反。
3.2 哈希算法
哈希算法（Hash Algorithm）是数字签名的第一道工序。它将任意长度的制品文件映射为固定长度的摘要（Digest），具有以下特性：
- 单向性：无法从摘要反推出原始制品。
- 抗碰撞性：极难找到两个不同制品产生相同摘要。
- 雪崩效应：制品微小改动会导致摘要完全变化。
在制品签名链路中，常用的哈希算法如下：
| 算法 | 摘要长度 | 安全性 | IDP 推荐场景 |
|---|---|---|---|
| SHA-256 | 256 bit | 高（当前标准） | 通用制品签名、容器镜像摘要 |
| SHA-384 | 384 bit | 更高 | 高安全等级签名（如 FIPS 合规） |
| SHA-512 | 512 bit | 最高 | 长期存档签名、监管审计 |
| MD5 / SHA-1 | 128 / 160 bit | 已弃用（碰撞攻击） | 禁止用于签名，仅用于校验 |
实践建议： 在自动化流水线中，优先使用
sha256sum 或 openssl dgst -sha256 计算制品摘要。IDP 签名链路通常要求摘要算法与签名算法配套声明。
3.3 非对称加密
非对称加密使用一对密钥：私钥（Private Key）和公钥（Public Key）。私钥由签名者秘密保管，公钥可公开分发。在数字签名中，非对称加密用于对哈希摘要进行签名操作，而非加密整个制品。
主流非对称加密算法对比：
| 算法 | 密钥长度 | 签名速度 | 验签速度 | IDP 适用性 |
|---|---|---|---|---|
| RSA | 2048 / 4096 bit | 较慢 | 较快 | 传统 PKI 体系，兼容性好 |
| ECDSA | 256 / 384 bit | 快 | 快 | 现代 IDP（如 Sigstore、Cosign）首选 |
| Ed25519 | 256 bit | 极快 | 极快 | 高性能流水线，密钥短小 |
安全警告： 私钥必须存储在硬件安全模块（HSM）、密钥管理服务（KMS）或安全凭证存储中。禁止将私钥硬编码在流水线 YAML 或代码仓库中。
3.4 签名与验签流程
完整的制品签名与验签流程分为两个阶段，共六个步骤。以下 SVG 图展示了标准流程：
3.5 签名与验签详细步骤
以下表格将流程拆解为可操作的步骤，对应流水线中的 API 调用点：
| 阶段 | 步骤 | 操作描述 | 流水线对应动作 |
|---|---|---|---|
| 签名 | 1. 计算摘要 | 对制品文件执行 SHA-256 哈希，得到固定长度摘要 | sha256sum artifact.bin |
| 2. 私钥签名 | 使用签名者私钥对摘要进行 ECDSA 签名运算 | cosign sign-blob 或 openssl dgst -sign |
|
| 3. 输出签名 | 生成签名数据（.sig 文件），与制品一同发布 | 上传至制品仓库（如 OCI Registry） | |
| 验签 | 4. 接收制品 | 从仓库拉取制品及其关联签名数据 | docker pull 或 wget |
| 5. 重新计算摘要 | 对接收到的制品执行相同哈希算法，得到新摘要 | sha256sum artifact.bin |
|
| 6. 公钥验签 | 使用签名者公钥解密签名，比对两个摘要是否一致 | cosign verify-blob 或 openssl dgst -verify |
核心逻辑： 验签时，如果新摘要与签名中解密出的摘要一致，则证明制品未被篡改且签名者身份可信。任何不一致都会导致验签失败，流水线应中断部署。
3.6 签名链路中的密钥管理
在 IDP 自动化流水线中，密钥管理是签名链路的安全基石。以下 SVG 图展示密钥对生成与分发的典型架构：
IDP 集成提示： 在自动化流水线中，签名服务应通过 API 调用 KMS 获取签名操作，而非直接接触私钥文件。公钥可通过 OIDC 令牌或透明日志（如 Rekor）自动分发给验签方。
3.7 常见问题与避坑
- 哈希算法不一致： 签名时使用 SHA-256，验签时误用 SHA-1，导致验签失败。必须在签名元数据中声明算法。
- 私钥泄露： 私钥被意外提交到代码仓库或日志中。应使用密钥扫描工具（如 GitLeaks）在流水线中拦截。
- 公钥信任锚缺失： 验签方未正确配置信任的公钥列表，导致攻击者使用自签名证书伪造制品。应使用 PKI 或 Sigstore 的信任根。
- 签名数据与制品分离： 签名文件与制品未绑定存储，导致部署时无法找到对应签名。建议使用 OCI 镜像签名或 DSSE 封装格式。
安全红线： 永远不要跳过验签步骤。即使制品来自内部仓库，也必须执行验签，防止供应链攻击或内部篡改。