预计阅读时间： 8 分钟
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
