TUF基本介绍
-
TUF 是一个为软件更新系统设计的安全框架，最初由纽约大学的 Secure Systems Lab 提出。它的目标是解决传统软件更新过程中的各种安全问题（如中间人攻击、回滚攻击、密钥泄露等），通过多角色职责分离、多签名机制和密钥轮换机制来提高软件供应链的抗攻击能力和韧性。
-
具体案例： Notary是Docker 官方对 TUF 的实现，用来提供签名、校验、分发 Docker 镜像的能力，为人熟知的DCT（Docker Content Trust），就是Docker CLI 对 Notary 的集成和启用接口。
职责分派（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字节 - 检查是否存在恶意软件攻击：
- 需要超过
Threshold个版本N的Root.json签名验证通过（垂直验证） - 需要超过
Threshold个版本N+1的Root.json签名验证通过（水平验证）
- 需要超过
- 检查是否存在回滚攻击：
- 新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个签名验证通过 - 检查是否存在回滚攻击：
- 新Timestamp.json版本号 > 旧Timestamp.json版本号
- 新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个签名验证通过 - 检查是否存在回滚攻击：
- 新Snapshot.json版本号 = 最新的Timestamp.json中记录的Snapshot.json版本号
- 新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个签名验证通过 - 检查是否存在回滚攻击：
- 新Target.json版本号 = 最新的Snapshot.json中记录的Target.json版本号
- 检查是否存在冻结攻击：新Target.json文件过期时间戳未到，且高于固定更新时间
- 持久化Target.json
部署模型
Delegation与路径划分
在实际生产项目中，镜像往往不是直接挂在顶层的Target.json下，而是创建多个Delegation角色，每个 Delegation 角色（如 targets/releases、targets/dev-team-a）都可以指定它负责的 路径前缀（path pattern），用于匹配特定的镜像名或 target 路径。
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
扫一扫
102
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
