通过集体签名的Skipchains和验证构建实现主动软件更新透明度

15.1引用

Nikitin, Kirill & Kokoris-Kogias, Eleftherios & Jovanovic, Philipp & Gasser, Linus & Gailly, Nicolas & Khoffi, Ismail & Cappos, Justin & Ford, Bryan. (2018). CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds.

15.2摘要

软件更新机制对于现代系统的安全性至关重要，但它们通常的集中式设计提供了一个利润丰厚且经常受到攻击的目标。在这项工作中，我们提出了CHAINIAC，这是一个分散的软件更新框架，可以消除单点故障，强制执行透明度，并为软件发布过程提供高效完整性和真实性的验证。独立见证服务器共同验证软件更新与发布策略的一致性，构建验证器验证源到二进制的对应关系，以及防篡改发布日志存储集体签名的更新，从而确保客户端在被广泛披露之前不接受任何发布、验证。发布日志体现了一个跳过链，一种新颖的数据结构，使任意过时的客户端能够有效地验证更新和签名密钥。在可重现的Debian软件包上评估我们的C HAINIAC原型表明，自动更新过程对于单个软件包，每个版本平均需要5分钟，而对于总时间线，仅需要20秒。我们使用来自PyPI包存储库的实际数据进一步评估框架，并表明它为客户端提供了与自身验证每个更新相当的安全性，同时仅消耗了带宽的一倍，并且计算开销最小。

15.3 系统概述

首先，我们陈述了强化软件更新系统应该实现的高级安全目标。

1. 没有单点故障：软件更新系统应保留其安全保证，以防其中任何一个组件发生故障（或受到损害），无论是设备还是人员。
2. 从源到二进制的确认：软件更新系统应该为其客户提供一个高保证级别，即已部署的二进制文件是由可靠且未被篡改的源代码构建的。
3. 有效的发布 – 搜索和验证：软件更新系统应该为其客户提供找到软件版本（最新版本或旧版本）的方法，并以有效的方式验证其有效性。
4. 线性不可变公共发布历史：软件更新系统应提供全局一致的防篡改公共日志，其中每个软件版本对应于唯一的日志条目，该条目一旦创建，就无法修改或删除。
5. 签名密钥的演变：软件更新系统应该启用权威密钥的轮换，即使密钥的（非多数）子集受到损害也是如此。
6. 更新的及时性：客户应该能够验证软件确实与最新的软件相对应。

图15-1给出了C HAINIAC的一个例子，展示了它的各个组件如何相互作用。为了介绍CHAINIAC，我们从当今大多数软件更新系统使用的简单草编设计开始，我们提出了一个路线图。将此设计演变为我们的目标布局。最初，我们假设只使用一个静态，不可妥协的加密密钥对来签署/验证软件版本。私钥可以在一组开发者之间共享，并且公钥安装在客户端设备上，例如，在引导期间。为了分发软件，其中一个开发人员构建源代码并将二进制文件推送到可信的软件更新中心，用户可以从中下载并安装它。该稻草人系统可确保用户以最小的验证开销接收经过身份验证的版本。

图15-1 CHAINIAC架构概述

这种设计虽然很常见，却充斥着不稳定的假设。期望签名密钥是不可妥协的是不切实际的，特别是如果在多方之间共享，因为攻击者只需要破坏一个开发人员的机器来检索密钥或只强制一个密钥所有者。出于类似的原因，假设软件更新中心值得信赖是不明智的。此外，如果没有特殊措施，很难验证二进制文件是否是根据给定（未经修改的）源代码构建的，因为编译过程经常受到建筑环境变化的影响，因此非确定性。如果攻击者设法用其后门版本替换已编译的二进制文件，则在签名之前，开发人员可能无法检测到替换并且在不知不觉中签署了被破坏的软件。

15.4 Skipchains

Skipchains是经过身份验证的数据结构，它结合了区块链和skiplists的思想。Skipchains允许客户端（1）在前向和后向安全地遍历时间线，以及（2）通过采用多跳链路有效地穿越短距离或长距离。后向链接是过去块的加密哈希，与常规区块链一样。前向链接是未来块的加密签名，在目标块出现时追溯添加。

我们区分随机和确定性跳过链，其在确定多跳链路的长度方面不同。链接长度与在块创建期间计算的块的高度参数相关联，随机化的随机跳过链或通过确定性跳过链中的固定公式。在这两种方法中，跳过链都启用了对数成本时间轴遍历，包括前向和后向。图15-2示出了简单的确定性Skipchains。

图15-2 确定性Skipchains

15.5 CHAINIAC的设计

在本节中，我们将介绍CHAINIAC，这是一个增强软件更新安全性和透明性的框架。为了清楚地说明，我们首先介绍源代码和相应二进制文件的分散验证，这减轻了开发人员和客户的开销。然后，我们通过使用跳过链来提高透明度并解决更新配置的演变。最后，我们使用多级跳过链减少遍历开销，并演示如何使C HAINIAC适应多包项目。

CHAINIAC的第一步涉及扩大批准软件发布的信任基础。每个软件开发人员使用他们各自的密钥签名，而不是使用单个（共享）密钥来签署更新。在项目开始时，开发人员在策略文件中收集所有公钥，以及指定使发布有效所需的最小有效开发人员签名数量的阈值。遵循我们的威胁模型，我们假设作为信任锚的此策略文件是由用户在初始获取软件时安全获得的，例如，它可以驻留在项目的 站上，在当前的软件模型中通常是单个签名密钥的情况。

签署源代码版本的开发人员的安全优势是以要求用户构建二进制文件为代价的。这种成本是一个重要的可用性劣势，因为用户通常希望直接从软件中心接收功能齐全的二进制文件。因此，在迈向C HAINIAC的第二步中，我们将构建二进制文件的责任从用户转移到开发人员。

尽管分散的开发人员批准和可重现的构建提高了软件更新的安全性，但为每个二进制文件运行可重复的构建会给开发人员带来很大的负担（例如，在普通的现代笔记本电脑上构建Tor浏览器套件需要32个小时）。参与多个软件项目的开发人员的负载变得更糟。此外，验证大型软件项目中的许多开发人员签名可能是客户端设备的负担，尤其是在升级多个软件包时。中间人自然会更方便地接受开发人员的承诺，运行可重现的构建并产生一个容易被客户验证的结果。然而，使用受信任的第三方与CHAINIAC的权力下放目标背道而驰。因此，为了维持权力下放，我们将中间人作为集体的权力来实施。

许多软件项目由一小组（通常资金不足或志愿者）开发人员维护。因此，假设强大的攻击者可以强制组成员的阈值来创建用于目标攻击的秘密后门版本并不是不合理的。在我们迈向CHAINIAC的下一步中，我们解决了这种隐秘的开发人员模棱两可的问题，以及（不受信任的）软件更新中心的威胁，该中心意外或故意忘记了部分软件发布历史。

到目前为止，我们假设开发人员和cothority密钥是静态的，因此验证（个人或集体）签名的客户端不需要依赖集中中介（如CA）来检索这些公钥。然而，这种假设是不现实的，因为它只是在时间问题上妥协。集体签名会加剧这个问题，因为对于最大程度的独立性和管理可管理性，证人的密钥可能需要在不同的时间表上轮换。为了在不依赖于集中式CA的情况下解除这一假设，我们构建了一种用于信任委派的分散机制，该机制能够实现密钥的演进。因此，开发人员和同事可以在必要时更改其签名密钥，并为攻击者创建一个移动目标，并且流失性变得更加强大。

除了验证和验证更新之外，软件更新系统还必须确保更新的及时性，以便客户不会在不知不觉中成为冻结或重放攻击的受害者。为了保持CHAINIAC的分散化，我们依靠更新cothority来提供时间戳服务。使用一组密钥签署新版本和时间戳可以在安全性和可用性之间进行权衡，因为在线密钥比fl键更易于妥协，而后者不能经常使用。为了解决所描述的挑战，我们引入了一个具有不同信任角色的多层基于跳过链的架构，每个架构都有不同的职责和权限。我们区分ROOT，CONFIG，RELEASE和TIME四个角色。前三个基于跳过链，并通过分别表示为加密哈希和签名的向上和向下链接相互连接。图3显示了这种多层架构的概述。

图15-3 CHAINIAC的信任委托

为了跟踪软件包，用户通常依赖大型软件项目，例如Debian或Ubuntu，以及他们的 区存储库。这些软件包中的每一个都可以由一组独立的开发人员维护，因此可以部署自己的发布日志。要随时更新已安装软件包的新版本，用户必须经常联系所有相应的发布日志并按照其配置跳过链接。这不仅对用户来说是带宽和耗时的，而且还要求每个包的维护者运行新鲜度服务。为了减轻这种负担，我们进一步增强了CHAINIAC以支持多包项目。我们将聚合层引入CHAINIAC：该层负责收集，验证并向客户提供有关项目中包含的所有包的信息。项目级更新cothority实现项目日志，其中每个条目都是项目状态的快照（图4）。

图15-4 在CHAINIAC中构建聚合层。

在这项工作中，我们提出了CHAINIAC，这是一个新颖的软件更新框架，可以分散软件更新过程的每个步骤，以提高可信度并消除单点故障。C HAINIAC设计的关键新颖组件是多级跳过链和验证版本。跳过链的不同层提供了虽然为客户端引入最小开销，但具有多种功能，例如（1）新更新的防篡改和防等效日志记录，以及（2）开发人员和在线集合的签名密钥的安全演进目击者。通过将实际可重现的构建过程委派给分散的构建验证集，已验证构建减少了更多的客户负担。对我们原型的评估表明，通过对来自Debian的真实数据进行实验，使用CHAINIAC的开销对于客户和分散的证人组都是可以接受的。