待整理

论文与结项-研究脉络整理

一句话概括

本研究围绕 Tor 隐藏服务通信链路中的 stream-level flow control 展开：攻击者在客户端侧通过伪造/改写 XON/XOFF 反馈注入可控流量水印，使隐藏服务端按照该反馈调制发送速率，并在隐藏服务侧的 Guard 出口观测中识别该水印，从而完成目标隐藏服务定位。

一、研究主线

1. 起点：把不可控的接收侧反馈变成可控的调制接口

最初的研究切入点来自 Tor 的 stream-level 流控机制。客户端会基于自身接收/排空能力向对端发送 XON/XOFF：

  • XOFF 表示“暂时不要继续发送”
  • XON(kbps_ewma) 表示“建议按照某个速率继续发送”

原始实现中，XON 携带的 kbps_ewma 来自客户端真实测得的 ewma_drain_rate，因此它本来是一个“被动测量值”，而不是一个“主动控制量”。

你的第一步工作，就是把这个本来不可控的反馈量改造成一个可以实验操控的调制接口。为此，你在客户端流控发送路径上实现了一套低侵入的控制面，支持：

  • 固定速率
  • 上限截断
  • 比例缩放
  • 方波高低速切换
  • 强制 XOFF
  • 配置文件热更新

这一阶段的核心意义是：把 Tor 原本用于自适应流控的机制，转化为了可编程的水印注入通道。

2. 第一阶段假设：是否需要固定 RP 才能控制隐藏服务

在研究早期，你曾提出一个自然假设：如果要通过客户端侧控制隐藏服务流量，也许需要把 RP 固定到受控节点，或者至少把 RP 当成关键处理位置。

基于这个判断，你完成了两类探索：

  • 修改客户端建路逻辑，使 C_ESTABLISH_REND 选择 RP 时能够像普通 Exit 一样受 ExitNodes 控制
  • 禁用部分 internal circuit 复用，避免旧电路绕过新的 RP 固定逻辑

这一阶段的价值不只是“做了固定 RP 的实现”，更重要的是它为后续研究提供了一个明确的过渡问题：

XON/XOFF 究竟是在 RP 被处理，还是会继续传递到 HS？

3. 关键机制确认：RP 不是处理终点，XON/XOFF 会被转发到 HS

随后，你对隐藏服务链路结构和 relay cell 处理逻辑进行了确认，得到两个关键结论。

第一，隐藏服务到 RP 的实际电路不是简单三跳，而是：

HS -> S Guard -> S Middle1 -> S Middle2 -> RP

因此整个通信链路是：

Client -> C Guard -> C Middle -> RP <- S Middle2 <- S Middle1 <- S Guard <- HS

第二，RP 并不会作为 stream endpoint 处理 XON/XOFF，而是仅作为中继转发这些控制单元，真正处理它们的是隐藏服务本身。

这个结论非常关键，因为它直接把研究从“控制某个特定 RP”收束为“只要客户端能稳定发出控制信号，任意 RP 下都可能影响 HS 发送行为”。

也就是说，研究主问题从：

  • “如何固定 RP 并在 RP 侧施加控制”

收束成了：

  • “如何通过客户端侧流控水印稳定调制 HS 发送，并在 Guard 侧识别这种调制”

这一步实际上完成了你的研究问题定型。

4. 现象验证：客户端注入的调制确实能传到 HS，并在 Guard 侧留下可观测特征

在机制确认之后，研究重点从“能不能控制”转向“能否稳定留下可识别特征”。

现阶段你已经得到几类重要实验现象：

  • 在客户端开启方波控制时，隐藏服务侧监控到的上传流量会呈现相应方波模式
  • 此时 RP 可以是随机公网 relay，仍然能观察到相同效果
  • 平均发送速率通常稳定在 XON 建议值的约 0.75-0.78 区间
  • 建议值越大，越不容易逼近上界，但不会超过建议值

这些结果说明：

  1. 客户端侧 XON/XOFF 确实构成了有效调制信号
  2. HS 会对该信号做出稳定而可重复的速率响应
  3. 虽然存在平滑和衰减，但响应足以形成统计上可识别的模板

5. 从“现象”走向“水印设计”：寻找最短时间和最隐蔽幅度

在 3 月中旬的实验中，你已经开始把问题进一步收敛到“可识别边界”：

  • 用 慢 -> 快 作为检测指标时，约 4-5s 延迟即可检测到特征
  • 当前认为约 33% 的高低速差可以作为较隐蔽但仍可区分的幅度
  • 设计目标转向“既能识别，又不容易被隐藏服务察觉”

这意味着你的研究不再停留在“我能造出一个明显波形”，而是开始进入更有论文价值的命题：

在隐蔽性约束下，最弱多强的水印仍然可被 Guard 侧可靠识别？

6. 系统化阶段：把研究问题展开成完整实验矩阵

到 3 月下旬，你已经把实验问题抽象成较完整的论文式框架，主要覆盖四个核心研究问题：

  • RQ1 可注入性：客户端是否能稳定诱导 HS 到 Guard 的特征流量
  • RQ2 可识别性：攻击者能否在 Guard 侧准确识别水印
  • RQ3 并发可区分性：多个客户端同时访问同一 HS 时是否仍可定位目标连接
  • RQ4 防御有效性：防御机制能否识别或削弱该水印

与之对应，你已经设计了从注入验证、短时识别、长时识别、目标定位，到参数敏感性、边界实验、消融实验、防御实验和开销实验的一整套实验矩阵。

这说明你的研究已经从“证明一个机制存在”上升为“评估一个攻击框架的有效性、边界与防御面”。

7. 分析框架阶段：从人工看波形转向可复现的自动分析

到 4 月初，你进一步搭建了 A/B 对齐分析框架，把实验分析从“肉眼观察方波”推进为结构化、批量化、可重复的统计分析。

框架的核心思想是：

  • A 端记录真实控制序列
  • B 端记录连续出口速率
  • 通过扫描候选时延 lag，找到让高低符号窗口可分性最强的对齐方式
  • 在最佳 lag 下恢复符号并计算分类指标

这一步的意义很大，因为它把你的研究从“现象实验”推进到了“可量化识别实验”，并且已经具备论文中实验方法章节的雏形。

二、当前已经形成的核心研究结论

基于现有笔记，已经可以提炼出下面几条核心结论。

1. 攻击入口成立

Tor 客户端侧的 stream-level XON/XOFF 反馈通道可以被低侵入改写，从而作为可编程的流量调制接口。

2. 作用路径成立

XON/XOFF 不在 RP 被终止处理，而是会被转发到隐藏服务，由隐藏服务调整其发送行为。

3. 无需固定 RP

固定 RP 是研究初期的工程假设，但在后续机制确认后已经被弱化。对于“客户端通过流控影响 HS”这一主命题来说，RP 并不是必须控制的处理点。

4. Guard 侧存在可检测响应

隐藏服务侧对 XON/XOFF 的响应会在 HS -> Guard 方向留下连续速率特征，能够被 Guard 出口观测到。

5. 特征具备可重复性与可量化性

注入后的高低速模式不是一次性偶发现象，而是可以通过窗口对齐、延迟估计和阈值分类稳定恢复。

6. 该问题具备完整论文展开空间

该研究已经自然覆盖了机制设计、攻击建模、实验验证、鲁棒性边界和防御分析几个维度，不是单点现象，而是一个完整的系统安全研究问题。

三、适合写论文的叙事方式

如果你现在开始写论文，最顺的叙事不应该是“我先改 RP，再做分析”，而应该是下面这条主线。

1. 研究背景

Tor 隐藏服务定位长期关注路径关联、流量指纹和时序分析，但较少讨论：客户端是否能够主动利用协议自身的流控反馈机制，对隐藏服务发送行为施加可控调制，并在 Guard 侧恢复该调制。

2. 核心洞察

Tor 的 stream-level flow control 虽然设计目标是接收侧拥塞反馈，但其 XON/XOFF 实际上构成了一条可被攻击者利用的“反向控制信道”。

3. 攻击思路

攻击者作为客户端，向目标 .onion 服务发起请求，并通过改写客户端侧 XON/XOFF 序列向隐藏服务注入水印；随后在隐藏服务侧 Guard 的出口流量中检测对应的速率模式，从而判断该 Guard 是否承载了目标隐藏服务流量。

4. 关键技术挑战

  • 如何把原本不可控的 XON 速率建议变成可编程控制量
  • XON/XOFF 到底在哪个节点被处理
  • 在持续下载和缓冲平滑下，如何从连续速率序列中恢复水印
  • 水印在并发背景下是否仍然可分
  • 多大幅度、多长时间的注入才既可检测又足够隐蔽

5. 你的解决方案

  • 在客户端侧实现可热更新的流控控制面
  • 用源码分析和实测确认 XON/XOFF 最终由 HS 处理
  • 设计多种注入模式，尤其是高低速交替的持续调制模式
  • 搭建基于 lag scan + window separability 的分析框架
  • 用分类指标而不是主观观察来评估识别效果

6. 贡献点写法

论文里可以把贡献概括为：

  1. 发现并验证了 Tor 隐藏服务通信中一条可被利用的基于 XON/XOFF 的主动流量调制路径。
  2. 设计并实现了一个低侵入的客户端侧流控水印注入机制，支持多种可配置调制模式。
  3. 证明了该调制无需控制 RP 即可传递到隐藏服务，并在 Guard 侧形成可恢复特征。
  4. 提出了一套面向持续调制场景的 A/B 对齐分析框架，可自动完成延迟估计、符号恢复与识别评估。
  5. 通过系统实验刻画了该攻击的识别能力、隐蔽性边界、并发影响及潜在防御面。

四、适合写国创结项材料的表达

国创结项材料通常更看重“做了什么、解决了什么、有什么结果”。可以整理成下面这套口径。

1. 已完成工作

  • 分析了 Tor 隐藏服务通信中 stream-level flow control 的工作机制
  • 在客户端实现了可控 XON/XOFF 注入模块，支持多种水印模式与热更新
  • 验证了控制信号会经由 RP 转发至隐藏服务并影响其发送速率
  • 设计了面向隐藏服务 Guard 定位的攻击模型与实验方法
  • 搭建了实验分析框架，实现控制序列与出口观测序列的自动对齐分析
  • 初步获得了高精度识别结果

2. 阶段性结果

根据现有分析报告，某次持续调制实验已经得到：

  • best_lag_ms = 1400
  • accuracy = 0.989
  • precision = 0.983
  • recall = 0.994
  • f1 = 0.989

这些结果说明在当前实验条件下，注入的高低速控制符号已经可以在观测侧被稳定恢复。

3. 创新点

  • 将 Tor 正常协议中的 XON/XOFF 流控机制转化为攻击侧可利用的水印注入通道
  • 证明隐藏服务侧的流控响应可在 Guard 观测中留下稳定可识别特征
  • 针对持续调制场景设计了新的窗口对齐与分类分析方法

4. 应用意义

该研究揭示了匿名通信系统中“正常性能控制机制”可能被转化为“主动定位信道”的风险，对隐藏服务匿名性分析和协议防御设计都具有参考价值。

五、你现在最适合补齐的内容

如果你的目标是尽快写论文和结项材料，下面几部分最值得优先补。

1. 威胁模型写清楚

要明确说明：

  • 攻击者能力边界是什么
  • 客户端侧和 Guard 侧的控制/观测条件是什么
  • 攻击目标是“定位 HS 对应 Guard”还是“直接确认某个 HS 身份”

2. 把“固定 RP”处理成研究中的中间假设，而不是最终方案

这部分不要写成主贡献，更适合写成：

  • 研究初期的工程探索
  • 用来帮助确认处理位置和链路机制
  • 最终结论是攻击不依赖固定 RP

这样论文会更干净，逻辑也更强。

3. 补齐并发和定位实验

你现在已经有较强的单连接识别结果，但如果论文目标是“定位 HS”，那么还需要更明确回答：

  • 多条候选 Guard 流里能否找到目标
  • 多客户端并发访问同一 HS 时能否区分目标连接

4. 补齐隐蔽性与防御部分

目前你已经有“33% 幅度”和“4-5 秒检测延迟”的初步判断，这非常适合进一步扩展成：

  • 最小可检测幅度
  • 最短可检测时间
  • 吞吐损失和可察觉性
  • 防御方是否可通过平滑、限幅或随机扰动削弱水印

六、可以直接放进论文摘要的短版表述

本文研究 Tor 隐藏服务通信中的一种基于 stream-level flow control 的主动流量水印攻击。攻击者通过改写客户端侧 XON/XOFF 反馈，将原本用于接收侧速率建议的协议机制转化为可编程调制通道，从而诱导隐藏服务按预定模式调整发送速率。我们进一步证明，该控制信号不会在 rendezvous point 被终止处理，而是会被转发至隐藏服务，并在隐藏服务侧 Guard 的出口流量中形成可观测特征。基于此，本文设计了多种流量调制模式，并提出一套面向持续调制场景的 A/B 对齐分析框架，用于完成延迟估计、符号恢复与识别评估。初步实验结果表明，该方法能够在持续下载场景下实现高精度识别，说明匿名通信协议中的正常流控机制可能被攻击者利用为隐藏服务定位信道。

七、可以直接放进结项简介的短版表述

本项目围绕 Tor 隐藏服务匿名性展开研究，发现并验证了一条基于 XON/XOFF 流控反馈的主动定位路径。项目实现了客户端侧的可控流量水印注入模块，证明了控制信号可经由隐藏服务通信链路传递至服务端并影响其发送速率，同时构建了面向 Guard 侧观测的分析框架，实现了水印模式的自动识别。相关结果表明，该类攻击在一定条件下具有较高识别准确率，为匿名通信协议的安全分析与防御设计提供了新的研究视角。

八、目前这条研究脉络最简洁的总结

你的研究不是“改 Tor 做方波实验”，而是一条很完整的安全研究链条：

  1. 发现 Tor 流控反馈里存在可被主动利用的控制变量。
  2. 将该变量工程化为可配置的客户端侧水印注入接口。
  3. 验证控制信号经 RP 转发并最终作用于隐藏服务。
  4. 证明该作用会在 HS -> Guard 流量上留下稳定特征。
  5. 设计分析框架在 Guard 侧恢复该特征，从而实现隐藏服务定位。
  6. 进一步研究该攻击的边界、并发表现、隐蔽性与防御可能。