Soatok 非正式威胁建模指南
在经历了关于混合后量子密码学（Hybrid Post-Quantum Cryptography）的漫长而令人疲惫的对话、一些随机混蛋试图用端点攻击来对端到端加密消息应用玩"抓到你了"的把戏、以及愚蠢政客推行更多"年龄验证"狗屁规定引发的论坛讨论之后，我清楚地意识到一件事："威胁模型"（Threat Model）这个词对大多数人来说是一个完全陌生的概念。
呃，除了作为一个流行词之外。
首先说明：如果你来这里是为了寻找一篇包含 100 多篇参考文献的学术资源，教你如何为你的涉及多条区块链的新创业公司编写正式的威胁模型文档，那么这个同性恋 furry 博客可能不适合你。不妨从 STRIDE 和 系统理论 开始。
但如果你想建立对"好的威胁模型应该回答哪些问题"的直觉，而且你正从零开始，那你可能来对地方了。
那么，我们来谈谈威胁建模吧。
面向新手的威胁建模
从高层看，别想得太复杂。
虽然威胁模型是一个正式的网络安全流程，一些信息安全专业人士确实专攻于此，但你在开发新产品或服务的设计和架构阶段进行非正式的威胁建模，谁也拦不住你。最终的结果可能还会更好。
一个威胁模型至少应该回答以下基本问题：
1. 我们到底要保护什么？
如果你回答不了这个问题，那你还有很多基础工作要做。
2. 谁/什么想要伤害我们正在保护的东西？
黑客、活动分子、网络 stalker、社交媒体骚扰网络
自然灾害 / 坏运气
薪水低、工作过度、终于忍无可忍的员工
被大企业说客收买、通过愚蠢法律伤害所有人的白痴立法机构
国家级对手！！！！
3. (2) 如何攻击 (1)？
攻击场景写在这里
墨菲定律也写在这里
4. 我们将采取什么措施来防止 (3) 的发生？
墨菲定律同样写在这里！
好吧，如果你能把这几点列出来，你的文档在某种意义上就可以被称为威胁模型了。
然而，这在实践中往往毫无用处，因为一些关键细节被遗漏了。
5. 资产 (1) 之间是如何关联/连接的？
用图来思考，而不是列表。
并非所有目标的价值都相等。
6. 我们做了哪些假设，特别是关于 (4) 和 (5) 的？
下面我会详细说明。
7. 我们故意不应对哪些威胁？
你根本不可能应对未来任何人在不可预见的未来能想象到的每一种可能的攻击，所以别假装你能。
讽刺的是，太多人把假设 (6) 当作理所当然，但尽可能清晰地阐明你的假设是极其重要的。
如果你的某个假设是错误的，那么你的模型最多是不完整的，或者你需要重新考虑你的已接受风险列表 (7)。
例如：隐形蝾螈攻击（Invisible Salamanders attack） 破坏了一些端到端加密消息设计中的滥用举报功能，但这仅在引入了滥用举报功能时才成立。
这个攻击之所以可能，是因为相关 AEAD 方案（AES-GCM、ChaCha20-Poly1305）的假设之一是：对于给定的消息，只有一个有效的密钥。一旦你为给定消息引入了多个有效密钥（或混淆代理人），你就已经超出了算法的安全保障范围——对攻击者来说，这就成了一个有趣的把戏。
明确你的假设能让你识别自己的"未知的未知"。你不需要追求完美。
事实上：威胁模型应该是活文档，而不是某个时间点的快照。在适当的时候更新它们。
如何开始
如果你想专业地做威胁建模，你可能需要阅读 威胁建模宣言（Threat Modeling Manifesto）。以下是我个人的方法。
首先，把上面 7 个问题写在一个可以快速复制粘贴的格式里。你会需要它的。
接下来，在一大张方格纸（或者数字等效物）上画出你正在设计或分析的系统的各个组件。如果某个组件直接与另一个组件通信、依赖或交互，你需要用你最习惯的约定画出这种关系。
完成后，在整个图的外围画一个方框，然后假装你在玩《堡垒之夜》：每隔一会儿，方框会缩小并聚焦到每个单独的组件上。每次迭代，记录每个组件的所有输入和输出，并尽可能回答那 7 个问题。
重复这个过程，直到深入到你的抽象层级允许的极限，然后头脑风暴你对未继续深入的那些层级有哪些假设。
你正在做的是从最高层级开始，逐步向下深入到更具体的部分。
你的数据库可能不像你的负载均衡器那样依赖 X25519 的安全性。但你的数据库可能也不应该内置 RSS 订阅功能。注意那些不合适的关系，并在可能的情况下切断它们。
实例：我自己的工作
你可能已经知道，我正致力于为 Fediverse 提供密钥透明性。这项工作在 publickey.directory 上跟踪进度。
该威胁模型分为以下几个部分：
1. 假设（事先声明）
2. 资产
3. 行为者（包括攻击者和我们想要保护的人），赋予角色名称
4. 风险，附有四种状态之一：
设计层面即已阻止（Prevented by design）：攻击根本不起作用 😀
已缓解（Mitigated）：攻击不应成功，除非某个假设是错误的。对研究人员来说最值得关注。
可处理（Addressable）：有办法缓解风险，但需要付出努力或谨慎。运营人员应了解这一点。
未处理（Open）：这是我们无法或不会缓解的风险。这些攻击将会成功。
这个威胁模型当然并不完美。我没有以人类可读的图形方式完美地关联资产和行为者。风险部分可能有一些我从未考虑过的盲点。我可能忘记写下某个对系统安全至关重要的假设。
如果你能看我的项目的威胁模型并发现它的不足，那你很可能已经足够理解这项任务，可以自己写一个了。
但不多做自我推销了。只看我的 furry 实例你是学不到多少的。我们还需要一个糟糕的威胁模型文档的例子，而我还真有一个现成的。
反面示例：Matrix 的威胁模型
我以前就找过 Matrix 的茬（两次），所以如果你读过那些博客，这对你来说并不新鲜。
这份 是 Matrix 的威胁模型（最新 v1.18 版）：
9. 安全威胁模型
9.1 拒绝服务（Denial of Service）
攻击者可能试图阻止消息传递给受害者或从受害者处发出，目的是：
扰乱商业竞争对手的服务或营销活动。
审查讨论或审查讨论中的参与者。
进行一般性破坏。9.1.1 威胁：资源耗尽（Resource Exhaustion）
攻击者可能导致受害者的服务器耗尽特定资源（如开放 TCP 连接、CPU、内存、磁盘存储）。
9.1.2 威胁：不可恢复的一致性违规（Unrecoverable Consistency Violations）
攻击者可能发送消息，在集群中造成不可恢复的"脑裂"状态，使受害者的服务器无法得出一致的聊天室状态视图。
9.1.3 威胁：不良历史（Bad History）
攻击者可能诱使受害者接受无效消息，受害者会将这些消息包含在其聊天室历史视图中。聊天室中的其他服务器会拒绝这些无效消息，并可能因为受害者依赖于这些无效消息而拒绝其消息。
9.1.4 威胁：阻断网络流量（Block Network Traffic）
攻击者可能试图在受害者的服务器与聊天室中的部分或全部其他服务器之间设置防火墙。
9.1.5 威胁：消息量过大（High Volume of Messages）
攻击者可能向有受害者的聊天室发送大量消息，使聊天室无法使用。
9.1.6 威胁：未经必要授权封禁用户（Banning users without necessary authorisation）
攻击者可能试图在没有必要授权的情况下封禁聊天室中的用户。
9.2 欺骗（Spoofing）
攻击者可能试图发送声称来自受害者、但受害者并未实际发送的消息，目的是：
冒充受害者进行非法活动。
获取受害者的权限。9.2.1 威胁：篡改消息内容（Altering Message Contents）
攻击者可能试图篡改来自受害者的现有消息的内容。
9.2.2 威胁：伪造消息"来源"字段（Fake Message "origin" Field）
攻击者可能试图发送一条声称来自受害者的新消息，并带有伪造的"origin"字段。
9.3 垃圾信息（Spamming）
攻击者可能试图向受害者发送大量主动或非主动请求的消息，目的是：
寻找诈骗受害者。
营销不需要的产品。9.3.1 威胁：未经请求的消息（Unsolicited Messages）
攻击者可能试图向不希望接收消息的受害者发送消息。
9.3.2 威胁：辱骂消息（Abusive Messages）
攻击者可能向受害者发送辱骂或威胁性消息。
9.4 间谍（Spying）
攻击者可能试图访问由受害者发送或发送给受害者的消息内容或元数据（这些内容本不应被攻击者获取），目的是：
获取敏感的个人或商业信息。
使用消息中含有的凭证冒充受害者（例如密码重置消息）。
发现受害者在与谁交谈以及何时交谈。9.4.1 威胁：传输过程中泄露（Disclosure during Transmission）
攻击者可能试图在服务器间传输过程中暴露消息内容或元数据。
9.4.2 威胁：向聊天室外服务器泄露（Disclosure to Servers Outside Chatroom）
攻击者可能试图说服聊天室内的服务器将消息发送到其控制的、未被授权进入聊天室的服务器。
9.4.3 威胁：向聊天室内服务器泄露（Disclosure to Servers Within Chatroom）
攻击者可能控制聊天室内的一个服务器，以暴露该房间中消息的内容或元数据。
（是的，我把整个部分都摘录在上面了。）
浏览下来，你可能会注意到几点：
1. 这只是一份不同攻击类型的列表而已。
2. 没有假设列表。
3. 没有资产列表，也没有资产之间的关系。
4. 攻击列表极不完整——尽管有人鼓吹Matrix 优于其他 E2EE 消息应用，他们的威胁模型对密码学或密钥管理只字未提。
5. 额外观察：它自 v1.1（2021 年发布）以来基本没有变化，尽管我披露了漏洞，Lotte 也发现了另外两种密码学攻击。
虽然这令人恼火，而且完全给 Matrix 不及格的诱惑很大，但至少他们有一个威胁模型。
相比之下，Signal 给了你一堆技术规范，然后期望你自己去弄清楚威胁模型。这是 Signal 让我恼火的许多事情之一。
所以，对于 Matrix 的威胁模型作者，我授予以下评价：
Matrix 的威胁模型？我给 C-。
一个糟糕的威胁模型也胜过没有威胁模型。
威胁模型如何帮助你构建更好的产品
你在职业生涯早期会听到很多信息安全的老生常谈。比如："防御者必须每次都对，攻击者只需要对一次。"
是啊，但装备精良的防御者可以选择战场。把这个放进你的《孙子兵法》烟斗里抽吧。
每个安全从业者都宣扬纵深防御，但真正的纵深防御意味着充分理解你的威胁模型，从而迫使攻击者走入可预见的死胡同。
让我先给你一个实用的例子，再来一个更有趣的。
防止凭据填充（Credential Stuffing）
凭据填充是一种愚蠢简单的攻击，在大多数现实场景中却出奇地有效。
为什么？因为人们重复使用密码。
为什么人们重复使用密码？因为他们只能记住这么多密码，而要求他们为你的应用创建唯一且安全的密码简直是天方夜谭。
为了缓解这种风险，在很长一段时间里，密码管理器是解决这个问题的正确答案。如今，它们仍然还行（但 Lastpass 除外），不过通行密钥（passkeys）更好。
为什么？因为通行密钥是一种更用户友好（注意：不是完全用户友好）的方式，让用户使用非对称密码学进行认证。在最好的情况下，他们使用的是硬件安全令牌（如 SoloKeys 或 YubiKeys）。在一般的情况下，他们的操作系统或密码管理器在替他们做这件事。
像这样追问一连串的"为什么？"是感受（存在严重缺陷的）安全控制中固有威胁的一种方式。但这确实有陷入兔子洞的风险，所以得小心。
如果你想避免凭据填充和相关的琐碎攻击：
1. 设计你的应用要求使用通行密钥。
2. 要求用户注册多个通行密钥（或至少一个用于备份）。
3. 给管理员提供一种"破例"为丢失所有凭据的其他用户添加新通行密钥的方式。以管理员无法篡改的方式记录这些操作。
4. 如果可能，根本不要支持密码用于认证。——用于派生加密密钥的密码是可以的。
额外的好处是，通行密钥也不可钓鱼——因为协议在注册期间将每个凭据以密码学方式绑定到一个域名。
无论你让用户接受通行密钥需要付出什么成本，你都会在凭据填充和钓鱼导致的支持负担（以及完全避免那些不能可衡量改善结果的愚蠢的"钓鱼测试"）上省下更多。
通过消除人类记忆（且永不重复使用）高熵秘密的不合理期望，你同时消灭了多类攻击并提高了可用性。一个好的威胁建模练习可以让你独立于我的博客文章而发现这一点。
以牺牲可用性为代价的安全，最终会以牺牲安全为代价。
—— Avi Douglen
下一个例子更有趣，但也稍微高级一些。
分布式端到端加密（Distributed End-to-End Encryption）
目前有两个关于直接消息的端到端加密提案正在被密码学专家和去中心化爱好者讨论：
1. ActivityPub E2EE 规范，旨在为联邦宇宙软件（如 Mastodon）提供私密 DM。
2. 像 Germ Network 这样的项目，希望为 ATProto（如 BlueSky）实现同样的目标。
两个项目都曾考虑使用 MLS 作为其 E2EE 会话密钥管理协议。
然而，在非中心化系统中使用 MLS 有两个重要的注意事项，使得安全性不那么直接。
1. MLS 指定了一个名为"认证服务（Authentication Service）"的抽象概念，SimpleX 的负责人以一种公开而尴尬的方式误解了它。我提出的密钥透明性方案是在不创建中心化权威的情况下解决这个问题的一种方式。
2. 消息排序对于构成 MLS 中 epoch 基础的棘轮树的安全性至关重要。
对于 ActivityPub，如果他们采用密钥透明性来处理第一个注意事项，他们只需要明确如何处理来自多个服务器、特别是不同服务器上的多个 KeyUpdate 消息的竞态条件。这并非易事，但可以解决。
但 ATProto / BlueSky 的情况更棘手。
为什么 ATProto 让这变得困难
ATProto 没有实例，不像 Fediverse 那样。部分原因是因为 ATProto 是由 Jack Dorsey 工资单上那些被比特币洗脑的开发者设计的，他们认为拥有"全局状态"是一个好的服务设计选择。而区块链是最糟糕的稳定全局状态的方式，因为会有太多的写入者。
你不再仅仅构建一个客户端用来加密消息并传递给其实例的东西（就像 ActivityPub 那样），而是基本上需要把所有东西都当作点对点（或非常接近 p2p）来进行安全分析。
这意味着你需要找出另一个复杂的协议来保证分布式系统中的消息排序（例如，像 Raft 共识算法这样的东西），或者你完全放弃 MLS，转而使用成对 E2EE 并放弃群组抽象。
威胁建模如何帮助
如果你将用户之间传递的消息的机密性视为项目的安全目标，并且你希望托管是去中心化的，那么 ATProto 受区块链启发的设计实际上是在阻碍使用当今标准化的最高效的群组密钥协商协议。
是的，这是几位优秀的工程师目前正在巧妙应对的障碍，但如果你当初还在画图阶段时就可以避免他们的错误。
威胁模型的不实用用途
好吧，如果你读到了这里，希望你已经了解了：
1. 什么是威胁模型
2. 一个好的威胁模型应该包含什么
3. 如何发现糟糕的威胁模型
4. 威胁建模如何帮助你构建更好的产品
这些都是实用、有用的东西，但可能会有点枯燥。
如果我告诉你，提升你的威胁建模技能可以让你在技术讨论中更好地嗅出胡说八道呢？
为后量子密码学进行威胁建模
我最近写了一篇关于混合后量子构造的博客文章，讨论的是签名而非后量子 KEM。
碰巧的是，IETF 的 TLS 工作组邮件列表上正在进行一项 Last Call，Daniel J. Bernstein 不帮忙地决定试图通过召集 Twitter 路人和阴谋论者来制造草根反对。
我没有夸张。像这样的帖子促成了 DJB 的发帖：
我强烈反对 NSA 的提议。
Patrick Timothy Dalrymple
LYRIA 创始人兼 CEO
或者，可能是迄今为止最愚蠢的：
不要发布这份文档。启用国家信号情报（SIGINT）会伤害所有人。
—— Willow
除了那些明显不理智的人（以及不受欢迎的性骚扰者，比如我拒绝交流的 Jacob Appelbaum），我确实问了许多被 DJB 召唤到该线程的人，让他们详细说明他们具体的安全担忧。
不出所料，他们遵循的是同样的非黑即白思维（"混合好！纯 PQ 坏！"），正如我所怀疑的那样，但你总得试探一下，以防有出乎意料的原因！
为了将我们对威胁建模的理解应用到这种情况，我们需要确立一些事实。
1. ML-KEM 不是 NSA 的设计。
其主要提交者是 Peter Schwabe，他曾与 Daniel J. Bernstein 合作开发 NaCl 密码学库，居住在德国。其他提交者遍布欧洲各地。
2. 信息论排除了 ML-KEM 后门的可能。
参见：Sophie Schmieg。
3. ML-KEM 是通过一个非常公开的、为期十年的国际努力被选中进行标准化的。
4. NIST / FIPS / NSA 要求在机密系统中使用非混合的 ML-KEM / ML-DSA。
如果这些算法中存在 NOBUS 后门，那么他们急于将所有东西迁移到这些算法上就他妈是愚蠢的。
任何不同意这些事实的人只是在拒绝现实。对于这种讨论路线，我只能说：PoC || GTFO。
正在讨论的 IETF 问题是关于发布一份建立纯 ML-KEM 码点的 RFC。
非混合 RFC 草案标记为 Recommend=N，而混合 KEM RFC 将标记为 Recommend=Y。这是因为混合 KEM 优先于非混合 KEM。如果 IETF 发布了指定 ML-KEM 的 RFC，对于配置为始终使用混合 KEM 的系统，安全性不会有任何降低。
Google Chrome 已经支持非混合 ML-KEM。如果 IETF 的努力未能产生 RFC，这也不会改变。对大多数互联网用户来说，阻止此 RFC 对现实世界的安全没有任何好处。
所以你可能会问："如果 RFC 似乎什么都不做，那它还有什么意义？"
嗯，它确实有作用，只是对大多数人来说没有：如果你是一个组织，你的工程师被律师告知 (a) 你们必须遵守 CNSA 2.0 和/或 FIPS 140-3（或可能其他奇怪的规定），并且 (b) 你们指定的任何设计必须有一个稳定的 IETF RFC 编号，而不仅仅是一个互联网草案，那么这个 RFC 就把你们从一大堆官僚主义的繁文缛节中解放了出来。
这是个愚蠢的问题吗？绝对是。
这对某些商业领域（特别是向政府客户销售的领域）是常见问题吗？当然是。
出于意识形态原因反对这个 RFC，只会让那些人淋在雨中没有伞。这与减少伤害完全相反。
但是技术上的反对意见呢？混合 PQ+T 不是比纯 PQ 更好吗？
嗯，这就是你威胁建模技能派上用场的地方。如果我们用 Q-Day 作为"一旦对手建造出密码学相关的量子计算机"的简写，我们可以清晰地思考这些风险。
提醒：对于 KEM，我们面临的风险是"先收割，后解密"（Harvest Now, Decrypt Later），而不是"等 Q-Day 到了再破解密码学"。
纯 ECDH（无 PQ）：在 Q-Day 被追溯性破解，无论是否出现其他攻击。
纯 PQ：在 Q-Day 不会被破解，假设 PQ 算法首先没有被破解。
混合 PQ+ECDH：是对 Q-Day 之前算法被破解的套期保值，但一旦 Q-Day 发生，与纯 PQ 相比完全毫无用处。
DJB 一直在煽动那些没有参与任何背景讨论的人反对纯 PQ、支持混合 PQ+ECDH，他的号召充满了 NSA 恐惧宣传和其他恐吓手段。
但问题在于：如果你真的担心 ML-KEM 的安全性，如果到了 Q-Day，ECDH 的贡献实际上是零安全性，那么 ECDH + ML-KEM 有什么用？
今天主张 ECDH + ML-KEM 实际上是承认 ML-KEM 是一个长期安全的算法选择，除了罕见的实现缺陷（大多数可以通过健壮的测试向量捕获）。
偏好混合方案有两个原因：
1. 混合方案让我们更快地过渡到 PQ——从非专家的角度来看，混合方案比完全陌生的算法更容易吞咽（尽管正如我在之前的博客中所说，它们并不真的是新的）。
2. 你试图对冲 ML-KEM 或整个格密码学类别的算法被破解的风险，与 Q-Day 无关。
如果你真的仔细思考这个问题，应该很清楚，只有 PQ+PQ 混合方案才能在你对冲赌注时仍然对密码学相关的量子计算机具有韧性。可选：把 ECDH 加进去以确保维持现状的安全性。
据我所知，反对 RFC 的人中没有人主张 ML-KEM + HQC + ECDH 三路混合，而这才是从智力上最诚实的论点，特别是如果你关心算法多样性的话：
ML-KEM 是一种基于格的 KEM，世界一流的密码学专家相信它对量子攻击具有免疫力。
HQC 是一种基于编码的 KEM，世界一流的密码学专家相信它对量子攻击具有免疫力。
ECDH 是我们今天已经在使用的方法，但容易受到量子攻击。
但是，实际上，对这个 RFC 的反对意见通常是愚蠢的、普遍考虑不周……这使得这些线程成为一个很好的锻炼你的胡说八道探测器的机会。
你不必信任 NSA，或任何其他国家的间谍机构。（我他妈肯定不信任。）
结语
互联网上有很多指南会教你威胁模型的正式处理方法和有用的方法论。但这有什么意思呢？
希望你能从这篇博客文章中带着一个对威胁模型文档质量和有效性的模糊烟雾测试离开，甚至可能受到启发，更认真地对待这个话题。
原文出处：Soatok's Informal Guide to Threat Models - Dhole Moments
