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字节
- 检查是否存在恶意软件攻击：
- 需要超过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
- 委托顺序问题：当多个角色关联到相同文件时，存在歧义
=> 区分优先级：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由开发者认领并签名离线开发者BothNew Project刚发布，开发者未注册签名 key在线无BothRarely Updated Project长期无更新但仍需信任离线管理员MSMUnclaimed Project没有绑定具体维护者，未进行“认领”在线无LSM软件包生命周期
新镜像
- 刚创建：New Project
- 开发者进行签名：转移到Claimed Project
- 长久未更新：转移到Rarely Update Project
- 开发者没有进行签名：转移到Unclaimed Project
原有镜像：
- 未签名：转移到Unclaimed 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文档
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
