{{Header}} {{title|title= {{project_name_short}} Threat Model }} {{#seo: |description=Technical Design Documentation about {{project_name_long}} Threat Model. This document covers aspects like Attacker Capabilities, Goals, and Attack Surface. }} {{tech_intro_mininav}} {{intro| Technical Design Documentation about {{project_name_short}} Threat Model. This document covers aspects like Attacker Capabilities, Goals, and Attack Surface. }} == Classification of Threats == == Note == The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [https://www.ietf.org/rfc/rfc2119.txt RFC 2119]. == The Threats == First, let's quickly consider all the possible threats we could face. We can categorize threats against computer systems into five categories: ; 1. '''Non-technical/non-computer-based and legal attacks''' :* Examples include: ::* "Rubber hose cryptanalysis" ::* Mandatory key disclosure ::* Subpoenas ::* Real detective work/espionage (done by real humans, not bots) ::* Bugs ::* Surveillance cameras ; 2. '''Hardware attacks through physical access''' :* Examples include: ::* RAM and Hard disk Forensics ::* Keyloggers ::* TEMPEST ::* Evil Maid attacks ; 3. '''Backdoors''' :* Intentional weaknesses or additional hidden "functionality" inserted into your system by a manufacturer, vendor, or distributor (hardware or software) allowing remote access1. :* These can be introduced anywhere from: ::* Design/source code ::* Manufacturing/compilation ::* Distribution ;;* Learn more about {{kicksecure_wiki |wikipage=Malware_and_Firmware_Trojans#Backdoors |text=Backdoors }}. ; 4. '''Vulnerabilities''' :* Coding or hardware design errors that can be exploited to gain remote access.Used in the broadest sense, vulnerabilities can manifest as remote code execution, privilege escalation, DoS, etc. Essentially, they all allow remote parties to send your system instructions that diverge from the established security policy. :* In practice, vulnerabilities and backdoors can appear identical; only their creation methods differ. ; 5. '''Design flaws''' :* Even in a system free of backdoors and errors, with perfect physical and legal protection (which doesn't exist in reality), achieving perfect security may still be elusive. :* This is particularly true for anonymity systems. ::* While perfect cryptographic design exists (the one-time pad), anonymity isn't binary. ::* You're not simply anonymous or not; you possess some non-zero but imperfect degree of anonymity. ::* Your anonymity hinges on blending in with others. ::* Anonymity networks necessitate trust and a sizable, diverse user base. ::* A perfectly secure system wouldn't rely on trust in others or on such external factors. ::* Every complex (yet still usable) system design (all computer systems are complex) involves trade-offs. That's why the majority employ imperfect cryptography instead of the one-time-pad... Lastly, it's worth noting that the bug mentioned in [https://gitlab.torproject.org/legacy/trac/-/issues/5928 Research: IP discovery through Tor behind isolated network] seems to primarily concern determining the IP address a Tor client uses to connect to the Internet. It does not touch upon other types of information leakage. == Attacker capabilities == === Legal/Non-technical "attacks" and physical access === * Legal/Non-technical "attacks" and physical access are expensive. Anything that requires real humans to work, rather than relying on computers and algorithms, is prohibitively expensive for more than a small target group. === Backdoors === * Both hardware and software backdoors are costly to implement. Creating one is difficult and comes with risks. * The more frequently a backdoor is used, the more likely it will be detected and closed. Adversaries are unlikely to waste such tools on anything but high-profile targets. * Well-hidden passive "backdoors" are concerning as they can be nearly impossible to detect and may remain functional for years. * Consider a backdoor in a compiler affecting the PRNG. The cost of implementing such a backdoor is high, requiring patience, sophisticated coding, social engineering, and cryptography skills. However, the potential return on investment could be significant. === Software attacks === * Software attacks are economical. While a good 0-day exploit can be expensive and loses its usefulness once deployed, new vulnerabilities emerge regularly, and new exploits can be developed. * Compared to physical access and backdoors, software attacks are more cost-effective and can be automated for a broad target set. * If you question the significance or realism of the threat from client application 0-days, consider pwn2own 2012. A semi-legal, albeit questionable company, demonstrated their ability to exploit every web browser, bypassing all advanced security features (MAC, Sandbox, ASLR, NX, etc.). * Such findings are not shocking, given that large codebases will always contain bugs, some of which are exploitable. What stands out is that this company doesn't disclose their findings to the software developers; instead, they sell this information to governments (or the highest bidder) as offensive "cyber weapons" (though they wouldn't term it as such). * It is plausible that vulnerabilities in Tor are also being sold discreetly. Therefore, one should never rely solely on Tor, especially when requiring robust anonymity from well-funded adversaries. === Crypto-attacks === * Crypto-attacks are extremely expensive. If one discovers a method to break the currently used encryption, they will likely keep it a secret. * Most cryptographic attacks probably necessitate vast computing resources. === Attacking design flaws === * Attacking design flaws varies in cost. The expenses can differ significantly, but in every instance, once a design flaw is attacked and it becomes public knowledge, the target will rectify the flaw, making it tougher to exploit in the future. * This dynamic could lead to an arms race, which neither party may desire. * A significant issue for the defending party is that some systems have become so ubiquitous that transitioning to a more secure design is nearly impossible. * A prime example is the certificate authority system. Its design has numerous flaws, but nearly every computer user relies on it for authentication and confidentiality. * Similarly, the lack of crypto and hash agility in many applications results in dependence on fragile and compromised algorithms. This isn't due to ignorance but because of the demands of backward compatibility and the problems a few malicious actors can cause. * There's a threshold where, if an attacker remains discreet, they can operate undetected for an extended period, giving everyone the impression that the situation isn't "that bad yet." * For instance, a [https://en.wikipedia.org/wiki/Collision_attack#Attack_scenarios collision attack] against SHA-1, affecting various applications, including Tor, GPG, and TLS, has been deemed feasible for a potent adversary since 2005. With advances in technology and attack methods, the number of potential adversaries has only grown. SHA-1 will likely remain in widespread use until a collision is publicly demonstrated — not because we lack alternatives, but because the costs of transitioning are so steep. == Our Goals == * '''Hiding our Location and Identity when transmitting information''': Ensuring that our physical location and personal or organizational identity remain anonymous when sending or receiving information. * '''Confidentiality, Integrity, Authenticity, and Availability of transmitted data''': ** '''Confidentiality''': Ensuring that the data remains private and is only accessible to those intended to have access. ** '''Integrity''': Guaranteeing that the data remains unchanged during transmission, and no unauthorized alterations occur. ** '''Authenticity''': Verifying the source and destination of the data, confirming that it's coming from and going to legitimate entities. ** '''Availability''': Making sure that data remains accessible and retrievable when needed, especially during crucial moments. == Our Attack Surface == Every component we utilize to achieve our goals presents a potential attack vector: ; '''Physical Security and Privacy''': : Physical security and privacy are IMPERATIVE. Without them, achieving anonymity and confidentiality becomes challenging, if not impossible. ; '''Tor & Its Components''': : When considering Tor — its code, design, and the entire network (refer to [[Dev/Anonymity Network]] for details) — it's essential not to view Tor in isolation. We MUST consider its entire TCB ([https://en.wikipedia.org/wiki/Trusted_computing_base Trusted Computing Base]). If any component of the TCB is compromised, the Tor process can be undermined. For backdoor threats, the entire TCB is the attack surface, while for vulnerabilities, only the network-facing components of the TCB are. :* '''{{project_name_gateway_long}} Hardware''' :* '''GNU/Linux/OS''': The kernel, essential userland, APT, and all software update packages provided by the {{os}} distributor/vendor. :* '''Tor itself''' :* '''Build System & Virtualization''': The build system (e.g., gcc). Using Virtualization (as opposed to Physical Isolation) enlarges the TCB significantly. This includes: :: Host Kernel :: Host applications :: Host software updater :: Virtualization software ; '''Software Dependencies & Functions''': : It's CRUCIAL that the software we employ doesn't exceed its necessary functions, as this might compromise our anonymity through protocol leaks, identity correlation via Tor circuit sharing, and fingerprinting. To ensure this, we also depend on the {{project_name_workstation_long}} and the TCB of the applications we utilize. (For more details, see [{{project_name_short}} Protocol-Leak-Protection and Fingerprinting-Protection]). ; '''Confidentiality, Integrity, and Authenticity''': : To guarantee these, we (and this includes everyone, not just {{project_name_short}}) rely far too heavily on TLS (Transport Layer Security, the "s" in https). We also depend on: :* The entire Host (both Hardware and Software) :* All software within {{project_name_workstation_short}} :* TLS/PKI infrastructure :* For onion services: The full location/identity TCB. :* The security of the entity you're communicating with, unless employing symmetric key cryptography where you possess the exclusive key. ; '''Availability of Information''': : Our dependencies include: :* The reliability and connectivity of the upstream internet provider :* The Tor network's ability to withstand DoS attacks :* The resistance of the webservers you access to DoS assaults :* Your system's capability to resist DoS attacks. == Applying the threat model to {{project_name_short}} == === High Profile Target Considerations === First, you don't want to be on the "high profile target" list of any resourceful adversaries. If you are, neither {{project_name_short}} nor any other computer-based system can protect you. === Hardware Scope and Limitations === {{project_name_short}} is primarily a software project. Our scope for hardware and physical aspects is limited. Hardware security wouldn't be as significant an issue if we weren't dealing with monolithic systems where multiple parts have full system access through DRM or indirectly via hardware drivers that run in kernel space. Consider examining Qubes OS for cutting-edge hardware deprivileging. While it requires modern hardware and a larger user base, integrating {{project_name_short}} with Qubes OS was done in form of [[Qubes-Whonix]]. === Trustworthy Hardware and Recommendations === Assuming the hardware is trustworthy and the physical location uncompromised, it's RECOMMENDED to use "clean" computers with parts from reputable manufacturers and to make purchases in cash to prevent hardware IDs from revealing our identity. For forensic analysis protection, full disk encryption SHOULD be used on the host, and RAM should be wiped upon shutdown. Implementation status: Since {{project_name_short}} doesn't yet include a host operating system, we RECOMMEND users follow the guidelines provided in the {{project_name_short}} documentation. === Hardware Best Practices === Some additional pointers: * Favor IOMMU over DMA, and avoid attaching untrusted devices to FireWire and PCI* interfaces. * Opt for open-source hardware or at least hardware that's open-source friendly, meaning they make specifications public. With open source, multiple companies can produce the hardware, making backdoors more challenging to introduce. * Embrace simplicity. Complexity is security's primary adversary. {{project_name_gateway_short}} could operate on straightforward hardware like the Raspberry Pi. === Cryptographic Considerations === Regarding cryptography, the approach we can take is to use [https://en.wikipedia.org/wiki/Multiple_encryption cascades] of varying cipher and hash families. However, it's more intricate than it seems, and no known software achieves this correctly. === Focus on Software Attacks === As mentioned in the "Attacker capabilities" section, our main area of focus should be software attacks. === Software Defense Mechanisms === To defend against software backdoors and vulnerabilities: * The source should be audited, preferably both by you and numerous others, and should ideally be free of bugs. Popular open source projects are your best bet. As {{project_name_short}} is fully open source, anyone can audit and submit patches. -> [[Reasons for Freedom Software]] * If you depend on others (and you do), ensure that you receive the same code as everyone else. Hash sums and signatures, especially when made public, can help verify this. If transparent signing (common in proprietary systems) is used, it becomes harder to confirm that you're receiving the same files as everyone else. By default, signing ensures you're receiving code from someone with access to the signing key, which protects against third parties, but not potential insiders. The checksums and signatures for {{project_name_short}} and its updates are made publicly available. * The code you utilize should have a strong track record. -> [[Whonix_against_Real_Attacks|{{project_name_short}} Track Record against Real Cyber Attacks]] ** Any known issues must be promptly addressed. Code that isn't regularly scrutinized but has no known issues is more concerning than code with many known (but patched) security vulnerabilities that is under continuous review. However, truly trustworthy code should have minimal, if any, security issues despite rigorous audits. It's worth noting that projects requiring frequent security patches are inherently insecure. But it's not just about the quantity of issues; the severity of bugs is also crucial. For instance, while Linux receives many security patches, critical vulnerabilities that could impact {{project_name_short}} (like remote code execution with root privileges) are rare. However, critical flaws in user-facing applications, such as browsers, PDF readers, media players, and IRC, are more common, and such software shouldn't be a part of the TCB (referenced below). * Merely reviewing the source isn't sufficient; trustworthy binaries are essential. Analyzing binaries is considerably more challenging than scrutinizing source code. If you're dependent on source code auditing, you must have a trustworthy compiler (along with a fully trusted system on which to run it) and utilize [https://dwheeler.com/trusting-trust/ DCC]. In the same vein, a trusted system is imperative for verifying signatures and hashes. This introduces the bootstrapping dilemma often likened to the "chicken and egg" problem. Generally, to circumvent this, you should employ at least two distinct, unrelated systems (including their foundational build systems and compilers). The systems should be configured in a manner that both would need simultaneous compromise by the same adversary, in a compatible manner, to result in a significant security breach. === Protecting against Software Vulnerabilities === If the code base is large and complex, code auditing is not a realistic strategy. Therefore, we need to reduce complexity and the attack surface by: * Making the TCB small, and * Using privilege separation: The TCB for identity/anonymity is as small as it can be on a monolithic general-purpose OS. It could be smaller (e.g., a custom kernel, busybox, uclibc instead of libc, and gnu-utils), but that would increase the cost in terms of maintainability, security updates, and ease of use. (And this still leaves us with a comparably large monolithic kernel and a vast gcc infrastructure.) Linux/Xorg (with DAC or even MAC) does not excel at privilege separation (e.g., no trusted path). The most robust privilege separation is achieved by using multiple physical computers, which we RECOMMEND, as seen in [[Dev/Build_Documentation/Physical_Isolation|Physical Isolation]] and [[Multiple Whonix-Workstation|multiple {{project_name_workstation_short}}]]. A more practical, but less secure, alternative is virtualization. For details about privilege separation between IRC/Browser/Clients and Tor, see [[Dev/Technical Introduction]]. We've spent considerable time considering ways to make {{project_name_short}} even more secure, but with the (free and open source) tools available today, it doesn't seem feasible. We would require an isolation kernel that offers robust guarantees of isolation between different subsystems and would ideally be verified. This way, concerns about sophisticated backdoors (barring those from the compiler, as discussed in "Trusting trust"/chicken and egg), software vulnerabilities, and even some hardware backdoors and vulnerabilities (through IOMMU and microkernel design one can move hardware and firmware components, aside from the CPU, out of the TCB) would be alleviated. For Fingerprint/Protocol leaks and the [https://en.wikipedia.org/wiki/CIA_triad#Key_concepts CIA Triad], we rely on the {{project_name_workstation_short}} TCB. This presents a dauntingly large TCB/attack surface. Therefore, we employ another strategy, "security through non-persistence". Specifically, you should frequently utilize the clone feature and rollback capabilities of the virtual machine. Instead of enforcing privilege separation within a Tor-Workstation (e.g., by using a Mandatory Access Control framework) which would result in significant usability compromises, we recommend the coarse-grained isolation provided through multiple VMs. To protect specifically against software attacks (vulnerabilities): * Make the software challenging to attack with tools like ASLR, canaries, NX, and kernel hardening. (See the Debian section [[Dev/Operating_System#Debian|About Debian]].) It's essential to understand that this makes attacks "harder" but not impossible. Hardening is not a substitute for fixing bugs. In a genuinely trustworthy system, hardening wouldn't be necessary. === Design Flaws and Single Points of Failure === To mitigate design flaws, the primary strategy is to eliminate single points of failure: * You SHOULD NOT rely solely on Tor; use WiFi or tunnel through [[Dev/Anonymity Network|anonymity network]] if available. (Not really.) [[Why_does_Whonix_use_Tor|Why does Whonix use Tor]] * You SHOULD NOT rely solely on TLS; also use GPG (and vice versa). * You SHOULD NOT rely on a software monoculture. * You SHOULD NOT expect the Debian infrastructure to remain uncompromised forever. We currently do not adhere this advice. * To lessen the impact of a potential compromise of the update infrastructure, which includes developer machines, build systems, and key security and cryptographic primitives like PRNG (remember OpenSSL or Flame?), we do not enable automatic software updates. After all, these are essentially remote root-level backdoors, albeit with some checks in place. == Notes about securing Confidentiality, Integrity and Authenticity == This is no different than in any other computer system without Tor. You MUST use end to end public key encryption, there is not really an alternative to that. But there are alternative implementations: TLS, SSH, GPG... End-to-End means, both ends need to be secure, one end is the {{project_name_workstation_short}}, which you can control and secure. In case of onion services, the {{project_name_gateway_short}} is ALSO part of the TCB! {{project_name_workstation_short}} is not specifically hardened because hardening a Desktop system to a degree that makes it actually secure against a serious adversary makes the system unusable. Instead we follow the nuke and restore approach, see [[Multiple Whonix-Workstation|Multiple {{project_name_workstation_short}}]] and [[Security_Guide#Recommendation_to_use_multiple_VM_Snapshots|Recommendation to use multiple Snapshots]]. About Availability: The most resilient approach is probably a distributed data store, like Tahoe-LAFS or Freenet. I2P offers multi-homing built in. For Tor we don't know of any solutions ready for general usage. == Notes about End-to-end security of Onion Services == Moved to [[Onion_Services#Notes_about_End-to-end_Security_of_Onion_Services|Notes about End to end Security of Onion Services]] == Attack on {{project_name_short}} == There is a comparison of Tor Browser, Tails, {{project_name_short}} Standard/Download version (host+VM+VM) and {{project_name_short}} with Physical Isolation in chapter [[Comparison_with_Others#Attacks|Attacks against {{project_name_short}}]]. == Design Document, Innovations, and Research == The {{project_name_short}} developer, Adrelanos, has a keen interest in serious design documents. Currently, there exists only one design document pertaining to Tor, transparent/isolated proxying, isolation, and Virtual Machines. Adrelanos has reviewed the old design paper titled "A Tor Virtual Machine Design and Implementation" from 2009. After reviewing, Adrelanos refined that paper by removing non-essential, non-security-relevant content, ensuring all considerations from the old design paper were incorporated into {{project_name_short}}. The entirety of {{project_name_short}} [[Documentation]] and [[Design]] supersedes the old design document. Adrelanos also monitors the following documents: * [https://tails.boum.org/contribute/index.en.html Tails Design] * [https://tails.boum.org/contribute/design/ Tails Design: Specification and Implementation] * [https://dee.su/liberte-security Security and Anonymity in Liberté Linux] ([https://archive.ph/srdCd archive.ph]) * [https://dee.su/liberte-motivation Liberté Linux Motivation and Philosophy] ([https://archive.ph/https://dee.su/liberte-motivation archive.ph]) Any security/privacy/anonymity updates will be considered for inclusion in {{project_name_short}}. The {{project_name_short}} project is committed to asking pertinent questions, offering valuable suggestions, and creating useful tools. -> [[What we do]] The following list helps track all discussions and periodically review them to discern any changes: * Smarm initiated a serious discussion on [[Dev/Leak Tests Old]], which was subsequently scripted by Adrelanos (see [[Dev/Leak Tests]]). This discussion may be of value to other projects as well. * [https://web.archive.org/web/20170222032855/https://mailman.boum.org/pipermail/tails-dev/2012-June/001245.html Tails-dev Removing SSL CA Dependency for HTP] * [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/torsocks Modified usewithtor to Support Setting IP and Port by Command Line Parameter by Adrelanos] * [https://gitlab.torproject.org/legacy/trac/-/issues/5928 Research: IP Discovery through Tor behind Isolated Network] * [https://gitlab.torproject.org/legacy/trac/-/issues/5611 Enhance "Transparent Torification (Requires Custom transproxy or Tor Router)" in Tor Button.] * For further discussions, consult [[Dev/Archived Discussions]] and the associated archives. Our approach is always considered; everyone is welcome to contribute, and we strive to make informed decisions. * [https://lists.torproject.org/pipermail/tor-talk/2012-May/024227.html tor-talk Tor Browser Disabling Javascript Anonymity Set Reduction] * [https://lists.torproject.org/pipermail/tor-talk/2012-March/023535.html tor-talk Awareness for Identity Correlation through Circuit Sharing is Almost Zero.]; [https://gitlab.torproject.org/legacy/trac/-/issues/6102 Add Warning Related to Identity Correlation through Circuit Sharing] * [https://lists.torproject.org/pipermail/tor-talk/2012-March/023486.html tor-talk Operating System Updates / Software Installation behind Tor Transparent Proxy] * [https://lists.torproject.org/pipermail/tor-talk/2012-August/025128.html tor-talk Attack against Tor: Statistic Manipulation Attack] * [https://web.archive.org/web/20170222032804/https://mailman.boum.org/pipermail/tails-dev/2012-July/001394.html Tails-dev tails_htp: Exit Relay can Fingerprint Tails Users until Exit Relay is Changed]; [https://web.archive.org/web/20170222032556/https://mailman.boum.org/pipermail/tails-dev/2012-August/001421.html 2] * [https://web.archive.org/web/20170222032726/https://mailman.boum.org/pipermail/tails-dev/2012-August/001436.html Tails-dev Better IRC Client, Include HexChat] * [https://web.archive.org/web/20141005211329/https://mailman.boum.org/pipermail/tails-dev/2012-August/001422.html Tails-dev Separate Tor Streams] * ... This list is not exhaustive... == {{project_name_short}} Threat Model not available as PDF or paper version == You may skip this optional chapter. While we read actual papers, such as the [https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf Onion routing design paper] and many others, we cannot be compelled to create a paper titled "Designing an anonymous operating system" using LaTeX for PDF output. As Mike Perry, a developer of the Tor Browser, [https://lists.torproject.org/pipermail/tor-talk/2012-May/024405.html stated], "''I find the PDF format heavy and unnerving from a security perspective.''". We share this sentiment and also find the PDF format inconvenient. Learning LaTeX, mastering PDF creation, and understanding formatting etiquette would consume considerable time. Time we would prefer to allocate to design enhancements, development, and other endeavors. The "Onion routing design paper" is now outdated, and we prefer an editable, frequently updated, and revised website over a static paper or PDF. Tails does not offer a design paper in PDF format either, yet it has garnered significant attention from both users and developers. Similarly, TrueCrypt did not have a design paper on plausible deniability, but it still underwent a review by Bruce Schneier and others. Hence, we do not see the inherent benefits of making our threat model available in PDF. However, if we have missed any advantages, please do not hesitate to inform us. = Footnotes = {{Footer}} [[Category:Design]]