Torfon - eine mobile Anwendung für anonyme Telefonie

Heute möchte ich über die Ergebnisse meiner siebenjährigen Forschung auf dem Gebiet der Sprachübertragung über das Tor-Netzwerk sprechen. Es ist allgemein anerkannt, dass Sprachkommunikation über Tor fast unmöglich ist:

• Bestehende Transportprotokolle für Telefonie funktionieren zusätzlich zu UDP, und Tor stellt nur TCP-Verbindungen bereit.
• Tor leitet Pakete über mehrere Knoten weiter und verschlüsselt die Daten. Dies führt zu einer erheblichen Latenz und macht Duplex-Telefonie unmöglich oder äußerst unangenehm.

Aber ist es wirklich so?

Bereits 2012 habe ich über die grundlegende Möglichkeit nachgedacht, anonyme Telefonkommunikation mit Tor- und i2p-Anonymisierern zu implementieren. Die Reaktion der Community war eindeutig negativ, einschließlich Phil Zimmermann selbst, dem Autor des berühmten PGPFone, auf dessen Grundlage der erste Torfon arbeitete. Aber ich war hartnäckig, testete neue Ideen, testete und verbesserte gefundene Tricks, die hauptsächlich darauf abzielten, die Latenz auf ein akzeptables Maß zu reduzieren. Andere Forscher arbeiteten ebenfalls in dieser Richtung, und ihre Veröffentlichungen gaben mir neue Ideen und die Grundlage für weitere Arbeiten. Die positiven Aspekte waren die signifikante Beschleunigung des globalen Internet-Netzwerks und insbesondere des Tor-Netzwerks sowie die schrittweise Entwöhnung der Benutzer von PSTN zugunsten der GSM-Kommunikation mit ihrer inhärenten signifikanten Latenz. Schließlich wurde ein geeignetes Konzept entwickelt, und es war an der Zeit, den Plan umzusetzen.
Im Jahr 2013 kritisierte Roger Dingledine in der persönlichen Korrespondenz das Projekt heftig wegen mangelnder Plattformübergreifendheit (zu dieser Zeit wurde PGPFone als Basis auf einer Windows-Plattform verwendet) und wegen seiner nicht modularen Architektur. Vor dem Hintergrund dieser Kritik wurde der Grundstein für die moderne Implementierung von Torfon gelegt, wobei viele Versuche und Irrtümer sowie moderne Trends in der Kryptographie berücksichtigt wurden.

Heute besteht Torfon aus vier Softwaremodulen, die über 36-Byte-Pakete mit streng festgelegten Feldern miteinander interagieren. Dies ist ein Transportmodul, das die Arbeit mit Sockets, ein Kryptografie- und Soundmodul, ein Speichermodul (führt Operationen mit einem privaten Schlüssel aus und enthält ein verschlüsseltes Adressbuch) und ein Benutzeroberflächenmodul bereitstellt. Sie können auf derselben Hardwareplattform (in einem oder in verschiedenen Streams) oder auf mehreren isolierten Plattformen unter Verwendung eines seriellen Standardprotokolls (Hardware-UART, USB CSD oder Bluetooth SPP) als Schnittstelle ausgeführt werden. Diese Architektur ermöglicht es dem Entwickler, einen Kompromiss zwischen Sicherheit und einfacher Implementierung zu ermitteln. Von einer eigenständigen Windows-Anwendung bis hin zur Hardware-Implementierung stehen Optionen in Form einer Einzelplatine mit Linux für Tor und eines Transportmoduls in Verbindung mit einem isolierten Cortex M4-Mikrocontroller zur Verfügung, der Audio verschlüsselt, vollständig verarbeitet und wiedergibt, private Schlüssel und Kontakte speichert und eine grafische Benutzeroberfläche implementiert.

Der Quellcode der Module ist in C geschrieben und vollständig plattformübergreifend, mit Ausnahme der einfachen Arbeit mit Audio, die in separate Dateien übertragen wird, die für Windows (Wave), Linux (Alsa), Android (OpenSL) und Bare Metal (ADC / DAC + DMA für den Mikrocontroller) spezifisch sind )
Bei der Auswahl eines Audio-Codecs und einer Warteschlange wurden die Funktionen des Tor-Netzwerks berücksichtigt: regelmäßige häufige spontane Verzögerungen, eine leichte Verringerung der Latenz für Pakete in einem bestimmten Längenbereich, die Möglichkeit, während eines Anrufs doppelte Ketten mit unterschiedlichen Routing-Pfaden zu erstellen usw. Das OnionPhone-Zwischenprojekt umfasste 17 der gängigsten Audio-Codecs mit niedriger Bitrate. Nach sorgfältigen Tests wurde die am besten geeignete Option ausgewählt: AMR mit einer Mindestbitrate von 4750 Bit / s und einem Hochgeschwindigkeits-VAD. Unter Berücksichtigung der natürlichen Pausen zwischen Wörtern und der Duplexnatur der Kommunikation beträgt die durchschnittliche Gesamtbitrate in jeder Richtung etwa 2000 bis 3000 Bit / s. Dies ermöglicht die Verwendung von GPRS auch unter Bedingungen einer schlechten GSM-Abdeckung und eines massiven Verlusts von GSM-Paketen.

Ein effektiver NPP7-Algorithmus wurde als Rauschunterdrücker entwickelt. Er wurde zur Bekämpfung von intensivem Audio-Rauschen entwickelt und ist Teil des MELPe-Codecs, des aktuellen militärischen Kommunikationsstandards STANAG-4591. Der Algorithmus zur Echokompensation wurde aus dem WebRTC-Projekt als effektivste offene Lösung ausgewählt.

Die allgemeine Funktionalität von Torfon wurde unter Berücksichtigung möglicher Anwendungsfälle und bestehender Bedrohungsmodelle entwickelt, die bereits gegen beliebte Instant Messenger verwendet wurden.

Grundlegende Betriebsarten:

1. Anonyme Sprachanrufe an den versteckten Dienst von Tor (an der Zwiebeladresse). Diese Anrufe sind so gut wie möglich geschützt, es gibt jedoch einige Verzögerungen, die für ungewohnte Benutzer unangenehm sein können.
2. Wechseln zu einer direkten UDP-Verbindung (mit NAT-Pass) nach dem Einrichten einer Tor-Verbindung. In Tor ausgehandelte Sitzungsverschlüsselungsschlüssel bieten eine starke Privatsphäre, aber die Anonymität geht verloren (Benutzer geben ihre IP-Adresse aneinander weiter).
3. Direkte Anrufe an die angegebene IP-Adresse (oder den angegebenen Domänennamen) und die angegebene TCP-Portnummer. Um solche Anrufe entgegenzunehmen, benötigen Sie eine „weiße“ (routbare) IP-Adresse auf dem Gerät (viele Mobilfunkbetreiber bieten diese als kostenpflichtigen Dienst an) oder eine Weiterleitung des TCP-Ports, der auf einem lokalen Router verwendet wird (z. B. in einem WLAN-Heimnetzwerk). Direkte Anrufe können in einem isolierten lokalen Netzwerk getätigt werden (z. B. einem lokalen WiFi-Netzwerk, das mit einem leistungsstarken Zugangspunkt erstellt wurde, der in der Mitte des Servicebereichs installiert ist). In diesem Fall erfordert Torfon keine Interaktion mit dem Internet: Das Projekt verfügt nicht über einen eigenen Server. Dies ist ein Punkt, an dem potenzielle Fehler, Angriffe und Metadaten auftreten können. Somit kann Torfon auch mit der vollständigen Isolierung des Netzwerksegments oder des gesamten Runet auf Statusebene erfolgreich arbeiten.

Heutzutage wird häufig die Frage des Vertrauens in Tor sowohl im Hinblick auf die Wahrung der Anonymität als auch im Hinblick auf die Vertraulichkeit der übermittelten Daten aufgeworfen. Der bekannte TorChat-Messenger verwendete seine Verschlüsselung und Authentifizierung nicht und vertraute vollständig auf die von Tor bereitgestellten Dienste. Persönlich vertraue ich Tor, zumindest in Bezug auf Privatsphäre und perfekte Geheimhaltung. Leider wird diese Position durch die Entdeckung globaler Schwachstellen SPECTER / MELTDOWN sowie einer Vielzahl von Zero-Day-Schwachstellen für alle bekannten Betriebssysteme überschattet, die praktisch als Arbeitstools im Arsenal eines speziellen Dienstes verwendet werden. Daher konnte ich dem TorChat-Pfad nicht folgen und fügte Torfon meine eigene Verschlüsselungs- und Authentifizierungsschicht hinzu, wobei ich die modernsten Protokolle und nachweislich starke kryptografische Grundelemente verwendete.

Das Konzept basiert auf der Fähigkeit, Anrufe zwischen unbekannten Teilnehmern zu tätigen und ihre öffentlichen Schlüssel dann automatisch für die gegenseitige Authentifizierung in nachfolgenden Kommunikationssitzungen auszutauschen. Dieser Ansatz bietet eine gewisse Ablehnung in Bezug auf das Vorhandensein eines kompromittierenden Schlüssels in der Liste Ihrer Kontakte: Jeder Abonnent, der Ihre Zwiebeladresse kennt, kann einen anonymen Anruf tätigen und Sie jeden Kontakt aus seinem Adressbuch sofort weiterleiten. Dieser Kontakt wird automatisch zu Ihrem Adressbuch hinzugefügt. Diese Funktion kann jedoch in den Einstellungen deaktiviert werden. Wer weiß, ob Sie sie zuvor aktiviert haben?

Besonderes Augenmerk wird auf den Schutz der Teilnehmerkennungen gelegt. Der Anrufer weiß also, wen er anruft, und muss ihm seinen Ausweis (Schlüssel) mitteilen. Aber nur er und sonst niemand! Wenn die Verbindung abgefangen wird, auch von einem aktiven Angreifer, und später alle privaten Schlüssel der Teilnehmer offengelegt werden, gibt es darüber hinaus keine Möglichkeit, die Kennungen der Teilnehmer in jeder Stichprobe oder abgefangenen Sitzung in der Vergangenheit zu ermitteln (oder aus der Liste der bekannten auszuwählen). Mit anderen Worten, der Schutz der ID der anrufenden und angerufenen Teilnehmer mit perfekter umgekehrter Geheimhaltung (PFS). Dies wurde erreicht, indem das Triple-DH-Protokoll (Diffie-Hellman-Triple, das auch in Signal verwendet wird) durch Hinzufügen eines parallelen SPEKE-Protokolls geändert wurde, das keine Offenlegung in Bezug auf explizite Authentifikatoren bietet, die während des anfänglichen Schlüsselaustauschs zwischen den Parteien ausgetauscht wurden.

Das in Torfon verwendete Protokoll hat die Eigenschaft Deniability, wenn die böswillige Partei nach einer abgeschlossenen Kommunikationssitzung den Richter nicht davon überzeugen kann, dass der Kontakt tatsächlich stattgefunden hat. Forward Deniability wird auch dann bereitgestellt, wenn die böswillige Partei im Voraus mit dem Richter vereinbart, dass sie die Sitzung durchführen wird, und nach Abschluss der Sitzung zu beweisen versucht, dass sie stattgefunden hat. Volle Verleugnung (Volle Verleugnung, wenn die böswillige Partei während einer Kommunikationssitzung Kontakt mit dem Richter aufnimmt) konkurriert mit einer so wichtigen Eigenschaft wie KCI - Stabilität (der Unfähigkeit, sich einem anderen Teilnehmer vorzustellen, dessen privater Schlüssel bekannt ist). Aufgrund der praktischen Gegebenheiten wurde die KCI-Stabilität als praktischere Eigenschaft bevorzugt, insbesondere unter Bedingungen nicht rechtlicher Beziehungen.

Von den zusätzlichen Funktionen zur gegenseitigen Authentifizierung beim ersten Kontakt (um die Authentizität des Schlüsselaustauschs zu gewährleisten) sind zwei Protokolle implementiert:

• Vergleich eines kurzen Fingerabdrucks eines gemeinsamen Geheimnisses (SAS, ähnlich dem ZRTP-Protokoll). Um den Angriff mit kurzen Fingerabdrücken während des MitM-Prozesses zu blockieren, wird das Commit in der Diffie-Hellman-Prozedur verwendet. Darüber hinaus wird der Fingerabdruck des gemeinsam genutzten Geheimnisses automatisch in den Namen des in dieser Sitzung akzeptierten Kontakts aufgenommen. Daher sollte beim Austausch von Kontakten während einer Sitzung der Beginn des Namens des neuen Kontakts für beide Teilnehmer gleich sein, was später beispielsweise persönlich überprüft werden kann. Übrigens muss der empfangene Kontakt umbenannt werden, damit Torfon sich (seine ID) gegenüber diesem Kontakt vertreten kann.
• Vergleich eines zuvor vereinbarten Geheimnisses (Wörter, Sätze). In der OTR erfüllt das Socialist-Millionaire-Protokoll eine ähnliche Funktion. Torf verwendet hinsichtlich der Eigenschaften dasselbe SPEKE-Protokoll (ohne Offenlegung).

Wenn beide Teilnehmer der Sitzung Kontakte (öffentliche Schlüssel) haben, wenn die Authentifizierung erfolgreich ist und Tor (Anruf an die Zwiebeladresse) verwendet wird, führt der empfangende Teilnehmer einen Gegenanruf unter Verwendung der Zwiebeladresse des anrufenden Teilnehmers aus seinem Adressbuch durch. Nachdem die Verbindung hergestellt wurde, wird auf dem zweiten Kanal eine gegenseitige Authentifizierung durchgeführt, die die Zwiebeladresse des Anrufers bestätigt. Ein ähnliches Verfahren wird von TorChat verwendet, um Chats zu authentifizieren, wobei die Zwiebeladresse des Kontakts als ID verwendet wird.

Die parallele Tor-Verbindung besteht aus anderen Ketten, die vorteilhafterweise zum Ausgleich spontaner Verzögerungen verwendet werden: Sprachpakete werden gleichzeitig an beide Kanäle gesendet, das zuvor empfangene Paket wird verwendet. Außerdem werden Statistiken zu Verzögerungen in beiden Kanälen gespeichert. Wenn einer der Kanäle viel langsamer ist, wird er während eines Gesprächs regelmäßig wieder verbunden. Dies verringert die Gesamtlatenz des authentifizierten Anrufs im Vergleich zu einem Anruf von einem unbekannten Teilnehmer.

Wie die traurige Praxis zeigt, ist es heute sehr wichtig, der Anwendung beizubringen, sich gegen mögliche Sperren zu verteidigen. Glücklicherweise hat Torfon keinen eigenen Server oder keine eigene Cloud, sondern verwendet stattdessen Tor. Daher ist das Blockieren von Torfon nur durch Sperren von Tor möglich. Aber heute ist es auch Realität, und in diesem Fall besteht nur die Möglichkeit, Anrufe direkt an die IP-Adresse und den TCP-Port zu tätigen. Im pessimistischsten Szenario wird der große Bruder versuchen, DPI-Systeme (Deep Packet Analysis) zu lehren, um den Verkehr zwischen zwei Torfons in einem kontrollierten P2P-Netzwerk zu erkennen. Daher wurden zusätzliche Maßnahmen ergriffen, um die Verschleierung dieses Verkehrs zu maximieren. Erstens kann der TCP-Überwachungsport manuell ausgewählt werden und ist tatsächlich Teil der Adresse des Teilnehmers. Zweitens haben absolut alle Pakete (einschließlich Audio) während einer Kommunikationssitzung (TCP-Sitzung) keine besonderen Merkmale (konstante oder inkrementelle Felder, Längen usw.) und sehen für einen externen Beobachter wie zufällige Daten zufälliger Länge aus . Drittens ist zur Durchführung einer aktiven Probe des Protokolls ein „Proof of Job“ erforderlich, um das massive Scannen von Adressen und Ports zur Erkennung von Torf zu verhindern.

Tatsächlich wird die Verbindung durch zwei aufeinanderfolgende TCP-Verbindungen hergestellt. Während der ersten Verbindung tauschen die Teilnehmer primäre Sitzungsschlüssel in Form von Punkten auf der elliptischen Kurve X25519 aus, wobei das übliche Diffie-Hellman-Protokoll ausgeführt wird. Da das Montgomery-Format der Punktdarstellung keine Zufallszahl ist, wird die Elligator2-Darstellung, ergänzt durch Zufallsbytes, verwendet. Nach dem Entfernen des gemeinsam genutzten Geheimnisses wird die erste Sitzung unterbrochen und nach einer zufälligen Zeitspanne (einige Sekunden) wird die zweite Sitzung eingerichtet, in der alle Daten mit einem aus dem gemeinsam genutzten Geheimnis abgeleiteten Schlüssel verschlüsselt werden. Neue Sitzungsschlüssel werden generiert und das Diffie-Hellman-Protokoll wird erneut ausgeführt, jetzt mit einem Kommentar. Aus dem erhaltenen Geheimnis werden symmetrische Schlüssel zur Ver- und Entschlüsselung abgeleitet. Das Diffie-Hellman-Dreifachprotokoll wird dann parallel zum SPEKE-Protokoll ausgeführt, um die Anrufer-ID zu schützen und zu authentifizieren. In Abwesenheit von Schlüsseln im Adressbuch (unbekannter Kontakt) oder einer Diskrepanz werden alle Nachrichten durch zufällige Bytes ersetzt. Das Protokoll wird nicht unterbrochen, um den Verlust von Identitätsinformationen der Teilnehmer zu verhindern.

Für die Implementierung dieser Protokolle werden sorgfältig überprüfte Quell-C-Codes von kryptografischen Grundelementen verwendet, die aus bekannten kryptografischen Bibliotheken stammen. Zur Überprüfung in der Entwicklungsphase wurden bekannte Testvektoren verwendet, und nach jedem Anwendungsstart wird eine zusätzliche Überprüfung einer bestimmten Implementierung des ausführbaren Codes (Kompilierungsergebnis) durchgeführt.

Für die Verschleierungsschicht wurde der symmetrische Serpent-128-Algorithmus ausgewählt, der im authentifizierten OCB-Verschlüsselungsmodus arbeitet. Für die Grundschicht der symmetrischen Verschlüsselung werden die Keccak-800-Transformation als Shake-128-Funktion und ein unidirektionaler CTR-Paketzähler verwendet. Das gleiche Grundelement wird als Hash, MAC und PKDF verwendet. Der ChaCha20-Algorithmus wird verwendet, um das Adressbuch und den Pseudozufallszahlengenerator zu verschlüsseln. Der Generator befindet sich zu Beginn jeder Sitzung für die Akkumulation von Entropie in Multitask-Betriebssystemen, der Havege-Algorithmus und im Mikrocontroller das niedrigstwertige Bit des ADC-Ergebnisses, das das Rauschen des Widerstandsteilers misst. Die Entropie wird auf die erforderliche Menge akkumuliert, die unter Verwendung des Gruppenfrequenztests geschätzt wird.

Die wichtigsten kryptografischen Grundelemente (Elementarmathematik für X25519, Keccak800, ChaCha20) verwenden compileroptimierte Assembler-Implementierungen für Mikrocontroller-Plattformen (Cortex M1 und M4), die sorgfältig auf konstante Ausführungszeit und mit minimierter Leckage durch Seitenkanäle elektromagnetischer Strahlung und Stromverbrauchsschwankungen getestet wurden. Ich muss sofort sagen - diese Assembler-Codes wurden von weltberühmten Fachleuten erhalten. Ich habe sie nur von GNU ASM in die Keil-Umgebung portiert, die für das Erstellen eingebetteter Projekte besser bekannt ist.

Nun, was am Ende?

Wenn Sie bis zu diesem Ort gelesen haben und nicht vor Langeweile gestorben sind, bedeutet dies, dass dieses Projekt für Sie wirklich nützlich sein kann. Wenn ja, dann stelle ich auf Anfrage per E-Mail gerne Testassemblys (statisch verknüpfte ausführbare Dateien, keine Installation erforderlich) sowie den Quellcode für die grafische Oberfläche für Windows, Linux und Android in den jeweiligen Entwicklungsumgebungen zur Verfügung. Der Kern des Projekts basiert auf der plattformübergreifenden Torfone-Bibliothek, die über die Github-Suche verfügbar ist. Dort finden Sie auch direkte Links zur Alpha-Version der Android-Anwendung sowie eine kurze Anleitung zu deren Installation und Verwendung, mit deren Hilfe jeder die Latenz der Telefonie im Tor-Netzwerk bewerten kann.

Die grafische Oberfläche wird für jede Plattform separat implementiert und ist keine Option (bisher handelt es sich nur um Alpha-Tests). Die Testanwendung für alle Windows-Versionen (ab dem alten Windows 98) wurde im alten, aber leistungsstarken Borland C ++ Builder 6 ausgeführt. Für Linux wurde die GUI-Anwendung unter Verwendung der vergessenen Wide Studio for X11-Grafik separat für i386- und ARM-Architekturen entwickelt. Der erste sollte sowohl auf 32-Bit- als auch auf 64-Bit-Desktops funktionieren, der zweite auf kostengünstigen Single-Board-Computern: RPi, Orange, Nano usw. Für Android wird in Embarcadero RAD Studio 10.2 eine APK-Datei kompiliert. Dies ist bei weitem nicht die beste Option und weiß immer noch nicht, wie ein Vordergrunddienst erstellt werden soll. Trotzdem funktioniert es im Hintergrund stabil, wenn die Optimierung des Batterieverbrauchs deaktiviert ist. Außerdem unterstützt die Android-Umgebung die automatische Sicherung von Konfigurationsdateien, Schlüsseln und Adressbüchern (in verschlüsselter Form) auf externem Speicher und die Wiederherstellung, wenn Torfon neu installiert oder auf ein anderes Gerät übertragen wird. Zum Zeitpunkt des Schreibens wird an einem Projekt in der Keil uVision-Umgebung gearbeitet, das Transport-, Verschlüsselungsmodule, eine auf Arduino basierende Audio- und Grafikschnittstelle umfasst - ein kompatibles 320 * 240 TFT + Touch-Display. Das NanoPi Neo mit dem installierten Debian-Server und der über einen physischen UART verbundenen Nucleo STM32F446RE-Karte wird als offene Hardwareplattform verwendet.In den langfristigen Plänen - Portierung auf iOS, obwohl ich kaum verstehe, wie dies mit grundlegenden Sicherheitsgarantien kombiniert werden kann.

Und zum Schluss.

Oft werden mir dieselben Fragen gestellt: Wie kann ich Benutzer ohne zentralen Server verwalten? Wie werfe ich Updates, Anzeigen? Und vor allem, warum brauche ich das alles, wenn dies keinen kommerziellen Wert hat?

Tatsächlich ist die Welt nicht so grau und ruiniert. Und es gibt viele Werte, die nicht mit Geld gemessen werden können. Aber die Antwort auf die ersten beiden Fragen - auf keinen Fall. Du kannst Turfon nicht aufhalten. Sie können keine "Schlüssel" von ihm erhalten, Sie können die Aktionen von Benutzern nicht zusammenführen, selbst diejenigen, die bei Terrorismus oder Pädophilie bemerkt wurden, Sie können keine unerwünschten Personen verbieten. Sie können keine Updates erzwingen. Sie können nicht von außen steuern. In Torfon gibt es keine Lecks und Nebenverbindungen, es sei denn, dies ist im Protokoll vorgesehen. Dies kann sowohl im Code (fast jede Zeile ist auskommentiert und es gibt nicht so viele Dateien im Projekt) als auch in Netzwerkanalysatoren leicht überprüft werden. Daher kann niemand Torfon-Benutzer verwalten. Aber denken Sie daran: Turfon ist nur ein Werkzeug, und alle Ihre Handlungen liegen auf Ihrem Gewissen, und Sie sind dafür verantwortlich, nicht der Autor des Projekts.