Sigstore 项目是什么

原文发布于Easton Man's Blog

Sigstore 是 Linux 基金会最新的项目，它是基于 Certificate Transparency Log 的软件签名新模式。Sigstore 解决了传统的 PGP 签名所带来的私钥保管问题，它有出色的开放性和扩展性，被誉为软件签名的 Let’s Encrypt 。

TL;DR

简要地说，Sigstore 项目实现的是通过 Certificate Transparency Log 记录每个签名的信息，终端用户需要使用的时候查询 Log 并验证。由于公钥被记录在 Log 中，因此每次签名可以使用不同的密钥。由此大大降低了私钥泄露的风险和保管私钥的痛苦。

我们为什么需要 Sigstore

开源供应链的脆弱性

从仍在继续发酵的 SolarWinds 攻击事件，到刚刚兴起的包管理器重名包攻击，可以看到在越来越多的厂商采用开源解决方案的同时，安全问题也在变得日益严重。开源供应链的这几个问题愈发突出：

__工具链长__：攻击面广泛，任何一个环节都有可能导致问题，比如 SolarWinds 事件，带毒的 VSCode 造成了很多- 供应链上游的软件包出现了问题。
__公开透明__：公开透明的 CI 、公开的源码和公开的管理机制给了有心之人更多的机会。
__不可控性__：开源工具链中的相当多环节都处于社区或者其它公司的控制中，不受末端用户和公司的控制。正如 Luke Hinds 在视频会议中所展示的那样，即便是大型公司的供应链中也存在有相当多的安全风险。

传统 CA 方式的问题

传统上，公司使用 CA 体系来进行软件签名。例如，一个希望软件能在 Windows 10 上不报风险提示地运行，那么这名开发者 /开发公司将不得不花费一定的钱款向 DigiCert 、Symantec 或者类似的 CA 购买用于签名的证书（注意，Let’s Encrypt 颁发的证书仅能用于域名验证，不能用于软件签名）来对他们的软件进行签名。当然这个体系的缺陷很明显：中心化。我们依赖于对 CA 的绝对信任来保证我们所运行的程序是未经篡改的，如果遇到 WoSign 之类的 CA 那么这一体系的安全性便荡然无存。

PGP 是最佳实践吗？

相当多的生态系统和包管理器等深度地使用 PGP 作为它们的信任体系基础，迄今为止，它确实在相当多的情况下表现得很不错。但是 PGP 信任体系也有它的问题：

__私钥保管__：私钥显然不能够被保存在人类的大脑里，那把它存放在何处就成了问题。如果仅仅保存一份，那么如果这一份由于某种原因（物理损坏，OVH 机房燃起来了等等）丢失了，那么重建信任将会是一个噩梦。如果存放多了又会带来问题，万一私钥泄露了，并遭到利用，那么撤回这些遭受污染的版本也是一个噩梦。多开发者：下面的截图展示了 Node.js 开发者使用中和曾经使用的 GPG 公钥，这么多的核心开发者使用每个人自己的密钥进行发布，终端用户如果想要验证签名，就不得不导入者数十个密钥并且信任它们，这给验证带来了麻烦。
__公钥分发__：大多数的项目使用简单的 HTTP 或 HTTPS 的方式进行公钥的分发。而这些 Web 服务器实在是很容易遭受黑客的攻击，如果这些公钥遭到替换，那么安全也就无从谈起了。
__信任体系的建立__：PGP 的信任体系是基于去中心化的人脉关系，通常人们在进行互相签名信任之前会在现实世界中认识或者见面，这无疑给信任体系的建立带来了麻烦，尤其是在新冠肺炎全球大流行的当下。

Sigstore 解决了什么

私钥保管问题

我们在开头曾经提到过，Sigstore 是使用 CT Log 作为信任源（ Trust Root ）的，由于在 Log 中包括了公钥信息，开发者在每次签名的时候不需要相同的密钥，每次使用的密钥对在签名过后，公钥被上传至 Log，私钥则被销毁，这样一来开发者就无需小心翼翼地保管自己的密钥了。由于 Log 的增长性，已添加的 Log 可以按照不可更改（ Immutable ）的数据来进行保管，相对于现行的 GPG 公钥方式来说，提供了更好的安全性。

使用的简便性

由于传统软件签名方式的复杂性，很多的开发者并不会去对自己发布的软件进行签名，绝大多数的用户更加不会对软件进行验证。那么如何才能让大家都参与到这一信任体系的建设中呢？

其关键在于便捷性。哪怕一套体系再完美，如果缺乏便捷性，那么很少会有人问津。有一个很好假设可以说明这个事情，如果微软宣布开发了一个绝对安全的新系统 SecureOS，我们假设它真的如微软所说绝对的安全，但是它不兼容 Windows 软件，没有 GUI，甚至不能在 x86-64 体系的处理器上运行，那么会有多少企业为这个新操作系统买单呢？答案可想而知。

Sigstore 使用几个方式来保证便捷性和域现有体系的兼容性，以确保迁移成本最小化。

__第一，Sigstore 使用 Web PKI + OpenID Connect 等身份信息提供者进行身份的验证。__未来还可能添加新的验证方式。这无疑节省了巨大的成本，这使得企业可以几乎无痛地迁移到 Sigstore 所主导的新体系。这个身份验证也完全可以不使用这一套系统，只要能够确定开发者的身份，GPG 、x509 、MiniSign 都是支持的。

__第二，Sigstore 在签名这一环节使用 x509 标准。__这使得 Sigstore 甚至可以与 Let’s Encrypt 合作提供免费的签名凭据。而且，x509 的基础设施几乎遍地都是，这相比与 MiniSign 这种解决方案无疑要简便的多。

__第三，终端客户验证使用 CT Log 的形式。__这使得客户不再需要导入信任的证书或者由操作系统或者浏览器等维护一个 CA 列表。任何出现在 CT Log 上的记录都是真实的，任何人都可以验证它的有效性。还可以使用不同的验证策略进一步加强安全性，例如要求同一个版本至少要由三位维护者共同签名。

结语

我也曾经有过对我所开发的软件进行签名的想法，但是被高昂（学生狗买不起）的证书价格劝退了。作为一名开发者，我由衷地希望 Sigstore 这个项目能够发展起来，毕竟有 Linux Foundation 做支持，这个体系推广开来以后，应该可以节省很多这方面的成本。

参考

Community Central: Connecting with sigstore By RedHat Community What is Sigstore Sigstore Homepage

原文发布于Easton Man's Blog