[论文笔记] Balboa: Bobbing and Weaving around Network Censorship

概述

Balboa: Bobbing and Weaving around Network Censorship [USENIX 2021]

Marc B. Rosen Galois, Inc.
James Parker Galois, Inc.
Alex J. Malozemoff Galois, Inc.

Balboa, 一种抗审查链接混淆框架, 提供在现有应用中隐蔽传输数据的框架, 位于应用层和系统层之间, 截取输出的网络流并重写流量数据以嵌入秘密信息. 为了防止应用行为上的异常, Balboa只会重写和外部通信方事先定义的流量模型相匹配的流量. 发送方使用流量模型指向模型相关位置的指针来替换传出的数据并在释放的空间中嵌入数据. 接收方提取数据时, 用模型中的原数据的指针替换回去再把数据传输给应用层. 这个方式会让带Balboa的应用和正常应用在行为上一致, 而且流量时间特性的差异性也较小.
Balboa的创新点: (1) 提供在任意协议/应用上构造数据通道的框架, (2) 运行的应用是标准的, 因为非标准的应用更易被识别和区分.
作者提供两种Balboa的实例, 音频流和web浏览服务. 最后对Balboa用机器学习方法进行了区分难度实验.

一句话: Balboa在应用层和系统层之间劫持和修改网络流实现任意协议和应用的数据隐蔽通道

导论

本文主要研究基于链接混淆的抗审查系统(censorship resistant systems, CRSs), 链接混淆的目标是在有审查者监视的网络中让多个通信方进行隐蔽通信. 现有的方法主要分类为两种: 似无和似有. 似无方法的思想是让通信流难以和正常流难以区分, 似有方法则是让生成的流与审查者不会阻隔的协议流接近. 这两种方法分别可以称为模拟和隧道.
在模拟方法中，CRS产生的网络流量旨在与目标协议的现有实现的网络流量密切匹配。此实现与CRS之间的任何差异都构成了一个足够强大的审查者可以针对的显著特征。在实践中，采用模仿方法的CRS往往会产生具有这种独特特征的网络流量。这导致Houmansadr等人[17]得出结论，模仿方法“从根本上是有缺陷的”。
另一种称为隧道的方法直接运行目标协议的具体实现，可以解决模拟方法的关键问题。为了以这种方式发送数据，标准实现使用一个非标准输入运行，该输入嵌入要发送的数据。例如，DeltaShaper[3]是一个通过Skype隧道传输用户数据的CRS, 基本思想是通过编码数据模拟相机和麦克风输入, 接收方通过处理调用的输出来提取数据。但是因为输入是非标准的, 所以审查者可以判断DeltaShaper是否在使用.
总之，模仿方法可以被检测，因为CRS不太可能完全匹配目标协议的具体实现，而隧道方法可以被检测到，因为目标协议的具体实现不是在标准输入上运行的。

因为Balboa只对TLS保护的网络流量的明文内容进行更改，所以对于缺少连接会话密钥的审查者来说，Balboa正在运行的事实是无法区分的，除了一个小的协议相关的定时延迟之外。重要的是，与许多规避审查的方法不同，Balboa根本没有修改TLS握手。这使得以往依赖TLS握手指纹[13]识别Balboa的许多审查人员更加困难。

contributions
(1) 介绍了一个用于规避审查的开源框架Balboa，它将数据嵌入由未修改的应用程序二进制文件生成的受tls保护的流量中。
(2) 描述了Balboa的两个实例: 一个用于音频流媒体，一个用于网页浏览。
(3) 提供了针对被动和主动对手的Balboa安全分析和评估

方法

Balboa位于应用程序和网络之间，拦截传出/传入的TLS流。然后将被拦截的流提供给TLS重写器，该重写器提取TLS流的底层明文。对于出站流量，明文被提供给特定于协议的明文重写器，该重写器用指向流量模型中适当位置的指针替换明文，并用要发送的隐蔽数据填充剩余字节. 对于接收方的输入流, 明文信息被提供给特定于协议的明文重写器, 抽取隐蔽数据和用正常数据替换回指针, 再重加密明文后传给应用层.

Traffic Models

Balboa利用流量模型捕获通信方之间预期明文网络流量的一些子集，并且Balboa假定通信方可以访问兼容的模型。同时注意, 不同的Balboa实例中的不同通信双方可以应用不同的流量模型. 而且流量模型也不必是静态的。例如在音频流设置中，服务器可以动态地从种子生成音频，并将种子与隐蔽数据一起发送到客户机。然后Balboa客户端可以复制服务器发送的动态生成的音乐。和对于网页浏览，服务器可以运行一个博客，其中的文章是由一些种子自动生成的(使它们能够被Balboa客户机的隐蔽数据替换)，而评论(可以由任意用户发布)可以通过未经修改的方式发送。

Potential Deployment Scenarios

Balboa的理想部署场景是这样的:一小组受信任的客户端知道给定的服务器是启用Balboa的。但是Balboa的应用层的行为与正常服务器的行为不可区分, 所以既可以给正常用户提供服务, 也可以给特定用户提供隐蔽通信的途径. 比如一个编程博客服务器, 正常用户可以用来发布正常的博客, 而特殊用户则可以使用balboa进行隐蔽数据传输.

Intercepting TLS Data

Balboa需要拦截传出的TLS数据，以便在将其发送给接收者之前重写底层明文，并且需要拦截传入的TLS数据来提取隐蔽数据.
在Balboa中，我们使用动态链接器特性，通过拦截对 libc 系统调用包装器的调用来操纵网络流量。与其他方法相比，这种方法有两个明显的优势:(1)由于我们直接运行应用程序的未修改版本，网络流量特征与应用程序的特征完全匹配(除了轻微的时间差异)，(2)这种方法更适合添加对附加应用程序(或附加应用程序版本)的支持，因为我们可以在很大程度上将应用程序视为黑箱，不依赖于应用程序的源代码。

动态库注入实现
在Linux上，Balboa利用ld.so的LD_PRELOAD选项来执行动态库注入, 使得对read()、write()、sendmsg()、writev()等的调用被Balboa捕获，而不是在C标准库中执行它们通常的操作。

性能考量
因为延迟特性可能会被审查者检测出来, 所以Balboa需要尽量降低流量处理的时间, 为此作者在实现时禁用内存分配操作, 并且采用高性能日志库方式(high-performance logging library).

递归问题
Balboa可以调用libc函数作为其操作的一部分。如果这样的调用发生在被拦截的libc函数中，则可能导致无限循环。Balboa通过在线程本地存储中维护一个标志来查看控件是否已经输入了注入的函数调用，从而缓解了这一问题。

Extracting TLS Key Material

关于TLS密钥的提取. 因为Balboa将应用程序的TLS库视为灰盒，除了使用libc系统调用包装器之外, 唯一要求的是TLS库支持以某种方式转储TLS密钥材料. 故Balboa有一个单独的TLS重写代码库，适用于OpenSSL, GnuTLS，NSS, Rustls。

Processing Intercepted TLS Data

一旦Balboa拦截了TLS数据，接下来的步骤是:(1)解密数据，(2)重写生成的明文，以及(3)重新加密明文，以便通过网络发送或返回给应用程序.
数据解密: Balboa对传入和传出的TLS数据进行相同的解密。解密的工作方式取决于所使用的特定TLS版本和加密套件。
明文重写: 给定提取的明文数据，Balboa要么重写明文以为隐蔽数据腾出空间，要么提取隐蔽数据并重写明文以恢复原始数据。重写的字节随后被转发进行重新加密。
重加密: 可以简单地使用提取的TLS主密匙重新加密; 但这会给在TLS连接中间的审查人员提取用户数据留下可能性。因此我们使用从TLS主密钥 $mk$ 和预共享密钥 $k$ 派生的密钥 $k^{\prime }$ 重新加密。即$k^{\prime }\leftarrow KDF(mk||k)$，其中 $KDF$ 是密钥派生函数.

Signaling

Balboa的信令协议允许客户端和服务器彼此进行身份验证，并且被设计成安全的，即使是针对审查者所做的活动探测。我们假设客户端和服务器之间已经预先共享了一个秘密密钥 $k$，并使用该密钥与TLS主密钥结合来派生服务器密钥 $k_S$ 和客户端密钥 $k_C$
作者重用TLS中的现有证书机制，以便客户机对服务器进行身份验证。Balboa客户端提供固定的公钥证书，该证书根据服务器在其服务器密钥中发送的签名进行验证.
关于服务端对客户端进行身份验证是一个挑战问题, 场景稍微复杂, 细节见论文.

实验

审查者识别Balboa的能力部分取决于该工具对应用程序的基线性能所带来的任何延迟。因此将可检测性评估的重点放在(1) Balboa的两个实例所引入的延迟; (2)为Balboa构建的分类器在各种网络延迟设置下，研究被动审查器是否能成功检测.

Goodput

实验发现音频流的吞吐量可以达到98%
对于web浏览应用, 因为隧道依附的数据主要是web所浏览的内容, 如果浏览的内容是简单的html, 那么吞吐量不会太大, 不过实际测试时得到结果是62%~99%

Microbenchmarks

音频流实例: 在以148 kbps的比特率编码的10秒Ogg Vorbis音频文件流媒体中收集数据。对于发送方，看到平均延迟为122微秒。接收端看到的延迟取决于我们正在运行的特定客户端应用程序;例如，VLC的平均延迟为36微秒，MPlayer的平均延迟为20微秒。

网页浏览实例: 为两种场景收集了数据:使用curl下载视频文件，使用Firefox浏览包含Wikipedia一小部分内容的网站上的几个链接。对于发送端(即Apache)，看到两种情况下的平均延迟约为89微秒。对于curl，平均延迟为90微秒，对于Firefox，平均延迟为216微秒.

总体来说web应用Balboa比音频流应用更高.

Timing Analysis

音频流应用
为了确定Balboa带来的时间差异对审查者分类Balboa能力的影响，在音频流和网页浏览实例上进行了几个实验。在所有的实验中, 启用和不启用Balboa的两个Ubuntu 18.04 docker容器之间生成130个pcap traces，使用 tc 控制模拟网络中的平均延迟及其标准偏差。生成0ms和30ms平均延迟的traces. 然后构建分类器，试图区分启用balboa和禁用balboa的流量.

在VLC, MPlayer, Audacious, mpv四种播放器的音频流Balboa实例中进行分类实验, 平均精度是66% ~ 84%

Web应用

测试了curl下载和FireFox的网页浏览应用, 相比音频流服务, web服务被区分出来准确率更高. 最高的准确率有96%, 不过这是在理想情况下(无网络延迟)的实验, 实际应用时因为有不可避免的正常网络延迟, 会让审查者对Balboa的区分精度足够低. (只能说这是作者的一面之言

总结

主要总结了论文提出的方案, 概况了部分实验结果.
安全分析部分, 实现细节部分, 可见论文

Related Works

[3] Diogo Barradas, Nuno Santos, and Luís Rodrigues. DeltaShaper: Enabling unobservable censorshipresistant TCP tunneling over videoconferencing streams. Privacy Enhancing Technologies, 2017(4):1–18, 2017.
[13] Sergey Frolov and Eric Wustrow. The use of TLS in censorship circumvention. In Network and Distributed System Security. The Internet Society, 2019.
[17] Amir Houmansadr, Thomas Riedl, Nikita Borisov, and Andrew Singer. I want my voice to be heard: IP over voice-over-IP for unobservable censorship circumvention. In Network and Distributed System Security. The Internet Society, 2013.

Insights

(1) 依赖于加密安全性的隐蔽传输, 单纯做替换就能发顶会, 想不通
(2) 这个设计有点问题, 如果假设审查者不能直接审查通信方机器, 那么在底层劫持和修改网络流, 维持应用层行为不变, 似乎意义不大; 续: 应用层行为不变是为了兼容正常用户和隐蔽通信用户
(3) 格式保持加密或许能增大传输容量