Let's start with the risk model. Our adversary wants to associate us with our online identities and activity. It wants to know who we are, what we're doing, who we communicate with, and so on. It observes our network activity, relying on intercepts from our ISPs, remote sites that we access, and intervening networks. And it tries to install backdoors, in order to access our data, and also to circumvent our attempts to anonymize our online activity.
Given that, we must consider all networks outside our perimeter firewall to be untrusted. Indeed, we must even consider our workspaces to be untrusted, given the risk of backdoors installed by malware. Risks of workspace compromise can be mitigated through OPSEC. However, compromised workspaces would also put our network stacks at risk, and so it's prudent to isolate them.
In isolating the tor process and workspace apps, one can simply route all TCP traffic through Tor's TransPort, and route DNS lookups (which are UDP) to its DnsPort. The Tor Project does not recommend this: "All applications will be forced through the same TransPort, thus mixing them all into the same circuit which leads to identity correlation through circuit sharing."
Alternatively, one can configure each app to use a particular SocksPort, either natively or using a wrapper such as torsocks, uwt (torsocks with stream isolation) or proxychains-ng.
Better yet, one can use an isolating proxy: "All applications can only access internet over Tor. Direct connections are impossible due to either a virtual internal network and/or physical isolation." The canonical example is Whonix: "Whonix is divided into two parts: Whonix-Workstation for your work and Whonix-Gateway for automatically routing all internet traffic through Tor. This is security by isolation, and it averts many threats posed by malware, misbehaving applications, and user error."
The most straightforward Whonix implementation comprises a pair of VirtualBox VMs. However, VirtualBox was not designed with security in mind. It's more secure to use Whonix in Qubes: "Qubes is based on Xen and Fedora, and through hardware support (VT-x, VT-d, TXT) Qubes provides a world class security-by-isolation architecture, while also offering a single integrated user-friendly desktop experience across VMs." Still, given what we now know about the NSA's Equation Group, relying on VM-VM isolation, even in Qubes, is iffy. And so it's safest to physically isolate the Whonix gateway and workstation.
Therefore, we want physical isolation of networking and workspace. But we also want something that's portable. What follows is a prototype for that, using two Raspberry Pi 2 Model B v1.1 ARM-based microcomputers. However, missing packages in Raspbian wheezy prevent building Whonix on the Pi. As a workaround, I've replicated basic design features in Raspbian wheezy. I've also added an iVPN client to the gateway, and adapted adrelanos' VPN-Firewall rules to lock it down. I found it much easier to write these how-to guides using a particular VPN service, because there's no need to cover alternative setups. And I picked iVPN because it's familiar and reliable.
Both network gateway Pi and workspace Pi are running Raspbian wheezy, with updated firmware. It's best to use Class 10 microSDHC cards, 8GB for the gateway Pi and 32GB for the workspace Pi, because they're much faster and more reliable. The gateway Pi has a USB-to-ethernet adapter, because we need both WAN (eth0) and LAN (eth1) adapters. Optionally, they both employ full-disk encryption, using standard Linux dm-crypt/LUKS, plus LVM2, which permits integrated encryption of root and swap partitions.
The gateway Pi connects to the Tor network through iVPN, and then reaches the Internet through Tor. Firewall rules allow outgoing connections on WAN (eth0) only to iVPN servers, Raspbian wheezy repository servers (for package updates) and NTP timeservers. No DNS servers are reachable via WAN (eth0) and so the IP addresses of these servers must be specified or resolved locally. Firewall rules allow outgoing connections on the VPN tunnel interface (tun0) only by the Tor client process. The Tor Browser and other apps on the workspace Pi can reach the Internet only through the Tor client process on the gateway Pi.
The gateway Pi boots with no iVPN route connected, and it allows no traffic from the workspace Pi to the Internet. If the gateway Pi is FDE, you SSH to dropbear, and open the LUKS volume. Then you SSH to the gateway Pi, and run a start script. The script prompts for your iVPN (etc) username and password, which it stores in RAM, and the name of the route that you want to use. It then starts the OpenVPN service, waits for connection, and then restarts the Tor service.
You need a DVI monitor (perhaps via an HDMI-DVI adapter) or an HDMI TV, a USB keyboard, and a USB mouse or touchpad. It's important to use a good power supply. Each Pi 2 uses 600-2000mA at 5V. Inadequate voltage at load may lead to instability and errors. Overvoltage supplied via the micro-USB power cable will temporarily trip the polyfuse. The USB ports bypass the polyfuse, so voltage surges on powered USB hubs can fry the Pi.
Steps