本文使用人工智能协助翻译，内容仅供参考，可能有错误或遗漏。如果你对内容或超链接有疑问，可以查看原文。
参考资料地址：https://github.com/PKUFlyingPig/MIT6.1600

6.1600课程团队：Henry Corrigan-Gibbs, Yael Kalai, Ben Kettle (TA), Nickolai Zeldovich
2022年秋季

[!warning] 免责声明
本套笔记为正在进行中的工作。其中可能存在错误，且缺少引用来源，内容亦不完整。如您发现任何错误，敬请告知工作人员。

1 概述

本课程的目的是向您介绍有关计算机系统安全的最重要的 “重要理念”。在整个课程中，我们将涉及计算机安全、密码学和（在一定程度上）计算机系统等领域的观点。

2 什么是安全？

安全是一个非常广泛的概念，但通常计算机安全的目标是确保某个计算机系统即使在面对试图破坏系统的“敌手”（或“攻击者”）时也能“正确运行”。

[!info] Info
在本课程中，我们将交替使用“敌手”和“攻击者”这两个术语。

为了实现这一目标，我们需要某种系统性的计划。也就是说，我们必须仔细定义系统“正确运行”的含义，并指定我们希望防御的“敌手”类别。

在本课程中，我们通常将计划分为三个部分：目标、威胁模型和实现。

• 目标：安全目标定义了我们希望系统实现的内容。例如，一个非正式的目标可能是“只有Alice可以读取文件F”，或者“如果有人篡改文件F，Alice将能够检测到”。正如您将在课程中学到的，确定您的安全目标究竟是什么通常是非常微妙且具有挑战性的。
• 威胁模型：威胁模型（或“敌手模型”）指定了我们希望防御的敌手类别。换句话说，威胁模型指定了敌手的能力：敌手在试图破坏我们的安全目标时可以做什么？通过定义威胁模型，我们可以使实现安全目标变得可行。例如，在分析基于密码的登录系统的安全性时，我们的威胁模型可能会指定敌手可以猜测密码，但不能窃取服务器。
• 实现：实现是我们如何实现目标。例如，我们可能会设置文件F的权限，使用Linux来强制执行这些权限，并要求双因素认证来访问系统。

[!info] Info
当你在新闻中读到安全漏洞时，值得尝试去理解这个漏洞是由于目标、威胁模型还是实现的问题引起的。

目标和威胁模型共同构成了我们对安全的定义。因此，它们不可能是“错误的”——目标可能最终并不完全符合我们的需求，威胁模型可能没有涵盖我们的系统在现实世界中可能面临的所有攻击，系统设计师在发现这一点时可能会感到惊讶，但目标和威胁模型共同定义了我们希望实现的安全属性。另一方面，实现肯定可能是错误的——如果由于错误、疏忽、供应链漏洞或其他任何原因，实现无法在威胁模型下保证目标，那么实现就存在错误。

2.1 安全是困难的

构建安全的系统是具有挑战性的。至少有两个广泛的原因。

首先，安全系统必须防御最坏情况下的行为。 安全系统必须防御威胁模型范围内的所有可能的攻击。相比之下，当我们只关注功能或正确性时，我们通常满足于一个在用户关心的场景下表现良好的系统。换句话说，安全关注的是最坏情况下的行为，而正确性通常关注的是预期情况下的行为。

[!info] Info
一些开发者确实会担心他们的系统在所有可能的输入和极端情况下的正确性；这种思维方式通常是确保安全性所必需的。

例如，假设我们有一个学生信息系统，其安全目标是：“只有助教可以访问成绩。” 测试随机抽取的助教是否可以访问成绩（正确性）很容易，但测试是否存在某种交互序列允许其他人访问成绩（安全性）则要困难得多。

其次，实现永远无法防御所有可能的威胁。 当我们指定威胁模型时，我们限定了实现必须防御的敌手集合。但现实世界中的敌手可能会以超出我们威胁模型的方式行事，从而破坏我们的安全目标。

例如，除了助教之外，其他人可能通过以下方式访问成绩：

• 发现服务器软件中的漏洞，
• 闯入助教的办公室，
• 入侵助教的笔记本电脑，
• 窃取管理员账户的密码，
• 诱骗助教泄露成绩，
• 破解服务器的加密，
• 在注册处找到工作并让自己成为助教。

这个列表永远不会结束。因为我们的威胁模型无法涵盖所有可能的威胁，安全永远不是完美的。几乎总是会有某些攻击者能够破坏您的系统。

这就是为什么我们需要威胁模型：威胁模型定义了我们需要担心的攻击类型，以及我们决定不在范围内的攻击类型。

2.2 设计安全目标和威胁模型

指定安全目标和威胁模型的核心在于比较防御攻击的成本与攻击发生时的成本。几乎不可能精确计算这些成本，但这个框架在概念上是有用的。能够阻止重大漏洞的廉价防御措施可能值得实施，但防御可能泄露不重要信息的射频（RF）侧信道攻击则可能不值得。

构建威胁模型总是需要迭代——您不会在第一次尝试时就做对。总会有一些您最初没有考虑到的攻击类型最终变得重要。

2.3 设计如何实现

在本课程中，我们将主要关注那些具有巨大回报的技术——开发软件和使用工具的方法，这些方法可以消除整个类别的攻击（或使它们变得更加困难）。

3 例子

我们给出了一些由于安全目标或威胁模型选择不当而导致的安全失败的例子。

3.1 错误的目标

商务舱机票。一家航空公司试图通过允许商务舱机票持有者随时免费更改机票（即出发日期、出发地和目的地）来增加其商务舱机票的价值。一位顾客意识到他们可以在登机后更改机票。然后，该顾客可以以一张机票的价格乘坐无限次商务舱航班。

在这种情况下，航空公司的目标并没有满足他们的实际需求——也许他们需要增加一个额外的目标，即“每次有人乘坐航班时，我们都会收到付款”。

莎拉·佩林的电子邮件。莎拉·佩林有一个雅虎电子邮件账户，雅虎使用安全问题来重置密码——他们的目标可能是“除非知道用户安全问题的所有答案，否则任何人都无法重置用户的密码。”（安全问题通常是诸如“您母亲的娘家姓是什么？”之类的问题。）事实证明，可以在互联网上找到佩林账户恢复安全问题的所有答案。[^1]雅虎的实现可能是完美的，但他们的目标并没有为某些用户提供任何有意义的安全性。

指令集架构（ISA）规范。在为处理器定义ISA时，设计者认为时间并不重要，处理器可以花费可变数量的周期来执行特定指令。这对性能和兼容性有很大的好处，但正如我们将在学期后面讨论的那样，研究人员最近利用这种时间可变性对广泛的处理器进行了复杂的攻击。[^2]处理器的实现符合规范，但规范本身允许这种攻击。

复杂的访问控制策略。弗吉尼亚州费尔法克斯的一所学校使用了一个具有复杂访问控制结构的在线课程管理软件：每个教师负责一些班级，每个班级有许多学生，每个学生有许多文件。教师无法访问学生的文件，还有一个可以访问所有文件的校长。教师可以更改学生的密码，并可以将学生添加到他们的班级中。结果发现，教师可以将校长添加为学生，更改校长的密码，然后通过校长的账户访问所有文件。虽然每个访问控制策略单独听起来都合理，但它们共同导致了糟糕的结果。

Mat Honan的Gmail账户。一位名为Mat Honan的《连线》杂志记者的Gmail账户通过一次巧妙的攻击被攻破。[^3]Honan有一个Gmail账户。Gmail的重置密码功能避免了使用安全问题，而是使用了一个备份电子邮件账户。攻击者触发了重置密码功能，该功能向Honan的Apple电子邮件账户发送了一个重置链接。

攻击者随后试图访问Honan的Apple电子邮件账户。攻击者触发了Apple账户的重置密码功能。Apple的重置密码功能需要Honan的地址和信用卡号码的最后四位数字。攻击者能够公开找到Honan的地址，但无法轻易找到他的信用卡号码。

攻击者通过Honan的Amazon账户找到了信用卡信息。Amazon知道他的信用卡号码，要求提供完整的信用卡号码才能重置账户。然而，Amazon允许在不登录的情况下为某个账户购买东西，只要提供一个新的信用卡号码。它还允许将这个新的信用卡号码保存到用户的Amazon账户中。因此，攻击者使用自己的信用卡在Amazon上进行了购买。然后，攻击者将自己的信用卡号码保存到Honan的Amazon账户中。接下来，攻击者触发了Amazon的重置密码功能，并使用保存到账户中的信用卡号码重置了Honan的Amazon密码并访问了他的Amazon账户。攻击者随后能够在Honan的Amazon账户中看到他真实信用卡的最后四位数字，使用这些数字重置了他的Apple邮件账户，然后使用该账户重置了Honan的Gmail账户。

像这样的复杂系统链可能非常难以推理，但这些交互最终对安全至关重要。

3.2 错误的威胁模型

假设特定策略：CAPTCHA。CAPTCHA被设计为通过自动化解决成本高昂，但人类易于阅读。确实，为CAPTCHA构建一个通用的光学字符识别系统可能成本高昂，但想要绕过CAPTCHA的攻击者并不这样做。相反，他们在劳动力成本低廉的国家建立了计算机中心。攻击者然后支付在这些中心工作的人员来解决CAPTCHA。[^4]结果是，解决一个CAPTCHA的成本只有几分之一美分。解决CAPTCHA的成本仍然不为零，但成本远低于系统设计者可能预期的。

计算能力：DES。曾经有一个名为DES的加密标准，它有$2^{56}$个可能的密钥。在设计时，美国政府标准机构断言它甚至可以抵御强大的攻击者，但今天，现代计算机可以以适中的成本尝试所有$2^{56}$个密钥。（甚至在DES设计时，学术研究人员就明白56位密钥不足以防止穷举密码分析。[^5]）

[!info] Info
例如，https://crack.sh/ 使用一组FPGA（现场可编程门阵列）来提供一种服务，该服务会穷举检查所有可能的密钥。

由于DES在现代计算机面前的弱点，所有使用该标准的人都必须升级他们的分组密码。例如，麻省理工学院不得不从使用DES进行身份验证转向使用具有更长密钥的更新分组密码，如AES。

依赖关系：通过短信的双因素认证（2FA）。许多2FA系统使用短信进行身份验证，但攻击者只需要说服AT&T商店的店员为您的电话号码提供一个新的SIM卡即可。

[!info] Info
这些攻击通常被称为“SIM交换”或“SIM劫持”。

软件版本：Xcode。iPhone应用程序通常在开发者的机器上创建和编译，发送到Apple的App Store，然后从那里发送到iPhone。iPhone应用程序是使用一个名为Xcode的工具创建的，该工具通常从Apple服务器下载。然而，Xcode是一个大型软件，对于中国防火墙后面的开发者来说，下载速度非常慢。中国境内的某人建立了一个更快的Xcode镜像，许多中国开发者使用了这个镜像中的Xcode版本。然而，这个镜像并没有提供Apple的Xcode版本——相反，它提供了一个稍微修改过的Xcode版本，该版本会在每个使用它编译的应用程序中注入一些恶意代码。这花了很长时间才被发现。

[!info] Info
维基百科上关于XcodeGhost的文章，https://en.wikipedia.org/wiki/XcodeGhost 提供了有关此攻击的更多详细信息。

3.3 有问题的实现

错误、配置错误和其他错误是安全问题的常见原因。一个经验法则是，每1000行代码大约会有1个错误。这是一个非常粗略的估计，但基本思想是代码越多，错误就越多。减少安全漏洞的有效策略是减少系统中的代码量。

缺少检查：iCloud。Apple的iCloud执行许多功能——电子邮件、日历、存储和“查找我的iPhone”。每个功能都有自己的登录方式，但在所有功能中，一个共同的目标是限制攻击者猜测用户密码的能力。为此，他们在所有登录界面中添加了速率限制，允许每小时只有10次登录尝试——但他们忘记了“查找我的iPhone”的登录界面。[^6]由于这些认证代码在多个地方重复，有许多地方需要记住添加速率限制，但攻击者只需要一个薄弱的登录界面就可以暴力破解密码。一般来说，避免这种重复将使构建安全系统变得更加容易。

不安全的默认设置。当您设置新服务时，它们几乎总是带有一些默认设置以简化设置。Wi-Fi路由器带有默认密码，AWS S3存储桶带有默认权限，等等。这些默认设置可能很方便，但它们对安全非常重要，因为许多人会忘记或忽略更改默认设置。因此，默认设置成为系统的操作方式。为了构建一个安全的系统，重要的是默认设置是安全的。

4. 安全系统设计的一般原则是什么？

4.1 目标和威胁模型

• 创建简单、通用的目标。
• 通过更好的设计避免假设（例如“没有人能够获得用户的SIM卡”）。
• 学习并迭代。
• 实践深度防御：不要依赖单一的防御措施来保护所有安全——使用备用防御措施来防范不可避免的错误是很有用的。

4.2 实现

• 更简单的系统会带来更少的问题。
• 将安全关键部分分解为一个小的独立系统或代码片段（例如，硬件安全密钥）。
• 重用设计良好的代码，例如经过良好测试的加密库。
• 理解并测试极端情况。

参考文献

• Diffie, Whitfield and Martin E. Hellman. “Exhaustive Cryptanalysis of the NBS Data Encryption Standard”. In: Computer 6.10 (1977), pp. 74–84.
• Hill, Mark D. et al. “On the Spectre and Meltdown Processor Security Vulnerabilities”. In: IEEE Micro 39.2 (2019), pp. 9–19.
• Honan, Mat. How Apple and Amazon Security Flaws Led to My Epic Hacking. https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/. Aug. 2012.
• Motoyama, Marti et al. “Re: CAPTCHAs—Understanding CAPTCHASolving Services in an Economic Context”. In: Proceedings of the 19th USENIX Security Symposium. Washington, DC, Aug. 2010.
• Trew, J. ‘Find My iPhone’ exploit may be to blame for celebrity photo hacks (update). https://www.engadget.com/2014-09-01-find-my-iphone-exploit.html. Sept. 2014.
• Zetter, Kim. Palin e-mail hacker says it was easy. https://www.wired.com/2008/09/palin-e-mail-ha/. Sept. 2008.

[^1]: Kim Zetter. Palin e-mail hacker says it was easy. https://www.wired.com/2008/09/palin-e-mail-ha/. Sept. 2008.

[^2]: Mark D. Hill et al. “On the Spectre and Meltdown Processor Security Vulnerabilities”. In: IEEE Micro 39.2 (2019), pp. 9–19.

[^3]: Mat Honan. How Apple and Amazon Security Flaws Led to My Epic Hacking. https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/ . Aug. 2012.

[^4]: Marti Motoyama et al. “Re:CAPTCHAs—Understanding CAPTCHA-Solving Services in an Economic Context”. In: Proceedings of the 19th USENIX Security Symposium. Washington, DC, Aug. 2010.

[^5]: Whitfield Diffie and Martin E. Hellman. “Exhaustive Cryptanalysis of the NBS Data Encryption Standard”. In: Computer 6.10 (1977), pp. 74–84.

[^6]: J. Trew. ‘Find My iPhone’ exploit may be to blame for celebrity photo hacks (update). https://www.engadget.com/2014-09-01-find-my-iphone-exploit.html . Sept. 2014.