TUF系统概述 - 技术栈

TUF基本介绍

TUF 是一个为软件更新系统设计的安全框架，最初由纽约大学的 Secure Systems Lab 提出。它的目标是解决传统软件更新过程中的各种安全问题（如中间人攻击、回滚攻击、密钥泄露等），通过多角色职责分离、多签名机制和密钥轮换机制来提高软件供应链的抗攻击能力和韧性。

职责分派（Role Delegation）

将软件更新所涉及的权限分给不同角色，各自负责不同类型的元数据，降低"单点控制"的风险。

好处： 如果一个角色（如 timestamp）密钥泄露，其能力有限；不会影响整个更新系统。

多密钥 + 阈值签名（Threshold Signatures）

每个角色可以设置多个密钥，以及一个 签名阈值 k-of-n 。
- 例如：targets 角色可以设置"必须有 2 个开发者签名才有效"。

好处： 即使一个开发者的密钥泄露，攻击者也无法伪造有效更新。

密钥轮转 & 撤销（Key Rotation & Revocation）

所有公钥都被记录在 root.json 中，因此可以通过发布新版本的 root.json 来更换密钥。
密钥丢失或泄露后，管理员可通过 root 签名发布新的密钥信息。

好处： 密钥是可更新的，系统不依赖于长期安全的密钥对。

相比传统软件更新的优势

传统方式	存在问题	TUF 对应的改进
单密钥签名包	密钥泄露 = 全系统沦陷	多密钥 + 阈值签名
所有操作权限集中在一处	单点失败问题严重	明确角色职责分工，攻击面变小
没有更新验证链	无法追踪或信任	所有元数据签名链确保完整性
密钥一旦泄露难以替换	无轮转机制	通过 root.json 灵活轮转密钥
无法识别元数据或内容是否篡改	无法抵御回滚，冻结攻击，混合匹配攻击	snapshot + timestamp 双重保护

定义元文件

元文件定义

TUF中被保护的软件或软件包称为Target File，保护软件包的元文件称为Metadata File，分为Root.json，Timestamp.json，Snapshot.json，Target.json。

Notary中只存储和操作元数据文件，不存储软件或软件包本身。

角色划分

角色名称	职责概要	签名对象	密钥位置	由谁管理	签名要求
Root	管理和分发所有其它角色的公钥。支持密钥轮换、撤销。	Root.json	离线	仓库管理员	一般需 ≥2-of-n 签名
Targets	指定哪些镜像（或文件）被信任，可发布。支持 Delegation。	Targets.json	离线	项目负责人、开发者团队	一般需 1 或多签名
Snapshot	确保 targets（及其 delegation）元数据的一致性与版本管理，防止回滚和混合匹配攻击。	Target.json及其Delegation	可存服务端	自动化构建系统或服务器	通常 1 个签名
Timestamp	指出最新的 snapshot 版本，减轻冻结攻击。	Snapshot.json	服务端	自动化构建系统或服务器

定义数据格式与验证方式

参考网址：TUF规范

数字签名概念，为什么不依赖信道安全和第三方背书。

威胁模型

恶意更新，混合匹配攻击：阈值签名，哈希校验
回滚攻击：json文件版本号，snapshot版本号
冻结攻击：timestamp快速过期
密钥泄漏：
- Timestamp泄漏造成冻结攻击
- Release，Target或Release+Target单独泄漏不造成危险
- Timestamp+Snapshot造成冻结攻击和Mix-Match
- Timestamp+Snapshot+Target全部泄漏或者Root泄漏，系统危险
- Root密钥泄漏个数少于Threshold时，不会使系统完全失信

系统架构与工作流

系统架构与初始化流程

首次信任配置，公钥注册。

元数据更新流程

更新Root.json（密钥轮转与撤销）

令N表示当前可信根元数据文件的版本号。
尝试下载Root.json的N+1版本，最多X字节
检查是否存在恶意软件攻击 ：
1. 需要超过Threshold个版本N的Root.json签名验证通过（垂直验证）
2. 需要超过Threshold个版本N+1的Root.json签名验证通过（水平验证）
检查是否存在回滚攻击 ：
1. 新Root.json版本号 = 旧Root.json版本号 + 1
检查是否存在冻结攻击：中间Root.json过期没有关系
持久化Root.json
重复2～9步
检查是否存在冻结攻击：最终的Root.json文件过期时间戳未到，且高于固定更新时间
持久化最新Root.json

Root.json更新需要逐级建立信任链，也就是从版本1，逐级更新到版本N，中间不能跳跃。

更新Timestamp.json

下载Timestamp.json，最多X字节
检查是否存在恶意软件攻击 ：用Root.json记录的公钥验证Timestamp.json签名，需要超过Threshold个签名验证通过
检查是否存在回滚攻击 ：
1. 新Timestamp.json版本号 > 旧Timestamp.json版本号
2. 新Timestamp.json中记录的Snapshot.json版本号 >= 旧Timestamp.json中记录的Snapshot.json版本号
检查是否存在冻结攻击：新TimeStamp.json文件过期时间戳未到，且高于固定更新时间
持久化Timestamp.json

更新Snapshot.json

下载Snapshot.json，最多X字节
防止中间人攻击者的混合搭配攻击：校验新Snapshot.json的哈希值是否与Timestamp.json记录的哈希值一致
检查是否存在恶意软件攻击 ：用Root.json记录的公钥验证Snapshot.json签名，需要超过Threshold个签名验证通过
检查是否存在回滚攻击 ：
1. 新Snapshot.json版本号 = 最新的Timestamp.json中记录的Snapshot.json版本号
2. 新Snapshot.json中记录的Target.json版本号 >= 旧Snapshot.json中记录的Target.json版本号
检查是否存在冻结攻击：新Snapshot.json文件过期时间戳未到，且高于固定更新时间
持久化Snapshot.json

更新Target.json

下载Target.json，最多X字节
防止中间人攻击者的混合搭配攻击：校验新Target.json的哈希值是否与Snapshot.json记录的哈希值一致
检查是否存在恶意软件攻击 ：用Root.json记录的公钥验证Target.json签名，需要超过Threshold个签名验证通过
检查是否存在回滚攻击 ：
1. 新Target.json版本号 = 最新的Snapshot.json中记录的Target.json版本号
检查是否存在冻结攻击：新Target.json文件过期时间戳未到，且高于固定更新时间
持久化Target.json

部署模型

Delegation与路径划分

在实际生产项目中，镜像往往不是直接挂在顶层的Target.json下，而是创建多个Delegation角色，每个 Delegation 角色（如 targets/releases、targets/dev-team-a）都可以指定它负责的 路径前缀（path pattern），用于匹配特定的镜像名或 target 路径。

txt 复制代码

projects/
├── notary
├── docker
internal/
├── monitor
├── backup

角色	负责路径（path pattern）	所属团队
targets/releases	projects/notary/, projects/docker/	官方发布
targets/notary	projects/notary/dev/*	团队 A 维护
targets/docker	projects/docker/dev/*	团队 B 维护
targets/internal	internal/*	内部维护者专属

存在的问题

委托顺序问题：当多个角色关联到相同文件时，存在歧义
=> 区分优先级：Target.json中的委托声明顺序作为优先级
故障转移问题：无法做到bar-*都通过B角色校验，其他通过C角色校验
=> 引入Terminating标记：比如标记B为Terminating，那么在B所关联的文件中没有找到bar-*文件的话，则也不会在其他角色下搜索相关文件。

最大安全模型和传统安全模型

基本描述

安全模型	简要描述	特点
Maximum Security Model (MSM)	精细化的委托，只有Timestmap Key保存在服务器，其余密钥都离线保存	安全性高，不易部署
Legacy Security Model (LSM)	部分签名操作由服务器完成，密钥（如 Snapshot、Timestamp）都保存在服务器上	安全性一般，容易部署

Project类型

MSM和LSM把各个软件包根据签名与否，划分为如下集合，称为Project：

项目类型	定义与特点	密钥类型	签名人	所属模型
Claimed Project	由开发者认领并签名	离线	开发者	Both
New Project	刚发布，开发者未注册签名 key	在线	无	Both
Rarely Updated Project	长期无更新但仍需信任	离线	管理员	MSM
Unclaimed Project	没有绑定具体维护者，未进行"认领"	在线	无	LSM

软件包生命周期

新镜像

刚创建：New Project
开发者进行签名：转移到Claimed Project
- 长久未更新：转移到Rarely Update Project
开发者没有进行签名：转移到Unclaimed Project
原有镜像：
未签名：转移到Unclaimed Project
- 管理员代签：转移到Rarely Project
已签名：转移到Claimed Projet

LSM转换为MSM

从上往下：角色优先级递减
LSM -> MSM：Unclaimed Project -> Rarely Update Project

参考资料

TUF规范
TUF论文：
- 原理：Survivable Key Compromise in Software Update Systems
- 实际部署：Diplomat: Using Delegations to Protect Community Repositories
Notary文档
DCT文档