Sigstore：软件签名解决供应链妥协问题

2353→本作品采用知识共享署名国际4.0许可协议进行许可。Sigstore：面向所有人的软件签名ZacharyNewmanChainguardzjn@chainguard.devJohn SpeedMeyersChainguardjsmeyers@chainguard.dev圣地亚哥·托雷斯-阿里亚斯普渡大学电气和计算机工程系santiagotorres@purdue.edu摘要软件供应链的妥协正在上升。 从XCodeGhost到SolarWinds的影响，黑客们已经发现，针对供应链中的薄弱环节，可以让他们危及美国政府机构等高价值目标以及谷歌和微软等企业目标。 软件签名是许多此类攻击的一种有希望的缓解方法，但在开源和企业生态系统中的应用有限。在本文中，我们提出了Sigstore，一个系统，提供广泛的软件签名能力。为了做到这一点，我们设计了这个系统，以提供基线工件签名功能，从而最小化开发人员的采用障碍 为此，Sigstore利用了三种不同的机制：首先，它使用类似于ACME的协议通过OIDC对开发人员进行身份验证，将签名与现有和广泛使用的身份绑定在一起。其次，它使开发人员能够使用临时密钥来签署他们的工件，减少了密钥管理的不便和风险。最后，Sigstore通过工件和身份日志实现用户身份验证，为软件签名带来透明度。Sigstore 正 在 迅 速 成 为 互 联 网 基 础 设 施 的关键部分， 在Kubernetes和Distroless等关键软件上拥有超过220万个签名。CCS概念• 安全和隐私密钥管理;数字签名;安全服务;安全和隐私的可用性;·网络→安全协议。关键词安全性;代码签名;分布式系统;软件透明性ACM参考格式：扎卡里·纽曼，约翰·斯比德·迈耶斯和圣地亚哥·托雷斯·阿里亚斯。2022年。Sigstore：适用于所有人的软件签名 在2022年ACMSIGSAC计算机和通信安全会议（CCS '22）的会议记录中，2022年11月7日至11日，美国加利福尼 亚 州 洛 杉 矶 。 ACM ， 纽 约 州 纽 约 市 ， 美 国 ， 15 页 。https://doi.org/10.1145/3548606.35605961介绍近年来，软件供应链的妥协引起了广泛的关注SolarWinds [65]和Codecov [62]妥协中的参与者CCS©2022版权归所有者/作者所有。ACM ISBN978-1-4503-9450-5/22/11。https://doi.org/10.1145/3548606.3560596软件换句话说，保护供应链对于软件产品的整体安全至关重要 能够控制此链中任何一步的攻击者都可以在源代码中引入后门，或者在二进制文件或包中包含易受攻击的库。因此，对软件供应链的攻击是攻击者一次影响许多用户的高影响机制。此外，针对软件供应链的攻击目前难以识别，因为它们滥用了通常受信任的流程。 特别重要的是最后一英里：软件交付管道。尽管存在记录不同机制的工作来保护软件用户和软件存储库之间的链接，但攻击软件交付步骤仍然是一种常见的攻击媒介。也许令人惊讶的是，软件签名，一种用于缓解软件存储库妥协影响的技术，并没有得到广泛的采用。事实上，流行软件库中支持签名的绝大多数软件包，如Python包索引（PyPI），都是未签名的。为这些社区准备签名基础设施的各种努力已经取得了进展，但通常存在与易用性，密钥管理和维护人员摩擦增加有关的争议问题。在本文中，我们介绍了Sigstore，一个新的开源服务，使软件签名的一部分，一个无形的和无处不在的基础设施。从Let'sEncrypt及其对HTTPS采用的影响中汲取灵感，Sigstore使用现有的身份提供程序为单个包签名工作流颁发短期证书。通过这种方式，用户可以使用临时密钥（“无密钥签名”）进行签名，这允许开发人员在不管理自己的加密材料的情况下对软件包进行签名;据我们所知，临时密钥尚未用于软件签名。这不仅允许常规的包上传过程，还允许自动化的工作者（例如， GitHub Actions）代表开发人员签署和发布软件包。通过将Web公钥基础设施（PKI）和Golang的sumdb等透明日志系统使用的构建块应用于工件签名问题，Sigstore能够链接软件工件和身份。与其他基于透明日志的包交付安全机制一样，Sigstore使用透明日志来记录包上的签名，但它也在此日志中发布有关身份的声明。其效果是，Sigstore不仅可以防止攻击者在没有适当访问权限的情况下将新的恶意包注入存储库，还可以使审计人员检测到存储库篡改和帐户泄露。Sigstore作为一种包签名解决方案和一种满足与软件工件供应链级别（SLSA）等框架相关的软件供应链安全控制的方法正在获得关注[24]。在GitHub行动[39]、Arch Linux [40]和Red Hat [37]等流行的Linux发行版以及Google的Distroless [ 81 ]、Sigstore等项目采用2354CCS截至2022年4月，在450多个GitHub存储库中托管了超过200万个不同的软件包签名本文的贡献如下(1) 我们确定了以前的方法的局限性，工件签名。(2) 我们引入了一个新的签名机制，使用类似于Let'sEncrypt的(3) 我们给出了这种机制的应用程序，并分析了包存储库签名。(4) 我们评估了Sigstore的性能和使用情况，并描述了在其部署中吸取的经验教训(5) 我们分析了采用Sigstore的几个项目和开发人员2背景Sigstore依赖于三种技术：工件签名、透明日志和身份提供者。2.1数据库和存储库签名签名。 为了对工件进行签名，签名者生成一个私钥/公钥对，并使用私钥对任意一段数据进行签名。在软件包管理的上下文中，这通常是对软件包元数据的签名，包括软件包的名称，内容的散列和安装说明（如预安装钩子）。传统上，签名者必须保持私有签名密钥安全但可访问;这是许多可用性问题的根源[82]。存储库签名。 Cappos等人[12]表明攻击者可以篡改存储库元数据以进行攻击，即使包已签名（例如，提供合法包的过期易受攻击版本为了避免这些攻击，软件包存储库管理员还必须对关于存储库为了抵抗对仓库本身的损害，仓库可以将包的所有权委托给各个包的维护者[43]。 这些维护人员需要管理密钥;因此，这种系统的采用率很低。2.2透明PKI与Web PKIWeb公钥基础设施（PKI）是一个成熟且广泛部署的信任生态系统。在其核心，Web PKI使用X.509证书[17]将Web服务器的信任钉在“证书颁发机构”（或CA）上这些CA验证Web服务器的操作员拥有特定的域，然后向他们颁发证书。通常，服务器运营商使用自动DNS质询-响应协议来证明他们控制了所选的域。Web PKI的一个局限性是缺乏顶级命名空间：多个CA可以向同一个域颁发证书为此，各大CA提出并实施了证书透明性（CT）.证书透明性保留已颁发证书的公开透明日志，以便第三方可以注意到是否有两个CA向同一个域颁发证书（通常，CA会监视其颁发证书的域）。类似地，CT提供了可验证性和检测：域所有者可以监视日志，因此即使是正确的CA也可以检测到它是否被破坏并颁发了恶意证书。透明日志生态系统包含四个主要参与方。首先，客户提交参赛作品。第二，日志服务器使用历史Merkle树[57]（保留过去状态的记录）在初步验证步骤后记录日志中的条目。第三，一系列审计器监视日志，以避免分叉攻击，并确保日志服务器永远不会删除任何条目。最后，验证者可以检查给定的条目是否在日志中（这迫使其他参与者发布条目）作为一般结构，透明日志提供了信任生态系统状态的仅附加，全局，不可分叉的视图（通过使用审计员[54]）。学术界[41]和工业界已经提出了这些日志的各种用途（例如，Go这些日志类似于区块链，其中添加的条目无法删除，并且随着更多条目的执行，攻击者更难替换它们。然而，与区块链不同，透明度日志不使用昂贵的共识机制来支持去中心化。2.3身份提供者最后，Sigstore使用身份提供者来验证签名者。我们使用OpenIDConnect（OIDC）作为生产中使用的当前结构（集成是模块化的，可以使用其他类似的系统）。OIDC[61]是一种广泛支持的协议，允许依赖方（应用程序）验证由身份提供商（如Google，Facebook，GitHub或Okta）确认的资源所有者（最终用户）的身份。例如，一个Google Tech员工（资源所有者）可以使用他们的Google（身份提供者）账户登录到内部Google Tech应用程序（依赖方），并出示由Google颁发的身份。OIDC基于OAuth 2.0 [34]构建，提供互操作性和广泛的语言支持，针对大型攻击的安全性[49，51]，定义良好的身份规范，支持多因素身份验证，以及用于非交互式身份验证的“工作负载身份”（例如，通过构建服务）。3系统目标和威胁模型我们的威胁模型基于对软件交付管道的历史攻击，特别是与受损的OIDC提供商帐户[ 28，85，85 ]和注册表压缩[31，48，79]无关的帐户接管。 参见供应链妥协的数据集以获得更多示例[12，15，27，43]。3.1当事人和角色Sigstore生态系统由以下角色组成签名者保证内容真实性的验证者检查内容是否真实的个人。签名者创建的工件元数据的日志记录。标识日志记录从标识到签名密钥的映射。OIDC提供商机制，保证实体（个人）控制身份（例如，电子邮件帐户）证书颁发机构实体验证OIDC身份令牌并向签名者颁发加密证书独立的服务，确保日志不会对所保存的内容撒谎（以避免分叉攻击[53]）。包存储库独立服务，托管在数据库日志中引用的工件（例如，PyPI）。2355Sigstore：面向所有人的软件签名CCS包存储库对Sigstore来说不是必不可少的，但却是我们在第5节中描述的特定用例的核心部分。3.2系统目标借鉴以前的文献[4，43，67，75]，我们设想以下安全目标：(1) 将工件上的签名绑定到OIDC标识。(2) 提供全球一致的签名生态系统视图(3) 提供一个审计跟踪的危害检测和事后分析.对于包签名案例研究（第5节），我们有以下附加目标：(4) 将软件包绑定到可以为其签名的OIDC身份（维护者）。(5) 提供确保数据“新鲜”的机制从而避免重放和冻结攻击）。3.3攻击者能力和动机以软件供应链为目标的攻击者能够危害服务器（例如，一个像Dock这样的软件包存储库，erHub）并对互联网通信执行中间人攻击。但是，我们假设攻击者无法控制来自开发人员和打包人员的加密材料或密码。我们还假设攻击者无法长时间控制服务器攻击者可以尝试冒充打包人员或开发人员来引入恶意代码。因此，它们经常针对被忽视的包依赖项。此外，攻击者可能通过破坏特定目标使用的包来执行有针对性的攻击关于Sigstore，我们设想了几种类型的妥协：(1) 攻击者能够破坏用于执行OIDC身份验证的单个身份提供程序。(2) 攻击者能够在以下位置执行有针对性的中间人攻击-实施透明度Sigstore不应要求前供应链改变其做法以确保安全;相反，它增强了现有的签名系统。安全属性的优雅降级Sigstore在密钥泄露的情况下不应丢失所有安全属性也就是说，即使某些供应链步骤受到损害，系统的安全性也不会完全受到破坏。除了这些安全目标之外，Sigstore还面向实用性，因此，它应保持最小的运营、存储和网络开销，并使用广泛可用的密码图形原语。4系统设计为了在任意工件上提供签名，Sigstore执行三个主要操作（见图11）。1为概述）。第一种是OIDC Issuance，它保证客户端控制身份（例如，电子邮件帐户）。 第二种方法将短期公钥证书与这些身份（来自证书颁发机构）相关联，并将这些证书发布到身份日志。第三种方法将工件（或工件元数据）上的长期签名发布到一个验证日志，允许验证者检查其有效性。第一和第二操作由称为Fulcio的系统执行，该系统用作OIDC身份的命名空间的证书颁发机构和透明性日志（身份日志）。第三个操作是由一个名为Rekor的系统执行的，Rekor是一个用于工件签名的透明性日志（Transparency Log）。Cosign是Sigstore客户端实现的参考，但Fulcio和Rekor具有公共API规范，可以被任何客户端使用。有了这些组件，Sigstore有三个主要阶段：信任设置，签名流程和验证流程。①OIDC挑战赛开始②OIDC响应OIDC提供商签名并发布签名者签名并发布包存储库与客户端、打包器与包存储库以及身份提供者之间的tacks。但是，我们假设攻击者无法拦截所有流量。(3) 同样，攻击者也可以危害包存储库。我们假设验证客户端本身的安全分发，包括生态系统信任根的公钥。 这类似于Web PKI证书包的安全分发。关键妥协。 我们假设验证者知道项目所有者的公钥，并且攻击者无法泄露相应的私钥。此外，开发者的私钥、持续集成（CI）系统和其他基础设施公钥对于项目所有者是已知的，并且它们的对应的密钥可以被共享。…电子日志（Rekor）③发行申请签名证书更新信任根制品储存库下载神器验证器攻击者不知道密钥在第6节中，我们探讨了其他威胁模型，这些模型是由不同程度的攻击者访问供应链造成的，包括访问基础设施和密钥（在线和离线）。3.3.1实施和安全目标。 为了建立一个安全的软件供应链，可以打击上述威胁，我们设计了一个系统，具有以下属性：图1：Sigstore密钥发布流程4.1信任设置：通过更新框架建立信任根Sigstore依赖于更新框架（TUF）[4，67]作为信任根。TUF允许有效的密钥轮换，密钥新鲜度和UUID：5a88c7SAN：user@github.comUUID：7a40cfSAN：user2@github.comUUID：b76141SAN：user@name.io…身份日志（Fulcio）获取签名UUID：5a88c7SAN：io.github.pytorchUUID：7a40cfSAN：com.aws.xxxUUID：b76141SAN：dev.client.artifact2356←（）CCS授权机制。Web PKI确实提供了这些好处中的大部分，但TUF也支持签名阈值，并提供针对微妙的它还可以在本地处理撤销，而不需要任何撤销列表。这是可能的，因为该框架内的所有委托都适合客户端可以下载的文件，而在Web PKI的规模上则不是这样。Sigstore使用TUF和5个离线根密钥，由开源，学术界和工业界的一旦这个信任根被发布，它将通过各种方式发布信任根是在实时流密钥仪式中创建的，根数据实时发布到公共Git存储库和其他由不同实体控制的一旦发出，此信任根将包含在客户端库中以进行验证（如下所述）。在Sigstore生态系统中，TUF管理关键材料，而不是工件本身（TUF的典型用途Sigstore使用TUF为Fulcio和Rekor分发根证书这允许客户端附带包含根密钥的TUF根元数据，然后可以使用这些元数据来验证所有未来的CA证书。4.2签约流程在Sigstore中签名需要与三个不同的在线系统交互：OIDC提供程序、身份日志/证书颁发机构和身份日志。此过程最大限度地减少了签名者执行的密钥管理量，同时保持生成的签名的合理安全属性。 为此，我们依赖于短期证书（有效期为10分钟），其相应的私钥用于生成单个签名。这样，签名者可以在任意工件上生成签名然后，它们会丢弃任何私钥材料，从而最大限度地降低密钥泄露的可能性。基于这种见解，Sigstore引入了临时密钥：一次性使用的密钥对和相应的短期证书。为了切断证书生命周期和工件生命周期之间的联系，Sig- store引入了Rekor，一个工件日志。与Fulcio结合使用，这允许客户端在证书有效时（即使在证书过期后）验证签名总之，这些服务允许签名者消除对密钥管理的依赖（他们通过OIDC进行身份验证来获得证书，并在单次使用后销毁密钥），并最大限度地降低密钥接管的风险（即使一次性密钥被泄露，也不能在短有效期后重新使用正如我们将在安全分析中探讨的那样，帐户的泄露不会完全破坏对已签名软件包的信任。此外，日志使帐户妥协和恶意颁发的证书公开，并在事件发生后帮助调查。Google可以验证这些日志中的正确行为，以确保Rekor和Fulcio的诚实性。最后，Sigstore提出了新的签名和证书分发机制虽然这些在技术上并不复杂，但它们通过简化维护人员和最终用户的工作流程来实现新的用例（参见第5.2节）。4.2.2签字流程操作。算法1描述了为生成签名而执行的客户端流程。这包括获得OIDC身份令牌（第2行），并生成密钥对和相应的证书签名请求（第3行和第4行）。 有了这些信息，客户端将向Fulcio（身份日志和证书颁发机构）提交签名请求，Fulcio将返回一个由其根密钥签名的证书（第5行）。 此证书将具有将其与令牌中的OIDC身份关联的主题和颁发者字段。 如果成功，客户端现在可以对数据进行签名，并将签名提交给Rekor（Rekor日志;第6到8行）。最后，相同的客户机工具可以将签名的工件提交到一个可扩展的位置，比如包注册表（第9行）。4.2.1无密钥管理的公钥基础设施。而WebPKI在过去十年中几乎得到了普遍采用[13，35]，这在很大程度上是由于Let'sEncrypt[1]等服务，大多数开源开发人员可能无法控制域或有闲钱购买来自商业CA的X.509证书，因此没有采用安全的代码签名身份。此外，即使开发人员获得了这样的证书，他们也将面临围绕密钥管理的众所周知的可用性和安全性问题[26，66]。相反，Sigstore依赖于现有的数字身份提供商，这些数字身份提供商管理的身份远远超过PGP，与DNS（1B [14]）或证书透明度（1亿个域名的1.5B证书[71][33]）相当。例如，截至2019年，谷歌的电子邮件服务Gmail拥有15亿用户。Sigstore用于身份验证的OIDC[61]是一种在整个互联网中使用的标准，用于为注册Gmail，GitHub，Facebook和更多Let's Encrypt和Sigstore之间存在一个根本区别 也就是说，在TLS中，如果当前时间在其有效期内，则证书有效。 传统的代码签名方法将构件的生存期与证书的生存期绑定在一起。这通常需要定期重新签名，这在参与者可能来来去去的社区环境中是困难的。这意味着签名密钥必须定期上线，这可能会危及安全。算法1生成签名要求：提供商，OIDC提供商一曰： 过程Sigstore。体征（伪影）2：tok← OIDC. GetToken（provider）3：sk，pk←GenerateKeyPair（）4：chal ←符号sk（tok. sub）证书自签名5：cert←Fulcio. RequestCertificate（pk，tok，chal）6：sig符号sk工件7：丢弃sk8：Rekor。提交签名（sig，pk）9：将文档（工件）提交到存储库我们在算法2中概述了服务器执行的操作。这些主要包括检查质询-响应的正确性。 这些包括验证（1）OIDC令牌由可信提供商生成并具有有效签名（第2行到第3行），以及（2）主题字段与证书中声明的身份匹配（第4行到第5行）。 如果这些检查都是正确的，Fulcio签署证书请求，并将签名的证书返回给客户端，客户端现在可以签署并向Rekor提交签名。如上所述，一旦创建了短期证书，签名者就可以向Rekor日志提交签名。为了提交一个可信的2357（）下一页（）下一页←（）Sigstore：面向所有人的软件签名CCS算法2接受签名的服务器流要求：提供商，值得信赖的OIDC提供商一曰： 富尔西奥程序RequestCertificate（pk，tok，chal）2：如果是OIDC。验证（tok）或tok。然后，3：返回Err（4：如果<$验证pk（tok. sub，chal）然后5：returnErr（6：cert←X509. NewCertificate（tok. iss，tok. （sub.pk）7：签署skcert富尔西奥发布证书证书9：返回证书在Rekor中，签名者必须提供公钥和签名本身。虽然客户端不使用它来正确验证签名，但它用于检查条目请注意，虽然签名验证过程涉及许多步骤和与外部系统的交互，但最终用户的界面很简单：要使用cosign工具进行签名（参见第7节），用户只需在工件上调用cosign sign-blob，并使用浏览器这些日志是为最终的一致性而设计的，提交的证书可能需要几个小时才能出现在日志中为了处理这种情况，由于许多工件在发布后不久就被使用，Rekor向用户返回一个签名的证书时间戳（SCT），它表示一个带时间戳的承诺（使用Rekor根证书中的密钥签名），以在称为最大合并延迟（MMD）的时间段内将证书合并到日志中。证书透明度中的典型MMD是24小时。 Sigstore没有已发布的MMD，但当前仅在完成合并新日志条目后才完成请求。 这些SCT可以充当签名的时间戳来验证签名生成时间，而不是对日志进行在线查询。 与Web PKI一样，客户端无限期地接受SCT[16]）。4.2.3监视两个日志。 通过将证书移动到公共视图中，任何一方都可以验证Fulcio和Rekor的行为是否正确。 为此，Sigstore社区中的不同参与者运行监视器来验证日志的一致性（即两个日志都不会创建fork）。监视器还可以查看可能引发警报的条目中的语义信息。例如，监视器可以记录签名者更改OIDC提供者的情况，因为这可能是有人试图冒充他们的情况。这种检查的另一个示例可以是识别为同一软件包的不同版本签名的拼写错误的抢注身份（user1234@gmail.com和user1234@outlook.com4.3验证流程为了验证工件，客户端运行算法3。首先，验证器通过执行TUF密钥更新来确保可信密钥是新鲜的。使用更新的信任根，第一次检查确保身份日志正确验证了声明的身份，并且提供的签名与签名的工件的内容最后的检查验证签名是在证书有效的时间窗口内创建的。为了验证，用户运行cosign verify-blob并检查输出以查看验证者的身份（cosign还支持用户提供的验证策略）。算法3验证流程需要：root，一个TUF root一曰： 过程Sigstore。验证（签名、伪影、证书）2：ca ←TUF。UpdateTrust（root）3：如果是X509。验证CA（证书），然后4：返回Err（5：如果<$Fulcio. VerifyInclusion（cert），然后6：返回Err（7：包含Rekor。验证Inclusionsig、伪影、证书8：如果包含错误，则9：returnErr（10：如果包含。时间证明。validityWindow则11：returnErr（12：如果验证证书。pk（伪影，sig），然后13：returnErr（5案例研究：SIGSTORE的安全包装制造商Sigstore是一个通用系统，用于对工件进行签名，并以可审计的方式将这些签名链接到OIDC身份 使用上述结构，可以构建一个系统来提供包和存储库签名，对现有基础设施进行微小更改，并减少用户管理加密材料的需求。为了做到这一点，Sigstore中的一些抽象描述的元素被具体的细节所取代;我们还引入了另一方，包存储库。尽管人们对为包管理器提供签名功能很感兴趣，但在实践中对这些机制的采用却很有限。例如，2020年对允许使用SSL证书进行可选签名的RubyGems的分析发现，只有1。最新版本的软件包中有6%是签名的[84]。 这可能是由于难以有效地管理加密材料以及操作某些加密工具包的负担造成的。这种相对小规模的基于PGP的包签名的采用反映了PGP的更广泛的经验，它一直在努力实现广泛的用户群[52，78]。2016年对PyPI的一项分析发现，只有4%的项目甚至列出了签名，而只有0。07%的用户下载这些签名进行验证[43]。因此，一个允许签名而不需要密钥管理的系统，比如Sigstore，可以在这种设置下推广签名包。5.1TUF集成和存储库联合Sigstore作为现有包存储库的签名覆盖层，以便打包者可以签署工件，而无需更改现有的在流行的包管理器中使用基础设施然而，客户端工具包管理器（例如，pip[63]）需要是Sigstore感知的，以便可以验证签名。在执行此操作时，这些工具需要检查生成的证书中的主题名称是否可信任以签署特定的包。这看起来很简单，因为包存储库本身可以提供映射。然而，这打开了一条攻击途径，其中受损的包服务器在包名称和身份之间的关联上撒谎。对于软件仓库来说，这个问题的传统解决方案是更新框架（TUF）[43，67]。这提供了保护2358CCS表1：使用Sigstore发布到实现更新框架（TUF）的软件包存储库时的危害和相关攻击分类。攻击者控制：攻击者可以：伪造签名分发软件包重用密钥a拒绝服务包存储库没有是的没有是的雷科尔没有是的没有是的网络（MITM）目标用户b、c目标用户N/A目标用户签名者仅签名者b仅限签名者N/A仅限签名者OIDC提供商一些恒等式b，d没有N/A是的富尔乔任何身份b没有N/A是的a给定以前使用的签名密钥，可以伪造签名。b签字人/OIDC签发人可在日志中检测到这一活动c随着提议的OAuth 2.0拥有证明增强[22]，变为d与该OIDC提供商有关的任何身份通过要求软件包由其维护者签名并保护从软件包名称到维护者的映射，从受损的软件包存储库中删除软件包。然而，TUF要求用户（包括包管理员）管理自己的密钥。相反，使用Sigstore，TUF可以被修改为委托给身份，结合了TUF的防篡改性和Sigstore的便利性已经依赖于Sigstore的仓库操作员可以使用仓库联盟来在Sigstore生态系统中为他们的包建立信任，而不是运行他们自己的TUF实例。包存储库能够参与与Sigstore基础设施的交互式协议，以在Sigstore日志中声明命名空间（例如，pypi.org/*）上提供。然后，在包存储库声明名称空间之后，它可以进一步委托存储库中的特定包名称1除了能够将这些用户名映射提交到Sigstore生态系统中的客户端之外，这还允许包存储库配置身份提供者之间的信任关系（例如，通过阻止或添加新的身份提供者），以及签署存储库元数据（以避免冻结和混合匹配攻击[12]）。因此，包存储库可以使用Sigstore来提供签名覆盖，该签名覆盖提供类似TUF的保证，同时最小化打包者维护其自己的加密材料的需要。5.2Sigstore用户访谈为了补充上述技术评估，我们还对Sigstore的七位个人用户进行了访谈其中两个人将Sigstore集成到开源Kuber-netes项目中，这是一个流行的容器管理平台。另外两个人，都是Shopify的员工 ， 参 与 了 一 个 将 Sigstore 集 成 到 RubyGems 的 项 目 ，RubyGems是Ruby编程语言包的注册表第五个人在Sigstore的Java客户端上进行了设计工作和原型设计第六和第七个人都是开源软件开发者，流行项目的创建者，并且仅仅是1目前，Sigstore中的联邦使用每个人的安全生产身份框架（SPIFFE）[73]，其操作原理与本文所述的构造类似，而不是直接使用TUFSigstore（其他受访者在不同程度上参与了该项目）。 所有访谈都是半结构化的，通过在线访谈形式进行，持续30分钟至1小时。我们关注的是用户希望通过Sigstore解决哪些问题，考虑的替代方案，以及受访者对Sigstore安全优势的看法。参与Kubernetes的个人最初试图验证Kubernetes使用的基本容器映像 这些人被Sigstore吸引，而不是其他签名解决方案，如Notary [60]或PGP，因为他们认为Sigstore使签名相对容易，并且开发人员的密钥管理简单。 对于这些人来说，本文其他地方描述的许多安全性好处都是次要的，而不是对可用性和实现速度的直接关注。Shopify的员工对Sigstore产生了兴趣，认为这是保护他们的软件开发团队和业务所依赖的开源软件共享的一种手段。这些人将开源软件包和注册表的完整性确定为核心关注点，这最终导致他们提议将Sigstore集成到Ruby包存储库RubyGems这些人对PGP和信任网络等概念持怀疑态度，他们更喜欢“用密钥管理问题来交换身份问题”。换句话说，Sigstore减轻了绑定实体和公钥的传统困难，只留下了决定给定软件包信任哪些身份的问题受访者还表示强烈支持Sigstore使用公共分类账，“迫使攻击者公开行动”。为Sigstore开发Java客户端的软件开发人员旨在提供工具，使Sigstore更容易集成到语言生态系统中。 虽然开发人员指出“摆脱密钥管理很好”，但受访者很快强调Sigstore的安全保证取决于下游验证者的安全策略。开发人员认为，Maven Central目前对PGP的使用“似乎已经达到了PGP预期用途的极限”。然后，受访者表示希望Sigstore能够实现与工件验证相关的更丰富的安全策略集。2359Sigstore：面向所有人的软件签名CCS访谈样本还包括两名开源软件开发人员，他们仅作为工具的 其中一位开发人员希望签署他发布的容器映像，并发现Sigstore的GitHub集成和无密钥签名功能很有吸引力。有趣的是，这个Sigstore用户对软件工件的数字签名的安全性好处相对不确定，但仍然相信他“应该”签署他发布的图像。另一位开源软件开发人员努力探索了替代的代码签名方法，得出的结论是从传统的证书颁发机构获得数字代码签名证书既繁琐又昂贵。 对于这个用户来说，Sigstore更容易，没有直接成本。该用户的动机也是为了帮助他的开源项目的Windows用户;这些用户在使用他创建的项目时有时会遇到Windows Defender防病毒软件的问题，他希望有一天Sigstore可以帮助验证他的项目的完整性并防止这些误报（目前，Windows防病毒软件不包括Sigstore在其信任根中）。总之，易于集成、密钥管理难度降低以及身份和加密材料之间的紧密联系等因素吸引开发人员使用Sigstore而不是传统的包签名解决方案。6安全分析在第3节中，我们描述了一个强大的对手，他可以控制实体之间的互联网流量，并危害生态系统中的参与者但是，我们假设攻击者不会长时间控制服务器，或者一次控制Sigstore生态系统中的大多数服务器。考虑到这一点，我们着手研究系统在正常运行条件下的安全性能。之后，我们将探讨攻击者控制系统的各个元素时可能发生的不同类型的妥协的影响。 表1总结了以下攻击分类。6.1正常操作条件在正常操作条件下，验证者知道由Sigstore身份签名的软件包是合法的;以下是此保证的论据：首先，如果一个标识控制着存储库中的包的命名空间，那么它就被信任来对该包进行签名。为了验证这一点，客户端执行更新框架（TUF）[67]中的程序包查找然后，客户端确信给定的身份是可信的，可以签署包;否则，这违反了Kuppusamy等人提出的TUF委托的安全性。[43]第43段。然后，只要签名来自持有该身份的一方，该包就是合法的假设某个不持有身份的一方可以说服客户接受他们的签名。然后，他们必须生成一个签名，该签名使用Fulcio颁发的证书中的公钥进行验证，因此他们必须持有相应的私钥（否则，这违反了数字签名方案的安全性）。类似地，签名上的时间戳必须在证书的有效期内（由Rekor的签名证书时间戳证明）;只有在该窗口期间将签名提交给Rekor时才可能。此外，证书必须具有与主题，必须是有效的，必须由富尔西奥签署这意味着Fulcio必须向他们颁发这样的证书（否则，这违反了Fulcio签名的签名方案的安全性）。只有在提供了与证书中的主题对应的有效OIDC身份令牌时，它才会这样做。为了有效，此令牌必须带有OIDC提供商的签名但是，OIDC提供者只为使用相应身份进行身份验证的用户签署身份令牌;这是一个矛盾。此外，由于客户端会检查签名是否存在于身份验证日志中以及证书是否存在于身份验证日志中，因此任何有效的签名都必须具有两个相应的条目。即使签名者确实控制了相应的身份，他们也不能在不被检测的情况下为工件发出签名在解决了常规操作条件之后，我们继续探索系统的不同部分受到损害的情况6.2中间人攻击能够进行中间人对话的攻击者能够对组成协议的不同对话进行攻击。如果攻击者能够做到以下两点，他们就可以以用户的身份发布软件包（这类似于危害用户本身的情况）。签名提交流程。 当打包者向存储库提交一个包时，攻击者可以用一个被篡改的包替换该包。但是，如果签名无效，客户端和日志将拒绝该包。OIDC流。 能够拦截OIDC令牌的攻击者可能能够伪造单个短包签名（通过向Fulcio请求证书）。对OAuth 2.0 [ 22 ]的增强建议将通过将OAuth令牌绑定到与证书中的公钥对应的私钥来消除这种风险。6.3包服务器受损如果软件包存储库遭到破坏，攻击者将能够向存储库提交软件包但是，如果没有通过OIDC流生成签名的能力，客户端将拒绝相反，攻击者可以利用压缩来从存储库中删除现有版本（例如，以迫使用户使用软件包的降级/易受攻击的版本然而，这可以通过验证日志中生成的签名（即， 通过确认生成了在储存库中没有对应包的新签名）。此外，通过使用更新框架（TUF）[67]结合Sigstore，客户端可以检测到此类攻击。如果身份提供者和包服务器由同一方控制，则存在风险例如，GitHub是Sigstore中的身份提供者如果GitHub也用于分发发布，则使用GitHub作为身份提供者并不能提供更多的安全性来防止GitHub的危害（但是，监视透明度日志可以检测到不当行为）。6.4Sigstore妥协类似地，攻击者可以危害Fulcio或Rekor。攻击者可以通过篡改身份或身份日志来删除2360≈CCS表2：Sigstore生态系统中工具的源代码统计名称描述版本语言行代码余弦逆客户端库和工具1.8.0去二十八、二百三十六富尔乔身份日志和证书颁发机构0.4.0上啊，巨蟒五千五百六十二雷科尔企业简介0.6.0去一万六千六百七十五maven插件Maven集成1.0Java819用于包的签名（例如，导致拒绝服务）。这两种攻击都是可检测的，并且只有在交叉引用日志和包存储库之间的信息时才能导致拒绝服务攻击。更令人担忧的攻击是攻击者试图在身份日志中为任意OIDC提供商颁发证书。但是，OIDC提供商可以检测到这种攻击，他们可以交叉引用他们的日志并注意到日志中的身份不明。由于OIDC提供者公钥是广泛可用的，未来的工作可以扩展该协议，以允许任何监视器检测未说明的证书。如果攻击者控制Rekor和合法用户的一次性密钥，则可以通过在持有该密钥的证书有效时在透明度日志中注入签名来重用该密钥但是，这种攻击可以被任何监视器检测到，因为它需要修改日志中较早的条目。6.5包维护者/发布者妥协自动签名管道（例如，通过GitHub操作提供程序）可能会被攻击者破坏在在这种情况下，攻击者应该能够执行OIDC流，生成任意可信密钥，并提交恶意篡改的包版本。然而，这种妥协仅限于自动签名器的单独运行这是因为密钥是一次性的，并且对应于单个OIDC流。因此，未来和以前的包签名（即，对于其它软件包版本）不受此折衷的影响。攻击者可以尝试保留加密材料以签署未来版本（因为身份日志信任证书）。然而，签名将在短时间窗口之后被拒绝（例如，30分钟）。这是因为证书是短期的，并且签名只有在适当的时间窗口内生成和记录才是可信的要求包的签名阈值可以减轻这种攻击，因为攻击者需要控制多个帐户。6.6OIDC发行人妥协控制OIDC提供商的攻击者（例如， Google或Microsoft）可以模仿他们的任何用户。在这种情况下，攻击者不仅可以为用户生成任意证书，还可以代表用户使用包存储库进行身份验证。因此，攻击者可能能够将篡改的包提交到存储库并相应地生成签名在这种情况下，Sigstore不会阻止或检测攻击。然而，这种攻击可以被没有请求证书以证明其身份的被冒充的个人检测到。多视点OIDC验证。然而，通过使用类似Let'sEncrypt[10]等技术所使用的类似方法，可以实现这种攻击。 在这种情况下，Sigstore可以请求不是一个OIDC流，而是多个流来认证用户。这是在协议级（即，在身份/打包日志中承认证书之前），通过请求