Whonix Threat Model

From Whonix
< Dev
Jump to navigation Jump to search

Technical Design Documentation about Whonix Threat Model. This document covers aspects like Attacker Capabilities, Goals, and Attack Surface.

Classification of Threats[edit]

Note[edit]

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 RFC 2119archive.org.

The Threats[edit]

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 logo Backdoors Onion Version .
4. Vulnerabilities
  • Coding or hardware design errors that can be exploited to gain remote access.[1]
  • 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 Research: IP discovery through Tor behind isolated networkarchive.org 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[edit]

Legal/Non-technical "attacks" and physical access[edit]

  • 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[edit]

  • 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[edit]

  • 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[edit]

  • 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[edit]

  • 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 collision attackarchive.org 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[edit]

  • 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[edit]

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 (Trusted Computing Basearchive.org). 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.
  • Whonix-Gateway™ Hardware
  • GNU/Linux/OS: The kernel, essential userland, APT, and all software update packages provided by the operating system (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 Whonix-Workstation™ and the TCB of the applications we utilize. (For more details, see [Whonix Protocol-Leak-Protection and Fingerprinting-Protection]).
Confidentiality, Integrity, and Authenticity
To guarantee these, we (and this includes everyone, not just Whonix) 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 Whonix-Workstation
  • 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 Whonix[edit]

High Profile Target Considerations[edit]

First, you don't want to be on the "high profile target" list of any resourceful adversaries. If you are, neither Whonix nor any other computer-based system can protect you.

Hardware Scope and Limitations[edit]

Whonix 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 Whonix with Qubes OS was done in form of Qubes-Whonix.

Trustworthy Hardware and Recommendations[edit]

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 Whonix doesn't yet include a host operating system, we RECOMMEND users follow the guidelines provided in the Whonix documentation.

Hardware Best Practices[edit]

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. Whonix-Gateway could operate on straightforward hardware like the Raspberry Pi.

Cryptographic Considerations[edit]

Regarding cryptography, the approach we can take is to use cascadesarchive.org 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[edit]

As mentioned in the "Attacker capabilities" section, our main area of focus should be software attacks.

Software Defense Mechanisms[edit]

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 Whonix 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 Whonix and its updates are made publicly available.
  • The code you utilize should have a strong track record. -> Whonix 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 Whonix (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 DCCarchive.org. 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[edit]

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 Physical Isolation and multiple Whonix-Workstation. 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 Whonix 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 CIA Triadarchive.org, we rely on the Whonix-Workstation 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 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[edit]

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 anonymity network if available. (Not really.) 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[edit]

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 Whonix-Workstation, which you can control and secure. In case of onion services, the Whonix-Gateway is ALSO part of the TCB!

Whonix-Workstation 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 and 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[edit]

Moved to Notes about End to end Security of Onion Services

Attack on Whonix[edit]

There is a comparison of Tor Browser, Tails, Whonix Standard/Download version (host+VM+VM) and Whonix with Physical Isolation in chapter Attacks against Whonix.

Design Document, Innovations, and Research[edit]

The Whonix 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 Whonix.

The entirety of Whonix Documentation and Design supersedes the old design document.

Adrelanos also monitors the following documents:

Any security/privacy/anonymity updates will be considered for inclusion in Whonix.

The Whonix 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:

This list is not exhaustive...

Whonix Threat Model not available as PDF or paper version[edit]

You may skip this optional chapter.

While we read actual papers, such as the Onion routing design paperarchive.org 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, statedarchive.org, "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[edit]

  1. ↑ 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.
Your support makes
all the difference!

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!

Retrieved from "https://www.whonix.org/w/index.php?title=Dev/Threat_Model&oldid=97071"