首页分享走马观花云原生技术（15）：安全更新规范 TUF

走马观花云原生技术（15）：安全更新规范 TUF

来源：花匠小妙招时间：2025-01-08 15:00

今天继续聊云原生的相关技术，这一次要讲到的这个技术与安全相关。

今天的计算机，安全已经成为一个越来越重要需要考量的因素，我们的个人隐私，公司商业数据等几乎一切数据都在计算机中存储，如何保障安全成为架构中不得不考量的要素。

当然，关于架构上的安全，我认为零信任网络这个概念与实践，可能更值得做产品或项目的架构师关注。而今天要聊到的安全更新规范TUF，属于一个非常抽象，并且离我们实际使用可能比较远的一个技术。

什么是TUF

TUF -- The Update Framework，中文翻译过来就是安全更新框架。但实际上，如果你理解了TUF是什么之后，可能我认为用安全更新规范来称呼它更合适。

因为TUF是一种设计上的规范，它实际上并不包括任何实现。实现TUF需要自行编码去实现TUF中的理念与规范。

比如，Docker中有一个Content trust in Docker的安全实现，它其实是基于TUF规范而实现的。

所以，TUF并不是一个实际可调用的框架或能集成到你项目或产品中的东西，它是规范与理念，如果你认同TUF的规范，那你就得基于它的规范自行去实现它这一套安全机制。

TUF关注什么

TUF关注与想解决的是，网络中的分发的二进制的安全性。在TUF列举的一些不安全的网络行为，包括：

• 任意软件安装：你可能认为下载了一个可信的安装包，但它可能是伪造的。• 回滚攻击：你更新了一个新的版本，但实际上它是有漏洞的旧版本• 快进攻击：攻击者修改软件的预期更新版本号为一个非常高的值，导致软件无法更新到当前最新的版本，因为最新的版本小于这个值• 无休止的数据攻击：攻击者提供一个更新下载，这个下载的数据永远没有尽头，导致软件一直不断的下载

可能在架构中，我们预期的安全更多的是用户密码访问，数据明文，传输是否加密，非法入侵服务器等行为，TUF列举的这些很多压根不在架构师的考虑范围之内。

这也是我认为做为普通的架构师，能实践与应用到TUF的场景可能很少。

不过我说一个场景，大家就会理解TUF的作用，特别是在容器时代，镜像的安全性如何保证？

上述列举的一些不安全的网络行为，针对镜像的更新与下载，是都有可能存在的。所以可以理解，在这种业务场景下，TUF就可以派上用场。

TUF的核心概念

前面已经解释过了，TUF并不是实现。它更多的是规范，它提出了一个它认为足够防止这些不安全行为的规范，如果你想使用TUF，你可能需要使用自己的语言来实现TUF中的这些规范。

当然有一些已经实现的语言版本，比如python的python-tuf

因此，在这篇文章中，可能稍微解释下TUF到底是个什么理念更妥当。

实事求是的说，想要简明清晰的讲清楚TUF的理念与规范，并不是个容易的事，我也只能让大家对它大致有个理解。我总结的TUF中的核心理念包括：

• 多重签名• 角色机制• 频繁的更新

多重签名

保证二进制安全，有一个重要的措施是我们大家都知道的，就是使用公私钥，用私钥对需要发行的二进制文件进行签名。下载二进制的一方使用公钥进行检验。

但这个其实并不足够安全，因为私钥是非常容易传播，共享与泄露的。

比如我以前在负责iOS开发时，iOS打包都是需要一堆相关联的证书（包含私钥）的，我们当时的策略就是在团队内部共享这些证书及私钥。相信这种行为在很多公司或团队中是个比较普遍的。

所以，光是签名，并不足够安全。而TUF也是基于认为私钥可能会传播及泄露这个不安全的基础之上，TUF设计了一种看似比较笨但也非常实际的思路，那就是：

不共享密钥，取而代之的是产生足够多的私钥并进行频繁的更新，以及支持一个文件需要多个签名才有效

私钥虽然会泄露，但基于频繁的更新及要求多个签名的双重保证之上，单个私钥的泄露不足以影响安全。这个设计不得不说有点夸张，但仔细想想确实能解决问题。

角色机制

要支持多重签名，TUF设计了Role角色这个概念。

TUF自己设计了几种角色，包括Root，Targets，Snapshot，Timestamp

上面这些角色对应一些固定的JSON配置，每个JSON中可以对角色的公钥及能做的可以进一步定义。每个角色承担的任务也不同，比如Root是根角色，用来定义其它角色的，Timestamp是定义有效期的，TUF认为任何一个授权不应该永远有限，一定要有有效期。

而最重要的是Targets角色，Target角色有两个作用，一个是定义当前Role允许的发行二进制文件及其hashs值等；二个是定义Delegated Targets，Delegated Targets相当于子角色，Delegated Targets又可以定义自己的Delegated Targets，这样相当于分级授权。

频繁的更新

TUF认为，为了保证安全，密钥不应该永久有效，而应该频繁的更新。所以TUF提出了频繁更新密钥的理念。也就是上面所讲的各种多重签名也好，角色也好，都应该是定期更新以获取最新的授权机制。

举例说明，比如每周更新一次所有的密钥。这样下载安全更新的一方，需要定期更新最新的TUF配置文件。

基于这种理念的设计之下，就算个别的密钥被传播，影响也几乎可以忽略不计。因为很快这个密钥就会失败。