Torfon - a mobile application for anonymous telephony

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

• existing transport protocols for telephony work on top of UDP, and Tor provides only TCP connections;
• Tor routes packets through multiple nodes, encrypting the data, which causes significant latency and makes duplex telephony impossible or extremely uncomfortable.

But is it really so?

Back in 2012, I first thought about the fundamental possibility of implementing anonymous telephone communications using Tor and i2p anonymizers. The reaction of the community was clearly negative, including Phil Zimmermann himself, the author of the famous PGPFone, on the basis of which the first Torfon worked. But I was stubborn, tested new ideas, tested and improved found tricks, mainly aimed at reducing latency to an acceptable level. Other researchers also worked in this direction, and their publications gave me new ideas and the basis for further work. The positive aspects were the significant acceleration of the global Internet network and Tor network in particular, as well as the gradual weaning of users from PSTN in favor of GSM communication with its inherent significant latency. Finally, a suitable concept has been developed,
In 2013, Roger Dingledine in personal correspondence severely criticized the project for the lack of cross-platform (at that time PGPFone was used as a base on a Windows platform) and for its non-modular architecture. Against the background of this criticism, the foundation was laid for the modern implementation of Torfon, taking into account many trial and error, as well as modern 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 one hardware platform (in one or in different threads) or on several isolated platforms using a standard serial protocol (hardware UART, USB CSD or Bluetooth SPP) as an interface. This architecture allows the developer to determine a compromise between security and ease of implementation.

The source code of the modules is written in C and is completely cross-platform, with the exception of low-level work with audio, made in 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 queue, the Tor network features were taken into account: periodic frequent spontaneous delays, a slight decrease 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 careful testing, the most suitable option was selected: AMR with a minimum bitrate of 4750 bps and a high-speed VAD. Thus, taking into account the natural pauses between words and the duplex nature of communication, the total 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.

An effective NPP7 algorithm was developed as a noise suppressor. It was developed to combat intense audio noise and is part of the MELPe codec, the current military communications standard STANAG-4591. The echo cancellation algorithm was selected from the WebRTC project as the most effective open solution available.

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

Basic operating modes:

1. Anonymous voice calls to the Tor hidden service (at the 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 NAT pass) after establishing a Tor connection. Session encryption keys negotiated inside Tor provide strong privacy, 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 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 area 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, attack and metadata collection. Thus, Torfon can successfully work even with the complete isolation of a network segment or the entire Runet at the state level.

Today, quite often the question of trust in Tor is raised both in terms of maintaining anonymity and in terms of confidentiality of the transmitted data. The well-known TorChat messenger did not use its encryption and authentication, relying entirely on the services provided by Tor. Personally, I trust Tor, at least in terms of privacy and perfect backward secrecy. But, unfortunately, this position is overshadowed by the discovery of global vulnerabilities SPECTRE / MELTDOWN, as well as a mass of zero-day vulnerabilities for all known operating systems that are practically used as working tools in the arsenal of any special service. Therefore, I could not go the way of TorChat and added to Torfon my own layer of encryption and authentication, 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 forward 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 you had it turned on before?

Particular attention is paid to the protection of subscriber identifiers. So, the caller knows who he is calling and must tell him his ID (key). But only him and no one else! Moreover, if the connection is intercepted, including by an active attacker, and later all the private keys of the participants are revealed, there is no way to establish (or select from the list of known) the identifiers of participants in each sample or intercepted session in the past. In other words, the protection of the ID of the calling and called subscribers with perfect reverse security (PFS). This was achieved by modifying the Triple-DH protocol (Diffie-Hellman triple, which is also used in Signal) by adding a parallel SPEKE protocol, which provides zero disclosure with respect to explicit authenticators,

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

Of the additional capabilities to authenticate each other at the first contact (to guarantee the authenticity of the key exchange), two protocols are implemented:

• Comparison of a short fingerprint of a shared secret (SAS, similar to the ZRTP protocol). To block a short fingerprint attack in the MitM process, the commit in the Diffie-Hellman procedure is used. In addition, the fingerprint of the shared secret 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 the new contact for both participants should be the same, which can be checked later, for example, in person. And by the way, the received contact must be renamed in order to allow Torfon to represent himself (his ID) to this contact.
• comparison of a previously agreed upon secret (words, phrases). In OTR, the Socialist-Millionaire protocol performs a similar function. Peat uses the same SPEKE protocol in terms of properties (with zero disclosure).

In case both participants of the session have contacts (public keys) of each other, if authentication is successful and Tor (call to the onion address) is used, then the receiving party makes a counter call using the onion address of the calling party from its address book. After the connection is established, mutual authentication is performed on the second channel, confirming the onion address of the caller. TorChat uses a similar procedure to authenticate chats, using the onion address of the contact as its ID.

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

As sad practice shows, today it is very important to teach the application to protect itself from possible locks. Fortunately, Torfon does not have its own server or cloud, using Tor instead. Therefore, blocking Torfon is only possible by locking Tor. But today it is also a reality, and in such a case there will only be 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 systems (deep packet analysis) to detect traffic between two Torfons in a controlled p2p network. Therefore, additional measures were taken to maximize the concealment of such traffic. First, the TCP listening port can be manually selected and is actually part of the subscriber’s address. Secondly, absolutely all packets (including audio ones) during a communication session (TCP session) do not have any distinctive features (constant or incremental fields, lengths, etc.) and look like random data of random length to an external observer. Thirdly, to conduct an active sample of the protocol, a “Proof of Job” is required as a protection against massive scanning of addresses and ports for the detection of Peat.

In fact, the 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, performing the usual Diffie-Hellman protocol. Since the Montgomery format for representing a point is not a random number, the Elligator2 representation, supplemented by random bytes, is used. After removing the shared secret, the first session is broken, and after a random period of time (several seconds), the 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 a comment. Symmetric keys for encryption and decryption are derived from the obtained secret. The Diffie-Hellman triple protocol is then run in parallel with the SPEKE protocol to protect the caller ID and authentication. In the absence of 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 identity information of participants.

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

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

The main cryptographic primitives (elementary mathematics for X25519, Keccak800, ChaCha20) use compiler-optimized assembler implementations for microcontroller platforms (Cortex M1 and M4), carefully checked for constant execution time and with minimized leakage through the side channels of EMR and fluctuations in current consumption. I must say right away - these assembler codes were received from world-famous professionals, I just ported them from GNU ASM to Keil, which is more familiar for building embedded projects.

Well, what in the end?

If you read up to this place and did not die of boredom, then this project can really be useful to you. If so, then, upon request by mail, I am pleased to provide test assemblies (statically linked executable files, no installation required), as well as the source code for the graphical interface for Windows, Linux and Android in the respective development environments. The core of the project is based on the cross-platform torfone library, available on github search. There you can also find direct links to the alpha version of the Android application and a brief guide to its installation and use, which will help everyone to evaluate the latency of telephony in the Tor network.

The graphical interface is implemented separately for each platform and is not an option (so far this is only alpha testing). The test application for all versions of Windows (starting from ancient Windows 98) was run 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 should work on both 32-bit and 64-bit desktops, the second - 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 still does not know how to create a Foreground service, but, nevertheless, it works stably in Background with the optimization of battery usage disabled. 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 it to another device. At the time of writing, work is underway on a project in the Keil uVision environment, which includes transport, encryption modules, an audio and graphical interface based on Arduino - a compatible 320 * 240 TFT + Touch display. The NanoPi Neo with the installed Debian server and the Nucleo STM32F446RE board connected via a physical UART will be used as an open hardware platform. In the long-term plans - porting to iOS, although I hardly understand how this can be combined with basic security guarantees. keys and address book (in encrypted form) to external storage and recovery when reinstalling Torfon or transferring to another device. At the time of writing, work is underway on a project in the Keil uVision environment, which includes transport, encryption modules, an audio and graphical interface based on Arduino - a compatible 320 * 240 TFT + Touch display. The NanoPi Neo with the installed Debian server and the Nucleo STM32F446RE board connected via a physical UART will be used as an open hardware platform. In the long-term plans - porting to iOS, although I hardly understand how this can be combined with basic security guarantees. keys and address book (in encrypted form) to external storage and recovery when reinstalling Torfon or transferring to another device. At the time of writing, work is underway on a project in the Keil uVision environment, which includes transport, encryption modules, an audio and graphical interface based on Arduino - a compatible 320 * 240 TFT + Touch display. The NanoPi Neo with the installed Debian server and the Nucleo STM32F446RE board connected via a physical UART will be used as an open hardware platform. In the long-term plans - porting to iOS, although I hardly understand how this can be combined with basic security guarantees. Arduino-based audio and graphical interface - compatible 320 * 240 TFT + Touch display. The NanoPi Neo with the installed Debian server and the Nucleo STM32F446RE board connected via a physical UART will be used as an open hardware platform. In the long-term plans - porting to iOS, although I hardly understand how this can be combined with basic security guarantees. Arduino-based audio and graphical interface - compatible 320 * 240 TFT + Touch display. The NanoPi Neo with the installed Debian server and the Nucleo STM32F446RE board connected via a physical UART will be used as an open hardware platform. In the long-term plans - porting to iOS, although I hardly understand how this can be combined with basic security guarantees.

And in conclusion.

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

In fact, the world is not so gray and ruined. And there are many values ​​that cannot be measured with money. But the answer to the first two questions - no way. Well, you can't stop Turfon. You can’t get “keys” from him, you can’t merge the actions of users, even those who have been noticed in terrorism or pedophilia, you can’t ban undesirable people. You cannot force updates. You can not control from the outside. There are no leaks in Torfon, side compounds, except as provided by the protocol. This can be easily checked both in the code (almost every line is commented out and there are not so many files in the project), as well as network analyzers. Therefore, no one will be able to manage Torfon users. But remember: Turfon is just a tool, and all your actions are on your conscience, and you are responsible for them, not the author of the project.