威胁模型全解析：从新手入门到实战应用，助你构建安全产品！

转载于 2026-07-04 17:05:59 发布 · 16 阅读

0 GEO检测

威胁模型的陌生现状

在忙碌疲惫的一天里，参与了关于混合后量子密码学的讨论，应付端点攻击找茬的人，还参与留言板讨论后，发现“威胁模型”对多数人仍是陌生概念，且多被当作时髦用语。

有趣的相关画作

有一幅由 Embyr 创作的画，画中穿着 DEFCON 衬衫的人说“威胁模型”，Soatok（蓝色豺狗形象）有相应反应。这幅画是在反疫苗者将“威胁模型”用作时髦用语时期委托创作的，即便没这背景也挺有趣。

博客适用人群说明

若想找有超 100 篇引用、关于为涉及多个区块链的新初创公司撰写正式威胁模型文档的学术资源，这个博客可能不合适，可从 STRIDE 和系统理论入手；若想从零培养对好的威胁模型应回答哪些问题的直觉，可能来对地方了。

新手的威胁建模

有一幅由 Harubaki 创作的名为“新手”的画。从宏观看，别把威胁建模想得太复杂，虽它是正式网络安全流程，有专家专门研究，但也可在新产品或服务设计和架构阶段进行非正式威胁建模，且可能有更好结果。

一个威胁模型至少应回答这些基本问题：1. 我们最初要保护的是什么？若答不上来，还有很多基础工作要做。2. 谁或什么想要损害我们要保护的东西？包括黑客、激进分子等多种主体。3. 第 2 点中的主体可能如何攻击第 1 点中的目标？要列出攻击场景，考虑墨菲定律。4. 我们将采取什么措施来防止第 3 点中的情况发生？墨菲定律同样适用。若能回答上述问题，可称文档为威胁模型，但实践中往往因关键细节遗漏而无用。还有 5. 第 1 点中的资产是如何关联或连接的？要从图的角度思考，并非所有目标都有同等价值。6. 我们做了哪些假设，尤其是在第 4 点和第 5 点中？将在下面详细说明。7. 我们故意不处理哪些威胁？不可能应对所有可能攻击，别假装能做到。

明确假设极其重要，若假设错误，模型至少不完整，或需重新考虑接受的风险列表。例如隐形蝾螈攻击会破坏某些端到端加密消息设计中的滥用报告功能，前提是引入滥用报告机制，这是因为相关 AEAD 方案的假设被打破。明确假设能识别未知的未知因素，威胁模型应是动态文档，可适时更新。还有一幅由 CMYKat 创作的击掌贴纸画。

如何开始威胁建模

若想专业进行威胁建模，可阅读《威胁建模宣言》。做法是先将上述 7 点写成可快速复制粘贴的格式，接着绘制系统组件及关系，设置好后在图周围画框，像玩《堡垒之夜》一样迭代，记录组件输入输出，尝试回答 7 个问题，重复过程直到深入底层，思考对未深入研究层的假设。还有一幅由 CMYKat 创作的剪贴板贴纸画。要从最高层面开始，逐步深入，注意不恰当关系并尽量切断。

示例：自己的工作

正在为 Fediverse 实现密钥透明性，可在 publickey.directory 查看进展。该工作始于一份规范，其中包含显著的威胁模型，分为假设、资产、参与者并赋予角色名称、风险等部分，风险有设计上可防止、可缓解、可解决、开放四种状态。当然，这个威胁模型并不完美，可能存在呈现关系不完美、有盲点、忘记写重要假设等问题。若能看出不足，可能已足够理解如何编写自己的威胁模型，但只看此例学不到太多，还需糟糕的威胁模型文档示例。还有一幅由 CMYKat 创作的 Soatok 喝咖啡的画。

糟糕的示例：Matrix 的威胁模型

之前曾批评过 Matrix，Matrix 的威胁模型列出了拒绝服务、欺骗、垃圾邮件、间谍活动等攻击类型及具体威胁，但存在只是攻击类型列表、无假设列表、无资产列表及关系说明、攻击列表不完整、多年基本不变等问题。尽管如此，Matrix 至少有威胁模型，相比之下，Signal 只提供技术规范让用户自己琢磨威胁模型。所以给 Matrix 的威胁模型打 C - ，一个糟糕的威胁模型总比没有好。还有一幅画得很糟糕的星星，上面写着“一次尝试”。

威胁模型如何帮助你构建更好的产品

在信息安全领域初期会听到“防御者必须每次都做对，而攻击者只需要成功一次”，但装备精良的防御者可选择战场。安全从业者鼓吹纵深防御，真正做到需充分理解威胁模型，迫使攻击者陷入死胡同。

防止凭证填充攻击

凭证填充攻击有效是因为人们重复使用密码，而人们重复使用密码是因为只能记住有限数量密码。为降低风险，密码管理器曾是正确答案，如今通行密钥更好，因为它是更用户友好的身份验证方式，理想情况用户用硬件安全令牌，一般情况操作系统或密码管理器提供功能。不断追问“为什么”可了解安全控制中固有威胁，但有陷入死胡同风险。若想避免凭证填充和相关攻击，可采取设计应用程序要求使用通行密钥、要求用户注册多个通行密钥、为管理员提供添加新通行密钥方法并记录操作、尽量不支持密码身份验证等措施。通行密钥无法被网络钓鱼，采用它能节省成本、避免无效测试、消除多种攻击并提高可用性。一个好的威胁建模练习可让人有此发现。有一句名言“以牺牲可用性为代价的安全，最终也会损害安全”。还有一幅由 CMYKat 创作的 Soatok 戴着用胶带粘起来的眼镜的画。

分布式端到端加密

密码学专家和去中心化爱好者讨论两种直接消息端到端加密提案，即 ActivityPub E2EE 规范和 Germ Network 项目，都曾考虑用 MLS 作为密钥管理协议，但在非中心化系统中使用 MLS 有两个重要注意事项。一是 MLS 定义的认证服务被 SimpleX 负责人误解，提出的密钥透明性提案是解决方法；二是消息排序对 MLS 时代的棘轮树安全性至关重要。对于 ActivityPub，采用密钥透明性后需处理 KeyUpdate 消息竞争问题；对于 ATProto / BlueSky 情况更棘手。

为什么 ATProto 让问题更难解决

ATProto 不像 Fediverse 有实例，部分原因是其由受比特币影响的开发者设计，认为拥有“全局状态”是不错的服务设计选择，而区块链是难稳定的全局状态。与 ActivityPub 不同，不能简单构建加密消息传递工具，安全分析时要将内容视为点对点，需设计复杂协议保证消息排序，或放弃 MLS 采用成对端到端加密。还有一幅由 AJ 创作的 Soatok 对着电脑大喊的画。

威胁建模的帮助

若将用户消息保密性视为安全目标且希望托管去中心化，ATProto 受区块链启发的设计会阻碍使用有效群组密钥协商协议。目前有工程师在解决问题，但设计阶段可避免错误。还有一幅由 AJ 创作的 Soatok 出现故障的画。

威胁模型的非实用用途

读到这里，应明白什么是威胁模型、好的威胁模型应包含什么、如何识别糟糕的威胁模型、威胁建模如何帮助构建更好的产品。这些实用内容可能枯燥，提升威胁建模技能还能在技术讨论中识破胡说八道。

后量子密码学的威胁建模

最近写了关于混合后量子结构的博客，IETF 的 TLS 工作组邮件列表在进行最后一轮讨论，Daniel J. Bernstein 召集人谴责。像 Patrick Timothy Dalrymple、Willow 等人的言论引发 DJB 回应。除了不讲道理和性骚扰者，要求很多人说明具体安全担忧，他们遵循非黑即白思维方式。

为应用威胁建模理解这种情况，需确定事实：1. ML - KEM 不是 NSA 的设计，主要提交者是 Peter Schwabe，其他提交者分布在欧洲各地。2. 信息论排除 ML - KEM 存在后门的可能性。3. ML - KEM 是通过公开、长达十年的国际努力被选中进行标准化的。4. NIST / FIPS / NSA 要求在机密系统中使用非混合的 ML - KEM / ML - DSA，若有后门他们急于迁移系统就太愚蠢。不同意这些事实的人是拒绝现实，应拿出证据。

当前 IETF 讨论发布为非混合的 ML - KEM 建立代码点的 RFC，混合 KEM 更受青睐，发布该 RFC 对配置为始终使用混合 KEM 的系统安全性无降低。谷歌 Chrome 已支持非混合的 ML - KEM，阻止该 RFC 对大多数互联网用户的现实世界安全无好处。该 RFC 对需遵守特定规则且要求有稳定 IETF RFC 编号的组织有作用。出于意识形态反对 RFC 会让相关人陷入困境，与减少危害目标相反。

技术上有人认为混合后量子 + 传统密码学比纯后量子更好，这就需运用威胁建模技能思考。用 Q - Day 简称“对手建造出与密码学相关的量子计算机的那一刻”，KEM 面临“现在收集，以后解密”风险。纯 ECDH 在 Q - Day 时会被追溯性破解；纯后量子算法在 Q - Day 时若本身未被破解则不会被破解；混合后量子 + ECDH 是对 Q - Day 之前算法被破解的对冲策略，但 Q - Day 之后完全没用。DJB 煽动反对纯后量子算法，支持混合后量子 + ECDH，但 ECDH 在 Q - Day 时对安全性贡献为零。如今主张使用 ECDH + ML - KEM 承认 ML - KEM 长远来看是安全算法选择。选择混合方案一是能更快过渡到后量子时代，二是对冲 ML - KEM 或基于格的密码学算法类在 Q - Day 之前被破解的风险。最理智的主张是使用 ML - KEM + HQC + ECDH 的三方混合方案，反对 RFC 的人没人主张此方案。对 RFC 的反对意见往往愚蠢且考虑不周全，是锻炼辨别能力的好机会，也不必信任 NSA 等间谍机构。还有一幅由 CMYKat 创作的吐舌贴纸画。