摘要

VoLTE（Voice-over-LTE）是LTE移动网络的指定语音解决方案，其全球部署正在进行中。它将呼叫服务从传统的电路交换电信电话重塑到分组交换Internet VoIP。在这项工作中，我们在全面推出VoLTE安全之前进行了首次研究。我们在其控制平面和数据平面功能中发现了几个漏洞，这些漏洞可被利用来破坏运营网络中的数据和语音。特别是，我们发现广告客户可以轻松获得免费的数据访问权限，关闭持续的数据访问权限或服从正在进行的呼叫等。我们使用商用智能手机（rooted and unrooted）验证了这些概念验证攻击. 在两家美国Tier-1移动运营商中。我们的分析表明，问题出在设备和网络上。设备OS和芯片组无法禁止非VoLTE应用访问和将数据包注入VoLTE控制和数据平面。网络基础结构还缺少适当的访问控制和运行时检查。

类别和主题描述符
C.2.0 [计算机通信网络]：通用—安全性和保护； C.2.1 [计算机通信网络]：
网络架构与设计—无线通信

关键词
蜂窝网络； LTE； VoLTE；攻击;防御

1.引言

语音是一项简单的公用服务，但对移动运营商和电话用户而言至关重要。数十年来，它一直是移动网络的杀手级应用。随着基础架构升级到第四代（4G）移动技术长期演进（LTE），语音服务也正在经历其快速发展。这种针对4G网络的解决方案称为VoLTE（LTE语音）。

简而言之，VoLTE是一个VoIP方案, 用于仅基于分组交换（PS, packet-switched），全IP的LTE网络[5]。它将电路交换（CS）传统呼叫解决方案不提供给2G / 3G网络。设计看起来很简单。它在数据平面的IP数据包中承载语音消息，而不再通过专用电路。为了促进语音通信，每个VoLTE呼叫还在控制平面上维护单独的信令会话。这类似于Internet上的VoIP。但是，VoLTE采用特定于蜂窝的技术来确保运营商级的质量。它利用LTE网络为两个会话提供的高优先级服务质量（QoS）。

因此，VoLTE与其传统的2G / 3G呼叫服务相比具有明显的优势，包括质量提高（例如，通过高保真编解码器进行清晰的呼叫），更多选项（例如，视频呼叫，语音邮件和会议）以及更好的互操作性（例如， ，通过移动网络，WiFi和有线互联网）。因此，它是强制性的，并被指定为最终呼叫解决方案[5]。随着VoLTE将其设计范式从CS转移到PS，我们对这种重大变化是否会损害LTE网络以及移动用户产生了兴趣。

在这项工作中，我们研究了VoLTE是否暴露出新的和意外的威胁。我们的研究基于一条简单的经验法则，即任何重大变化都可能导致不安全感。随着核心技术从CS到PS的重大转变，VoLTE可能会干扰其他系统组件，从而导致新的漏洞。从技术角度来看，我们怀疑语音和数据基于PS的相同操作可能会打开通过VoLTE运行数据的大门。此外，由于移动操作系统可轻松访问IP转发，因此VoLTE将设备芯片组（硬件）中的刚性CS访问扩展到软件（操作系统和移动应用程序）中更开放的PS访问。这可能会使传统语音的现有保护机制和安全防御失效。最后，与普通数据服务不同，VoLTE在资源分配中具有更高的优先级，以确保更高的质量。它可能会无意间充当泄漏关键信息的辅助渠道。

我们的研究证实了以上所有怀疑。 VoLTE可能会破坏数据和语音。首先，VoLTE控制会话可能会被滥用来携带PS数据包，而不是语音信令消息。更具威胁性的是，由于无需对VoLTE控制数据包进行计费，此漏洞可导致免费数据访问。这种免费服务可用于“移动到Internet”和“移动到移动”通信。此外，控制平面漏洞利用可实现更高优先级但不值得的数据访问。这将关闭正在进行的数据会话（数据DoS），或对受害者施加数据超额收费。第二，VoLTE容易受到新的语音DoS攻击。当会话信息从数据平面上的侧信道泄漏或数据平面和控制平面之间的不正确协调时，没有特权的恶意软件可以使正在进行的呼叫静音。表1总结了我们的发现，这在美国两家顶级航空公司中得到了证实。我们进一步在设备和网络方面在控制平面和数据平面上提出补救措施，以确保VoLTE的安全。

识别出的根本原因也是多方面的。移动技术标准，设备操作系统和硬件以及网络操作都造成了安全漏洞。首先，移动标准为控制平面和数据平面上的操作提供了宽松的规定。 VoLTE通过IP数据包承载控制信令和语音消息。但是，可以欺骗两个平面来发送或接收非VoLTE数据包。移动技术标准未规定在VoLTE中仅允许真实语音数据包的机制。其次，移动设备不能禁止意外访问VoLTE。软件和硬件相互依赖以提供保护。非VoLTE应用程序可通过软件访问VoLTE，从而将数据包注入硬件芯片组。同时，硬件始终信任来自软件（操作系统和应用程序）的流量，并允许其通过而无需进行适当检查。因此，设备也应承担责任。第三，网络运营也应承担责任。运营商信任移动设备（实际上是他们的芯片组），并且网络侧的适当防御并未完全实施。

总之，我们通过系统地考虑所有维度：控制平面，数据平面及其协调，对VoLTE的不安全性进行了首次实证研究。我们进一步证实了我们对两家美国航空公司的发现。本文做出了三点贡献。

1.我们在其控制平面，数据平面以及两者之间的协调上确定了七个漏洞。它们跨移动设备（硬件和软件）和运营商网络，范围从访问控制，计费策略到QoS方案和VoLTE操作。

2.我们设计概念验证攻击（例如，免费数据访问，数据过度收费，数据和语音DoS攻击）以利用已识别的漏洞。我们评估它们对运营网络的影响。

3.我们推断出根本原因，建议解决方案，并分享所学到的经验教训。移动互联网行业可能会从这些经验教训中受益，因为它仍处于全面的全球VoLTE部署的早期阶段。请注意，控制平面和数据平面的安全性是不同网络服务的普遍问题。 VoLTE所暴露的问题和汲取的经验教训也可以应用于它们。本文的其余部分安排如下。 §2给出了VLTE的背景，潜在的漏洞以及这项工作的攻击模型。在§3和§4中，我们分别披露了VoLTE的漏洞和针对VoLTE控制和数据平面的草图攻击。然后，我们在§5中提出建议的修复程序，在§6中讨论几个剩余的问题，并在§7中更新解决这些问题的持续努力。 §8和§9分别介绍了相关工作和结论。

2.当语音转换为“数据”时，出现的新的安全问题

在本节中，我们首先回顾VoLTE，然后确定其潜在的漏洞。我们描述了攻击模型和评估方法。

2.1 VoLTE入门

VoLTE预计将成为LTE用户的主要语音解决方案。它将传统的电路交换（CS）语音服务迁移到分组交换（PS）设计。

VoLTE的网络架构。图1描绘了支持VoLTE的简化架构。涉及两个子系统。第一个是PS交付子系统（顶部），在启用VoLTE之前存在。它的作用是提供与移动设备之间的PS连接，从而容纳通用数据服务。核心组件是4G网关，该网关转发数据包，类似于Internet中的边缘路由器。它还提供某些控制实用程序，例如策略执行和数据量计费。第二个是IP多媒体子系统（IMS，底部），它支持IP电话和多媒体服务[9]。它由两个关键元素组成：媒体网关和信令服务器。前者是为VoLTE用户或传统电话用户提供多媒体（例如语音）流量。后者用于在设备，媒体网关和4G网关之间执行呼叫控制功能。

VoLTE如何运作？如图1所示，每个VoLTE呼叫都维护两个通信会话。控制面会话是通过流行的会话发起协议（SIP）交换呼叫信令消息的方法[30]。只要启用了VoLTE功能，它就会建立并保持活动状态。数据平面会话处理语音数据包的传输，例如通过Internet实时传输协议（RTP）[6]；它是由控制会话按需建立的。注意，在呼叫者和被呼叫者之间没有保留专用的通信信道（电路）。取而代之的是，所有语音流量和信令消息都以数据包的形式承载，并通过IP传递。结果，4G网关不仅为普通的移动宽带服务向/从Internet中继数据包，而且还在设备和IMS核心之间的控制和数据平面上路由数据包。

为了确保运营商级的通话质量，VoLTE利用了LTE提供的多种服务类别（例如，保证的比特率和不同的优先级[8]）。它的数据平面由保证比特率等级承载，以确保最低比特率。其控制平面使用非保证比特率类别，但具有最高优先级。在这两种情况下，VoLTE信令和语音均比数据服务具有更高的优先级。

2.2潜在漏洞

最终，语音和数据在相同的无连接IP网络中运行。但是，这种模式转变是双重的，使LTE网络和用户面临意料之外的漏洞。

在本文中，我们研究了三个安全方面。

1.尽管VoLTE扮演着语音的角色，但如何诱使VoLTE获得PS数据访问？从技术上讲，这与设备和网络上VoLTE的访问控制防火墙有关。

2.如何从VoLTE学习有关语音呼叫的私人关键信息？请注意，VoLTE是基于IP的，并且比传统CS呼叫服务更为开放和可访问。

3.与语音相关的策略和操作（例如，语音计费和QoS控制）在VoLTE环境中能否正常运行？如果不是，那么对LTE的威胁是什么？

我们的研究涵盖了VoLTE操作的三个方面：控制平面，数据平面以及控制平面和数据平面之间的协调。这些安全问题涉及设备，4G网关和IMS核心。在以下各节中，我们将介绍当前采用或新开发的机制如何无法增强VoLTE抵御攻击的能力，以及如何利用它们来威胁数据服务（§3）和语音呼叫（§4）。

2.3攻击模型和方法

假定的攻击者是移动用户，而受害者可能是网络运营商或/和其他移动用户。对手使用rooted的商用智能手机获得完全的可编程能力。但是，他没有远程访问权限，至少没有特权访问受害者电话。在某些攻击中（例如数据DoS，超额计费和语音DoS），需要一种无特权的恶意软件来监视受害者电话上的基本活动和信息（例如，数据传输何时开始以及网络接口的IP信息）。语音DoS还要求恶意软件生成垃圾邮件流量。在所有情况下，攻击者都无法控制运营商网络。网络不受影响。

为了验证漏洞和攻击，我们在称为OP-I和OP-II1的两家美国顶级运营商中进行了实验。它们合起来占据了近50％的市场份额。我们使用两种支持VoLTE的Android手机型号：分别运行Android 4.4.4和4.4.2的Samsung Galaxy S5和LG G3。请注意，VoLTE仅在少数几种最新型号上起作用，因为它需要对电话硬件和软件进行升级（从2014年开始在美国推出）。有root的和无root的都经过测试。我们将重点放在Android OS上，但我们认为已确定的问题是适用的在与他们共同解决已确定的问题时，我们将其名称隐藏起来以保护两家运营商。可以在任何其他操作系统上使用。除非明确指定，否则结果也适用于两个运营商。

我们谨记一些可行性测试和攻击评估可能对用户或操作员有害。因此，我们通过两种措施负责任的方式进行这项研究。首先，我们仅使用自己的手机作为受害者。其次，在那些对移动用户有利的测试中（例如，免费数据访问），我们进行的实验并未将其真正利用。具体来说，对于每部电话，我们测试的免费数据服务的总量始终少于我们拥有的数据计划的总量。我们试图披露VoLTE的漏洞和有效攻击，但不会加剧损失。我们并不声称这些攻击不是造成破坏的最强大的方法。

3.在语音控制平面中提供移动数据服务

首先发现的问题是VoLTE可以被用来承载移动数据服务，这是其设计者所不希望的。 VoLTE是为支持呼叫而开发的，但不仅限于语音操作。 PS用于在控制平面上交换VoLTE信令消息。但是，它并未针对非VoLTE流量（即正常的PS数据服务）的访问进行加固。我们发现，确实可以欺骗这种方式来维持运营网络中两种形式的“移动到Internet”和“移动到移动”数据访问。更具威胁性的是，可能会滥用VoLTE的计费方案和质量控制来危害LTE网络和用户。在前一种情况下，这种意外的数据访问可以绕开其应有的费用，从而提供免费的数据服务，或导致对受害者的过度收费。在后者中，它不公正地获得了分配给VoLTE信令的最高优先级。可以对其进行进一步处理，以针对普通数据服务进行DoS攻击。

3.1在VoLTE信令中传输数据

尽管VoLTE打算使用PS数据包来承载信令消息，但是从不禁止将PS数据转换为VoLTE（信号）。与保留承载（即IP连接性）的数据服务类似，VoLTE还具有用于其控制面操作的信令承载。如图2a和2b所示，两者都需要首先激活承载并获得LTE网络中的IP连接。之后，一旦任何服务启动，数据包就可以通过该承载传递。设备将源地址设置为4G网关分配的地址，并将目标地址设置为目标主机的地址。对于VoLTE，在任何呼叫请求下，都会通过信令承载在设备和IMS核心之间交换SIP消息。然后，如果呼叫被接受，则按需调用语音承载以进行通话业务。通话结束后，语音承载被释放。

借助分组承载功能，在两个漏洞下通过VoLTE信令承载承载任何数据都是可行的。首先，在设备端，没有访问控制来防止将非VoLTE数据包注入信令承载（V1）。其次，在网络侧，允许这些注入的数据包通过（例如，由4G网关V2路由到目的地）。

V1：手机软件和硬件上缺少访问控制

控制平面上的访问控制是要确保其被真正的VoLTE信号专用。但是，我们发现该设备缺乏对VoLTE控制平面的防弹访问控制。图3显示了移动设备上的当前做法。我们还为CS语音绘制了一个以进行比较。
电话上有两种访问控制选项：基于硬件的软件（即4G / 3G芯片组）和基于软件的软件（即OS和应用程序）。对于CS呼叫，所有信号都在芯片组内处理，绝不会暴露给OS和应用程序。除非硬件受到威胁或开发人员调用特殊的调试模式，否则没有劫持它们的简便方法。相反，VoLTE信令访问暴露给移动OS，在动OS中仅为VoLTE创建了称为VoLTE接口的网络接口。采用软件方法的原因多种多样：VoLTE采用了OS很好支持的Internet协议（IP和SIP）（例如android.net.sip。*库）；该软件方案为操作系统和应用程序提供了高度的灵活性（例如，轻松升级）和丰富的信息，以优化性能。通过设计，只有真正的信号才能通过VoLTE接口并进入基础芯片组。

但是，VoLTE接口尚未针对非授权访问进行加固。其他无特权的应用程序可以轻松获取VoLTE接口信息，就像它们对移动数据接口一样（有关使用IPv6的双接口示例，请参见图4（左））。实际上，可以直接从OS的网络设置中检索信息。例如，在我们的Android手机中，从/ proc / net / if_inet6获得IP地址，并从路由表（/ proc / net / ipv6_route）获得信号发送服务器的IP地址。此外，攻击者可以注入非VoLTE数据包（图3中的红色虚线）。没有root特权的攻击者可以将其目的地指定给任何与VoLTE相关的服务器。给定具有规则的默认路由表，没有特权的应用程序可以将数据包注入VoLTE信令承载，并将此类数据包路由到那些VoLTE服务器。借助根特权，对手可以将路由规则添加到VoLTE接口的任何目的地。因此，他能够通过信令承载将数据包注入到任何目标。

请注意，在本节的经验研究中，我们测试了三种流行的流量类型：UDP，TCP和ICMP。暴露的漏洞可能仅对于某些协议和端口存在。我们使用一种流量类型来说明每个漏洞的可行性。如果未明确指定，则所有其他类型的流量都将具有相似的结果。

实证验证。我们通过以下测试确认了上述漏洞。首先，没有特权的应用程序可以获取VoLTE信令承载（rmnet1）的接口，以及PS数据承载（rmnet0）的接口。我们了解到rmnet1属于VoLTE，因为当启用/禁用VoLTE时rmnet1会出现/消失。图4（左）和图5（左）显示了OP-I中两部手机的快照，这些快照是由Android应用[3] Network Info II捕获的。在两个运营商中，均使用IPv6。两个接口的IP地址都不同。请注意，rmnet0和rmnet1的角色可以互换。我们可以根据路由表来推断它们。分配给默认路由规则的一个用于PS数据服务，另一个用于VoLTE。其次，我们验证非特权应用程序是否能够通过VoLTE接口将非VoLTE流量注入信令承载。该测试工作如下。我们将跳数限制设置为1的UDP数据包发送到VoLTE信令服务器，然后通过VoLTE接口从VoLTE网关接收ICMP数据包。它来自网关，因为此IP地址与服务PS数据服务的IP地址不同。这意味着该UDP数据包确实是通过信令承载从电话之外发送的。

原因和教训。我们进一步研究了为什么电话上的软件和硬件都没有为VoLTE信令承载提供适当的访问控制。通常，OS采用许可控制或使用执行容器来保护网络访问（例如，WiFi）。但是，它不会为VoLTE调用系统权限控制。这可能是因为OS中没有相应的机制将专用于VoLTE的网络接口与用于Internet数据访问的网络接口区分开。从操作系统的角度来看，对两个接口的访问是相同的，而底层芯片组没有任何额外的要求。在硬件方面，当前的做法完全依赖于软件保护，并且始终信任来自软的VoLTE接口的流量。当芯片组打开对OS的访问权限时，缺少保护VoLTE访问的软件和硬件方面的共同努力。

V2：网络中不适当的路由和转发

下一个弱点在于网络侧的路由和数据包转发。它导致两个意想不到的后果。首先，在运行时不验证通过VoLTE信令承载承载的流量。非真实的控制包可以由网络转发。如果没有运行时过滤，则不发往IMS核心中VoLTE服务器的数据包可以通过VoLTE承载进入。

其次，移动网络中的路由规则容易被滥用。 VoLTE电话需要通过VoLTE信令服务器相互交换信令消息。当在4G网关上存在针对信令承载的指向每个电话的路由规则时，电话可以彼此通信而无需到达信令服务器。因此，它可以实现直接的移动到移动通信。同时，这也为非VoLTE移动到移动数据通信打开了大门。可能存在到Internet其余部分的路由规则。这有助于通过VoLTE信令承载进行移动到Internet的数据访问。

实证验证。 VoLTE信令承载可能被误用于执行（i）移动到互联网和（ii）移动到移动数据服务（图2c）。前者仅在OP-I中可行，而后者对两者均适用。

（i）移动到Internet：我们通过VoLTE接口观察电话与外部服务器之间的消息交换。我们首先使用rmnet1来ping谷歌公共DNS服务器（其地址为2001：4860：4860 :: 8888）。图4b显示了通过类似tcpdump的流量嗅探器Shark [4]收集的部分数据包跟踪。前两个SIP消息指示rmnet1接口确实用于VoLTE信令。在电话和Google DNS服务器之间交换的以下ping请求和答复显示，利用VoLTE信令承载来传递正常的数据流量是可行的。入站（下行）和出站（上行）数据传输都是可行的。我们还在移动网络外部部署了IPv6服务器，并重复了测试，并且观察到了相似的结果。

（ii）移动到移动：我们发现可以利用VoLTE直接与属于同一运营商的另一个移动设备进行通信。我们通过其VoLTE和数据服务接口（请参阅图5左侧的两个接口）从一个电话（移动电话1）的VoLTE接口向另一个电话（移动电话2）的另一个电话（移动电话2）发送ICMP回声请求。右图显示了手机1在OP-1中的VoLTE-to-VoLTE和VoLTE-Data情况下都接收到ICMP Echo Reply数据包。这证实了两种形式的移动到移动通信在OP-I中都是可行的。我们发现OP-II仅支持用于移动到移动通信的VoLTE到VoLTE选项，但是仅允许UDP流量而不允许ICMP。这意味着在OP-II的核心网络中实施了更多防御措施，但仍不足以防御VoLTE攻击。

我们还将研究协议变体的可行性。 UDP和ICMP都适用于OP-I而OP-II仅允许使用UDP。稍微的区别是，某些但不是所有UDP端口都可以在OP-I中工作，而几乎所有端口都可以在OP-II中工作。在OP-I中，可行的UDP端口在测试中会有所不同，并且需要进行预扫描。这种差异反映了运营商制定自己的政策和实施的自由。但是，无论如何，两个载波都不允许使用TCP。稍后，我们将证明只要允许至少一种协议通过VoLTE信令穿越核心网络，攻击始终是可行的。任何实际流量（TCP或UDP）都可以封装在ICMP / UDP隧道中。

原因和教训。运营商未正确监管VoLTE信令承载的路由和数据包转发。在网络方面，运营商不对VoLTE实施访问保护，类似于CS语音呼叫和普通PS数据。一旦将此承载分配给VoLTE控制平面，网络就依靠电话转发真实的信令消息（不幸的是，不能保证）。这种谨慎的做法忽略了VoLTE与CS呼叫和普通PS数据的区别（请参阅稍后的V3和V4漏洞利用）。电话中的信令承载所携带的数据包应仅到达VoLTE信令服务器，而不能到达另一部电话或Internet主机，反之亦然。，

3.2利用VoLTE进行免费数据访问

考虑到计费会使意外的数据访问更具威胁性。实践是，数据/语音计费从未考虑过VoLTE信令消息（V3）。如果流量是通过信令承载传递的，则它是免费的。无论流量是否发往信令服务器，这都保持有效。

V3：滥用不计费的VoLTE信令

VoLTE控制信号是免费的。通过VoLTE信令承载的任何数据包都是免费的，无论其目的地是否是VoLTE信令服务器。因此，这种意外的数据传输被视为VoLTE信令，并绕开了常规PS数据访问的计费机制。通常，移动数据访问是根据容量（即已传送的字节数）收费的。

对于运营商而言，免除VoLTE信令交付费用并不奇怪。由于VoLTE继续提供呼叫服务，因此遵循传统CS语音的常规做法很自然地采用基于时间的计费。因此，仅收集数据平面上的呼叫持续时间以进行计费。 VoLTE控制消息用于简化语音通话，并且应该免费。此外，甚至在建立呼叫之前交换一些信号，例如，使用SIP-INVITE，SIP-INVITE-OK，SIP-INVITE-ACK消息来建立呼叫。但是，提供免费VoLTE信令的做法确实存在漏洞。运营商并不强制所有通过VoLTE信令承载的数据包确实都是控制消息。更糟糕的是，没有有效的机制来限制通过它的流量。结果，这很容易被滥用以提供“免费”数据服务。

实证验证。我们首先表明，真正的信令消息（通过rmnet1）是免费的。我们通过尝试拨打许多电话来产生过多的此类消息；每隔15秒，我们就会拨号并立即挂断电话，直到接听电话为止。持续10个小时。我们总共提供42.4 MB的控制消息，但数据账单中不收取任何费用。此外，由没有打通电话，因此不会收取任何分钟的费用。

我们进一步检查绕过服务器的虚假信号仍然免费。我们使用图5中的VoLTE到VoLTE内部案例对其进行测试。在一个实验运行中，我们发送了5000个ICMP Echo请求（每个携带1 KB）并收到4914个ICMP Echo答复；流量约为10 MB（上行链路和下行链路），但不会产生基于卷的计费和基于时间的计费。在其他测试运行中观察到类似的结果。

原因和教训。实践免费的VoLTE信令策略没有错。但是，人们确实有动机利用任何免费的传输。这需要bullet-proof访问控制或无免费策略，或两者兼而有之。与[23]中公开的通过DNS隧道进行的另一种免费数据访问相比，VoLTE信令面临更多挑战。它旨在延续传统的业务模型，而VoLTE计费仅记录数据平面语音的持续时间。 4G网关执行基于卷的数据访问计费，但不记录VoLTE信令承载的使用量。

3.3操纵数据访问优先级

毫不奇怪，利用VoLTE的数据访问可以获得更高的优先级提供QoS。但是，高优先级的快速交付会损害正常的PS数据服务，尤其是在网络拥塞期间。

V4：滥用VoLTE信令的高QoS
VoLTE的一个显着特点是它能够保证语音通话的高质量。表2列出了3GPP标准[7]中指定的相关承载配置。每个承载都与一个QoS标识符类别（QCI）相关联，该类别根据优先级，带宽保证，分组延迟和丢失来定义IP分组的特性。 VoLTE信令承载具有最高优先级（即1），而数据承载（例如web，视频流）具有最低的优先级（即9）。 VoLTE开发的数据访问可以进一步利用先占特权抑制普通PS数据。请注意，两者均属于非保证比特率类别，而QCI = 1的语音承载具有保证比特率（GBR）。 GBR指出，通过确保给定时间段内的平均速率，可以在无线和有线链路上为承载授予专用网络资源，并确保语音质量。稍后在第4.1节中将对此进行利用。

实证验证。我们通过两个比较实验对其进行了验证：（1）在长期的下行链路数据会话（10Mbps）期间，我们启动了另一VoLTE开发的数据访问方式。源速率大于可承受的下行链路吞吐量（30 Mbps），持续时间在15秒到45秒之间（图6a）； （2）我们将正常数据会话的启动顺序交换为VoLTE开发的启动顺序（图6b）。可以看出，利用VoLTE的数据访问具有更高的优先级，从而抑制了具有先占特权的正常访问。当下行链路资源被信令承载捕获时，数据承载吞吐量迅速缩小为零。相反，数据会话不能影响信令承载的吞吐量。它只能获取剩余资源，并且其峰值吞吐量受到限制。

原因和教训。与V3相似，运营商向VoLTE提供更高的QoS似乎没有错。但是，如果没有谨慎的流量过滤，可能会成为攻击者利用VoLTE的诱因。

3.4概念验证攻击

我们设计了三种概念验证攻击：（1）免费数据服务； （2）数据DoS； （3）数据过度收费。它们分别显示在图7的顶部，中间和底部。第一个适用于两个运营商，而后两个仅适用于OP-I。所有这些都易于启动，并且也具有破坏性。请注意，最后两次攻击不需要受害者具有root特权。

免费数据攻击。显然，可以利用上述漏洞来获得免费的外部（移动到Internet）和内部（移动到移动）数据访问。请注意，免费的外部服务仅适用于OP-I，但免费的内部服务对于这两者都是可行的。以OP-I为例。攻击的工作方式如下。由于始终允许4G网关将ICMP数据包转发到Internet或其他移动电话，因此该广告商利用ICMP隧道来通过信号承载传递数据。使用原始套接字将每个数据包封装为ICMP包。此外，路由表需要使用指定目的地的路由规则进行更新，因此可以通过信令承载将ICMP数据包发送到目的地。这两个操作只能在有根电话上执行。在外部情况下，我们在移动网络之外部署隧道服务器以运行ICMP隧道。在内部情况下，ICMP隧道位于两个VoLTE手机之间。

在这两种情况下，我们都使用各种流量来源速率（最高16 Mbps）和执行时间（最高10小时）进行测试。图8显示，在外部和内部情况下，免费数据服务的容量，吞吐量和持续时间都没有限制的迹象。在测试运行中，可以免费观察到450MB。

数据DoS攻击。该攻击旨在通过利用VoLTE开发的数据传输带来的更高优先级访问来关闭受害方正在进行的数据服务。攻击者通过其信令承载向受害电话的信令承载注入垃圾邮件流量。它可以抢占受害者数据服务的所有下行链路带宽，从而导致数据DoS。请注意，攻击者和受害者无需为此垃圾邮件流量付费，该流量由信令承载者承担。

这就需要在受害设备上使用无特权的恶意软件，该恶意软件可以检测是否有任何数据服务启动，类似于非路径TCP劫持攻击[27，28]。一旦受害者启动任何数据服务，该恶意软件将向攻击者服务器或攻击电话发送消息，从而泄漏VoLTE接口的IP地址。之后，攻击者开始向该IP注入高速垃圾邮件数据。在高峰时间的情况下（例如，在校园餐厅的上午11点至下午1点），可以发现在10Mbps VoLTE开发的流量下，数据承载吞吐量可以被限制为零。请注意，数据DoS所需的VoLTE开发流的量随受害者所在的网络的流量负载而变化。

收费过高的攻击。攻击者可以通过将来自其信令承载的数据注入到受害电话的数据服务承载中，使受害人承受过多的超额费用。与上述DoS攻击只有一个区别。 DoS攻击会将数据发送到受害者电话的信令承载。选择的受害者是目标用户或随机选择的单个电话用户。根据受害者的IP地址，我们发现，未经受害者同意，垃圾邮件可能会发生。可以从网络钓鱼网站或无特权的恶意软件中获取IP地址。与其他垃圾邮件攻击相比[18,23,24]，该威胁很容易绕过防火墙和安全箱。这是因为它们总是部署在移动网络的边界，以防止来自Internet的恶意流量。但是，由VoLTE引起的垃圾邮件纯粹是依靠内部流量而没有到达Internet。在OP-I中的一次运行中，多收的容量达到449 MB，仍然没有显示出任何限制的迹象。

3.5对真实应用的攻击

我们还将针对移动应用程序的免费移动到Internet数据服务和数据DoS的两种攻击应用于实际应用。对于前者，我们免费使用Skype服务和移动网络上的ICMP隧道。后者迫使网络浏览器和Youtube在受害者的电话上中止。请注意，这两种攻击仅对OP-1是可行的。

通过移动网络的免费Skype服务我们在电话和外部服务器之间建立了一个ICMP隧道，以利用由VoLTE开发的免费数据服务。如图9所示，我们在移动网络外部部署了隧道服务器。它位于电话与应用程序服务器或其他通信主机之间。在电话上，我们创建一个虚拟接口并修改路由表以实现两个目的。首先，将其设置为应用程序的默认接口，以便将所有应用程序的数据包转发到该接口。其次，来自接口的所有数据包都重定向到我们的隧道服务器。服务器进行封装​​/解封装，并且数据包为电话中继。因此，不需要修改应用服务器或其他通信主机。

然后，我们在其之上运行Skype应用程序。我们显示，通过移动网络具有ICMP隧道的恶意用户可以与另一个Skype用户进行10分钟的聊天。此外，在此时间段内消耗的数据量是免费的。请注意，利用ICMP隧道的优势，其他应用程序也可以通过移动网络免费使用。

Web浏览器和Youtube上的Data DoS我们在受害者通过Web浏览器加载CNN网页或观看Youtube时，在受害者的电话上启动Data DoS。当手机处于高峰时段时，我们会向其发送10Mbps VoLTE利用的垃圾邮件流。可以看到，如图10a和10b所示，CNN浏览和Youtube观看都被迫中止。

4.通过语音数据平面中的垃圾邮件静音

我们将进一步研究VoLTE数据平面上的不安全性，以及与控制平面之间的协调性。我们发现，与控制平面上的数据平面相比，无论采用哪种机制来保护机密语音会话信息，数据平面都没有得到很好的保护。不需要生根或越狱电话的无特权应用程序可以将非语音垃圾注入语音承载。此外，私人信息可能从语音QoS的指定方案和协调失效中泄漏。通过利它们，我们设计了一种新颖的语音DoS攻击，可以通过它发起VoLTE呼叫，但是其语音被静音（即，呼叫者和被叫者无法互相听到）。

4.1将数据包注入语音承载

在数据平面操作中，语音承载是根据任何呼叫请求按需构建的，然后在呼叫结束后释放。考虑到PS的性质，它也容易受到非语音数据包的注入。但是，与信令承载相比，语音承载通过两个固有的保护机制显得更安全。首先，语音数据包由硬件（芯片组）处理，而无需软件干预。如图3所示，它们的有效负载必须由芯片组（例如，Qualcomm Snapdragon处理器）中的IMS（VoLTE）堆栈进行编码或解码，而无需到达移动操作系统。因此，如果没有硬件攻击，移动操作系统上方的任何应用都不太可能通过语音承载传递有效数据。其次，每个RTP会话标识符（即，目标IP以及用于RTP和RTCP的一对端口）都被保护为机密，不会暴露给操作系统。此信息在信令消息中加密，并随每个呼叫而变化。广告商很难获得会话ID并伪造数据包头（带有正确的会话ID）。

但是，经过全面分析，我们发现当前防御仍然不足以保护数据平面。通过语音承载传递无效的数据包（垃圾数据）很容易，尽管它无法传递有效的数据包。我们在数据平面中揭露了两个漏洞。首先，VoLTE数据平面访问控制存在问题（V5），因此尽管传递的字节不受应用程序控制，但仍可以将数据注入语音承载。第二，可以从其重要特征（其QoS配置的保证比特率）推断出机密的VoLTE数据平面会话信息，从而使其受到恶意攻击（V6）。

V5：手机据访问权限不足

数据平面也没有足够的访问控制。与控制平面相比，它会在硬件中生成所有语音数据包。具体地说，如图3所示，在芯片组内实现了将模拟语音信号转换为数字编码字节的语音编解码器。但是，看似安全的硬件保护机制仍然不够。它永远不会只限制对真实VoLTE呼叫的访问（即系统级拨号器应用程序）。相反，它接受其他应用程序注入的流量，即使这些应用程序获得了正确的会话信息，即使是那些非特权应用程序也是如此。值得注意的是，如果注入的流量超过了最大语音承载流量的最大比特率（MBR）（例如数十kbps），则语音承载的硬件缓冲区可能会溢出。因此，可能会丢弃真正的语音数据包，从而降低语音质量。

实证验证。我们确认，没有root特权的应用程序可以将高速流量注入语音承载。我们在被呼叫方正在进行的呼叫过程中运行此应用程序，并以10 Mbps的速率生成包含正在进行呼叫的语音RTP会话标识符（即目标IP和RTP / RTCP端口）的数据包，然后通过VoLTE接口发送它们。我们将在V6和V7中公开如何精确确定语音RTP会话标识符。我们进行了20次测试，并不断观察到被叫方的语音在呼叫者处被静音（即，被叫方没有声音）。这意味着由非特权应用创建的数据包已成功注入到语音承载中，并且注入的流量确实在被叫方溢出了语音承载的上行链路缓冲区，大多数语音包都被丢弃了。

原因和教训。当前的两种防御措施仍然配备不足，无法验证语音流量的来源。第一个防护措施来自VoLTE通用操作，数据计划遵循传统设计（即CS语音）。语音流量由硬件中的特定编解码器进行编码/解码，因此不需要软件干预。它从本质上防止了非VoLTE应用滥用语音承载。但是，它只是减少了劫持的可能性，但却无法避免劫持。第二种防御依赖于RTP会话ID的保密性。两者都不检查流量是否来自真实的VoLTE应用。硬件允许从OS进行语音传输，但仍允许来自非VoLTE应用的流量。

V6：会话隐私的旁通道泄漏

每个RTP会话的ID被视为会话秘密[26]。它由VoLTE应用程序的信令消息携带，并且可以进一步加密。如果没有root特权，其他未特权的应用程序将无法捕获信令，从而无法获知会话ID。图11显示了SIP消息中会话ID的示例。注意，我们通过根据方法[2]对来自OP-1的加密的SIP消息进行解密来获得它。请注意，解密需要root特权。

但是，我们提出了一种在没有root特权或调用操作权限的情况下通过辅助通道提示获取ID的方法。它包含两个部分。首先，可以很容易地从路由表中检索目标IP地址（即媒体网关的IP）。第二，由于其保证的比特率QoS方案，可以从唯一的模式推断RTP和RTCP端口号。具体地，该标准规定，无论是否将服务最高优先级信令承载上的分组，都应以最小速率（例如，8 KB / s）保证语音承载。

此外，VoLTE信令和语音承载使用分配给VoLTE接口的相同IP，并且基于这两个承载的相应端口来区分这两个承载的分组。也就是说，只有具有会话ID的RTP和RTCP端口的数包才传递到语音承载，而其他数据包则传递给信令承载。因此，可以通过扫描所有端口（通过一个端口发送一个数据包）来学习会话端口。在向信令承载注入大量流量的情况下，语音承载上的流量将具有更小的延迟，因为它们已经保证了资源。实际上，两个延迟最小的端口应该是RTP和RTCP使用的端口。

实证验证。我们仅关注上行链路RTP会话的目标端口（即RTP和RTCP端口），因为可以如第3.1节中所述获得目标IP。

在正在进行的调用过程中，没有root特权的应用程序执行两项操作。首先，它通过发送一个数据包来扫描每个端口。其次，为了使信令承载不堪重负，它不断向某些端口（例如80）发送某些肯定不是用于RTP和RTCP的数据包。我们考虑每个端口的单跳RTT，在该端口上，我们将UDP数据包的“跳数限制”设置为1，并接收到ICMP响应。基于UDP报文的发送时间和ICMP响应的接收时间之间的时间差来计算单跳RTT。图12a绘制了一次测试运行中的感知延迟。具有两个目标端口64580和64581的数据包具有39 ms的最小延迟，而其他端口则具有较大的延迟（> 90ms）。这些端口与从解密的SIP消息中公开的端口匹配。图12b显示了始终观察到的RTP / RTCP端口与其他端口之间的延迟间隔，在20个测试中至少有50 ms。因此，推断RTP端口号是可行的，尽管它们在每次运行中都会有所不同。

原因和教训。有两个因素可能会侵犯会话隐私。首先，基于专有规则从VoLTE接口调度信令和语音数据包，其中，将具有语音会话ID的信令和语音数据包传递给语音承载，将其他语音信号传递给信号承载。其次，语音承载的资源预留不受信令承载的影响。该辅助信息有助于区分两个承载。因此，QoS对性能有利，但对隐私不利。

4.2平面间协调泄漏

我们进一步揭示了控制平面和数据平面之间在协调方面的另一个弱点。这使得泄漏语音会话ID更容易。

V7：协调不当导致侧通道泄漏

会话ID也可能由于平面之间的不适当协调而泄漏。它可以在呼叫建立和呼叫终止期间获得。在这两个阶段，一旦在控制平面上接到某些信号，就建立并释放数据平面上的语音承载。如果未按正确的时序调用操作，则语音数据包可能会错误地传递到控制平面。

我们首先看到，如果未及时建立语音承载，则来自媒体网关的一些初始语音数据包将被转发到控制平面。这是因为在创建语音承载之前，4G网关只有一个针对VoLTE IP的转发规则（即去往/来自信令承载）。例如，在应答呼叫之前，应将某些初始语音数据包（例如警报音和早期媒体（例如，CallerTune））传递到电话。 IMS核心中的媒体网关确实有这样做的理由。这是大多数运营商提供的语音功能。

通话挂断后，我们还从控制面板界面观察到一些VoLTE语音数据包。事实证明，信号服务器由两个单独的组件组成，即代理服务器和服务服务器。前者负责在4G网关处建立/释放语音承载，而后者则负责管理媒体网关处的语音传输开始/停止。但是，它们之间没有明确的协调程序。相反，隐式协调是通过传递它们的信令消息来激活的。当电话终止呼叫时，它将发送SIP BYE消息。该消息首先到达代理服务器，然后转发到服务服务器。通过此序列，前者在后者停止传送语音分组之前释放语音承载。结果，由于没有语音承载，到达4G网关的语音包必须转发到VoLTE信令承载。语音数据包转发到信令载体后，便到达电话的VoLTE接口。一旦被非VoLTE应用捕获，它们就会泄漏会话ID。

实证验证。图13显示了通过Shark从移动设备上的VoLTE信令接口收集的IP数据包[4]。当用户拨出或挂断电话时，会捕获一些VoLTE语音数据包（此处为UDP）。我们进一步开发了一个无特权的应用程序来捕获这些早期数据包。该应用程序绑定到语音RTP会话使用的VoLTE IP地址和UDP源端口。可以推断出UDP源端口。两家运营商都有一条简单的选择规则。对于OP-I，它从启动后的数字1234开始，然后对于每个呼叫单调增加10。对于OP-II，端口始终为49158。我们在进行VoLTE呼叫之前启动此应用程序。在呼叫建立和终止阶段，它会收到一些UDP数据包。我们确认它们确实属于正在进行的呼叫的RTP会话。

原因和教训。 VoLTE需要通过在移动网络中采用IMS进行实质性升级。它招致了复杂的操作，可将其用于意外目的。

4.3语音静音DoS攻击

我们发起攻击以迫使呼叫静音，而不是取消呼叫服务。在这种攻击下，受害者始终可以建立呼叫，但是呼叫应答后，双方都无法听到对方的声音。这需要在受害者电话中没有root权限或语音呼叫权限的恶意软件。请注意，该恶意软件可以嵌入网络应用程序中。在正在进行的通话中，有两个主要步骤来发起此攻击。第一步是尽快学习RTP会话的端口。我们利用V6和/或V7来做到这一点。利用V6需要扫描许多端口。但是，没有root特权，网络套接字将仅返回ICMP息的错误类型，而不返回其内容。因此，我们无法检索与套接字内每个收到的ICMP消息相对应的扫描端口。因此，我们进行基于组的搜索。我们将端口聚合为许多小组，并比较每组中最小的延迟。然后，我们以最小的延迟扫描组中的每个端口以找到RTP端口。可以在我们的测试手机中在20秒内完成。通过提供一种更快的会话隐私探测方法，V7可以轻松加重语音静音攻击的危害。可以从初始语音数据包中直接学习会话ID，而无需花费时间来搜索会话ID。

在第二步，恶意软件开始通过注入具有正确会话ID的伪造RTP数据包来劫持语音承载。即使它们仅用于上行链路流量，它们也可以使上行链路和下行链路语音静音。这是因为RTP数据包的上行链路业务会超载一种硬件组件，即鲁棒报头压缩（RoHC），这是VoLTE对语音数据包（解压缩）的要求[5]。图14显示了利用V7时的汇总语音突变攻击的一次运行。应答呼叫后，恶意软件会在第8秒开始发起DoS攻击，并在第31秒停止。在攻击期间，呼叫者和被呼叫者的声音大部分时间都保持沉默。 ID泄漏后，此攻击将一直有效直到呼叫结束。无论恶意软件在呼叫方还是被呼叫方，该攻击都有效。

5.推荐的修复

提议的防御措施涵盖了网络和设备。网络端解决方案具有三种措施。请注意，运营商几乎不会控制设备，并且更有动力解决这些问题。

首先，4G网关对每个承载实施严格的路由法规。这是为了强制信号/语音承载所承载的流量仅由4G网关在电话和IMS核心中的信令服务器或媒体网关之间中继。消除了V2。由于设备上被劫持的控制平面访问无法到达任何目的地，因此修复V1变得更加紧迫。但是，如果不修复V1，它仍然容易受到数据DoS攻击，因为在网关丢弃这些数据包之前可能会浪费宝贵的无线电资源。这需要升级4G网关，并且可以通过添加VoLTE承载过滤器来完成。将所有有效服务器添加到白名单时，可能需要额外的精力。

其次，运营商停止实行免费信令政策，并对类似于数据流量的信号收费。这消除了V3，也大大降低了用户鼓励使用VoLTE进行数据访问的动机。但是，这需要升级计费系统。 4G网关还应启用其对信令数据包的计费。主要挑战不是技术方面，而是业务实践。它要求每个用户都拥有一个数据计划。如今，语音计划独立于数据计划。在LTE网络中，让每个用户订阅用于Internet访问的数据计划似乎是合理的。补充解决方案是为每个语音计划启用VoLTE数据量配额。当音量低于此配额时，不会产生任何额外费用。此配额基于每个呼叫的信令量通常较小时的常用情况。这种方法不需要用户意识到良性情况下的计费变化，但是可以识别出滥用VoLTE进行大量传输，并为此收取了额外费用。

第三，关于DoS攻击，它要求一种新的机制来确保仅将资源分配给真实流量。天真的解决方案是放弃VoLTE的高优先级QoS。但是，它实质上破坏了VoLTE的吸引力。一种替代方法是强制执行延迟机制。一旦检测到流量为伪流量或垃圾流量，便会对该流进行统计，如果流量超过特定阈值，则将追溯到源。在运行时，每当请求的资源大于配额时，其优先级就会降低。此方案可以缓解但不能消除先验资源浪费。理想情况下，应在设备上实施防护措施，以防止发送非真实流量。但是，如果在受害者身上部署了恶意软件，则这可能会通过利用延迟机制来引发一种新形式的阻止访问。

在设备方面，我们建议两种补救措施。首先，移动操作系统应建立VoLTE权限，该权限仅允许拨号器应用程序访问VoLTE界面。恶意软件不应轻易获取私人信息。但是，对于root手机，可能会绕过此保护。其次，芯片组执行严格的访问控制。对于来自OS的流量，它需要验证流量源和目的地以及会话端口号（如果适用）。这可以解决大多数常见设置中的问题，但是当在root手机上存在特权的恶意软件时，无法消除语音突变攻击。后一种情况要求防御移动恶意软件，这是对上述防护措施的补充。请注意，基于设备的解决方案确实有帮助，但还不够。在某些旧设备或受损设备的情况下，仍然需要基于网络的解决方案。

请注意，基本问题在于PS服务，并且不能通过上述修复完全解决。长期的解决方案要求共同努力，以语音专用策略（例如，资源消耗和计费）为给定形式的PS服务设计安全防御。我们的短期解决方案旨在允许VoLTE仅提供真实语音。这是为了确保与当前实践的向后兼容性。随着VoLTE（例如，高清视频会议）支持更多服务，它可能不再是最佳选择。但是，该规则仍然适用：当作为PS数据使用时，应将其视为PS数据。保持整洁一致的政策有助于消除不必要的漏洞。

6.讨论

接下来，我们要澄清几个剩余的问题。

早期部署中的错误？顽固的乐观主义者可能会说，所揭示的问题是部署初期的实现错误。随着部署的进行，它们很可能会很快修复。实际上，事实证明，我们展示的漏洞并不难解决。但是，大多数都植根于VoLTE技术本身，而不是运营商的特定配置错误。例如，自由数据攻击和语音突变攻击在这两种运营商中都是可行的。它们也不是简单的错误，因为漏洞发生的位置并不等同于负面影响的发生位置：设备端漏洞（例如V1）导致网络端收入损失，而网络端漏洞（例如V2）和V7）使移动设备遭受过度充电和语音静音攻击。要发现这些漏洞，需要对移动设备和网络都有共同的了解。因此，到目前为止，顶级运营商很大程度上都忽略了它们，并使部署的网络容易受到这些攻击，这并不奇怪。我们与此类运营商的持续互动表明，即使有一些实施和操作故障，他们也没有意识到此类漏洞。更深层的原因是，VoLTE彻底改变了移动运营商中的传统语音服务，并且仍然缺少对4G系统安全性影响的完整理解。由于美国运营商是全球市场的领导者，因此从其早期部署中吸取的教训对于未来安全VoLTE技术的兴起至关重要。

不完全过渡的症状？这些问题也可以归因于从老式的移动网络思维到互联网风格思维的不完全过渡。自从早期的基于CS的网络以来，前者已被用来控制所有移动设备。相反，后者不考虑对设备的控制，每个设备都可能是恶意的。由于移动网络采用了互联网技术（例如，IP），因此它赋予了移动设备更多自由，并逐渐减少了对它们的控制。但是，它的基本设计和操作不是完全遵循Internet的思维方式来开发的。这种方式可能导致移动网络缺乏针对恶意移动设备的保护。

骂运营商？尽管LTE运营商和用户遭受了这些攻击，但我们的立场应被误解为网络运营商（两个用户）的直接责任。实际上，各方都对威胁做出了贡献。将语音从CS重塑到PS保证了各方的实质性升级，包括设备OS和应用开发商，移动芯片组供应商，网络设备制造商和运营商。设备操作系统，芯片组和网络设备的开发人员和供应商应共同承担责任，而不必及时升级其访问（权限）控制。它们共同暴露了用于VoLTE和普通数据的两个IP接口的漏洞。如果没有整体了解VoLTE的工作原理，各方都会对近距离威胁采取近视方法。

激励措施。到目前为止，我们的重点是漏洞，而不是攻击动机。对于某些攻击（例如免费数据访问），人们总是被激励去利用漏洞。对于其他攻击（例如DoS），阻止某人访问语音或数据可能是出于娱乐或个人利益。

7.更新

我们正在与业界合作，以解决已发现的问题。我们已经将主要风险告知了主要的芯片组供应商，并将就VoLTE访问控制漏洞与更多的供应商（包括操作系统和网络设备供应商）进行联系。我们还与两家运营商联系，以报告并帮助修复此类漏洞。到目前为止，由于不允许通过VoLTE接口的数据包穿越OP-I运营商网络，所有与数据相关的攻击（包括免费数据攻击，超额计费，抢先数据和数据DoS攻击）都已得到修复。核心网络。语音DoS攻击的修复以及其他运营商中的问题仍在继续。

8.相关工作

几项研究探索了组件解决方案的安全性含义：IMS [22]，SIP [31,36]和VoIP [17,19,38]。 Park等。为威胁建模并分析IMS部署的可能问题[22]。其他研究[17、19、31、38]在没有解决移动网络问题的情况下，在Internet上下文中检查了SIP和VoIP。他们着重于呼叫者ID欺骗或SIP消息欺骗，以发起DoS / DDoS攻击。最近的报告（例如[1]）研究了VoLTE安全性，但仅限于先前研究解决的问题（例如，呼叫方ID欺骗）。我们最近的工作揭示了另一种语音DoS攻击，但它是通过对VoLTE中的信令消息进行细粒度操作而发起的[36]。此外，大多数VoLTE研究都集中在其性能分析或部署计划制定上[20,21,37]。我们的研究不同于所有现有技术。据我们所知，这是有关运营网络上VoLTE安全性的首次研究。我们的工作涵盖安全性分析和现实世界的影响，而早期发现是通过安全性分析或在受控环境中进行的有限实验获得的。更重要的是，本文中讨论的漏洞和攻击从未公开过。

近年来，移动网络安全一直是活跃的研究领域。 Peng等。和Go等。找出移动数据收费中的漏洞，并设计免费的数据访问和收费过度攻击[18，23–25，35]。 Enck和Traynor等人。通过超载SMS和其他服务的控制信道来设计DoS攻击[15、32、33]。研究人员还揭示了其他特定于蜂窝的组件中的漏洞，例如用户身份验证漏洞[11，12]，MMS垃圾邮件[29]防火墙处的信息泄漏[27,28]和T-Mobile中的WiFi呼叫漏洞[13]。 ，仅举几例。自从我们研究VoLTE（4G LTE网络的新兴语音服务）以来，我们的工作有所不同。移动恶意软件是另一个广为人知的话题（有关示例，请参见[14，39]）。我们的DoS攻击需要未经root许可的恶意软件，我们将恶意软件感染作为一个独立的主题[16，34]。

9.结论

VoLTE仍处于全球推广的初期阶段。在此期间，很容易出现易于修复的错误。但是，我们寻求除简单的错误和错误以外的基本问题。秉承基于电信的设计思想，VoLTE要求在基础架构方面进行实质性升级（核心功能复杂），并进行设备更新。在这项工作中，我们研究了VoLTE的安全隐患。我们表明，可以利用VoLTE对网络运营商（从而使移动用户受益）和单个用户发起攻击。用户可以通过滥用VoLTE信令承载来承载数据包，从而获得免费的高优先级数据访问。由于语音/信号承载者的垃圾邮件，他还可能遭受语音/数据DoS攻击。从我们的工作中可以学到两个教训。首先，VoLTE在控制平面和数据平面上均进行操作。其信令和数据在设备上的软件和硬件中均实现，并由LTE中的独特无线电承载承载。因此，为了确保两个平面的安全，该解决方案要求网络基础架构与终端主机以及设备上的软件和硬件之间共同努力。其次，VoLTE利用移动网络中的高优先级服务（与低优先级，尽力而为的传输相比）来确保高质量的呼叫。由LTE网络补充的优先级服务可以用作隐式辅助信道，以泄漏机密信息。随着语音解决方案与Internet设计兼容，谨慎地在设备和网络上添加更多智能，以解决PS和IP的双重边缘，安全性副作用。

致谢

我们要感谢匿名审稿人的宝贵意见。 这项工作得到了美国国家科学基金会的部分资助，资助号为CNS-1421933和CNS-1422835，以及IBM博士奖学金（关冠华）。 本材料中表达的观点，发现和建议仅是作者的观点，并不一定反映国家科学基金会的观点。

1. REFERENCES
   [1] “2014: A VoLTE Security Nightmare?”. http://tinyurl.com/p4rpm52.
   [2] Decypt ISPEC packets. http://tinyurl.com/ptzurve.
   [3] Network info ii. http://tinyurl.com/baa6jtu.
   [4] Shark for Root. http://tinyurl.com/n7e9ubz.
   [5] Voice over LTE. http://www.gsma.com/technicalprojects/volte.
   [6] RFC 3550: RTP: A Transport Protocol for Real-Time Applications, Jul 2003.
   [7] 3GPP. TS23.203: Policy and Charging Control Architecture, 2013.
   [8] 3GPP. TS23.107:Quality of Service concept and architecture, 2014.
   [9] 3GPP. TS23.228: IP Multimedia Subsystem (IMS);Stage 2, 2014.
   [10] 3GPP. TS36.321:E-UTRA; Medium Access Control (MAC) protocol specification, Jan 2015.
   [11] M. Arapinis, L. Mancini, E. Ritter, M. Ryan, N. Golde, K. Redon, and R. Borgaonkar. New Privacy Issues in Mobile Telephony: Fix and Verification. In ACM CCS, 2012.
   [12] M. Arapinis, L. I. Mancini, E. Ritter, and M. Ryan. Privacy through pseudonymity in mobile telephony systems. In NDSS, 2014.
   [13] J. Beekman and C. Thompson. Man-in-the-middle attack on t-mobile wi-fi calling. Technical Report UCB/EECS-2013-18, EECS Department, University of California, Berkeley, Mar 2013.
   [14] S. Chakradeo, B. Reaves, P. Traynor, and W. Enck. MAST: Triage for Market-scale Mobile Malware Analysis. In WiSec, 2013.
   [15] W. Enck, P. Traynor, P. McDaniel, and T. La Porta. Exploiting Open Functionality in SMS-Capable Cellular Networks. In CCS, 2005.
   [16] C. Fleizach, M. Liljenstam, P. Johansson, G. M. Voelker, and A. Mehes. Can you infect me now?: malware propagation in mobile phone networks. In ACM workshop on Recurring malcode, 2007.
   [17] C. Fuchs, N. Aschenbruck, F. Leder, and P. Martini. Detecting VoIP based DoS Attacks at the Public Safety Answering Point. In ACM ASIACCS, 2008.
   [18] Y. Go, J. Won, D. F. Kune, E. Jeong, Y. Kim, and K. Park. Gaining Control of Cellular Traffic Accounting by Spurious TCP Retransmission. In NDSS, February 2014.
   [19] A. D. Keromytis. A Look at VoIP Vulnerabilities. Login, 1:41–50, 2010.
   [20] A. P. S. Louvros and A. Gkioni. Voice Over LTE (VoLTE): Service Implementation and Cell Planning Perspective. In System-Level Design Methodologies for Telecommunication, pages 43–62. Springer, 2014.
   [21] N. S. Networks. From Voice over IP to Voice over LTE, 2013. http://tinyurl.com/q79vyu6.
   [22] F. S. Park, D. Patnaik, C. Amrutkar, and M. T. Hunter. A Security Evaluation of IMS Deployments. In IEEE IMSAA, 2008.
   [23] C. Peng, C. Li, G. Tu, S. Lu, and L. Zhang. Mobile Data Charging: New Attacks and Countermeasures. In CCS, Oct. 2012.
   [24] C. Peng, C.-Y. Li, H. Wang, G.-H. Tu, , and S. Lu. Real Threats to Your Mobile Data Bills. In ACM CCS, Nov 2014.
   [25] C. Peng, G. Tu, C. Li, and S. Lu. Can We Pay for What We Get in 3G Data Access? In MobiCom, Aug. 2012.
   [26] J. Peterson. RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP), 2002.
   [27] Z. Qian and Z. M. Mao. Off-Path TCP Sequence Number Inference Attack-How Firewall Middleboxes Reduce Security. In S&P, 2012.
   [28] Z. Qian, Z. M. Mao, and Y. Xie. Collaborative TCP Sequence Number Inference Attack: How to Crack Sequence Number under a Second. In ACM CCS, 2012.
   [29] R. Racic, D. Ma, and H. Chen. Exploiting MMS vulnerabilities to stealthily exhaust mobile phone’s battery. In SecureComm, 2006.
   [30] RFC3261: SIP: Session Initiation Protocol, June 2002.
   [31] D. Sisalem, J. Floroiu, J. Kuthan, U. Abend, and H. Schulzrinne. SIP security. John Wiley & Sons, 2009.
   [32] P. Traynor, W. Enck, P. McDaniel, and T. L. Porta. Exploiting open functionality in sms-capable cellular networks. Journal of Computer
   Security, 16:713–742, 2008.
   [33] P. Traynor, P. McDaniel, and T. La Porta. On Attack Causality in Internet-Connected Cellular Networks. In USENIX Security, 2007.
   [34] H. T. T. Truong, E. Lagerspetz, P. Nurmi, A. J. Oliner, S. Tarkoma, N. Asokan, and S. Bhattacharya. The company you keep: Mobile
   malware infection rates and inexpensive risk indicators. In WWW’14.
   [35] G. Tu, C. Peng, C. Li, X. Ma, H. Wang, T. Wang, and S. Lu. Accounting for roaming users on mobile data access: Issues and root
   causes. In MobiSys, Jun. 2013.
   [36] G.-H. Tu, C.-Y. Li, C. Peng, and S. Lu. How Voice Call Technology Poses Security Threats in 4G LTE Networks. In IEEE Conference on
   Communications and Network Security (CNS), September 2015.
   [37] L. L. Ying and S. W. Yuan. Forward handover for voice call continuity. In NGMAST, September 2012.
   [38] R. Zhang, X. Wang, R. Farley, X. Yang, and X. Jiang. On the Feasibility of Launching the Man-In-The-Middle Attacks on VoIP
   from Remote Attackers. In ACM ASIACCS, 2009.
   [39] Y. Zhou and X. Jiang. Dissecting Android Malware: Characterization and Evolution. In IEEE S&P, 2012.