Skip to content

Threat model

Jump to bottom
Markus Ottela edited this page Apr 22, 2019 · 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, 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, 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 the tool and processes around it are secure enough for your needs.

Attacks TFC is secure against

1. 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 based on X448. 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.

2. Compromise of server-side logs

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

3. 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.

4. 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.

Attacks TFC is probably secure against

1. TLS-MITM attack against installer using private keys of server / CA

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, exfiltration security of private signing keys of third parties cannot be guaranteed.

Attacks TFC is not secure against

1. 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 serial interface to malware on Networked Computer that 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 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 Source Computer closes permanently after installation.

2. Remote compromise of Destination Computer

Receiver Program authenticates all received packets using Poly1305 MACs. Despite best efforts, it is impossible to guarantee Destination Computer cannot be infected by a sophisticated attacker. This is because the security problem states that Given a security scheme for an operating system, test whether it can be broken, just by using normal commands is an unsolvable 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 attacker has no way to learn the actual content of the on-going 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 displayed messages can be increased with an extended audit period during which displays of both devices are either recorded or observed simultaneously.

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

  • 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.

  • User might forget to remove wireless interfaces such as Wifi, 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 Destination Computer with emissions
      • Electromagnetic channels (eavesdropped by the antenna of nearby smartphone/implant)
      • Thermal channel (eavesdropped by nearby temperature sensor / thermal camera)
        • Artificial workload (BitWhisper)
        • HVAC systems connected to TCB-side network (HVACKer)
      • 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 camera in space / outside the window)
    • Source or Destination Computer might unintentionally leak sensitive data to nearby smartphone, device or implant
4. 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 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.

5. 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 key loggers or spy cameras in the space TFC is operated in, nor from physically observing screen and 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 symmetric keys are stolen, 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.

6. 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.

Will TFC hide my metadata?

Below is a dissection of different types attacks to obtain metadata about user activity. These attacks are made by two different types of attackers: Eve is the 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 Networked Computer's screen and 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 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.

Geolocation of user

Networked Computer is a normal computer, that comes with an ever-increasing number of sensors from Wireless interfaces to GPS antennas, microphones, web cameras and so on, that can deanonymize the user or reveal their location to Mallory. Stripping all sensors is highly recommended. An additional layer of anonymity can be obtained by connecting to a random public WiFi access point using a long-range parabolic or Yagi antenna.

IP address of user

Ubuntu 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.

Type of data transmitted

When traffic masking is disabled, sent files appear to Eve as large bursts of Tor cells, which indicates file transmission but only during traffic confirmation attacks. Mallory, however, can see when the user outputs files.

When traffic masking is enabled, 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 user

Regardless of traffic masking, 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 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 operation schedule, 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 user interacts with the TFC's Relay Program (e.g., 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 padding to round the length of the compressed message to 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.

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 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 reduces the issue of close proximity attacks by a significant margin.

Clone this wiki locally