【免费下载链接】publicationsPublications from Trail of Bits项目地址https://gitcode.com/GitHub_Trending/pu/publications点击查看免费下载本篇技术指南以 Trail of Bits 于 DeCompute 2025 大会发表的演讲《One, Two, TEE: Trust in Numbers Meets Hardware Security》为核心骨架系统解析多 party 计算MPC与可信执行环境TEE两种隐私计算范式的信任模型差异、真实世界部署中的脆弱性与运营挑战以及将两者安全叠加时的最佳实践与常见陷阱。读者读完后将掌握如何为隐私计算系统设计明确的信任边界、为何MPC 密码学保证不足以替代硬件信任、以及如何通过正确的远程证明attestation验证与最小化 TEE 攻击面避免组合反而更不安全的工程误区。演讲背景与仓库定位该演讲收录于本仓库的 presentations/One, Two, TEE: Trust in Numbers Meets Hardware Security 目录由 Trail of Bits 密码学专家 Paul Bottinelli 于 2025 年 9 月 30 日在 DeCompute 2025 会议上发表幻灯片文件为 OneTwoTEE_Decompute2025_Paul_Bottinelli.pdf。仓库根目录 README.md 的 Cryptography 分类中将其列为 2025 年 Cryptography 主题演讲标题即点明核心命题——Trust in Numbers Meets Hardware Security数字中的信任遇上硬件安全。值得强调的是这个话题并非孤立的理论探讨本仓库同时收录了大量与之直接相关的工程证据包括 TEE 基础设施安全审计如 Turnkey 的 AWS Nitro Enclaves 密钥管理案例、TEE 方向的两场主题网络研讨会Top TEE bugs you should fix before your audit、After Wiretap and Battering RAM: What Changes for TEE-Based Blockchain Infrastructure见 README.md以及侧信道方向的历年演讲与论文。这些材料共同构成了理解该演讲的完整背景。MPC 与 TEE两种隐私计算范式的信任模型对比MPC把信任分散到多方多方计算MPC的核心思想是让多个参与方在不泄露各自私密输入的前提下联合计算某个函数的结果。它的安全保证来自密码学协议本身而不是任何单一实体的可信度信任分布信任被分散到所有参与方之间。通过 Shamir 秘密共享、不经意传输OT、混淆电路garbled circuitYao 协议、SPDZ 家族协议等原语任何一方或少于安全阈值数量的合谋方都无法单独恢复或推断出他人的私密输入。安全模型可调协议可以在诚实但好奇honest-but-curious与恶意敌手malicious adversary模型下设计也可以用诚实多数honest majority或恶意多数等不同阈值假设来刻画攻击能力。去信任化的理想正如演讲原文所述在一个理想世界中MPC 的密码学保证应当足以消除对额外硬件信任假设的需求——密码学协议在数学上保证了即使某台机器被完全攻陷协议语义依然成立。TEE把信任集中到硬件可信执行环境TEE则走了一条相反的路线信任被集中到硬件厂商提供的安全飞地secure enclave之中。典型实现包括 Intel SGX/TDX、ARM TrustZone、AMD SEV-SNP 以及 AWS Nitro Enclaves。TEE 通过硬件强制隔离、内存加密与远程证明机制向外部观察者保证飞地内执行的代码与数据无法被主机操作系统或云服务商读取、篡改。两种范式的根本差异可以用下表概括维度MPCTEE信任锚点多方之间的密码学协议硬件厂商提供的安全飞地信任模型分布式信任阈值假设集中式信任单一硬件信任根安全假设协议正确性 参与方合谋阈值硬件不背叛 固件/微码无后门性能开销通信与计算开销大随参与方数量增长接近原生性能但受限于飞地资源部署形态纯软件可跨机构部署依赖特定硬件/云平台两种模型的互补性正因两者信任模型截然相反业界普遍将 MPC 与 TEE 视为互补而非互斥MPC 提供密码学层面的算法级保障TEE 提供运行环境层面的平台级保障。演讲的核心论点正是探讨如何有效结合二者——用 TEE 解决 MPC 真实部署中的实现漏洞与运营难题同时用 MPC 缓解对单一硬件信任根的过度依赖。理想与现实的鸿沟为什么 MPC 密码学保证不够用演讲明确指出在真实世界的部署中实现漏洞implementation vulnerabilities、侧信道攻击side-channel attacks和运营挑战operational challenges是客观存在的而 TEE 恰恰可以在这些方面提供缓解。这揭示了 MPC 从论文走向生产时面临的三个层次的问题实现漏洞MPC 协议的密码学安全建立在协议实现完全正确的假设上。实际工程中的随机数生成器缺陷、秘密共享的边界处理错误、协议状态机实现偏差都可能在数学证明之外引入新的攻击面。仓库中 Introduction to Smart Contract Exploitation - GreHack 2018 等材料反复印证了一个行业共识密码学正确不等于实现安全。侧信道攻击即使协议正确参与方机器上的其他软件尤其是共享云基础设施上的邻居进程也可能通过缓存时序、分支预测、功耗等微架构侧信道窃取敏感信息。仓库中专门收录了 Hardware side channels in virtualized environmentsHITB 2016 主题演讲与 Exploiting Out-of-Order Executionroots17.pdf 与 thesis.pdf 详细分析了乱序执行侧信道等材料说明侧信道攻击对隔离环境的破坏力是 Trail of Bits 长期关注的核心议题。运营挑战密钥托管、参与方掉线、网络分区、协议轮次同步、审计合规等问题会让理论上安全的多方协议在实际运行中产生新的信任缺口。例如若某参与方私下将私密份额导出到非隔离环境协议本身无法阻止这一行为。TEE 的价值正在于把计算发生的那个瞬间封闭在硬件隔离的飞地中飞地内的内存被加密、外部进程无法读取从而同时缓解实现漏洞被利用后的数据泄露、侧信道窃取以及运营过程中对中间状态的意外暴露。这也是当前大量 MPC 系统尤其是区块链领域选择MPC 做协议、TEE 做承载双层架构的根本原因。组合并非自动安全TEE 层自身的风险演讲给出了一个容易被忽略的警示这种组合并不会自动安全this combination isnt automatically secureTEE 实现的安全性是参差不齐的已知漏洞是真实存在的而错误的 attestation 或验证incorrect attestation or verification会彻底破坏整个系统的安全保证。这句话拆解出 TEE 层三大类风险1. TEE 实现之间的安全差异不同 TEE 平台的安全边界、威胁模型与已知攻击面差异巨大。SGX 曾经历多轮微架构侧信道攻击L1TF、Foreshadow、SGXspectre 等SEV 的虚拟化信任模型依赖固件与 VMM 行为Nitro Enclaves 则把信任建立在 AWS 的 Nitro 硬件与固件栈上。选择 TEE 平台本身就是一次安全权衡而不是用了 TEE 就安全。仓库中的审计记录正是这种差异的实证例如 HyperLink AWS Nitro TEE 安全审计 与 NEAR One TEE Solver Registry and AMM Solver 审计都表明即使基于同一类 TEENitro Enclaves不同项目的具体实现仍需逐案审计。演讲作者本人还参与了 2025 年 12 月的网络研讨会 Top TEE bugs you should fix before your audit专门梳理审计前应修复的 TEE 常见缺陷进一步佐证了 TEE 实现层面的系统性风险。2. 已知漏洞与攻击演进仓库 README.md 收录的 2025 年 11 月网络研讨会标题直接点名了两个真实攻击代号——Wiretap与Battering RAM并讨论这些攻击之后基于 TEE 的区块链基础设施该何去何从。这提醒我们TEE 的攻击面是动态演进的芯片微码、固件与 SDK 的更新节奏直接影响飞地的真实安全状态任何买断式的安全假设都可能被新的公开攻击打破。3. 错误的 attestation 与验证远程证明remote attestation是 TEE 信任链的入口客户端通过验证飞地生成的签名报告确认飞地内运行的确实是对应哈希的代码、运行在真实的 TEE 硬件上。演讲特别强调错误的 attestation 或验证可以彻底破坏安全保证常见的错误模式包括验证了签名但未校验 PCR/测量值只确认了报告来自合法硬件却未核对代码度量measurement是否符合预期等于放行了任意恶意代码。缺少挑战值nonce新鲜性检查重用旧证明报告导致重放攻击。信任链断裂未验证证明报告由厂商根密钥签名或未处理密钥轮换。忽略运行时测量只验证启动时镜像不验证运行时飞地内实际加载的模块集合。安全叠加的最佳实践如何把 MPC 与 TEE 真正组合起来基于演讲主张的基于真实世界经验总结的实践结合仓库中的 TEE 工程案例安全组合可以落地为以下五条可操作的实践原则1. 先明确威胁模型与信任边界在设计阶段就回答三个问题信任什么协议数学、TEE 硬件、云服务商运维、信任谁参与方集合、合谋阈值、信任到哪一层密码学层 vs 平台层。组合架构应做到MPC 负责协议语义TEE 负责执行环境隔离两者各司其职、互不越权替代。2. 把 attestation 验证当作一等公民将远程证明验证集成进密钥协商与数据交换的必经路径而不是旁路的手工步骤。验证链应覆盖证明报告签名 → 证书链 → PCR/测量值匹配 → nonce 新鲜性 → 代码版本与更新状态。任何一环缺失都应视为系统未建立信任而非系统默认可信。3. 最小化飞地内代码与数据面飞地越大攻击面越大。应把进入飞地的代码裁剪到最小仅保留执行 MPC 关键步骤所需的逻辑密钥生命周期管理、随机性来源、协议轮次状态机都应显式设计。仓库中 Turnkey 案例研究 展示了一个有代表性的工程形态基于 TEEAWS Nitro Enclaves构建密钥管理基础设施将私钥材料的生成、存储与签名操作封闭在硬件隔离边界内配套的 Turnkey Key Management System 安全审计 则说明这类系统必须经过独立审计才能建立可信度。4. 独立审计与持续验证TEE 组合系统不能只依赖厂商文档的安全声明。仓库中的审计证据表明每个具体实现Nitro 上的桥接合约、TEE 求解器注册表、密钥管理系统都需要针对其特有边界做审计。这正对应演讲作者强调的真实世界经验审计不是走形式而是发现 TEE 实现差异与实现缺陷的唯一可靠途径。5. 建立 TEE 更新与故障预案将 TEE 固件/微码更新、密钥轮换、飞地重启与证明失效纳入运维预案。当新的 TEE 攻击公开时如仓库研讨会提到的 Wiretap、Battering RAM 事件系统应能快速评估影响、升级平台或切换 TEE 提供商而不是在单一硬件信任根上孤注一掷。常见陷阱会彻底破坏安全性的工程错误演讲强调要highlight common pitfalls that can completely undermine security以下陷阱在实践中尤其致命把 TEE 当作 MPC 的替代品而非补充在需要多方联合计算的场景中用单一 TEE 取代 MPC等于把分布式信任重新集中到单点硬件合谋阈值与协议可验证性随之消失。验证了 attestation 却验证错了内容只验证平台身份不验证代码度量或验证了代码度量却不验证运行时状态均属形式上的安全。忽视侧信道与云共享环境TEE 并不能免疫所有侧信道在共享宿主机上运行的飞地仍需评估微架构攻击面参考仓库 Exploiting Out-of-Order Execution 的深入分析。信任单一 TEE 供应商的隐含安全不阅读厂商威胁模型、不核对已知漏洞清单直接采信硬件加密安全的营销表述。密钥材料与证明流程耦合不当密钥生成发生在飞地外、证明报告与密钥绑定关系被切断导致攻击者可以伪造合法飞地身份。结语从Trust in Numbers到Trust in Hardware再到两者的平衡《One, Two, TEE》的标题本身浓缩了整个论证弧线第一步One信任密码学数字MPC第二步Two遇到硬件安全TEE——而真正的答案不是二选一而是理解两者各自的信任边界后进行有意识的组合。MPC 提供了不依赖任何单一实体的密码学保证TEE 则为真实世界的实现漏洞、侧信道与运营风险提供了平台级兜底但组合本身需要严谨的威胁建模、严格的 attestation 验证、最小化的飞地攻击面与持续的独立审计。本仓库为这条学习路径提供了完整的配套资料演讲幻灯片 OneTwoTEE_Decompute2025_Paul_Bottinelli.pdf、TEE 基础设施审计案例 Turnkey 案例研究、HyperLink AWS Nitro TEE 审计、Turnkey 密钥管理系统审计以及侧信道方向的 Hardware side channels in virtualized environments 与 Exploiting Out-of-Order Execution 系列。建议读者按先读演讲 → 再看审计案例 → 最后回看侧信道背景的顺序深入逐步建立从理论信任模型到工程审计实践的整体认知。赞分享【免费下载链接】publicationsPublications from Trail of Bits项目地址https://gitcode.com/GitHub_Trending/pu/publications点击查看免费下载相关推荐AppFlowy-Cloud隐私计算数据隐私与安全计算AppFlowy Cloud隐私计算数据隐私与安全计算 引言数据隐私的现代挑战 在数字化协作时代数据隐私已成为企业和个人用户最关注的核心问题。传统的云端协后端云原生Chat Nio可信计算硬件安全架构深度解析Chat Nio可信计算硬件安全架构深度解析 引言AI时代的安全挑战 在人工智能技术飞速发展的今天大型语言模型LLM和AI应用已成为企业数字化转型的核后端前端人工智能大模型AI 应用LLM 网关API网关BV隐私计算数据安全与隐私保护BV隐私计算数据安全与隐私保护 引言第三方应用的数据安全挑战 在数字时代隐私保护已成为用户最关注的核心问题之一。作为哔哩哔哩的第三方Android TV应移动开发音视频上一篇n8n文档编写API文档生成与管理下一篇CLUI核心控件全解析从Window到SparkChart的15个实用组件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考