Skip to content

Threat model

Jump to bottom
Markus Ottela edited this page Sep 21, 2022 · 28 revisions

Understanding security

Security is a process, not a product. It is also about economics. Briefly explained, each attacker has a set of capabilities, privileges, and a certain amount of budget, time and motivation. Given enough of these resources, the security of any process will fail; The goal when securing a system is to add layers of security that make attacks too expensive.

Nation-state actors have massive budgets, and no single system can be made secure enough against targeted attacks. However, if widely deployed, systems that cannot be compromised with automated attacks, increase the attacker's cost linearly and thus force the attacker to pick targets. Such systems are the only way to make mass surveillance infeasibly expensive.

The primary goal of TFC is to provide secure communications under the emerging threat of automated remote exploitation. The scalability of these attacks is enabled by the fact zero-day exploit deployment cost is negligible compared to the sunk cost of its development.

As the security layers of TFC are not perfect and vary depending on the configuration used, the benefits and limitations of the layers need to be explained. This article attempts to explain the full threat model TFC is designed against so that you (the user) can make an informed decision on whether a configuration and the surrounding processes are secure enough for your needs.

TFC configurations

TFC runs in three distinct configurations that offer varying levels of endpoint security and thus, varying level of overall security:

  • Hardware-isolated configuration (maximum security)
  • Qubes-isolated configuration (high security)
  • Local testing configuration (low security)

TFC configurations (even larger image)

While the configurations are inter-compatible in use, the user and their peers must all collectively select the configuration they consider secure enough for their needs.

Note: The majority of the screenshots of TFC are taken from the local testing configuration, as it's the easiest way to take screenshots that capture the state of all three programs of one endpoint at the same time. This does not mean users should run TFC in the local testing configuration!

Hardware-isolated configuration

The hardware-isolated configuration should be selected when the communication must stay secure even if an organized crime unit or nation state actor tried to remotely hack the devices of the user to steal the keys and messages from the endpoints.

Protects from

Passive eavesdropping

Passive eavesdropping of the backbone of the Internet is the most common form of surveillance. TFC is end-to-end encrypted with 256-bit XChaCha20-Poly1305, a state of the art symmetric cipher that will not be broken even by a universal quantum computer running Grover's algorithm. The weak link is, however, public key cryptography, the X448 key exchange to be specific. While X448 is in practice unbreakable by classical super computers, large quantum computers running so-called Shor's algorithm will eventually be able to break the X448 key exchange, leading to retrospective decryption of conversations that relied on the key exchange protocol. If such threats are part of the threat model, TFC also has support for password-protected pre-shared keys (PSK) that cannot be broken by a quantum computer.

Compromise of server-side logs

TFC is a p2p system that uses native software -- excluding packet routing it runs exclusively on users' devices. The Tor Onion Service (i.e., the server) runs as part of the Relay Program on user's Networked Computer and only sees encrypted data. Private keys or plaintexts are never uploaded to any third party in the network.

MITM attacks against end-to-end encryption

Man-in-the-middle attacks against the end-to-end encryption can be detected by comparing the public key fingerprints via an authenticated out-of-band channel, preferably over Signal call or during face to face meeting. PSKs exchanged face to face are also secure against MITM attacks.

Computer Network Exploitation (CNE) after setup

After setup, TFC cannot be remotely compromised, as the hardware data diode physically blocks either insertion of malware or exfiltration of keys/plaintexts with inserted malware. TFC is currently the only tool that offers such protection. CNE might sound like a non-issue as it has traditionally been considered targeted surveillance, but it turns out nation-states are rapidly automating it, meaning it will become the mass surveillance of tomorrow.

Context-aware content manipulation

Since there is no way for attacker to exfiltrate plaintexts, it's extremely difficult change the content of messages in a way that takes into account the context (what is being discussed at that moment).

Does not protect from

Key/plaintext exfiltration with malware installed remotely before/during setup

If the Source Computer is compromised before or during setup, it can later covertly transmit private keys through the data diode to malware on the Networked Computer that then forwards the keys to an adversary in the network. The risk is real, but in comparison, all other end-to-end encrypted protocols such as the Signal protocol and OTR are vulnerable to key exfiltration attacks all the time, as the operation of applications using the protocols requires that the TCB remain connected to the Internet. In TFC, the window of opportunity to exfiltrate keys from the Source Computer closes permanently after installation.

TLS-MITM attack during installation

As long as the user has a way (face-to-face meeting with the developer or web of trust) to obtain the authentic fingerprint of the PGP key used to sign the installer, installation is mostly secure against MITM attacks. TFC is installed with a one-liner, the pinned SHA256 fingerprint of which authenticates the 4096-bit PGP/RSA signature verification key, which in turn authenticates the installer. If the attacker has a sufficient universal quantum computer that is capable of running Shor's algorithm, the authenticity of the installer cannot be reliably guaranteed with PGP signatures. The installer comes with pinned SHA512 hashes of all files downloaded from TFC's GitHub repository. These files include the requirements*.txt-files that contain the SHA512 hashes for dependencies downloaded over PIP. However, TFC requires dependencies (namely git, libssl-dev, net-tools, python3-pip, python3-setuptools, python3-tk, and Tor) that are downloaded with APT, and while the related public signature verification key is pinned to the OS, the exfiltration security of the private signing keys of third parties cannot be guaranteed.

Remote compromise of Destination Computer

The Receiver Program authenticates all received packets using Poly1305 MACs. Despite the best efforts, it is impossible to guarantee Destination Computer cannot be infected by a sophisticated attacker. This is because the security problem (Given a security scheme for an operating system, test whether it can be broken, just by using normal commands) is an intractrable problem similar to the halting problem. In the situation where the Destination Computer is compromised, the attacker will have the capability to

  1. Destroy data with, e.g., an injected shell command.

  2. Display arbitrary messages: This attack is also part of the security problem, but luckily it is very difficult, as the remote attacker has no way to learn the actual content of the ongoing conversation. Therefore, the displayed message is very likely to be out of context. If the forged messages are logged, the attack can be detected by cross-comparing Transmitter Program's log of Alice with Receiver Program's log of Bob and vice versa. Assurance against malware substituting content only in the displayed messages can be increased with an extended audit period during which displays of both devices are either recorded or observed simultaneously.

Key/plaintext exfiltration over any covert channel the user has not addressed

  • The user might reuse removable media used to deliver PSKs. In such case Destination Computer could infect Source Computer that could then exfiltrate sensitive data. The PSK transmission media from an untrustworthy contact might also contain a covert transmitter, that an accompanied malware might use to exfiltrate key material.

  • The user might forget to remove wireless interfaces such as Wi-Fi, LTE, Bluetooth, and NFC from Source or Destination Computer. The interface could then be used to infiltrate malware or exfiltrate keys.

  • In addition to these channels, multiple covert ones -- that could leak or be used to exfiltrate keys from Source or Destination Computer -- have been found:

    • Malware could exfiltrate data from the Destination Computer with emissions
      • Electromagnetic channels (eavesdropped by the antenna of a nearby smartphone/implant)
      • Thermal channel (eavesdropped by a nearby temperature sensor / thermal camera)
      • Power lines (eavesdropped by tapping into the main electrical service panel of the building)
      • Acoustic channel (eavesdropped by a nearby microphone or laser microphone that has line-of-sight)
      • Optical channel (eavesdropped by a camera in the space / outside the window)
    • Source or Destination Computer might unintentionally leak sensitive data to nearby smartphone, device or implant
Covert channel based on user interaction

There exists a possibility, where an attacker could compromise Destination Computer in a way that makes the device display some message based on key data. The user's reaction to that message on Source Computer that is visible either to the Networked Computer (i.e., when traffic masking is disabled) or to the recipient (i.e., when the attacker is also a contact), can leak key data to the adversary. The only way to prevent this is to enable TFC's traffic masking feature and to vet contacts carefully. More information here.

Close proximity surveillance and house intrusion

TFC is designed to protect against remote data exfiltration. It does not prevent someone in the close proximity of the user from eavesdropping on any malicious/unintended emissions. It is a truism TFC also does not prevent anyone from installing keyloggers or spy cameras in the space TFC is operated in, nor from physically the observing screen and the keyboard of the user.

TFC encrypts persistent user data to prevent impersonation and simple forms of physical data exfiltration, but weak password or keyloggers remotely installed on Destination Computer can still compromise persistent data if the system is later physically compromised. Use of full-disk-encryption (FDE) is highly recommended, but protection against bootkits and evil maid attacks are out of scope for TFC.

TFC provides forward secrecy meaning retrospective decryption of unlogged messages is impossible. However, TFC does not provide future secrecy. Thus, if the user is deanonymized, geolocated, and their symmetric keys are physically stolen from the endpoint, all future conversations can be decrypted. To recover from such an attack (assuming it will not repeat), the user has to replace the Source Computer (now assumed to be infected) and generate new keys. The risk of close-proximity implants might render future setups insecure, thus recovery while the user is under targeted attack, might be impossible.

Interdiction of hardware

Nation-state actors have been caught installing malicious implants into hardware ordered online. If hardware such as computers/optocouplers user has bought is pre-compromised to the point it actively undermines the security of the user, TFC (or any other piece of software for that matter) is unable to provide security on that hardware.

Denial of Service attacks

It is a truism TFC is not able to maintain connection in a situation where the ISP / nation state turns off access to the Internet or if they're successful in censoring the Tor network.

Traffic confirmation attacks

To quote Roger Dingledine, the director of Tor Project:

The way we generally explain it is that Tor tries to protect against traffic analysis, where an attacker tries to learn whom to investigate, but Tor can't protect against traffic confirmation (also known as end-to-end correlation), where an attacker tries to confirm a hypothesis by monitoring the right locations in the network and then doing the math. Source

Qubes-isolated configuration

Running TFC on Qubes allows Xen hypervisor based isolation for the TCBs. In Qubes-isolated configuration, each TFC program runs on a dedicated Debian 10 virtual machine (VM) called a Qube. The Source and Destination VMs are isolated from the network by the hypervisor, and inter-VM data transfers are handled with qrexec RPC calls.

The Qubes-isolated configuration adds some protection against remote key/plaintext compromise. It is not (and will never be) as secure as the hardware-isolated configuration:

  • If the Networked VM running the Relay Program and the hypervisor are compromised with a chain of exploits where one allows VM escape, the endpoint security of the entire host OS will fail catastrophically.
  • If the Networked VM is compromised and the attacker manages to compromise the Destination VM through the qrexec's vchan channel, the attacker can then exfiltrate keys and plaintexts via Xen's shared memory, or establish a slow, control flow based covert channel, where e.g. the RPC buffer's "full" status is used to signal whether a bit in some sensitive key is one or zero.
  • Furthermore, there are numerous bugs in CPUs that allow VMs to access sensitive data of another VM via CPU cache.

That being said, architecture-wise, the Qubes-isolated configuration is still much, much more secure than e.g. the local testing configuration, or any other E2EE messaging app on a single networked OS, whether that OS is running as host or as a Qubes guest VM. An attacker can compromise a networked OS via many paths, and if keys and plaintexts reside in that system, they are trivial to exfiltrate. In contrast, TFC's Qubes-isolated configuration has extremely tiny attack surface, as compromise of Destination VM requires compromising the qrexec framework, or TFC's RPC service:

  • Xen / qrexec is much easier to secure than an entire OS, and only 60 Xen vulnerabilities over the past ~9 years have affected Qubes.
  • The TFC's RPC service merely caches the incoming ciphertexts into files. Furthermore, the stored data is always encoded in Base85 which adds to the execution prevention that's already provided by the guest OS's access control lists.

The Qubes-isolated configuration should thus be used when the adversary is assumed to be in possession of some exploits, but not in possession of rare Xen exploits.

Assuming no VM escape or propagation to Destination VM, protects from

  • Passive eavesdropping
  • Compromise of server-side logs
  • MITM attacks against end-to-end encryption
  • Computer Network Exploitation (CNE) of Networker VM after setup
  • Context-aware content manipulation

Does not protect from

  • Key/plaintext exfiltration with malware installed remotely before/during setup
  • Malware/CNE that utilizes a VM escape exploit
  • Malware/CNE that breaks into Networker and Destination VM and that exfiltrates keys through
    • CPU cache
    • Xen shared memory
    • control flow based covert channel
  • Remote compromise of Destination VM that results in
    • existential forgeries
    • loss of data
  • Key/plaintext exfiltration over any other covert channel the user has not addressed
  • Covert channel based on user interaction
  • Close proximity surveillance and house intrusion
  • Interdiction of hardware
  • Denial of Service attacks
  • Traffic confirmation attacks

Local testing configuration

The local testing configuration is an easy way to emulate a complete TFC system (software and hardware) with just software, on a single Linux OS (Debian/PureOS/*buntu/PopOS/LMDE). It is mainly intended for users who want to try out the features and study the system before buying TCB-side computers and building the data diode (or before installing Qubes for the related TFC configuration).

Warning! The local testing configuration does not provide endpoint security.

If however, the threat model does not include a scenario where someone is going to try to remotely hack the user, the local testing configuration still offers superior protection against adversaries in the network who would try to observe content and/or metadata of users' communication. The local testing configuration is thus an alternative to normal end-to-end encrypted apps like Signal (that does not anonymize the user with Tor by default), under similar threat model.

Window manager isolation

Warning! The X11 window manager does not protect inputs to e.g. TFC Transmitter Program from other user-level applications running in the background. Use of Wayland is thus necessary when running TFC in the local testing configuration.

Assuming no remote CNE / malware, protects from

  • Passive eavesdropping
  • Compromise of server-side logs
  • MITM attacks against end-to-end encryption
  • Context-aware content manipulation

Does not protect from

  • Key/plaintext exfiltration with Malware or via Computer Network Exploitation (CNE) of the host OS
  • Existential forgeries and/or data loss with Malware or via Computer Network Exploitation (CNE) of the host OS
  • Key/plaintext exfiltration over any covert channel the user has not addressed
  • Covert channel based on user interaction
  • Close proximity surveillance and house intrusion
  • Interdiction of hardware
  • Denial of Service attacks
  • Traffic confirmation attacks

Will TFC hide my metadata?

Below is a dissection of different types attacks to obtain metadata about user activity. These attacks are performed by two different types of attackers: Eve is an eavesdropper who is monitoring traffic at ISP level. Mallory is a malicious active attacker who has compromised the Networked Computer and is observing what inputs the computer receives from the network, Source Computer, and local peripherals, and what it outputs to the Networked Computer's screen and to Destination Computer.

The amount of metadata TFC leaks depends on whether traffic masking is enabled. When it is enabled, Transmitter Program will output a constant stream of noise messages to Receiver Program of the selected contact or members of the selected group. In the dissection below, if traffic masking setting affects the end-result, the implications of both setting values are discussed.

Real-life identity of the user

Since Relay Program reveals nothing about the identity of the user or their contacts, the identity of the user is not revealed even to Mallory. However, as any personal files on Networked Computer can reveal the identity of the user, use of Tails live USB (that does not store personal files) is highly recommended. Registration details of Networked Computer's hardware can also deanonymize the user, so the use of commercial off-the-shelf (COTS) hardware paid with cash is highly recommended.

IP address of the user

Debian based Networked Computer does not force all connections via Tor by default, so it can trivially reveal the user's IP-address to Mallory. Use of Tails OS (that enforces Tor routing) on Networked Computer is highly recommended. This is because on Tails, special care has been put to whitelist applications' rights to request e.g. the public IP address of the endpoint.

Type of data transmitted

When traffic masking is disabled, sent files appear to Eve as large bursts of Tor cells. The burst will indicate a file transmission, but it requires a traffic confirmation attack. Mallory on the other hand, can see when the user outputs files.

When traffic masking is enabled, the Source Computer will output messages and files inside assembly packets, amidst noise packets. As all these packets look identical to Mallory, the type of transferred data is hidden from both Eve, and Mallory.

Social graph of the user

Regardless of traffic masking setting, Eve learns nothing about the social graph of the user. However, Mallory can see to which call signs (Onion Services) the user talks to, as well as what kind of groups the user has formed from them, and when the user talks to the group. Mallory will not be able to learn whether an incoming message from a contact is a private message or a group message, unless she has also compromised the Networked Computer of the sender. However, as long as Mallory is unable to determine the real-life identity of users, their social graph remains hidden.

Quantity and schedule of communication

When traffic masking is disabled, Eve only sees that a burst of Tor cells was uploaded to the network. However, Mallory can see when and how many messages the user sends to each contact.

When traffic masking is enabled, Source Computer will output a constant stream of noise messages to Networked Computer. To prevent the user from accidentally revealing interaction with contacts, changing the active recipient of messages is disallowed. That way TFC hides quantity and schedule of output messages from both Eve and Mallory. It should be noted, however, that the use of Networked Computer reveals to Mallory that the user is present. It does not indicate TFC is being used, unless the user interacts with the TFC's Relay Program (e.g., if the user closes and reopens the application).

Message length

When traffic masking is disabled, Eve can only see Tor traffic, but Mallory can see how many packets Source Computer outputs to each contact. However, since TFC applies compression and adds padding to the compressed message to round its length to the next 255 bytes before encryption, Mallory does not learn the exact length of message or file.

When traffic masking is enabled, even Mallory will be unable to tell when message or file transmissions start or stop. The moment the transmission of a message or a file completes, the next packet will again be a noise packet.

Existence of Onion Server and the fact TFC is used

Assuming Eve does not know the full TFC account, she is unable to decrypt the blinded Introduction Points in the Onion Service descriptor to establish a connection to the server.

Since Mallory is assumed to have control over the Networked Computer, she both knows the Onion Service's address and that it represents a TFC endpoint. However, since each TFC user looks like a typical Tor user, it is difficult for her to know which computers she should compromise in the first place. The fact it's hard to even figure out who is using TFC (and where they are physically located) makes close proximity attacks very difficult.

Clone this wiki locally