跳转至

Mind the Location Leakage in LEO Direct-to-Cell Satellite Networks

这一篇是安全相关. 新兴LEO卫星直连手机网络 (DCSN)中的用户位置隐私风险

这篇文章侧重于“攻”, 分析并揭示: "位置隐私泄露风险" 确实存在!

笔者对本篇的侧重点是: 看看实验咋做的, 尤其是这些硬件, 它们分别是干啥的. 为后续我做D2C设计/实验服务

Abstract 重点:

LEO D2C 存在新的隐私泄露风险: 由于星地通信中无线介质的独特性以及LEO卫星的动态特性, 窃听DTC广播的攻击者可能窃取活跃用户的物理位置

为"证明存在"此风险, 本文提出了一种新颖的位置泄露分析器——DCATOR: DCATOR持续监控广播信道中的DTC信令消息, 提取各种位置线索, 并将其与时变的卫星轨迹相结合, 推断活跃用户的物理位置

研究人员利用DCATOR分析了三种代表性DCSN:

  • 运行中的Iridium
  • 开发中的Starlink DTC
  • 基于最新3GPP NTN标准的DCSN

给出了上述三种情况下位置泄露的后果

广泛的实验表明, 真实DCSN中存在位置泄露, 在最坏情况下, 攻击者可以在数百米范围内精确跟踪其他用户的位置

最后，本文提出了增强DCSN隐私的对策

Introduction 重点:

背景知识: 现有的地面"攻击获取用户位置"的手段, 不适用于 D2C 场景

  1. 用户位置 是 个人隐私信息 的关键
  2. 现有的针对地面蜂窝网络的攻击方式, 很难适用于 D2C-Network
    • 精度不够
    • 攻击需要嗅探低功率的终端上行信号, 这在D2C "长距离 + 频切换"的场景下, 难以实现
  3. 近期有一些针对地面蜂窝网络的攻击方式, 但它们需要很长时间才行 (16h, 将半径缩至 4km)

我们 DCator 的机制:

  1. 优势: 更准确、更高效
  2. Key Insight: 用户位置信息虽然没有直接嵌入在无线信令消息中, 但可通过广播信道中隐藏的多种位置线索 (e.g. 传播延迟和多普勒频移) 进行推断
  3. 做法: DCator 持续监控广播 DTC 信令消息, 提取位置线索, 并将其与时变的卫星轨迹相结合, 以推断用户的精确位置
  4. 确保能激活以实现攻击:
    • 现状: 如果 UE 处于 idle 状态, 那就不会进行 location-related exchange.
      • 应对方式: ghost calls, 强制其激活并交换信令消息
    • 现状: 多UE对单卫星, 很难识别谁对谁
      • 应对方式: 比对 frequency
    • 现状: 由于broadcast, 信令信号等信息可能面临失真
      • 应对方式: 形式化 location-inference problem, 最小化错误率

[积累] 我们实验验证三类 D2C:

  • GSM: 测试对象 Iridium
  • LTE Protocol: 测试对象 Starlink
  • 3GPP NTN: 测试对象 Starlink

Background and Motivation 重点:

背景:

  • DCSN架构和协议: 直连蜂窝卫星（DTC）通常是LEO卫星，旨在直接为地面手机（UE）提供服务
    • DCSN 架构:
      • 透明模式: "无情的信号转发机器", 常见于 bent-pipe 模式
      • 再生模式: "星上再处理", ISL 离不开它 alt text
    • DCSN 协议:
      • GSM 扩展 (Iridium/ViaSat). 需要使用专用的卫星手机
      • 重用现有的 LTE/NR 协议 (Starlink DTC)
      • 新兴的 3GPP NTN 协议. 聚焦NTN新型特征给出更多改进: mobility management, timer management ...
  • 隐藏的位置线索: UE 与卫星交换的信令消息中隐式地包含了位置线索
    • 传播延迟:
      • 通过时序提前 (TA) 机制体现, TA 确保所有 UE 的上行传输同步到达卫星, 其值与 UE 和卫星之间的距离直接相关
      • TA 存在于 Iridium (pd 字段)、重用 LTE/NR 的 DCSN (MAC CE 和 Random Access Response 消息)，以及 NTN 协议中
    • 多普勒频移:
      • 描述了信号频率因卫星相对速度引起的改变，直接与 UE 和卫星的相对速度相关，Iridium 的接入请求消息中明确包含此信息

动机:

  • TA 和多普勒频移等位置相关信息由卫星广播
  • 任何在同一卫星覆盖范围内的嗅探器都可能捕获这些广播信令消息
  • 鉴于 TA 和多普勒频移隐式地揭示了 UE 与卫星之间的物理距离和相对速度，因此研究人员的动机是探究这些广播信息在当前和未来的 DCSN 中如何泄露 UE 的精确位置，并为制定对策提供指导

DCator Ovewview 重点:

(1) Threat Model

  1. "攻击者是谁"
    1. Passive Adversary: 纯纯被动窃听
    2. Proactive Adversary: 针对性的攻击者, 可以给目标UE打电话
  2. "攻击目标是什么"
    1. 共同目标: 推断用户的位置
    2. Passive One: 谁在打电话, 它们在哪里? Proactive One: 这个特定号码的人在哪里?
  3. "攻击手段是什么"
    1. 持续监控广播信令: USRP ...
    2. 获取卫星的轨道轨迹: TLE ...
  4. "信任边界"
    1. 只考虑“位置隐私泄露”威胁
    2. 不考虑攻击者篡改、注入或干扰信号
    3. 只在外部监听, 不考虑黑入BS等
Threat Model 简单介绍

在安全类会议的Design中, “Threat Model”章节是基石

Threat Model 内容组成:

  1. 攻击者是谁:
    • 被动的网络窃听者 / 主动的网络攻击者 (Man-in-the-Middle) / malicious 内部员工 ...
  2. 攻击目标是什么:
    • 想破坏: 保密性? 完整性? 可用性?
  3. 攻击手段是什么:
    • 网络层能力 / 计算能力 / 访问权限 ...
  4. 信任边界: "我们的假设"
    • 假设: 底层的加密算法是安全的
    • 假设: 不考虑物理攻击 (把基站炸了)

定义一个合理、清晰且有意义的威胁模型, 很重要:

  • 一个太弱的威胁模型: 会被直接 dr, 因为毫无攻击性的“进攻者”, 没有任何🐦用
  • 一个太强的威胁模型: 往往不切实际, 而且是在搬起石头砸自己的脚...
为什么要有 threat model?

Threat Model的本质: 设定“战场”和“游戏规则”

威胁模型为论文的“防御”或“攻击”提供了一个可衡量的benchmark:

  1. 对于防御性论文:
    • 给出防御方式! 在Evaluation证明: 在其定义的威胁模型下，它的系统是有效的
  2. 对于攻击性论文
    • 给出攻击手段! 证明: 在某个（大家公认的）威胁模型下, 现有的系统是不安全的

Threat Model 是一种“坦诚的妥协”。作者通过它来明确声明：“我的系统可以抵御A类和B类攻击，但是我假设攻击者无法做到C”

(2) 基本原理

懒得看数学了. 我直接缴械投降, 接受原理正确

alt text

(3) 系统概览

alt text

4个关键组件

  • Signaling Sniffer: 连续监控和解码包含位置线索的广播信令消息
  • Proactive Probe: 使用 "ghost call" 技术，在不干扰用户的情况下，强制空闲目标 UE 激活并交换信令
  • Satellite Locator: 确定当前服务区域的卫星，并估算其时变位置和速度
  • Analysis Controller: 协调所有组件，并最终用于位置分析

(4) 工作阶段

5个工作阶段

  1. 持续信令监控: 嗅探器监控广播信令
    • 若目标空闲，则通过 Proactive Probe 进行 "ghost call" 激活目标 UE
  2. UE 标识符提取: 提取临时用户标识符 (UE_id)，在主动模式下，通过比较呼叫频率来确定目标 UE 的标识符
  3. 位置线索获取: 从目标 UE 的信令消息中提取传播延迟、延迟变化和多普勒频移等位置线索 (loc_clue)
  4. 卫星轨迹收集: 通过 SIB19 信令或公共 TLE 数据收集服务卫星的时变轨迹 (sat_tra)
  5. UE 位置推断和分析: 将位置推断问题转化为优化问题求解，以最小化推断误差

(5) Feasibility Analysis

Feasibility Analysis 简单介绍

"Feasibility Analysis" 是一个论证章节!

它通过量化数据和情景分析来证明论文提出的方法（无论是攻击还是防御）在现实世界中的实用性、成本和可部署性

(1) "攻"类型论文: 侧重点是"这个攻击有多容易被复现"

  1. 硬件/软件成本: "我们证明攻击者不需要昂贵的专用设备, 只需要 ..."
  2. 前提条件: "我们的攻击不需要目标用户的任何交互, 只需要 ..."
  3. 攻击效率: "我们对100个用户进行测试，定位他们的平均时间仅为 30 秒，成功率达到 95% ..."
  4. 攻击匿名性: "由于我们是被动监听, 不会产生任何异常网络流量, 因此 ..."

(2) "防"类型论文: 侧重点是"这个防御有多容易被部署"

  1. 性能开销: "我们评估了系统的开销。结果显示. 它只给延迟带来了 1.2% 的增长. 对吞吐量的影响低于 0.5%. 这对用户是完全无感的"
  2. 兼容性: "我们的防御系统完全向后兼容 (backward-compatible). 不需要修改现有的应用程序"
  3. 部署成本: "仅需服务器端更新，无需用户更换手机或安装新App"
  4. 可扩展性: "我们的系统在10Gbps的骨干网络上进行了测试，CPU占用率始终低于10%，证明了其可扩展性"
为什么要有 feasibility analysis?

核心原因: 为了证明研究的 Real-world Impact

安全顶会的审稿人都是“资深怀疑论者”! 他们看到一篇论文时，脑子里会立刻冒出两个问题:

  • 对于攻击性论文 (Attack Paper):

    • 这个攻击是不是太"理想化"了？你假设的条件在现实中根本不可能满足吧？

  • 对于防御性论文 (Defense Paper):

    • 这个防御是不是太‘重’了？为了防这个攻击，系统慢了100倍，这谁会用啊？
    • 这防御真行吗？...

Feasibility Analysis 章节就是作者主动回应这些质疑的地方:

  1. 拒绝 "Toy Model": 一个攻击可能只是在作者的“实验室”里，在各种“理想”假设下才能成功
  2. Balance: Security vs. Usability: 一个防御可能实现了“完美安全”，但也导致了“完全不可用”
  3. 展示贡献的“含金量”: 一个需要10万美元设备、耗时100年才能完成的攻击 vs. 一个用20美元的树莓派、10分钟就能搞定的攻击，高下立判!

Real-world DCator Implementation 跳过!

因为我不在乎技术路线的理论, 更在乎的是 “如何与真实世界交互” / “用哪些硬件” / “硬件用来干啥”

Location Leakage Analysis with DCator 重点:

这一章节只需要看5.1, 了解实验环境是如何真实部署的, 软硬件是如何交互的 ...

(1) DCATOR 攻击原型硬件配置

为三种不同的卫星网络（Iridium, Starlink DTC, 3GPP NTN）分别构建了一套攻击原型:

alt text

测试平台 攻击目标 (Target UE) DCATOR 攻击原型硬件 (图10中橙色框)
1. Iridium (真实网络) 1x Iridium 9555 卫星电话 控制器: 1x 笔记本电脑
嗅探器: 1x USRP B210
探测器: 1x LTE 安卓手机
卫星定位器: 1x Iridium 9555 卫星电话
2. Starlink DTC (仿真) 1x LTE 手机 控制器: 1x 笔记本电脑
嗅探器: 1x USRP
探测器: 1x LTE 手机
卫星定位器: 1x LTE 手机
3. 3GPP NTN (仿真) 1x AMARI Callbox (天线) 控制器: 1x 笔记本电脑
嗅探器: 1x AMARI Callbox (天线)
探测器: 1x AMARI Callbox (天线)
卫星定位器: 不需要

(2) 核心硬件使用方式

  • 💻 笔记本电脑 (Controller):

    • 作为攻击的大脑
    • 通过 ADB (Android Debug Bridge) 工具向安卓手机（Probe）发送指令，令其执行 Ghost Call
    • 通过 gr-iridium 或 LTESniffer 等软件控制 USRP，执行sniffer任务
    • 在 Iridium 平台中，通过 AT 命令控制卫星电话（Locator）

  • 📻 USRP (Sniffer):

    • 作为软件定义无线电（SDR）设备
    • 其核心功能是被动捕获和监听空中的无线信号（Iridium / TE 信号）

  • 📱 手机 (Probe / Locator):

    • LTE 安卓手机 (Probe): 作为主动探测器，用于拨打和取消呼叫，以迫使目标 UE 发出信号
    • Iridium 卫星电话 (Locator): 作为卫星定位器，用于获取卫星的实时位置

  • 📡 AMARI Callbox (Emulator):

    • 在 NTN 仿真平台中，这是一台专业的商用 NTN 工具包
    • 它被“一机多用”，通过不同天线同时模拟了攻击者的嗅探器（Sniffer）、探测器（Probe）以及受害者（Target UE）

  • 🛰️ Starlink “星载基站”仿真 (重用 LTE 协议):

    • 一台 USRP B210 充当星载基站 (eNodeB), 连接到一台 Dell Precision 7920 塔式工作站
    • 工作站运行开源 srsRAN 来控制 USRP
    • GNU Radio 接收StarryNet的信息, 在 srsRAN 和 USRP 之间构建虚拟用户-卫星链路, 用于调整传播延迟, 模拟卫星动态性
current design for Starlink D2C

一个让笔者大惑不解的地方是, 为什么没有CoreNet? (与srsRAN配套的, srsEPC)

(1) 核心: 模拟 UE 和星载基站 (RAN) 之间的无线信令交互

dataflow 主要发生在 UE 和运行 srsRAN 的工作站之间

(2) 硬件对应关系:

  • UE: Target UE (LTE Phone)
  • RAN (基站): Dell Precision 7920 Workstation + USRP B210
  • 卫星链路 (时延): Dell Workstation 上的 GNU Radio + StarryNet
    • GNU Radio 会人为地根据 StarryNet 计算出的TLE，给这个信号注入一个动态变化的传播时延

只要能成功模拟 UE 和 srsRAN 之间的 RRC（无线资源控制）信令交换，就可以让 Sniffer捕获到这些关键信息，从而完成攻击分析

因此不需要CoreNet的参与

Basic Design: E2E Starlink D2C Emulator

一言以蔽之:

  1. 无线射频(天线): 由 USRP B210 硬件模拟
  2. 基站处理(BBU): 由 Dell工作站 上的 srsRAN 软件模拟
  3. 星地链路(时延): 由 Dell工作站 上的 GNU Radio 和 StarryNet 软件模拟
  4. 核心网: srcEPC

展开细节 - Uplink:

(1) UE:

  • 硬件: Target UE (LTE Phone)
  • 行为: send_pkt()

(2) RAN: (无线接入网 / 星载基站)

  • 硬件: USRP B210 -> Dell Precision 7920 工作站
  • 行为:
    • [星载天线]: USRP B210 作为星载eNodeB的天线, 接收来自手机的无线电信号, 并将其数字化
    • [星地链路仿真]:
      • 信号被发送到 Dell 工作站
      • GNU Radio 软件（在工作站上运行）会人为地根据 StarryNet 计算出的卫星轨道数据（TLE），给这个信号注入一个动态变化的传播时延
    • [基站处理]:
      • 经过时延注入的数字信号，被交给工作站上运行的 srsRAN 软件
      • srsRAN 作为星载eNodeB的基带处理单元, 对信号进行解调、解码, 还原出原始的 IP 数据包

(3) CoreNet (核心网)

  • 硬件: Dell Precision 7920 工作站
  • 行为:
    • [内部转发] srsRAN（RAN）将提取出的 IP 包, 通过GTP隧道, 发送给在同一台机器上运行的 srsEPC 软件（LTE核心网）
    • [核心网处理] srsEPC 的 PGW（分组网关）组件对数据包进行处理
      • 解除GTP隧道封装、验证用户身份、分配IP地址 (NAT), 然后准备将其路由到外部互联网

(4) WAN (广域网)

  • 硬件: Dell Precision 工作站物理网卡
  • 行为: 转发出去, 很显然