收听加密的VoIP通信

VoIP电话在传统的铜线电话系统中正在逐渐普及,因为它以较低的部署成本提供了更高的吞吐量。 2013年,VoIP用户数超过1.5亿 ,这本身就很多。 而在2017年,这一数字接近10亿 。 但是VoIP通话的隐私又如何呢? VoIP软件中使用的端到端加密是否能够提供相同的隐私? 在斯诺登(Snowden )的事迹曝光后,此类问题变得尤为热门。斯诺登向世界介绍了整个窃听活动,这是由诸如NSA(国家安全局)和CPS(政府通信中心)之类的政府情报机构使用间谍软件PRISM和BULLRUN进行的,该侦听程序监听加密的对话


-攻击者可以从加密的音频流中提取的内容
-通过旁路通道攻击VoIP
-关于DTW算法的几句话
-HMM机器的操作原理
-PHMM机器的工作原理
-从理论到实践:对对话语言的认可
-收听Skype的加密音频流
-如果您关闭了VBR模式?



PRISM,BULLRUN和其他类似软件如何从加密通道传输的语音流中提取信息? 为了理解此问题的答案,您必须首先了解VoIP中语音流量的传输方式。 VoIP系统中的数据通道通常是通过UDP协议实现的,并且通常使用SRTP协议(安全实时传输协议;实时安全数据传输协议)来工作,该协议支持打包(通过音频编解码器)和音频流加密。 在这种情况下,在输出处接收到的加密流的大小与输入音频流的大小相同。 如下所示,这种看似微不足道的信息泄漏可用于侦听“加密的” VoIP对话



攻击者可以从加密的音频流中提取什么


VoIP系统中使用的大多数音频编解码器基于CELP算法 (代码激励线性预测;代码线性预测),其功能模块如图1所示。为了实现更高的音质,而又不增加负载对于每个数据通道,VoIP软件通常在VBR模式下使用音频编解码器(可变比特率;可变比特率的音频流)。 例如,通过此原理,Speex音频编解码器可以工作。



图1. CELP算法的功能块


从保密性上讲,这会导致什么? 一个简单的例子。Speex在VBR模式下工作,它发出的嘶嘶声辅音的比特率低于元音。 而且,甚至某些元音和辅音也以特定的比特率打包在一起(见图2.a)。 图2.b中的图表显示了数据包长度的分布-对于带有嘶嘶声的短语:“速滑运动员冲刺到终点”。 图的深处凹陷恰好落在该短语的嘶嘶声片段上。 图2.c 显示了输入音频流动态,比特率和输出(加密)数据包的大小-叠加在一个通用的时间尺度上; 第二张和第三张图具有惊人的相似性-可以用肉眼看到。



图2.嘶嘶声如何影响数据包大小


另外,如果您通过数字信号处理(在语音识别任务中使用)的数学设备(例如PHMM机器 (配置文件隐藏的马尔可夫模型;隐藏的马尔可夫模型的扩展版本))来观察图2,那么您将看到的不仅仅是简单的元音和辅音之间的差异。 包括 ,确定说话者的性别,年龄,语言和情感。



绕过VoIP攻击


PHMM机器在处理数字链,相互比较以及找到它们之间的模式方面做得非常好。 这就是为什么PHMM机广泛用于解决语音识别问题的原因。


PHMM机器在侦听加密音频流的任务中也很有用。 但不是直接,而是通过旁路。 换句话说,PHMM机器无法直接回答以下问题:“在此加密音频数据包链中有什么短语?”,但是它可以准确地回答以下问题:“这样的短语是否包含在这样的地方?是加密的音频流?”


T.O. PHMM机器只能识别最初训练过的短语。 但是,现代深度学习技术是如此强大,以至于它们能够将PHMM机器训练到一定程度,从而消除了上面刚才提到的两个问题之间的界限。 要欣赏这种方法的全部功能,您需要稍微深入研究一下装备。



关于DTW算法的几句话


直到最近,DTW算法(动态时间扭曲;时间轴的动态转换)已广泛用于解决说话人识别和语音识别的问题。 他能够找到根据相同定律生成的两个数字链之间的相似性,即使这些链以不同的速度生成并且位于时间尺度上的不同位置时也是如此。 这正是对音频流进行数字化处理时发生的事情:例如,说话者可以说出具有相同口音的相同词组,但同时又会因背景噪声不同而变快或变慢。 但这不会阻止DTW算法在第一选项和第二选项之间找到相似之处。 为了举例说明这一点,请考虑两个整数链:


0 0 0 4 7 14 26 23 8 3 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 6 13 25 24 9 4 2 0 0 0 0 0


如果我们“在额头上”比较这两条链,那么它们似乎彼此非常不同。 但是,如果我们比较它们的特性,我们会发现这些链肯定有一些相似之处:它们都由8个整数组成; 两者都有相似的峰值(25-26)。 从它们的切入点开始的“正面”比较忽略了它们的这些重要特征。 但是DTW算法比较了这两个链,并考虑了这些和其他特征。 但是,由于今天有一个更有效的替代方法-PHMM机器,因此我们不会将重点放在DTW算法上。 实验确定 ,PHMM机器可以以90%的准确度“识别”加密音频流中的短语。 而DTW算法仅提供80%的保证。 因此,提及DTW算法(在鼎盛时期曾是解决语音识别问题的流行工具)只是为了表明PHMM机器比它更好(特别是在解决识别加密音频流的问题上) 。 当然,与PHMM机器相比,DTW算法的学习速度要快得多。 这个优势是不可否认的。 但是,使用现代计算能力,这种优势并不是根本。



HMM机器的工作原理


HMM (只是HMM,不是PHMM)是一种统计建模工具,它根据确定性有限状态机定义的系统生成数字链,每个状态机的瞬态函数都是所谓的 “马尔可夫过程”。 此自动机的操作(请参见图3)始终以状态“ B”(开始)开始,并以状态“ E”(结束)结束。 根据当前状态的转换函数来选择将从当前转换到的下一状态。 当您在状态之间移动时,HMM机器会在每个步骤中产生一个数字,从中逐步形成数字的输出链。 当HMM机器处于“ E”状态时,链接结束。 使用HMM机器,人们可以在一开始就发现随机的链型。 例如,此处使用HMM机器的这一优势来查找数据包长度链与目标短语之间的模式,我们在加密的VoIP流中检查其模式。



图3. HMM机器的示例


尽管HMM机器有很多可能的方式可以从“ B”点到达“ E”点(在我们的情况下,是打包单个音频片段),但仍然适用于每种情况(即使是随机的“马尔可夫过程”)有一个最佳方法 ,一个最佳链。 她本人是最有可能的申请人,在打包相应的音频片段时,她最有可能选择音频编解码器(因为她的独特性还体现在她比其他人更擅长打包的事实)。 可以使用维特比算法找到这种“最佳链”(例如,在此处完成)。


此外,在语音识别任务中(例如,在我们的案例中包括加密数据流),除了能够找到观察到的链的最佳路径之外,能够计算出HMM机器生成所选链的可能性也很有用。 这里提供了一个解决这个问题的简洁方法; 它依赖于Forward-Back算法和Baum-Welsh算法


在此,基于HMM自动机,已经开发了一种用于识别正在开发会话的语言的方法。 精度为66%。 但是,如此低的精度并不令人印象深刻,因此对HMM机器进行了更高级的修改-PHMM,它从加密的音频流中提取了更多的模式。 因此,例如, 这里将详细描述如何使用PHMM机器在加密的流量中识别单词和短语(与简单地识别进行对话的语言相比,此任务将更加困难); 精度为90%。



PHMM机器的工作原理


PHMM是HMM机器的改进型变体,其中(参见图4.a),除了“对应”状态(带有字母M的方框)之外,还有“插入”状态(带有字母I的菱形)和“删除”状态(圆圈)和字母D)。 由于有了这两个新状态,与HMM自动机相比,PHMM自动机能够识别假设链“ ABCD”,即使它并不完全存在(例如“ ABD”)或在其中插入了一个插入物(例如“ ABXCD”)。 在解决识别加密音频流的问题时,PHMM机器的这两项创新特别有用。 因为即使音频输入非常相似(例如,当同一个人说相同的短语时),音频编解码器的输出也很少匹配。 T.O. PHMM机器的最简单模型由三个相互连接的状态链(“对应”,“插入”和“删除”)组成,这些状态链描述了链的每个位置(选定短语的加密VoIP流量数据包)的预期网络数据包长度。



图4. PHMM机器的示例


但是,由于将目标短语打包在加密音频流中的网络数据包通常被其他网络数据包(对话的其余部分)包围,因此我们需要一台更高级的PHMM机器。 可以将目标短语与周围的其他声音隔离开的一个。 在这里,为此,将5个新状态添加到原始PHMM机器中(参见图4.b)。 这五个添加状态中最重要的是“随机”(带有字母R的菱形)。 当那些不是我们感兴趣的短语一部分的数据包到达时,PHMM机器(在训练阶段完成之后)进入此状态。 PS(配置文件开始)和PE(配置文件结束)状态-在随机状态和模型的配置文件部分之间提供过渡。 对PHMM自动机的这种改进改进甚至能够识别自动机在训练阶段“没听到”的那些短语(参见图5)。



图5. PHMM机器解决了加密音频流识别的问题



从理论到实践:识别对话的语言


是一个基于PHMM机器的实验性设置(请参见图6),该设备用于分析来自20个不同语言组的2,000位母语使用者的语音的加密音频流。 培训过程完成后,PHMM机器以60%到90%的准确度识别对话语言:对于20种语言中的14种,识别的准确度超过90%,对于其余部分-60%。


图6中显示的实验设置包括两台装有OpenSource VoIP软件的Linux PC。 其中一台机器充当服务器,并侦听网络上的SIP呼叫。 收到呼叫后,服务器会自动应答用户,将语音通道初始化为“ Speex over RTP”模式。 这里应该提到的是,VoIP系统中的控制信道通常是通过TCP协议实现的,并且可以在具有开放式体系结构(SIP,XMPP,H.323)的某些公共可用协议上工作,或者具有特定于特定协议的封闭式体系结构。应用程序(例如在Skype中)。



图6.用于PHMM机器的实验设置


语音通道初始化后,服务器将文件播放给呼叫者,然后终止SIP连接。 订户(这是我们本地网络上的另一台计算机)对服务器进行SIP调用,然后使用嗅探器“侦听”服务器播放的文件:它侦听来自服务器的加密音频流量的网络数据包链。 此外,订户或者训练PHMM机器以识别对话的语言(使用前面几节中描述的数学装置),或者“询问” PHMM机器:“对话所用的语言是什么?” 如前所述,这种实验设置可确保语言识别的准确性-高达90%。 培训PHMM机器的过程将在下一节(以Skype为例)中详细介绍。



收听Skype的加密音频流


演示了如何使用PHMM机器解决更复杂的问题:识别Skype生成的加密音频流(在VBR模式下使用Opus / NGC音频编解码器;以及256位AES加密)。 所呈现的开发根据图5所示的原理进行工作。为此,它使用如图6所示的实验设置。但是仅使用Skype编解码器Opus。


为了训练他们的PHMM机器, 研究人员使用了以下步骤:1)首先,他们收集了一组音轨,包括他们感兴趣的所有短语; 2)然后安装网络数据包嗅探器,并在两个Skype帐户之间发起语音对话(此操作导致在P2P模式下在两台计算机之间生成加密的UDP通信); 3)然后,他们使用媒体播放器在Skype会话中播放每个收集的音轨; 音轨之间保持五秒钟的沉默间隔; 4)同时,将数据包嗅探器配置为注册进入实验设置的第二台计算机的所有流量(参见图6)。 收集所有训练数据后,使用PCAP文件自动解析器提取UDP数据包长度链。 然后使用Baum-Welsh算法将包含有效载荷数据包长度的结果链用于训练PHMM模型。



如果您关闭VBR模式?


似乎可以通过将音频编解码器切换到恒定比特率模式来解决此类泄漏的问题(尽管这是一种解决方案-带宽显着降低),但是即使在这种情况下,加密音频流的安全性仍然有很多不足之处。 毕竟,利用VBR流量的数据包长度只是攻击旁路信道的一个示例。 但是还有其他攻击示例,例如跟踪单词之间的停顿


这项任务当然是不平凡的,但可以解决的 。 为什么不平凡? 因为在Skype中,例如,为了协调UDP协议和NAT(网络地址转换;网络地址转换)的操作; 并且还提高了传输语音的质量-即使会话中有暂停,网络包的传输也不会停止。 这使识别语音停顿的任务变得复杂。


但是,这里开发了一种自适应阈值算法,该算法可以以超过80%的精度区分语音中的静音。 提出的方法基于以下事实:语音活动与加密数据包的大小密切相关:与用户沉默相比,当用户讲话时,语音数据包中编码的信息更多。 在这里 (重点放在Google Talk,Lella和Bettati上),即使在数据包大小不发生泄漏的情况下(即使禁用了VBR模式),也可以确定扬声器。 在这里,研究人员依靠测量数据包接收之间的时间间隔。 所描述的方法依赖于静默阶段,该阶段以较小的分组以较长的时间间隔进行编码,以将单词彼此分开。


T.O. 即使最先进的加密技术也无法正确保护加密的VoIP通信,即使这种加密技术得到了正确实施,这本身也不大可能 。 , (PHMM-), - ( PRISM BULLRUN). . – .


  1. Charles Wright, Lucas Ballard. Language Identification of Encrypted VoIP Traffic // Proceedings of the 16th USENIX Security Symposium. 2007. pp. 43-54.
  2. Charles Wright, Lucas Ballard. Uncovering Spoken Phrases in Encrypted VoIP Conversations // Proceedings of the IEEE Symposium on Security and Privacy. 2008. pp. 35-49.
  3. Benoit Dupasquier, Stefan Burschka. Analysis of information leakage from encrypted Skype conversations // International Journal of Information Security. 9(5), 2010. pp. 313-325.
  4. Shaun Colley. Practical Attacks Against Encrypted VoIP Communications // HITB Magazine. 4(19), 2014. pp. 30-41.
  5. Global VoIP subscriber numbers and net growth // Point Topic. 2013. URL: http://point-topic.com/free-analysis/global-voip-subscriber-numbers-q1-2013/ ( : 25 2018).
  6. World Broadband Statistics – Q3 2017 // Point Topic. URL: http://point-topic.com/free-analysis/world-broadband-statistics-q3-2017/ ( : 25 2018).
  7. James Ball. Revealed: how US and UK spy agencies defeat internet privacy and security // Guardian. 2013. URL: https://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security ( : 25 2018).
  8. Hiddem Markov Model // Wikipedia. URL: https://en.wikipedia.org/wiki/Hidden_Markov_model ( : 25 2018).
  9. Forward–backward algorithm // Wikipedia. URL: https://en.wikipedia.org/wiki/Forward%E2%80%93backward_algorithm ( : 25 2018).
  10. Leonard Baum, Norman Weiss. A maximization technique occurring in the statistical analysis of probabilistic functions of Markov chains // Annals of Mathematical Statistics. 41(1), 1970. pp. 164-171.
  11. Andrew Viterbi. Error bounds for convolutional codes and an asymptotically optimum decoding algorithm // IEEE Transactions on Information Theory. 13(2), 1967. pp. 260-267.
  12. Manfred Schroeder. Code-excited linear prediction(CELP): High-quality speech at very low bit rates // Proceedings of the 1985 IEEE International Conference on Acoustics, Speech, and Signal Processing. v.10, 1985. pp, 937-940.
  13. S. Eddy. Multiple alignment using hidden Markov models // Proceedings of the Third International Conference on Intelligent Systems for Molecular Biology. 1995. pp. 114-120.
  14. Yu-Chun Chang. Inferring speech activity from encrypted Skype traffic // Proceedings of IEEE Globecom. 2008.
  15. Tuneesh Lella. Privacy of encrypted voice-over-IP // Proceedings of the 2007 IEEE International Conference on Systems, Man and Cybernetics. 2007. pp. 3063-3068.
  16. Charles Wright. Language identification of encrypted VoIP traffic: Alejandra y Roberto or Alice and Bob? // Proceedings of the 16th USENIX Security Symposium. 2007. pp. 1-12.
  17. .. : SSL/TLS- // . №228. 2018.
  18. .. // . 2015. URL: https://habrahabr.ru/post/272385/ ( : 25 2018).

Source: https://habr.com/ru/post/zh-CN461759/


All Articles