3. 制品签名基础概念：数字签名原理、哈希算法、非对称加密在制品签名中的应用
在 Backstage IDP 的制品签名链路中，数字签名是确保制品完整性、真实性和不可否认性的核心机制。理解其底层原理，是后续排查签名链路故障的基石。本节将拆解数字签名的三大支柱：哈希算法、非对称加密以及签名与验签流程。
3.1 核心概念速览
在深入细节前，先通过下表建立对三个核心组件的宏观认知：
| 组件 | 核心作用 | 在制品签名中的角色 | 典型算法/标准 |
|---|---|---|---|
| 哈希算法 | 将任意长度数据映射为固定长度摘要（指纹） | 为制品内容生成唯一、不可逆的“数字指纹”，确保内容未被篡改 | SHA-256, SHA-384 |
| 非对称加密 | 使用一对密钥（公钥 & 私钥）进行加解密 | 私钥用于签名（加密哈希值），公钥用于验签（解密哈希值） | RSA, ECDSA, Ed25519 |
| 数字签名 | 结合哈希与非对称加密，提供完整性、认证、不可否认性 | 将制品的哈希值用签名者私钥加密，附加在制品上 | PGP, Sigstore (Cosign), JWT |
3.2 哈希算法：制品的“数字指纹”
哈希算法是签名链路的第一道防线。它接收整个制品文件（如 Docker 镜像、JAR 包）作为输入，通过数学函数计算出一个固定长度的十六进制字符串（摘要）。
- 单向性：从摘要无法反向推导出原始制品内容。
- 抗碰撞性：几乎不可能找到两个不同的制品拥有相同的哈希值。
- 雪崩效应：制品内容哪怕只改动一个比特，生成的哈希值也会完全不同。
故障排查要点： 在 IDP 中，签名验证失败最常见的原因之一是哈希不匹配。例如，制品在构建后、签名前被重新压缩或添加了元数据，导致实际哈希值与签名时计算的哈希值不一致。排查时应首先确认签名时使用的哈希算法与验签时是否一致（如 SHA-256 vs SHA-1）。
3.3 非对称加密：密钥对的分工
非对称加密解决了对称加密中密钥分发的难题。在制品签名场景中，它定义了明确的角色分工：
- 私钥（Private Key）：由制品发布者（如 CI/CD 系统、开发者）严格保管，用于生成签名。私钥泄露意味着签名体系崩溃。
- 公钥（Public Key）：可以公开分发给任何需要验证制品的人或系统（如 Backstage 的软件目录、Kubernetes 集群），用于验证签名。
这种设计确保了：即使公钥被广泛传播，攻击者也无法伪造签名，因为他们没有私钥。
3.4 数字签名与验签流程（核心）
下图展示了在 Backstage IDP 中，一个制品从签名到验证的完整生命周期：
3.5 签名与验签步骤详解
结合上图，我们将流程拆解为清晰的步骤：
3.5.1 签名阶段（发布者执行）
- 计算摘要：对原始制品文件运行哈希算法（如
sha256sum artifact.bin），得到固定长度的哈希值 H。 - 加密摘要：使用发布者的私钥对哈希值 H 进行加密，生成数字签名 S。
- 打包发布：将原始制品、数字签名 S 以及签名者身份信息（如证书或公钥指纹）打包在一起，发布到制品仓库。
Backstage 实践提示： 在 IDP 中，签名通常由 CI 流水线（如 GitHub Actions、Jenkins）在构建步骤后自动执行。Cosign 是 Sigstore 项目下的主流工具，支持对容器镜像和二进制文件进行签名，其默认使用 ECDSA-P256 算法。
3.5.2 验签阶段（消费者/Backstage 执行）
- 分离制品与签名：从制品仓库获取已签名制品，并提取出数字签名 S 和发布者公钥。
- 计算本地摘要：对获取到的制品文件运行与签名时相同的哈希算法，得到本地摘要 H'。
- 解密签名：使用发布者的公钥对数字签名 S 进行解密，得到原始摘要 H。
- 比对摘要：比较 H' 与 H。
- 一致：签名验证通过。证明制品在传输过程中未被篡改，且确实由持有对应私钥的发布者签名。
- 不一致：验证失败。触发告警，Backstage 应标记该制品为不可信。
3.6 常见算法对比与选择
在 IDP 环境中，选择合适的算法组合至关重要。下表对比了主流方案：
| 算法组合 | 哈希算法 | 非对称算法 | 签名长度 | 性能 | 安全性 | 典型工具 |
|---|---|---|---|---|---|---|
| RSA-SHA256 | SHA-256 | RSA (2048/4096 bit) | 256 / 512 字节 | 较慢（尤其签名） | 高（广泛验证） | GnuPG, OpenSSL |
| ECDSA-SHA256 | SHA-256 | ECDSA (P-256/P-384) | 64 / 96 字节 | 快 | 高（同等安全强度下密钥更短） | Cosign, TUF |
| Ed25519 | SHA-512 (内部) | EdDSA (Curve25519) | 64 字节 | 非常快 | 极高（现代、抗侧信道） | Sigstore, SSH |
故障排查关键点： 算法不匹配是导致签名验证失败的常见原因。例如，签名方使用 RSA-2048，而验签方配置的公钥是 ECDSA-P256 格式；或者签名时使用 SHA-1（已废弃），而验签策略要求 SHA-256。在 Backstage 的签名插件配置中，务必显式声明并校验算法标识。
3.7 小结：签名链路中的信任锚点
数字签名并非孤立存在，它依赖于一个信任链。在 Backstage IDP 中，这个信任链通常表现为：
- 根信任：谁的公钥是可信的？通常通过 PKI（公钥基础设施） 或 Sigstore 的无密钥签名（Keyless Signing） 解决。
- 策略执行：Backstage 的软件目录或策略引擎（如 OPA）会定义：哪些公钥签名的制品可以被部署到生产环境。
- 审计日志：每次签名和验签操作都应记录，以便在故障发生时进行追溯。