这篇演讲挺好的，看完之后一直想写点什么，但系统化的说点什么，又比较难，于是就有了这篇碎碎念文章。
强烈建议你阅读原文。

原文

  • A Better Science and Engineering of Security
  • https://www.youtube.com/watch?v=Du8BbJg2Pj4

演讲中的重点

  • 现代安全的进步依赖于两条并行的路径：
    1. 更好的安全科学，它定义了更加严格的模型，用于构建和评估安全性；
    2. 更好的安全工程，它能够在极其严峻的现实世界约束条件下，构建出安全的系统。

  • 安全科学和安全工程这两门学科都正在走向成熟。推动这一进步的关键因素，是进攻性研究以前所未有的方式被深度整合进防御工程的闭环之中。

  • MIE 的两个目标：
    1. 让绝大多数内存安全漏洞无法被利用。
    2. 对那些仍然可利用的漏洞，使其每一次都需要完全定制、不可复用的攻击链。

碎碎念

  • 苹果用五年时间实现了 MIE，使 iPhone 的安全性处于业界领先地位。
  • 单看安全科学，其它公司也有。单看安全工程，其它公司也有。“未知攻，焉知防”，其它公司也有。为什么其它公司，在现实层面，没有把三者有机结合，应用起来？
  • 演讲中多次提到进攻性研究、攻击团队。
  • 实现 MIE，需要调动整个公司的资源，他们的基础组织与资源调度是什么样子？在协调、调动这些资源方面，安全团队具体是什么角色？这可能比技术更难。
  • 实现 MIE，总成本是多少？

  • 感觉，MIE 之后，iPhone 的安全架构应该已经搭建好了，之后主要是在具体的问题上，基于安全锚点(PAC、MIE 等)，做实现层面的修补与完善。

  • MIE 之前，针对 iOS 的漏洞挖掘与利用，还不完全是艺术，即：当有针对某种错误的通用利用技术（尤其是在用户空间），即使漏洞被修补了，只要用同类型的漏洞替换即可恢复利用链。
  • MIE 之后，针对 iOS 的漏洞挖掘与利用，几乎完全是艺术了。什么意思？简言之，可能每一步都需要创造性：漏洞挖掘、漏洞利用、后利用。
  • 艺术，不同于工程，可控性、可管理性极低。
  • MIE 之后的漏洞挖掘应该如何做？可以继续像之前一样，挖掘漏洞，不过只能用于老设备。
  • 如何挖掘漏洞，突破 MIE？方法在细节中，整天站着，在宏观层面，瞎 BB 肯定是不行的。需要结合具体的领域功能，改变之前主要基于行为（如：OOB 是行为）的漏洞挖掘思路。具体的、可能的漏洞挖掘方向，其实演讲中就有提到。
  • 多动脑，适当动手。

演讲主要内容的 AI 翻译

嗨，早上好。我看不到任何人，灯光太亮了。好吧，现在看到你们了。各位，感谢邀请我来到这里，
能在这里我感到非常荣幸。我是 Ivan Krstić，负责苹果公司的安全工程与架构团队（SEAR）。
今天我想和大家谈一谈更好的安全科学与工程。

我想尝试说服大家：在安全领域的前沿，安全性本身已经相当强大，而且进步的速度正在不断加快。
这是因为，安全不仅作为一门工程学科在持续改进，同时也越来越多地受益于更科学化的方法。

在这次演讲中，我想做一个区分：安全工程关注的是“能够构建什么、以及如何构建”；
而安全科学则致力于确定“应该构建哪些防御措施”，并帮助验证这些防御是否被正确地构建了。

这意味着，现代安全的进步依赖于这两条并行的路径：
一方面是更好的安全科学，它定义了更加严格的模型，用于构建和评估安全性；
另一方面是更好的安全工程，它能够在极其严峻的现实世界约束条件下，构建出安全的系统。

从我的角度来看，我很高兴地看到，安全科学和安全工程这两门学科都正在走向成熟。
而我今天想重点讨论的一个推动这一进步的关键因素，
是进攻性研究以前所未有的方式被深度整合进防御工程的闭环之中。

与此同时，工具方面的进步也在不断出现，这些工具真正起到了催化作用，加速了整体的安全进展。
因此，今天我想和大家分享三个安全进展的故事。它们彼此差异很大。
我们先从 corecrypto 说起。

corecrypto 是我们在所有 Apple 产品中使用的核心密码学库，
从小小的 AirPods 到最大的 Mac 都在使用。它运行在设备的所有环境中，
从用户态、内核态，一直到安全隔离区（Secure Enclave）。

这意味着我们必须确保这个库绝对正确，并且在各种威胁模型下都能安全运行——从恶意应用执行，
到攻击者物理持有设备。
同时，它还必须非常快，以提供良好的用户体验并尽量减少电池消耗；
而且我们还需要能够快速迭代，以支持新设备和新功能。

最近，我们在 corecrypto 中加入了对 ML-KEM 和 ML-DSA 的支持。
这些是新一代算法，属于向“抗未来量子攻击”的密码算法过渡的一部分，
目前已经在一些关键场景中使用，比如 iMessage，以及 Web 上的 PQ-TLS。

有意思的是，这些新算法基于一种完全不同的数学结构——格（Lattice），
它与我们过去使用的经典密码学（如椭圆曲线）在本质上完全不同。
正因为如此，这类算法在实现层面更容易出现静默失败，
而密码学社区在这类实现可能出什么问题方面的经验也相对较少。

为了尽可能达到最高级别的可信度，我们转而采用了形式化方法和计算机辅助证明工具。
这类方法其实几十年前就已经出现了，但在密码学领域真正产生转折是在 2010 年代中期。
当时，用于保护整个 Web 的 TLS 协议经历了一连串尴尬而严重的漏洞——如果你还记得
BEAST、CRIME、POODLE。于是，TLS 1.3 被启动，
目标就是“这一次把事情彻底做好”。作为其中的一部分，整个社区开始大规模采用形式化方法。

在 corecrypto 中验证这些算法时，
我们面临一个挑战：密码学标准本身无法被这些工具直接解析。
第一步必须把标准翻译成更高层次的数学规格说明；然后再验证实际实现的代码是否与该规格等价。
但考虑到 corecrypto 的所有现实约束，目前并不存在一个工具能够单独完成这一切。

我们确实使用了一些常见工具，比如 SAW 和 Cryptol，
它们可以把代码映射到一种低层次的数学规格（类似伪代码），
而且这项工作甚至可以由熟练的密码工程师完成，不一定非要是形式化方法专家。但这还不够。

因此，我们还引入了另一个工具 —— Isabelle，用来证明高层规格之间的数学等价性。
我们首先把算法手动翻译成 Isabelle 规格……
但问题在于，这并不是设备上真正运行的代码。设备上运行的是高度优化的汇编实现，
而这些工具根本无法直接解析汇编代码。

最终，我们不得不自己开发了一套全新的工具，用于证明汇编函数与其已验证的 C 实现之间的等价性。
这样一来，我们就可以从标准 → C 代码 → 手工调优的汇编，实现端到端验证。
验证内容还包括内存安全以及不存在未定义行为。

我用这个例子开头，是因为它非常清楚地说明：没有科学支撑的工程，很难做到真正强的安全；
同时它也展示了工具作为“催化剂”的巨大力量。工具扩大了设计空间，从而带来了更强工程实现的可能性。
在我们的例子中，“强”意味着：在交付极致性能、极度优化的汇编实现的同时，
还能提供严格证明过的安全保证。

好，到此为止，密码学就讲到这里。

接下来，我想谈谈我们另一个非常重要的底层软件安全项目，以及我们从 PPL（PageProtection Layer）
走向 SPTM（Secure Page Table Monitor） 的历程。

大家都知道，页表控制着执行。在 PPL 出现之前，只要攻击者拥有内核读写能力，就可以直接篡改页表，
在用户空间执行任意未签名代码。
PPL 的目标是：即便 XNU 内核被攻破，也不能直接破坏代码签名机制。

但问题在于，虽然 XNU 运行在单一特权域中，它实际上由一组近乎离散的子系统组成。
PPL 的整体思路是：利用硬件架构支持来保护 PMAP 层的内容。很快我们就发现，
虽然 PPL 的理念是正确的，但实现上存在严重的现实问题。

这导致 PPL 本身成了一个复杂的可信计算基（TCB）：
边界难以理解，而且使用的是原本假设“与内核同一安全域、可被隐式信任”的代码。
我们在复盘这些问题时发现，它们其实集中在少数几类 Bug 上：
比如虚拟地址处理错误、无处不在但经常出错的指针运算，以及对非法状态转换的宽松检查。

于是我们没有选择打补丁式修复，而是由攻防团队联合发起了一次大规模分析：
审视每一个已知的 PPL 问题，并思考是否可以通过全新的架构从根本上消除这些 Bug 类别。

结果是：确实可以做到。这就是我们构建 PPL 替代方案 —— SPTM 的方式。

SPTM 采用了干净的最小特权架构，从设计伊始就有攻防团队的深度参与。
现在的模型是：SPTM 与 TXM（负责代码签名）在逻辑和架构上都与 XNU 分离。

我想重点强调支撑这一安全设计的两个机制。

第一，在 SPTM 中，我们使用一种叫 frame table 的结构，
把合法的状态机转换以“数据策略”的形式表达，而不是散落在代码中的逻辑判断。
这使得策略可以被集中、系统性地验证，也避免了易出错的分布式逻辑。
这一设计还让我们能够扩展出非常强大的缓解机制，例如 XKR，用于防止私有内核内存被错误映射或多重映射。

第二，我们决定让编译器和 C 类型系统参与安全约束的强制执行。
我们把不安全字段包裹起来，只允许通过一个集中验证函数访问；
任何试图直接访问这些字段的代码，都会在编译期直接报错。这让安全不再只是“约定”，
而是被工具强制执行的事实。

鉴于 frame table 在 SPTM 中的重要性，我们还对状态机管理的部分进行了形式化验证。
令人振奋的是，即便在这样一个非常谨慎、采用了最佳实践的新代码库中，
形式化验证仍然发现了一些极其隐蔽的 Bug——这些问题几乎不可能被人工审计发现。

此外，我们还建立了严格的开发流程：
每一个 SPTM Bug 都必须进行完整的根因分析；
每一个 Pull Request 都要接受专门的安全审查；
整个开发过程中持续进行攻防轮换式参与。

结果如何？
我们的攻防团队重新审查了所有已知的 PPL 问题，并问了一个更深层的问题：
这些问题在 SPTM 中是否“理论上可能发生”？
答案是：95% 的问题在架构层面就被 SPTM 完全消除了，根本不可能出现。
剩下的只是极少数罕见的逻辑错误。

到目前为止：
SPTM 从未在真实环境中被成功利用；
在漏洞赏金计划中也没有被攻破；
我们甚至请了一家法国的顶级实验室做了为期 6 个月的独立审计，只发现了一个我们内部早已修复的问题。

这说明什么？
在页表管理这个领域，我们之所以能取得如此强的结果，是因为我们拥有：
严格的安全模型与流程、攻防深度融合、以及先进的形式化工具。

接下来，我想谈谈 MIE。

我们为 MIE 设定了两个极其雄心勃勃的目标：
第一，让绝大多数内存安全漏洞无法被利用；
第二，对那些仍然可利用的漏洞，使其每一次都需要完全定制、不可复用的攻击链。

在分配器安全上“凭直觉思考”几乎总是错的。所以我们首先建立了一个精确的内存破坏模型：
给定一个“攻击者对象类型”和一个“目标对象类型”，攻击者可以任意调用系统接口；
如果他能把攻击者对象放到距离目标对象 Δ 以内，就算成功。
这个模型非常深刻，甚至能统一描述 use-after-free（Δ=0）。

更重要的是，它告诉我们：防御其实只有两个“杠杆”——限制类型，以及限制 Δ。我们两者都做了。

我们引入了强类型感知的隔离机制，并通过多种手段让内存布局更不可预测；
再加上 allocation fronts，使虚拟内存分配与类型相关。

在此基础上，我们还改进了 MTE（内存标记扩展）：
我们认为原始 MTE 规范给了攻击者过多灵活性，于是增强了约束；
我们在内核中用软件模拟 ARM 的检查指针算术，确保不同 tag 的内存互不影响；
并通过硬件设计和验证，消除了与 tag 相关的时序侧信道。

最终，剩下的主要威胁是 Spectre v1。
我们通过定制缓解机制限制线性映射和分配范围，使跨域推测几乎不可能。

在 MIE 的整个设计过程中，进攻团队从第一天就深度参与，对真实世界攻击链进行重构和提前研究。
结果是：很多攻击链在第三步就被彻底破坏，而后续步骤完全失去复用性；
即便是稳定、纯逻辑漏洞，也会被 MIE 确定性地击溃。

最终结论是：
在启用 MIE 后，可行的内存破坏策略变得极其罕见；通用、可复用的攻击技术几乎不复存在；
剩余漏洞需要极其脆弱、完全定制的利用方式。

我要强调的是：
更好的安全科学与工程正在形成。
在安全前沿领域，我们有充分的理由保持乐观。

感谢大家。👏

随后他介绍了 Apple 安全漏洞赏金计划的巨大提升、最高可达 200 万甚至 500 万美元的奖励，
以及对研究者和公民社会的支持。

最后，我想分享一段个人感悟。

进攻性安全研究可以成为保护人的强大工具，也可能把人置于危险之中。
漏洞利用不仅仅是窃取数据，它们可能摧毁人的生命，让记者、活动人士和外交官陷入真实而致命的风险。

所以我想对在座的每一位说：
请要求你们的安全研究，让这个世界变得更好。
如果你不确定它是否如此，我恳请你停下来，去做别的事。

你们拥有极其罕见、卓越的技能。
我希望你们能用它们，造福人类。

感谢邀请我，Hexacon。
这是我的荣幸。