MIT 6.858 计算机系统安全讲义 2014 秋季（三）（2）https://developer.aliyun.com/article/1484158
多因素认证（MFA）：深度防御
- 需要用户使用两种或更多身份验证机制进行身份验证。
- 机制应涉及不同的模态！
- 您所知道的东西（例如，密码）
- 您拥有的东西（例如，手机，硬件令牌）
- 您是什么（例如，生物特征）
- 思路是攻击者必须窃取/破坏多个身份验证机制才能冒充用户（例如，攻击者可能猜测密码，但无法访问用户的手机）。
- 例如：谷歌的双因素认证需要密码加上一个可以通过短信接收授权码的手机。
- 例如：AWS 的双因素认证需要密码和一个“MFA 设备”（运行身份验证应用程序的智能手机，或专用安全令牌或安全卡）。Amazon MFA
- 多因素认证是个好主意，但实证研究表明，如果用户除了密码外还提供第二个身份验证因素，用户会选择更弱的密码！
家庭作业问题
家庭作业问题的潜在答案是什么？哪些因素很重要？
- 登录公共 Athena 机器？
- 对内部观察具有弹性：在机器上轻松安装恶意软件。
- 对物理观察具有弹性？+ MIT ID 可能是一个值得利用的好东西（将其用作智能卡）。
- 生物特征识别？不受信任的终端，可能不是一个很好的计划。
- 从网吧访问 Facebook？
- 在这里不是一个好主意使用密码管理器。
- 数据的敏感程度有多高？
- 可能被用于认证到其他网站！（要么是“使用 Facebook 登录”，要么是通过回答个人安全问题来重置密码。）
- 从 ATM 取款？
- 安全性非常重要。
- 对物理观察具有弹性。
- 对盗窃具有弹性。
- 可能是可信的终端：生物特征识别可能值得考虑。（然而，在实践中，银行可能不想信任终端。）
- 您可能还关心对个别交易进行身份验证！
- 防止对手使用被盗的凭证进行不同的、由攻击者选择的操作。
- 例如：也许用户只需使用密码就能查看余额，但如果她想要取款，她就需要使用手机进行双因素认证。
结论
论文结论：没有一个认证方案明显优于密码！例如，根据作者的说法，CAP 读卡器在安全性方面得分完美！
- CAP 读卡器是由万事达卡设计用来保护在线银行交易。
- 用法：
- 将您的信用卡插入看起来像手持计算器的 CAP 读卡器中。
- 输入 PIN 码（绕过键盘记录器！）。
- 读卡器与卡片的嵌入式处理器通信，输出一个 8 位数码，用户将其提供给网站。
分析：
CAP reader Easy-to-learn: Yes Infrequent errors: Quasi-yes Scalable for users: No (users require card+PIN per verifier) Easy recovery: No Nothing to carry: No Score: 1.5 CAP reader Server-compatible: No Browser-compatible: Yes Accessible: No (blind people can't read 8-digit code) Score: 1 CAP reader Res-to-Phys-Obs: Yes\ Res-to-Trgtd-Imp: Yes \__ One-time codes! Res-to-Thrtld-Guess: Yes / Res-to-UnThrtld-Guess: Yes/ Res-to-Internal-Obv: Yes Dedicated device Res-to-Phishing: Yes One-time codes No-trusted-3rd-Party: Yes Each site is its own verifier Res-Other-Ver-Leaks: Yes One-time codes Score: 8
- 因此，
密码=8，CAP 读卡器=10.5。然而，CAP 读卡器没有占领世界的原因（请参阅低可用性和可部署性得分）。 - 在实践中，可部署性和可用性通常比安全性更重要。
- 迁移成本（编码+调试工作，用户培训）让开发人员感到紧张！
- 方案越不可用，用户就越会抱怨（并尝试选择更容易受攻击者攻击的认证令牌）。
- 一些情况可能会给不同的评估指标分配不同的权重。
- 例子：在军事基地上，基于硬件的令牌的安全性优势可能超过可用性和可部署性的问题。
私密浏览模式
注意： 这些讲座笔记是从 2014 年 6.858 课程网站上发布的笔记稍作修改而来。
私密浏览：目标、定义、威胁模型
隐私的目标是什么？
- 模糊的理想：（某个）用户的活动与许多其他用户的活动不可区分。
- 今天我们将讨论网络浏览器隐私的问题。
- 由于网络应用程序非常复杂且可能生成大量可追踪的状态，因此对于私密浏览的定义并不明确。
- 浏览器根据用户需求和其他浏览器供应商的做法更新其私密浏览实现。
- 由于用户依赖私密浏览模式，他们对其期望更高…并且更多的实现缺陷浮出水面！
浏览器所谓的“私密浏览”是什么意思？
- 论文将此形式化为两个独立的威胁模型+攻击：
- 一个本地攻击者在浏览会话结束后拥有您的机器，并希望发现您访问过哪些网站。
- 一个网络攻击者入侵了您联系的网络服务器，并希望将您跨私密和/或正常会话进行关联。
- 如果两个攻击者合作，他们更容易识别用户。
- 例如：本地攻击者要求服务器检查服务器访问日志中的本地 IP 地址。
- 因此，对这两种攻击单独进行安全防护具有实际价值。
威胁 1：本地攻击者
- 假设： 攻击者在会话结束后控制用户的机器，并希望了解用户在私密浏览模式下访问了哪些网站。
- 安全目标： 攻击者不能了解这些网站！
- 非目标
- 不关心为未来的私密浏览会话实现隐私。
- 攻击者可能修改机器上的软件（例如安装键盘记录器）并跟踪未来的浏览活动。
- 这也是为什么我们假设攻击者在私密浏览开始之前无法访问机器。
- 隐藏使用私密浏览的事实。
- 通常被称为“合理否认”。
- 论文指出这很难实现，但没有解释原因。在后面的讲座中，我们将讨论一些潜在原因。
私密会话可以泄漏哪些持久的客户端状态？（持久性指的是“存储在本地磁盘上”。）
- JavaScript 可访问的状态：Cookies，DOM 存储
- 浏览器缓存
- 访问地址的历史记录
- 配置状态：新的客户端证书，更新的保存密码数据库，书签
- 下载的文件
- 新插件/浏览器扩展
…以及：
- 所有私密浏览实现都试图防止持久泄漏到 1、2 和 3. 但是，4、5 和 6 在私密会话结束后通常仍然存在。
- 网络活动可能留下持久的证据–DNS 解析记录！
- 要解决这个问题，私密浏览模式需要在会话结束时刷新 DNS 缓存。然而，这很棘手，因为刷新缓存通常需要在您的机器上具有管理员权限（您希望浏览器具有管理员权限吗？）并删除所有 DNS 状态，而不是特定用户生成的状态。
- 在私密浏览期间，内存中的对象也可能被分页到磁盘上！
演示：
Open Firefox in Private Browsing Mode Visit http://pdos.csail.mit.edu/ sudo gcore $(pgrep firefox) strings core.* | grep -i pdos // -e l: Look for string using the // character encoding 16-bit // little-endian. // -a: Scan all of the file. // -t: Print the offset within // the file.
数据生命周期是一个比私密浏览更广泛的问题！
- 例子：如果泄露了加密密钥或密码可能会有问题。参考链接
演示：
cat memclear.c cat secret.txt make memclear ./memclear & sudo gcore $(pgrep memclear) strings core.* | grep secret
数据存在于哪里？
- 进程内存：堆，栈。
- 终端滚动回溯
- I/O 缓冲区，X 事件队列，DNS 缓存，代理服务器，…
- 语言运行时会复制数据（例如，在 Python 中的不可变字符串）
- 文件，文件备份，SQLite 数据库
- 交换文件，休眠文件
- 内核内存：
- IO 缓冲区：键盘，鼠标输入
- 释放的内存页面
- 网络数据包缓冲区
- 管道缓冲区包含进程间发送的数据
- 随机数生成器输入（包括再次输入按键）。
攻击者如何获取剩余数据的副本？
- 文件本身可能包含多个版本（例如，Word 曾支持此功能）。
- 如果程序在释放内存或程序关闭时不擦除内存，可能会泄漏信息：
- 例如：在旧版 Linux 内核中，当创建新目录时，最多可以泄漏 4 KB 的内核内存到磁盘。
- 例如：如果内核/VMM 不擦除内存页面，那么来自进程 X 的信息可能泄漏到使用 X 旧内存页面的进程 Y 中。
- 核心转储
- 直接访问机器
- 闪存 SSD 实现日志记录–它们不会立即擦除旧数据！
- 盗取的磁盘，或者只是处理旧磁盘 [参考链接: http://news.cnet.com/2100-1040-980824.html]
我们如何处理数据生命周期问题？
- 清空未使用的内存[会有一些性能降低]。
- 在难以清零的地方加密数据（例如，在 SSD 上）。
- 安全删除密钥意味着数据无法再解密！
- 例如：OpenBSD 交换使用加密，每次启动时生成新的加密密钥。
- 与磁盘 I/O 相比，加密的 CPU 成本是适度的。
威胁 2：网络攻击者
- 假设：
- 攻击者控制用户访问的网站。
- 攻击者无法控制用户的机器。
- 攻击者希望检测用户访问网站的情况。
- 安全目标：
- 攻击者无法识别用户。
- 攻击者无法确定用户是否使用私密浏览模式。
防御网络攻击者非常困难！
- 识别用户意味着什么？
- 同一用户从不同私密浏览会话中访问链接。
- 用户从私密浏览和公共浏览会话中访问链接。
- 识别用户的简单方法：IP 地址。
- 合理概率上，来自相同 IP 地址的请求是同一用户。
- 下一讲，我们将讨论 Tor。Tor 保护 TCP 连接源（即用户的 IP）的隐私。但是，Tor 并不能解决实现私密浏览的其他挑战。
- 即使用户使用 Tor，Web 服务器仍然可以通过分析她的浏览器运行时的独特特征来识别她！
浏览器指纹演示：
- Open Chrome, go to http://panopticlick.eff.org/ - Open the same web site in private browsing mode.
- 隐私的良好思考方式：用户的匿名集是什么？即，在哪个最大的用户集中，某个用户是无法区分的？
- Panopticlick 显示，对于大多数用户，此集合很小，因为用户倾向于具有唯一的本地设置，如字体、插件等。
- 网络攻击者如何确定您是否在使用私密浏览模式？
- 论文描述了基于链接颜色的历史嗅探攻击。
- 攻击者页面在 iframe 中加载 URL，然后创建到该 URL 的链接，并查看链接是否为紫色（私密会话不存储历史记录）。
- 由于浏览器不再向 JavaScript 公开链接颜色，此攻击不再有效！[请参阅几堂课前讨论的历史嗅探攻击讨论。]
- 但是，攻击者可能有其他方法来判断您是否在使用私密模式。
- 例如：公共模式的 Cookie 无法被私密模式页面看到。因此，如果您在公共模式下访问页面，然后在私密模式下访问，页面可以检测到缺少预期的 Cookie。
方法
我们如何为私密浏览提供更强的保证？（暂时忽略 IP 地址隐私，或者假设用户使用 Tor。）
- 方法 1：虚拟机级隐私
- 计划：
- 每个私密浏览会话在单独的虚拟机中运行。
- 确保在私密浏览结束后删除虚拟机。
- 确保没有虚拟机状态最终出现在磁盘上[禁用分页？安全释放？]。
- 优势：
- 对本地攻击者和网络攻击者提供强有力的保证。
- 应用程序无需更改，只需安全删除虚拟机。
- 缺点：
- 为私密浏览启动单独的虚拟机是繁重的。
- 使用不便：用户更难保存私密浏览中的文件，使用书签等。
- 可用性和隐私之间存在固有的权衡！
- 方法 2：操作系统级隐私
- 计划：在操作系统内核级别实现类似的保证。
- 一个进程可以在“隐私域”中运行，之后将被删除。
- 优势超过虚拟机：更轻量级。
- **相对于虚拟机的缺点：**更难正确实现，因为操作系统内核管理了大量状态。
是否有方法可以对使用这些方法的用户进行去匿名化？
- 也许虚拟机本身是独一无二的！因此，我们需要确保所有用户拥有类似的虚拟机。
- 这限制了用户可以定制虚拟机的程度。
- 也许 VMM 或主机计算机引入了一些独特性。
- 例如： TCP 指纹识别：TCP 协议允许实现设置一些参数（例如，初始数据包大小，初始 TTL）。
- 像 nmap 这样的工具向远程服务器发送精心制作的数据包；可以高度可能性地猜测远程操作系统！
- 用户仍然是共享的！因此，攻击者可能会：
- 检测用户的击键时序。
- 检测用户的写作风格。这被称为笔迹学。参考
浏览器为什么要实现自己的私密浏览支持？
- 主要原因是可部署性：用户不必在自定义虚拟机或操作系统中运行其浏览器。
- Native Client 有类似的动机。
- 另一个原因是可用性：私密模式中生成的某些类型的状态应该能够在会话结束后持续存在。（例如：下载的文件）。
- 这是一个危险的计划！浏览器是复杂的软件，因此很难找到架构中允许某些类型的状态（但不允许其他类型）持久存在的清晰界限。
我们如何对这些类型的状态进行分类？论文指出我们应该考虑是谁发起了状态更改（第 2.1 节）。
- 由网站发起，无用户交互：cookies，历史记录，缓存。
- 保持在会话内，会话结束时删除。
- 由网站发起，需要用户交互：客户端证书，保存的密码。
- 不清楚什么是最佳策略；浏览器倾向于持久存储此状态，可能是因为用户必须明确授权该操作。
- 由用户发起：书签，文件下载。
- 与上述相同：浏览器倾向于持久存储此状态，因为用户授权了该操作
- …但请注意，存储此状态可能会泄露用户使用私密浏览模式的事实！
- 例如： 在 Firefox 和 Chrome 中，书签存储在 SQLite 数据库中。在私密浏览模式下生成的书签将对
last_visit_count等元数据有空值参考
- 与会话无关：浏览器更新，证书吊销列表更新。
- 将其视为在公共模式和私密模式之间共享的单个全局状态。
浏览器实际上实现了什么？
- 每个浏览器当然都是不同的。
- 此外，某些状态在一个方向上“泄露”，但在另一个方向上不会！私密模式和公共模式状态之间没有严格的分区。
问答：
- Q: 如果公共状态泄露到私密状态会发生什么？
- A:网络攻击者更容易将私密会话与公共会话关联起来。
- 例如： 在公共模式下安装的客户端 SSL 证书可以识别私密模式中的用户。
- Q: 如果私密状态泄露到公共状态会发生什么？
- A: 这对于网络攻击者和本地攻击者都有帮助：观察公共会话的状态将会泄露关于私人会话的信息！
- Q: 用户在私密模式会话中时状态应该如何处理？
- A:大多数浏览器允许状态在私密模式会话中持久存在（见表 3）。
- "否"表示网络攻击者可能能够检测到私密模式浏览！
- Q: 为什么允许在私密浏览模式下使用 cookies？
- 问： 对用户来说，在隐私浏览模式下能够创建临时会话很方便—浏览器将在私密会话结束时删除相关的 cookie。
- 问： 私密模式会话之间的状态应该如何处理？
- 答：理想情况下，每个私密会话应该从零开始—如果状态在多个私密会话之间传递，这会增加用户被指纹识别的可能性！然而，由于某些类型的状态可以从私密到公共传递，某些类型的状态可以从公共到私密传递，因此某些类型的状态确实可以在私密模式会话之间持续存在。[例如：证书、下载的项目。]
- 因此，将每个私密模式会话视为与单个公共模式共享某些状态。
浏览器扩展
浏览器扩展和插件是特殊的。
- 它们是可以访问敏感状态的特权代码。
- 它们不受同源策略或其他浏览器安全检查的限制。
- 此外，它们通常是由浏览器供应商之外的人开发的！
- 因此，它们可能不了解私密模式的语义，或者可能错误地实现了预期的策略。
- 然而，插件可能在不久的将来会灭绝！HTML5 提供了新功能，为以前需要 Flash、小程序、Silverlight 等的功能提供了本机支持。参考
- 多媒体：
- 图形：
WebGL - 离线存储：DOM 存储
- 网络：Web sockets，CORS
当前的私密浏览模式
该论文是在 2010 年撰写的—私密浏览的当前状态如何？
- 仍然很难正确实现私密浏览！
- 例如：2014 年 1 月的 Firefox 漏洞修复：pdf.js 扩展允许公共 cookie 泄漏到私密模式的 HTTP 获取中。参考
- 该扩展没有检查私密浏览模式是否已启用！
- 例如：2011 年的 Firefox 漏洞：如果您在隐私浏览模式下访问页面，然后关闭窗口，您可以转到 about:memory 并找到关于您所关闭的窗口的信息（例如，about:memory 将列出窗口的 URL）。参考
- 问题在于窗口对象是惰性垃圾回收的，因此关闭窗口不会强制窗口进行同步垃圾回收。
- 当潜在解决方案比最初预期的更复杂时，该漏洞被“降级处理”；作为回应，一位开发者说：“这听起来很令人难过。这几乎可以破坏诸如 sessionstore 忘记关闭的私密窗口等功能的目的。”
- 现成的取证工具可以找到私密浏览器会话的证据。
- 在私密会话期间，IE 将对象存储在文件系统中。这些对象在私密会话关闭时被删除，但存储空间并未被擦除，因此私人数据仍然存在于未分配的磁盘空间中。
- Chrome 和 Firefox 在私密浏览期间使用内存中的 SQLite 数据库，因此在文件系统中留下较少的痕迹。然而，像所有浏览器一样，它们在页面文件中留下痕迹。
Tor
注意： 这些讲座笔记是从 2014 年 6.858 课程网站上发布的笔记中稍作修改的。
论文的目标是什么（或 Tor 的目标是什么）？
- 为了客户端的匿名性，他们想要连接到互联网上的服务器。
- 对于希望为用户提供服务的服务器的匿名性。
- 什么是匿名性？
- 对手无法确定哪些用户正在与哪些服务器通信。
- 对手（最有可能）知道用户，服务器是通过 Tor 进行通信的。
- 换句话说，Tor 并不是为了防止对手找到 Tor 用户而设计的。
如何实现匿名性？
- 必须加密要匿名的人的流量。
- 否则，对手会查看数据包并弄清楚发生了什么。
- 但加密并不足够：仍然可以追踪加密数据包的去向。
- 将一个用户的流量与其他用户的流量混合（或“掩盖流量”）。
- 一个用户的匿名性需要有许多其他像第一个用户一样的用户。
- 如果所有其他用户只运行 BitTorrent，那么维基百科用户很容易被发现。
- 如果所有其他用户使用 Firefox，那么 Chrome 用户很容易被发现。
- …
- 对手将无法确定哪个用户发起了什么连接。
- 混合组件必须更改数据包（例如，加密/解密）。
- 否则，可以查找相同数据包稍后出现的位置。
- 因此，方法是：通过加密/解密的中间人中继流量。
为什么我们需要多个节点？
- 可扩展性：处理比单个节点更多的流量。
- 妥协：攻击者了解有关受损节点的直接客户端的信息。
- 有许多独立节点，这只影响了一小部分流量。
- 使用洋葱路由，攻击者必须妥协链中的所有节点。
- 流量分析：攻击者可以相关联传入/传出的流量。
- 可以查看数据包之间的时间间隔或数据包的数量。
- 链接使时间/数据量分析攻击更难实施。
- 攻击者仍然能够成功吗？
- 是的，如果他们观察或者妥协足够多的节点。
- 例如，可能足以观察第一个和最后一个节点。
- 攻击者还可以注入时间信息（通过延迟数据包）进行分析。
主要思想：洋葱路由
- 网络中的洋葱路由器（ORs）的网格。
- 假设：客户端知道所有 ORs 的公钥。
- 客户端选择通过这个网络的某条路径。
- 洋葱路由的天真草人（不完全是 Tor）：
- 客户端依次在路径中的每个 OR 的公钥中加密消息。
- 将消息发送到路径中的第一个 OR，该 OR 解密并中继，依此类推。
- “出口节点”（路径中的最后一个 OR）将数据发送到真实网络中。
- 为什么这是一个好的设计？
- 每个 OR 都知道前一个和下一个跳跃，而不知道最终源或目的地。
- 通过两个 ORs，妥协一个 OR 并不会破坏匿名性。
在哪个级别应该中继事物？
- 可以在任何级别进行–IP 数据包，TCP 连接，应用级别（HTTP）
- 优势/劣势是什么？
- 低级别（IP）：更一般，更少的应用程序更改，适用于更多应用程序。
- 更高级别（TCP，HTTP）：更高效（单个 TCP 帧的开销，而不是存储单个 TCP 帧的多个 IP 帧的开销），更匿名。
- Tor 做了什么？
- 使用 SOCKS 进行 TCP 级中继，拦截 libc 调用。
- 效率的例子：不需要 TCP 流量控制，Tor 进行重传
- 丢失通用性的例子：UDP 无法工作，无法进行路由跟踪，…
- Tor 如何处理 DNS，如果不支持 UDP？
- SOCKS 可以捕获目的地的主机名，而不仅仅是 IP 地址
- 出口节点执行 DNS 查找，建立 TCP 连接
- 丢失在较低层的匿名性的例子？
- 如果我们使用 IP，将泄漏大量 TCP 信息（序列号，时间戳）
- 如果我们使用 TCP，将泄漏各种 HTTP 头和 cookie。
- 如果我们使用 HTTP，可以通过 Javascript，Flash 等违反匿名性。
- Javascript 环境中有许多可识别的特征。
- 浏览器版本，历史嗅探，本地网络地址/服务器…
- “协议规范化”：在更高级别协议中修复所有自由度。
- 在实践中很难做到；特定于应用程序的代理很有用（例如，Privoxy）。
- 浏览器“识别”的演示：https://panopticlick.eff.org/
Tor 设计
- OR 的网格：每个 OR 通过 SSL/TLS 连接到其他每个 OR。
- 不需要 CA 签名的 SSL/TLS 证书。
- Tor 有自己的公钥检查计划，使用目录服务器。
- OR 主要由志愿者运行：例如，MIT 运行几个。
- 终端用户运行实现 SOCKS 的洋葱代理（OP）。
- OR 有两个公钥：身份密钥和洋葱密钥。
- 身份密钥在目录中注册，签署 OR 状态。
- Onion 密钥由 OP 用于连接 OR，建立电路。
- 客户端从目录下载 OR 列表。
- 选择一系列 OR 形成电路，依次联系每个 OR。
- 客户端建立电路是昂贵的。- 为什么要这样做？
- 任何单个服务器可能被 compromise，无法信任它。
- 无法避免信任客户端机器。
- 为什么我们需要洋葱密钥以及身份密钥？
- 可能能够保护身份密钥免受长期损害。
- 每个 OR 使用身份密钥签署其当前的洋葱密钥。
- Tor 为什么需要目录？
- 需要有人批准 OR。
- 否则攻击者可以创建许多 OR，监视流量。
- 目录是否会损害匿名性？
- 不，不需要在线查询。
- 如果一个目录被 compromise 了怎么办？
- 客户端需要大多数目录同意。
- 如果许多目录被 compromise 了怎么办？
- 攻击者可以注入许多 OR，监视流量。
- 如果目录不同步怎么办？
- 攻击者可能根据目录信息缩小用户身份范围。
- 看到一组目录消息的用户将使用特定的 OR。
术语：电路和流。
- 电路：客户端建立的通过 OR 列表的路径。
- 电路存在一段时间（也许几分钟）。
- 定期打开新的电路以防止攻击。
- 流实际上是一个 TCP 连接。
- 许多流在同一电路上运行（每个具有单独的流 ID）。
- 流是一个重要的优化：无需重建电路。
- Tor 为什么需要电路？
- 如果电路存在时间很长会出现什么问题？
- 对手可能将多个流关联到一个电路中。
- 将单个用户的连接与不同站点联系起来，破坏匿名性。
Tor 电路
- 电路是 OR 序列，以及共享的（对称 AES）密钥。
- ORs
c_1, c_2, .., c_n - 键
k_1, k_2, .., k_n
- 单元格格式：
+---------+---------------+-----------+| 电路 | 控制/中继 | - 数据 |+---------+---------------+-----------+2 字节 + 1 字节 + 509 字节
- 将"Circuit"和"Control/Relay"字段视为链路层头部。
- 电路 ID 是每对 OR 之间的。
- 用于在 OR 之间的同一 TLS 连接上多路复用许多电路。
- 控制消息是"链路本地的"：仅发送给直接邻居。
- 中继消息是"端到端的"：沿着电路中继。
- 为什么所有流量都是固定大小的单元格？
- 使流量分析更加困难。
- 控制命令是什么？
- 填充：保持活动或链路填充。
- create/created/destroy：创建和销毁电路。
- 中继数据包中有哪些中继命令（DATA 中有什么）？
- 如果中继数据包目标是当前节点：
+----------+--------+-----+-----+-----------+| StreamID | Digest | Len | CMD | RelayData |+----------+--------+-----+-----+-----------+2 字节 + 6 字节+ 2 + 1 + 498 字节- 如果中继数据包目标是另一个节点：
+-------------------------------------------+| 加密的、不透明的数据 + + + + + |+-------------------------------------------++ + + + 509 字节
- TCP 数据的 CMD 字段是"中继数据"。
- 其他值如"relay begin"等用于建立流。
OP 如何通过电路发送数据？
- 如上所述组成中继数据包（尚未加密）。
- 计算有效的校验和（摘要）。
- 摘要基于应解密数据包的目标 OR。
- 哈希是通过某个键的函数和与该 OR 交换的所有消息进行的。
- 防止重放攻击和主动攻击
- 摘要的前 2 个字节为零，其他 4 个字节来自哈希。
- 使用
AES(k_n)加密，然后使用AES(k_{n-1}), .., AES(k_1)加密。 - 发送加密单元格到第一个 OR（
c_1）。
- （OP 通过电路接收数据的逆过程。）
OR 如何处理中继数据包？
- 如果来自 OP 的方向，解密并远离 OP 转发。
- 如果不是来自 OP 的方向，加密并转发至 OP
OR 如何知道中继数据包是否适用于它？
- 验证校验和：如果匹配，则很可能适用于当前 OR。
- 优化：摘要的前 2 个字节应为零。
- 如果前两个字节不为零，则可以跳过哈希：不是我们的数据包。
- 如果校验和不匹配，则不适用于此 OR，继续中继。
- 美好的特性：
- 数据包大小与路径长度无关。
- 只有最后一个 OR 知道目的地。
如何建立一个新的流？
- OP 通过电路发送"relay begin"。- 包含目标主机名、端口。
- 谁选择流 ID？- OP 可以在其电路中选择任意流 ID。
什么是"漏水管"拓扑？
- OP 可以向其电路中的任何 OR 发送中继消息（不仅仅是最后一个 OR）。
- 可以通过任何 OR 构建流（即，TCP 连接），以防止流量分析。
初始化电路
- OP 选择要用于其电路的 OR 序列。
- 为什么要让 OP 这样做？- 抵抗其他 OR“转移”电路。
- 连接到第一个 OR，发出“创建”操作以创建电路。
- 创建包括 DH 密钥交换消息。
- 创建响应包括 DH 密钥交换回复。
- 密钥交换协议：
- [OP，OR 同意素数 p，生成器 g]
- OP 选择随机 x。
- OP 发送
E_{PK_OR}(g^x)。 - OR 选择随机 y。
- OR 计算
K=g^xy。 - OR 回复
g^y, H(K || "handshake")。 - OP 计算
K=g^xy。
- 我们如何在这里验证各方身份？
- 第一个 DH 消息使用 OR 的洋葱密钥加密。
- DH 响应中密钥的哈希证明向客户端证明正确的 OR 解密了消息。
- 服务器不验证客户端-匿名性！
- 前向保密：是什么？如何实现？
- 密钥新鲜度：为什么？如何实现？
- 谁选择电路 ID？
- TLS 连接的客户端端点（而不是整个电路的 OP）。
- 每个电路对于其穿越的每个链接具有不同的电路 ID。
- 控制数据包中的数据是什么？
- 控制操作（创建，销毁）或响应（例如，已创建）。
- 参数（例如，DH 密钥交换数据）。
- 对于每个后续 OR，OP 通过电路发送“中继扩展”消息。
- 在“中继扩展”单元中包含相同的 DH 密钥交换消息。
- 在电路结束时，“中继扩展”转变为“创建”。
- 客户端最终获得每个电路中每个 OR 的共享（对称 AES）密钥。
- Tor 为什么有单独的控制单元和中继单元？
- 确保单元始终具有固定大小。
- 旧电路中的最后一个 OR 需要知道新 OR 和电路 ID。
MIT 6.858 计算机系统安全讲义 2014 秋季（三）（4）https://developer.aliyun.com/article/1484161
