Soatok的非正式威胁模型指南

# Soatok 的非正式威胁模型指南 - Dhole Moments 来源：https://soatok.blog/2026/06/30/soatoks-informal-guide-to-threat-models/ 在经历了漫长的一天，讨论着混合后量子密码学（https://soatok.blog/2026/04/13/hybrid-constructions-the-post-quantum-safety-blanket/）、某些闲得无聊的家伙试图用端点攻击来玩“抓包”端到端加密消息应用、以及在愚蠢政客向我们所有人推行更多“年龄验证”废话后的留言板讨论之后，我清楚地认识到，“威胁模型”这个短语对大多数人来说是一个外来概念。 当然，除了作为一个流行词。 漫画。第一帧：一个穿DEFCON T恤的人说“威胁模型”。第二帧：Soatok（蓝色的dhole）眼睛发红，像一个被激活的潜伏特工。第三帧：蓝色的dhole悬在空中，阴森地出现在那个说“威胁模型”的人身后，手里拿着一根标有“STFU”的球棒。 插图来自Embyr（https://sfw.furaffinity.net/user/embyr7）。 需要背景说明：这幅画是在反疫苗失败者声称要“做自己的研究”，并短暂地把“威胁模型”这个词作为流行语的那个时期委托创作的。 即使没有这个背景，我仍然觉得有点好笑。 > 直说吧：如果你来这里是想找一份有超过100篇引用的学术资源，教你如何为你的新创业公司（涉及多个区块链）撰写正式的威胁模型文档，那么这可能不是适合你的同性恋毛茸茸博客。或许可以从STRIDE（https://en.wikipedia.org/wiki/STRIDE_model）和系统理论（https://www.ul.com/sis/blog/introduction-to-stamp-stpa-and-cast）开始。但如果你是从零开始，想要建立对“一个好的威胁模型应该回答哪些问题”的直觉，那么你很可能来对地方了。 那么，让我们来谈谈威胁建模。 ## 初学者的威胁建模 紫色的普罗托根（Neophyte）在微笑。它的名字就是Neophyte（新手），如果你没看懂这个笑话的话。 插图：Harubaki（https://harubaki.carrd.co/） 在高层面上，不要想得太多。 虽然威胁模型是一个正式的网络安全过程，一些信息安全从业者确实专门从事这个领域，但在开发新产品或服务的设计和架构阶段，你也可以进行非正式的威胁模型，没人能阻止你。你甚至可能会得到更好的结果。 一个威胁模型至少应该回答这些基本问题： 1. **我们到底在保护什么？** - 如果你回答不了这个问题，那你还有很多基础工作要做。 2. **谁/什么想要伤害我们保护的东西？** - 黑客、活动人士、网络跟踪者、社交媒体骚扰网络 - 自然灾害 / 恶业 - 工资低、工作强度大、终于忍无可忍的员工 - 被大企业游说者收买、通过愚蠢法律伤害所有人的白痴立法机构 - 国家层面的敌人！！！ 3. **（2）可能如何攻击（1）？** - 攻击场景写在这里 - 墨菲定律也写在这里 4. **我们将采取什么措施来防止（3）发生？** - 墨菲定律同样要写在这里！ 好了，如果你能勾选出这些，你的文档在某种程度上可以被称为威胁模型。 然而，这在实践中往往没什么用，因为缺失了一些关键细节。 5. **资产（1）之间是如何关联/连接的？** - 用图来思考，而不是列表（https://github.com/JohnLaTwC/Shared/blob/master/Defenders%20think%20in%20lists.%20Attackers%20think%20in%20graphs.%20As%20long%20as%20this%20is%20true%2C%20attackers%20win.md）。 - 并非所有目标都具有同等价值。 6. **我们做出了哪些假设，尤其是关于（4）和（5）的？** - 下面我会详细说明。 7. **我们故意*不*处理哪些威胁？** - 你根本不可能处理未来所有可能想象到的攻击，所以别装模作样。 太多人理所当然地轻视了假设（6），但明确你的假设是**极其重要的**。 如果你的一个假设是错误的，那么你的模型最多是不完整的，或者你需要重新考虑你的已接受风险清单（7）。 例如：隐形蝾螈攻击（https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/）在某些端到端加密消息设计中打破了滥用报告功能，但前提是你引入了滥用报告。 这个攻击之所以可能，是因为AEAD方案（AES-GCM、ChaCha20-Poly1305）中的一个假设是：对于给定的消息，只有一个有效的密钥。一旦你为给定的消息引入多个有效密钥（或者混淆的代理（https://scottarc.blog/2022/10/17/lucid-multi-key-deputies-require-commitment/）），你就超出了算法的安全保障范围——对攻击者来说，这就成了一个有趣的把戏（https://github.com/soatok/gcm-exploit）。 明确你的假设能让你识别自己的“未知的未知”。你不必做到完美。 事实上：威胁模型应该是活文档，而不是时间点的快照。在适当的时候更新它们。 ### 例子：我自己的工作 你可能已经知道，我正在致力于向Fediverse提供密钥透明度（https://soatok.blog/2025/12/15/announcing-key-transparency-fediverse/）。这项工作在publickey.directory（https：//publickey.directory/）上跟踪，如果你在这篇博客发布后对其状态感兴趣的话。 这项工作始于一份规范（https://github.com/fedi-e2ee/public-key-directory-specification），其中包含一个突出的威胁模型（https：//github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#threat-model）。 该威胁模型组织成以下部分： 1. 假设（一开始就陈述） 2. 资产 3. 行动者（包括攻击者和我们想要保护的人），赋予角色名称 4. 风险，每种风险带有四种状态之一： - **通过设计预防**：攻击根本不可能成功 😀 - **缓解**：攻击不应成功，除非某个假设是错误的。对研究人员来说，这部分最值得关注。 - **可处理**：有一种方法可以缓解风险，但需要付出努力或谨慎。操作者应该意识到这一点。 - **开放**：这是我们无法或不会缓解的风险。这些是会成功的攻击。 这个威胁模型当然不完美。我没有以人类可读的图形完美地将资产和行动者关联起来。风险部分可能有一些我从未考虑过的盲点。我可能忘记写下某个对系统安全至关重要的假设。 如果你能看到我项目的威胁模型及其缺点，你很可能已经足够理解这项任务，可以自己写一个了。 但用这种轻微的自我推销说够了吧。只看我的“利益相关”例子，你学不到太多。我们还需要一个糟糕威胁模型文档的例子，而且恰好我手里就有一个。 ### 糟糕的例子：Matrix 的威胁模型 我以前（两次（https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/））挑过 Matrix（https：//soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/）的毛病，所以如果你读过那些博客，这不会是什么新闻。 ***这是***（https：//spec.matrix.org/v1.18/appendices/#security-threat-model）Matrix 的威胁模型（最新版 v1.18）： > ## 9. 安全威胁模型 > https://spec.matrix.org/v1.18/appendices/#security-threat-model > ### 9.1 拒绝服务 > https://spec.matrix.org/v1.18/appendices/#denial-of-service > 攻击者可能试图阻止消息传递到受害者或从受害者发出，目的是： > - 干扰商业竞争对手的服务或营销活动。 > - 审查讨论或审查讨论参与者。 > - 进行一般性破坏。 > #### 9.1.1 威胁：资源耗尽 > https://spec.matrix.org/v1.18/appendices/#threat-resource-exhaustion > 攻击者可能导致受害者的服务器耗尽特定资源（例如开放TCP连接、CPU、内存、磁盘存储）。 > #### 9.1.2 威胁：不可恢复的一致性违规 > https://spec.matrix.org/v1.18/appendices/#threat-unrecoverable-consistency-violations > 攻击者可能发送消息，在集群中造成不可恢复的“脑裂”状态，导致受害者的服务器无法再得出聊天室状态的一致视图。 > #### 9.1.3 威胁：不良历史 > https://spec.matrix.org/v1.18/appendices/#threat-bad-history > 攻击者可能说服受害者接受无效消息，然后受害者会将这些消息纳入其聊天室历史的视图中。聊天室中的其他服务器将拒绝这些无效消息，并可能因为受害者依赖无效消息而拒绝其消息。 > #### 9.1.4 威胁：阻止网络流量 > https://spec.matrix.org/v1.18/appendices/#threat-block-network-traffic > 攻击者可能试图对受害者服务器与聊天室中部分或全部其他服务器之间的流量进行防火墙拦截。 > #### 9.1.5 威胁：高消息量 > https://spec.matrix.org/v1.18/appendices/#threat-high-volume-of-messages > 攻击者可能向聊天室发送大量消息，使聊天室无法使用。 > #### 9.1.6 威胁：未经必要授权禁止用户 > https://spec.matrix.org/v1.18/appendices/#threat-banning-users-without-necessary-authorisation > 攻击者可能试图在没有必要授权的情况下禁止聊天室中的用户。 > ### 9.2 欺骗 > https://spec.matrix.org/v1.18/appendices/#spoofing > 攻击者可能试图发送声称来自受害者的消息，而受害者并未发送该消息，目的是： > - 在进行非法活动时冒充受害者。 > - 获取受害者的特权。 > #### 9.2.1 威胁：更改消息内容 > https://spec.matrix.org/v1.18/appendices/#threat-altering-message-contents > 攻击者可能试图更改受害者现有消息的内容。 > #### 9.2.2 威胁：伪造消息“origin”字段 > https://spec.matrix.org/v1.18/appendices/#threat-fake-message-origin-field > 攻击者可能试图发送一条声称来自受害者且带有虚假“origin”字段的新消息。 > ### 9.3 垃圾信息 > https://spec.matrix.org/v1.18/appendices/#spamming > 攻击者可能试图向受害者发送大量主动请求或未经请求的消息，目的是： > - 寻找诈骗受害者。 > - 推销不需要的产品。 > #### 9.3.1 威胁：未经请求的消息 > https://spec.matrix.org/v1.18/appendices/#threat-unsolicited-messages > 攻击者可能试图向不想接收消息的受害者发送消息。 > #### 9.3.2 威胁：辱骂性消息 > https://spec.matrix.org/v1.18/appendices/#threat-abusive-messages > 攻击者可能向受害者发送辱骂或威胁性消息。 > ### 9.4 监视 > https://spec.matrix.org/v1.18/appendices/#spying > 攻击者可能试图访问受害者发送或接收的消息内容或元数据，而这些内容本不应让攻击者看到，目的是： > - 获取敏感的个人或商业信息。 > - 利用消息中包含的凭据（例如密码重置消息）冒充受害者。 > - 发现受害者在与谁交谈以及何时交谈。 > #### 9.4.1 威胁：传输过程中泄露 > https://spec.matrix.org/v1.18/appendices/#threat-disclosure-during-transmission > 攻击者可能试图在服务器间传输过程中暴露消息内容或元数据。 > #### 9.4.2 威胁：向聊天室外的服务器泄露 > https://spec.matrix.org/v1.18/appendices/#threat-disclosure-to-servers-outside-chatroom > 攻击者可能试图说服聊天室内的服务器将消息发送到其控制的、未被授权进入聊天室的服务器。 > #### 9.4.3 威胁：向聊天室内的服务器泄露 > https://spec.matrix.org/v1.18/appendices/#threat-disclosure-to-servers-within-chatroom > 攻击者可能控制聊天室内的一个服务器，以暴露该房间中消息的内容或元数据。 （是的，我直接在上面滚动的框中摘录了整个章节。） 你滚动浏览时可能会注意到几件事： 1. 这只是一个不同攻击类型的列表。 2. 没有假设列表。 3. 没有资产列表，也没有资产之间的关系。 4. 攻击列表非常不完整。 - 尽管人们宣扬 Matrix 优于其他 E2EE 消息应用（https：//web.archive.org/web/20240731062107/https：//pawb.social/post/9842375），但他们的威胁模型对密码学或密钥管理**只字未提**。 5. 给那些直接从 Matrix 网站阅读的人的一个额外观察：**它自 v1.1（https：//spec.matrix.org/v1.1/appendices/#security-threat-model）**（2021年发布）以来**基本保持不变（https：//github.com/matrix-org/matrix-spec/blame/68ffc62de3da55353cc9fd52cb0e775ee453c15c/content/appendices.md#L1114）**，尽管我披露了漏洞，并且 Lotte（https：//lotte.chir.rs/）还发表了两个（https：//lotte.chir.rs/2024/08/18/Missing-Salamanders-Matrix-Media-can-be-decrypted-to-multiple-valid-plaintexts-using-different-keys/）额外的（https：//lotte.chir.rs/2024/08/18/Malicious-homeserver-can-trick-Element-Schildichat-into-revealing-links-in-E2EE-Rooms/）密码学攻击。 尽管这很烦人，而且完全否定 Matrix 的诱惑很大，但至少他们*有*一个威胁模型。 相比之下，Signal 给你一堆技术规范，然后指望你自己去搞清楚威胁模型。这是 Signal 让我不爽的众多原因之一。 所以，对于 Matrix 的威胁模型作者，我授予以下奖项： 画得很差的星星，上面写着“一次尝试”。 Matrix 的威胁模型？ 我给个 C-。 一个糟糕的威胁模型总比*没有威胁模型*要好。 ## 威胁模型如何帮助你构建更好的东西 在你的职业生涯早期，你会听到很多信息安全界的真理。比如，“防御者必须一直做对，攻击者只需要对一次。” 是的，但装备精良的防御者可以选择地形。把这个放在你的《孙子兵法》里慢慢消化吧。 从 seclists 到这里的每个安全从业者都在宣扬纵深防御，但要做到真正的纵深防御，意味着你要足够了解你的威胁模型，迫使攻击者进入可预见的死胡同。 让我先给你一个实际的例子，然后再讲一个更有趣的。 ### 防止凭证填充 凭证填充是一种愚蠢简单的攻击，但在大多数现实场景中却异常有效。 为什么？*因为人们会重复使用密码*。 为什么人们会重复使用密码？因为他们只能记住那么多密码，而要求他们为你的应用创建一个唯一且安全的密码是可笑的。 为了缓解这种风险，在很长一段时间里，密码管理器是解决这个问题的正确答案。如今，它们仍然可以（但不是 Lastpass），但通行密钥更好。 为什么？因为通行密钥是一种更用户友好（注意：不是*完全*用户友好）的方式，让用户使用非对称密码学进行认证。在最好的情况下，他们使用的是硬件安全令牌（例如 SoloKeys 或 YubiKeys）。在一般的情况下，他们的操作系统或密码管理器会为他们提供这个功能。 像这样沿着一条“为什么”的问题链追问，是感受某个（存在深刻缺陷的）安全控制中所固有威胁的一种方法。但这也有陷入兔子洞的风险，所以要小心。 如果你想避免凭证填充和相关的琐碎攻击： 1. 设计你的应用程序要求使用通行密钥。 2. 要求用户注册多个通行密钥（或者至少一个用于备份）。 3. 给管理员一种“打破玻璃”的方式，在用户丢失所有通行密钥时为其添加新的通行密钥。