今天，我想谈谈我在通过Tor网络进行语音传输领域的七年研究成果。 人们普遍认为通过Tor进行语音通信几乎是不可能的：
- 现有的电话传输协议基于UDP，而Tor仅提供TCP连接。
- Tor通过多个节点路由数据包，对数据进行加密，这会导致巨大的延迟，并使双工电话无法使用或极为不舒服。
但是真的是这样吗？
早在2012年，我首先想到了使用Tor和i2p匿名器实现匿名电话通信的基本可能性。 社区的反应显然是负面的，包括著名的PGPFone的作者Phil Zimmermann本人，第一位Torfon就是在此基础上工作的。 但是我很固执，测试了新的想法，测试并改进了发现的技巧，主要目的是将延迟降低到可接受的水平。 其他研究人员也朝这个方向努力，他们的出版物给了我新的想法和进一步工作的基础。 积极的方面是全球互联网网络（特别是Tor网络）的显着加速，以及PSTN用户逐渐断奶，而支持具有固有固有延迟的GSM通信。 最终，提出了一个合适的概念，现在轮到该计划了。
2013年，Roger Dingledine在个人通讯中严厉批评该项目缺乏跨平台（当时PGPFone被用作Windows平台的基础）以及其非模块化架构。 在这种批评的背景下，考虑到许多试验和错误以及密码学的现代趋势，为Torfon的现代实现奠定了基础。
今天，Torfon由四个软件模块组成，这些模块使用具有严格固定字段的36字节数据包相互交互。 这是一个传输模块，提供与套接字，加密和声音模块，存储模块（使用私钥执行操作并包含加密的地址簿）和用户界面模块一起工作的功能。 它们可以使用标准串行协议（硬件UART，USB CSD或蓝牙SPP）作为接口，在相同的硬件平台（一个或不同的流）上运行，或在几个隔离的平台上运行。 这种体系结构允许开发人员确定安全性和易于实现之间的折衷。 从独立的Windows应用程序到硬件实现的选项都是可选项，形式是具有Linux for Tor的单板和与独立的Cortex M4微控制器结合的传输模块，该模块可加密，完全处理和播放音频，存储私钥和联系人，并实现图形用户界面。
模块的源代码是用C编写的，并且完全跨平台使用，除了音频的低级工作外，这些音频被传输到Windows（Wave），Linux（Alsa），Android（OpenSL）和裸机（ADC / DAC + DMA）专用的单独文件中。 ）
在选择音频编解码器和队列时，考虑了Tor网络功能：周期性频繁的自发延迟，在一定长度范围内的数据包的等待时间略微减少，在通话过程中使用不同的路由路径创建重复链的能力等。 OnionPhone中间项目包括17种最常见的低比特率音频编解码器。 经过仔细的测试后，选择了最合适的选项：最小比特率为4750 bps的AMR和高速VAD。 因此，考虑到字之间的自然停顿和通信的双工性，每个方向上的总平均比特率约为2000-3000 bps。这使得即使在GSM覆盖范围较差和GSM数据包大量丢失的情况下也可以使用GPRS。
开发了一种有效的NPP7算法作为噪声抑制器，该算法是为应对强烈的音频噪声而开发的，它是MELPe编解码器（现行军事通信标准STANAG-4591）的一部分。 回声消除算法是从WebRTC项目中选择的，是最有效的开放解决方案。
Torfon的一般功能是在考虑到可能的用例和已用于流行即时通讯程序的现有威胁模型的基础上开发的。
基本操作模式：
- 匿名语音呼叫Tor隐藏服务（位于洋葱地址）。 这些呼叫会受到尽可能多的保护，但会有些延迟，这可能会使不习惯的用户感到不适。
- 设置Tor连接后，切换到直接UDP连接（通过NAT通过）。 在Tor内协商的会话加密密钥提供了强大的隐私性，但匿名性却丢失了（用户彼此公开了自己的IP地址）。
- 直接调用指定的IP地址（或域名）和TCP端口号。 要接收此类呼叫，您需要设备上的“白色”（可路由）IP地址（许多移动运营商将其提供为付费服务）或转发本地路由器（例如，在家庭WiFi网络中）使用的TCP端口。 可以在隔离的局域网中进行直接呼叫（例如，使用安装在服务区域中心的功能强大的接入点创建的本地WiFi网络）。 在这种情况下，Torfon不需要与Internet交互：该项目没有自己的服务器，这是潜在的故障，攻击和元数据收集点。 因此，即使在状态级别完全隔离了网段或整个Runet，Torfon也可以成功工作。
如今，在保持匿名性和传输数据的机密性方面，人们经常提出对Tor的信任问题。 著名的TorChat Messenger不使用其加密和身份验证，而是完全依赖于Tor提供的服务。 就个人而言，我至少在隐私和完美的后向保密性方面都信任Tor。 但是，不幸的是，由于发现了全球漏洞SPECTER / MELTDOWN以及所有已知操作系统的大量零日漏洞，这些漏洞几乎被任何特殊服务的工具用作工作工具，因此这一状况被黯然失色。 因此，我无法使用TorChat路径，而是使用最现代的协议和可证明的强大加密原语向Torfon添加了自己的加密和身份验证层。
该概念基于以下能力：在陌生的订户之间进行呼叫，然后在后续的通信会话中自动交换其公用密钥以进行相互认证。 如果您的联系人列表中存在一个破坏性的密钥，则此方法提供了一定的拒绝：任何订户，只要知道您的洋葱地址，都可以进行匿名呼叫，并立即将您通讯录中的任何联系人转发给您。 该联系人将被自动添加到您的地址簿中。 但是，可以在设置中禁用此功能，但是谁知道您之前是否打开过此功能？
特别注意保护用户标识符。 因此，呼叫者知道他正在呼叫谁，并且必须告诉他他的ID（密钥）。 但是只有他，没有其他人！ 此外，如果包括主动攻击者在内的任何人都截获了连接，后来又公开了参与者的所有私钥，则无法建立（或从已知列表中选择）过去每个样本或拦截的会话中参与者的标识符。 换句话说，使用完全反向保密（PFS）保护主叫用户和被叫用户的ID。 这是通过添加一个并行SPEKE协议来修改Triple-DH协议（Diffie-Hellman Triple，也用于Signal）来实现的，该协议对初始密钥交换期间各方之间交换的显式身份验证器提供了零披露。
Torfon中使用的协议具有“可否认性”属性，当完成一次通信会话后，恶意方无法说服法官说确实发生了联系。 当恶意方事先同意法官将主持会议并在会议结束后尝试证明会议已经发生时，也会提供转发拒绝能力。 完全可否认性（当恶意方在通信会话期间与法官联系时为完全可否认性）与KCI这样的重要属性竞争-稳定性（无法将自己介绍给已知其私钥的另一个订户）。 根据实际情况，优先考虑KCI稳定性，因为KCI稳定性更实用，特别是在非法律关系的情况下。
在首次联系时相互进行身份验证（以确保密钥交换的真实性）的其他功能中，实现了两个协议：
- 共享机密（SAS，类似于ZRTP协议）的短指纹比较。 要在MitM过程中阻止短暂的指纹攻击，请使用Diffie-Hellman过程中的提交。 此外，共享机密的指纹自动包含在此会话中接受的联系人的姓名中。 因此，当在一个会话期间交换联系人时，两个参与者的新联系人姓名的开头应相同，例如以后可以亲自检查。 顺便说一句，必须重命名收到的联系人，以便允许Torfon向此联系人表示自己（他的ID）。
- 比较先前商定的秘密（单词，短语）。 在OTR中，“社会主义百万富翁”协议执行类似的功能。 Peat在属性方面使用相同的SPEKE协议（披露为零）。
如果会话的两个参与者都有彼此的联系人（公钥），如果身份验证成功并且使用了Tor（呼叫洋葱地址），则接收方使用呼叫者从其通讯簿中的洋葱地址进行反向呼叫。 建立连接后，在第二个通道上执行相互身份验证，以确认呼叫者的洋葱地址。 TorChat使用类似的过程来验证聊天，使用联系人的洋葱地址作为ID。
并行Tor连接由其他链组成，可有利地用于补偿自发延迟：语音数据包立即发送到两个通道，使用较早接收的数据包。 此外，还会保留有关两个通道的延迟的统计信息，并且如果其中一个通道的速度慢得多，则会在通话过程中定期重新连接。 与来自未知用户的呼叫相比，这减少了已认证呼叫的总体延迟。
正如糟糕的实践所表明的那样，今天教导应用程序防御可能的锁定非常重要。 幸运的是，Torfon没有自己的服务器或云，而是使用Tor。 因此，只能通过锁定Tor来阻止Torfon。 但是今天这也是现实，在这种情况下，只能直接拨打IP地址和TCP端口。 在最悲观的情况下，老大哥将尝试教DPI系统（深度数据包分析）以检测受控p2p网络中两个Torfon之间的流量。 因此，采取了其他措施以最大程度地隐藏这种交通。 首先，可以手动选择TCP侦听端口，该端口实际上是订户地址的一部分。 其次，在通信会话（TCP会话）期间，绝对所有数据包（包括声音数据包）都没有任何明显的特征（恒定或增量字段，长度等），并且对于外部观察者来说，它们看起来像是随机长度的随机数据。 第三，要进行协议的有效样本，需要“作业证明”，以防止大规模扫描地址和端口以检测泥炭。
实际上，该连接是通过两个连续的TCP连接建立的。 在第一个连接期间，双方交换椭圆曲线X25519上点形式的主会话密钥，执行通常的Diffie-Hellman协议。 由于点表示形式的蒙哥马利格式不是随机数，因此使用Elligator2表示形式，并附加了随机字节。 删除共享机密后，将断开第一个会话，在一段随机的时间段（几秒钟）后，将建立第二个会话，其中的所有数据都使用从共享机密派生的密钥进行加密。 生成新的会话密钥，并再次执行Diffie-Hellman协议，现在带有注释。 从获得的秘密中获得用于加密和解密的对称密钥。 然后，Diffie-Hellman三重协议与SPEKE协议并行运行，以保护呼叫者ID和身份验证。 如果通讯录中没有密钥（未知的联系人）或存在任何差异，则所有消息都将替换为随机字节。 协议不会被中断，以防止参与者的身份信息泄漏。
为了实现这些协议，使用了经过仔细验证的加密原语源C代码，这些代码均来自知名的加密库。 为了在开发阶段进行验证，使用了众所周知的测试向量，并且在每个应用程序启动后，对可执行代码的特定实现（编译结果）进行附加验证。
对于混淆层，选择了对称的Serpent-128算法，以经过身份验证的OCB加密模式进行操作。 对于对称加密的基本层，使用了Keccak-800转换作为Shake-128功能和单向CTR数据包计数器。 相同的原语用作哈希，MAC和PKDF。 ChaCha20算法用于加密通讯簿和伪随机数生成器。 生成器驻留在每个会话的开始处，为了在多任务操作系统中积累熵，使用了Havege算法；在微控制器中，使用了ADC结果的低位，该值测量了电阻分压器的噪声。 熵累积到所需的数量，使用组频率测试进行估算。
主要的加密原语（X25519，Keccak800，ChaCha20的基础数学）使用针对微控制器平台（Cortex M1和M4）的编译器优化汇编程序实现，并经过仔细测试，以确保程序具有恒定的执行时间，并且通过电磁辐射和电流消耗波动的侧通道泄漏最小。 我必须马上说-这些汇编代码是从举世闻名的专业人士那里获得的，我只是将它们从GNU ASM移植到了Keil环境中，该环境对于构建嵌入式项目更为熟悉。
好吧，到底是什么？
如果您读过这个地方并且没有死于无聊，则意味着这个项目对您确实有用。 如果是这样，那么，我很高兴根据邮件请求提供测试程序集（静态链接的可执行文件，无需安装），以及相应开发环境中Windows，Linux和Android的图形界面的源代码。 该项目的核心基于跨平台的torfone库，该库可在github搜索上找到。 您还可以在其中找到指向Android应用程序Alpha版的直接链接，以及有关其安装和使用的简要指南，这将帮助每个人评估Tor网络中电话的延迟。
图形界面是针对每个平台单独实现的，不是一个选项（到目前为止，这仅是alpha测试）。 适用于所有Windows版本（从古老的Windows 98开始）的测试应用程序都在旧的但功能强大的Borland C ++ Builder 6中运行。对于Linux，GUI应用程序是使用被遗忘的Wide Studio for i11和ARM体系结构的X11图形开发的。 第一个可以在32位和64位桌面上运行，第二个可以在便宜的单板计算机上运行：RPi，Orange，Nano等。在Embarcadero RAD Studio 10.2中编译的apk文件可用于Android。 这远非最佳选择，并且仍然不知道如何创建Foreground服务，但是，尽管禁用了电池使用优化，但它仍可在后台稳定运行。 此外，Android环境支持在重新安装Torfon或将其传输到另一台设备时自动将配置文件，密钥和地址簿（以加密形式）备份到外部存储并进行恢复。 在撰写本文时，Keil uVision环境中的一个项目正在进行中，该项目包括传输，加密模块，基于Arduino的音频和图形界面-兼容的320 * 240 TFT +触摸屏。 装有已安装Debian服务器的NanoPi Neo和通过物理UART连接的Nucleo STM32F446RE板将用作开放式硬件平台。
在长期计划中-移植到iOS，尽管我几乎不了解如何将其与基本安全保证结合使用。并得出结论。经常有人问我同样的问题：在没有中央服务器的情况下如何管理用户？如何发布更新，广告？而且，最重要的是，如果没有商业价值，为什么我需要所有这些？实际上，世界并不是那么灰暗和被破坏。而且有许多价值无法用金钱来衡量。但是前两个问题的答案-没办法。好吧，你不能阻止Turfon。您无法从他那里获得“钥匙”，也无法合并用户的行为，即使是那些在恐怖主义或恋童癖中被发现的用户，也无法禁止不良用户。您不能强制更新。您不能从外面控制。除协议规定外，Torfon中无泄漏，副产物。可以在代码（几乎每一行都被注释掉并且项目中没有太多文件）以及网络分析器中轻松地进行检查。因此，没有人能够管理Torfon用户。但是请记住：Turfon只是一种工具，您的所有行为都出于良心，您应对此负责，而不是项目的作者。