Torfon - anonymous telephony mobile application

Today I would like to talk about the results of my seven-year research in the field of voice transmission over the Tor network. It is generally accepted that voice communication via Tor is almost impossible:

• existing telephony transport protocols run over UDP, and Tor provides only TCP connections;
• Tor routes packets through multiple nodes, encrypting data, which causes significant latency and makes duplex telephone communication impossible or extremely uncomfortable.

But is it really?

Back in 2012, I first thought about the fundamental possibility of implementing an anonymous telephone connection using Tor and i2p anonymizers. The community’s reaction was unequivocally negative, including Phil Zimmerman himself, the author of the famous PGPFone, on whose base the first Thorphon worked. But I was stubborn, I tested new ideas, tested and improved the tricks found, mainly aimed at reducing the latency to an acceptable level. Other researchers also worked in this direction, and their publications gave me new ideas and grounds for further work. Positive aspects were the significant acceleration of the global Internet and the Tor network in particular, as well as the gradual disengagement of users from the PSTN in favor of GSM communication with its inherent significant latency. Finally, a suitable concept was developed, and it was the turn of implementation of the plan.
In 2013, Roger Dingledine severely criticized the project in personal correspondence for the lack of cross-platform (at that time PGPFone on the Windows platform was used as the base) and for the non-modular architecture. Against this background, the groundwork was laid for the modern implementation of Torfon, taking into account a multitude of trial and error, as well as current trends in cryptography.
')
Today, Torfon consists of four software modules that interact with each other using 36-byte packets with strictly fixed fields. This is a transport module that provides work with sockets, a cryptography and sound module, a storage module (performs operations with a private key and contains an encrypted address book) and a user interface module. They can be run on the same hardware platform (in the same or in different streams) or on several isolated platforms that use the standard serial protocol as an interface (hardware UART, USB CSD or Bluetooth SPP). This architecture allows the developer to define a compromise between security and ease of implementation. Options are available from a standalone Windows application to a hardware implementation in the form of a Linux single-file for Tor and a transport module in conjunction with an isolated Cortex M4 microcontroller that encrypts, fully processes and plays audio, stores the private key and contacts, implements a graphical user interface.

The source code of the modules is written in C and is fully cross-platform, with the exception of low-level audio processing, rendered into separate files specific to Windows (Wave), Linux (Alsa), Android (OpenSL) and bare metal (ADC / DAC + DMA for the microcontroller ).
When choosing an audio codec and a queue, features of the Tor network were taken into account: periodic frequent spontaneous delays, some reduction in latency for packets in a certain length range, the ability to create duplicate chains with different routing paths during a call, etc. The OnionPhone intermediate project included 17 of the most common low-bitrate audio codecs. After thorough testing, the most suitable option was chosen: AMR with a minimum bit rate of 4750 bps and high-speed VAD. Thus, taking into account the natural pauses between words and the duplex nature of communication, the final average bitrate in each direction is about 2000-3000 bps., Which makes it possible to use GPRS even in conditions of poor GSM coverage and massive loss of GSM packets.

As a noise suppressor, an effective NPP7 algorithm was developed, designed to combat intense audio interference and included in the MELPe codec, the current military communications standard STANAG-4591. The echo cancellation algorithm was chosen from the WebRTC project as the most efficient open source solution available.

The general functionality of Torfon was developed taking into account the possible use cases and the existing threat models already used against popular instant messengers.

The main modes of operation:

1. Anonymous voice calls to the hidden Tor service (by onion-address). These calls are protected as much as possible, but there is some delay, which can cause some discomfort for unaccustomed users.
2. Switching to a direct UDP connection (with a NAT pass) after setting up a Tor connection. Session encryption keys agreed upon within Tor ensure strong confidentiality, but anonymity is lost (users reveal their IP address to each other).
3. Direct calls to the specified IP-address (or domain name) and TCP port number. To receive such calls, you need to have a white (routable) IP address on the device (many mobile operators offer this as a paid service) or a “forwarding” of the TCP port used on a local router (for example, in a home WiFi network). Direct calls can be made in an isolated local network (for example, a local WiFi network created using a powerful access point installed in the center of the service area). In this case, Torfon does not require interaction with the Internet: the project does not have its own server, which is a point of potential failure, attacks, and metadata collection. Thus, Torfon can work successfully even with complete isolation of a network segment or the entire Runet at the state level.

Today, the issue of trust in Tor is raised quite often, both in terms of maintaining anonymity and in terms of confidentiality of transmitted data. The famous TorChat messenger did not use its encryption and authentication, relying entirely on the services provided by Tor. I personally trust Tor, at least in terms of confidentiality and perfect reverse secrecy. But, unfortunately, this position is overshadowed by the discovery of global vulnerabilities SPECTER / MELTDOWN, as well as the mass of zero-day vulnerabilities for all known operating systems that are practically used as working tools in the arsenal of any special services. Therefore, I could not follow the TorChat path and added my own encryption and authentication layer to Torfon, using the most modern protocols and provably strong cryptographic primitives.

The concept is based on the ability to make calls between unfamiliar subscribers, and then automatically exchange their public keys for mutual authentication in subsequent communication sessions. This approach provides a certain denial in the matter of the presence of a compromising key in the list of your contacts: any subscriber, knowing your onion-address, can make an anonymous call and immediately send you any contact from his address book. This contact will be automatically added to your address book. However, this feature can be disabled in the settings, but who knows if it was enabled before?

Special attention is paid to the protection of subscriber IDs. So, the caller knows who he is calling, and should tell him his ID (key). But he and no one else! Moreover, if the connection is intercepted, including the active attacker, and later all the private keys of the participants are revealed, there is no possibility to establish (or select from the list of known) participants' identifiers in each sample or intercepted session in the past. In other words, the caller and callee IDs are protected with perfect reverse secrecy (PFS). This was achieved by modifying the Triple-DH protocol (triple Diffie-Hellman, also used in Signal) by adding a parallel-running SPEKE protocol that provides zero disclosure to explicit authenticators that the parties exchange at the initial key exchange stage.

The protocol used in Torfon has the Deniability property, when, after a completed communication session, the malicious side cannot convince the judge that the contact actually took place. It is also provided with Forward Deniability, when a malicious party agrees with the judge in advance about what will hold the session, and after the session ends, tries to prove that it took place. Full denial (Full Deniability, when the malicious side contacts the judge during a communication session), competes with such an important property as KCI - stability (the inability to introduce yourself to others in front of a subscriber whose private key is known). Based on practical realities, preference was in favor of KCI stability, as a more practical property, especially in non-legal relations.

Of the additional features to authenticate each other during the first contact (to ensure the authenticity of the key exchange), two protocols are implemented:

• Comparison of the shared secret short imprint (SAS, similar to ZRTP protocol). To block the attack of selecting a short fingerprint in the MitM process, commit is used in the Diffie-Hellman procedure. In addition, a shared secret fingerprint is automatically included in the name of the contact accepted in this session. Thus, when exchanging contacts during one session, the beginning of the name of a new contact should be the same for both participants, which can be checked later, for example, in person. And, by the way, the received contact must be renamed in order to allow Thorphon to represent himself (his ID) to this contact.
• comparison of pre-agreed secret (words, phrases). In OTR, the Socialist Millionaire protocol performs a similar function. In Torfon, the SPEKE protocol with similar properties (with zero disclosure) is used.

If both participants in the session have contacts (public keys) of each other, if the authentication is successful and Tor is used (the call to the onion-address), then the receiving party makes a counter call using the onon-address of the caller from his address book. After the connection is established, mutual authentication is performed via the second channel, confirming the onon-address of the calling subscriber. The same procedure uses TorChat to authenticate chats, using the onion-address of the contact as the ID.

A parallel Tor connection consists of other chains, which is advantageously used to compensate for spontaneous delays: voice packets are sent immediately to both channels, the packet that came earlier is used. In addition, statistics of delays are kept in both channels, and if one of the channels is much slower, then it periodically reconnects during the conversation. This reduces the overall latency of the authenticated call compared to a call from an unknown subscriber.

As the sad practice shows, today it is very important to teach the application to protect itself against possible blocking. Fortunately, Torfon does not have its own server or cloud, using Tor instead. Therefore, blocking Torfon is possible only by blocking Tor. But today it is also a reality, and in such a case there will be only the possibility of making calls directly to the IP address and TCP port. In the most pessimistic scenario, the big brother will try to teach DPI (deep packet analysis) systems to detect traffic between two Peatons in a controlled p2p network. Therefore, additional measures were taken to minimize such traffic. First, the listening TCP port can be manually selected and is actually part of the address of the subscriber. Secondly, absolutely all packets (including sound) during a session (TCP - session) do not have any distinctive features (constant or incremental fields, length, etc.) and for the external observer look like random data of random length . Thirdly, to conduct an active protocol sample, a “Proof of Job” is required as a protection against massive scanning of addresses and ports for the detection of Peathops.

The actual connection is made by two consecutive TCP connections. During the first connection, the parties exchange primary session keys in the form of points on the elliptic curve X25519, following the usual Diffie-Hellman protocol. Since the Montgomery point format is not a random number, the Elligator2 view is used, supplemented by random bytes. After removing the shared secret, the first session is broken, and after a random period of time (a few seconds) a second session is established, all data in which is encrypted with a key derived from the shared secret. New session keys are generated, and the Diffie-Hellman protocol is executed again, now with the commitment. Symmetric keys for encryption and decryption are derived from the received secret. It then runs the Diffie-Hellman triple protocol in parallel with the SPEKE protocol to protect caller ID and authentication. If there are no keys in the address book (unknown contact) or any discrepancy, all messages are replaced with random bytes., I.e. the protocol is not interrupted to prevent leakage of information about the identity of participants.

For the implementation of these protocols, carefully re-examined initial C-codes of cryptographic primitives, taken from well-known cryptographic libraries, are used. At the development stage, known test vectors were used for verification, and after each application launch, additional verification of a specific implementation of the executable code (compilation result) is performed.

For the obfuscation layer, a Serpent-128 symmetric algorithm was selected, operating in the authenticated OCB encryption mode. For the base layer of symmetric encryption, Keccak-800 is used as a Shake-128 function and a unidirectional CTR packet counter. The same primitive is used as Hash, MAC and PKDF. To encrypt the address book and pseudo-random number generator, use the ChaCha20 algorithm. The generator resides at the beginning of each session, for the accumulation of entropy in multitasking operating systems, the Havege algorithm is used, and the microcontroller uses the low-order bit of the ADC result, which measures the noise of the resistive divider. The accumulation of entropy is produced to the required amount, estimated using group frequency test.

Basic cryptographic primitives (elementary mathematics for X25519, Keccak800, ChaCha20) use assembler implementations that are not optimized by the compiler for microcontroller platforms (Cortex M1 and M4), thoroughly tested for consistency of execution time and with minimized leakage through side channels of EMR and fluctuations in the use of other devices. I’ll say right away that these assembler codes were received from world-renowned professionals; I just ported them from Keel to GNU ASM, which is more common for building built-in projects.

Well, what is the result?

If you have read this far and have not died of boredom, then this project may indeed be useful to you. If so, then on request to the mail I am happy to provide test builds (statically linked executable files, not required installations), as well as the source codes of the graphical interface for Windows, Linux and Android in the corresponding development environments. The core of the project is based on the torfone cross-platform library, accessible by searching on github. There you can also find direct links to the alpha version of the Android application and a quick guide to installing and using it, which will help anyone who wants to assess the latency of telephony on the Tor network.

The graphical interface is implemented separately for each platform and is not an option (for the time being it is only alpha testing). The test application for all versions of Windows (starting with the old Windows 98) was made in the old but powerful Borland C ++ Builder 6. For Linux, the GUI application was developed using the forgotten Wide Studio for X11 graphics separately for i386 and ARM architectures. The first one should work both on 32-bit and 64-bit desktops, the second one - on inexpensive single-board computers: RPi, Orange, Nano, etc. For Android, an apk-file is available, compiled in Embarcadero RAD Studio 10.2. This is far from the best option and so far it does not know how to create Foreground service, but, nevertheless, it works stably in the Background with the battery usage optimization turned off. Also, the Android environment supports automatic backup of configuration files, keys and address book (in encrypted form) to external storage and recovery when reinstalling Torfon or transferring to another device. At the time of this writing, work is underway on a project in the Keil uVision environment, including transport, encryption modules, audio, and a graphical interface based on an Arduino-compatible 320 * 240 TFT + Touch display.As an open hardware platform, the NanoPi Neo with the installed Debian server and the Nucleo STM32F446RE board, connected via a physical UART, will be used. Remote plans include porting to iOS, although I can hardly understand how this can be combined with elementary security guarantees.

And in the end.

I am often asked the same questions: how can I manage users without a central server? How to throw updates, advertising? And, most importantly, why do I need all this if there is no commercial value in it?

In fact, the world is not so gray and spoiled. And there are many values ​​that cannot be measured in money. And the answer to the first two questions - no way. Well, you can't stop Torfon. It is impossible to get “keys” from him, to merge the actions of users, even those who have been noticed in terrorism or pedophilia, cannot be banned for unwanted ones. Can not be forced to update. Can not be controlled from the outside. There are no leaks in Torfon, no side connections, except as provided by the protocol. This can be easily checked both in the code (almost every line is commented and there are not too many files in the project), or by network analyzers. Therefore, no one can manage users of Torfona. But remember: Torfon is only a tool, and all your actions are on your conscience, and you are responsible for them, and not the author of the project.