Copyright ownership transferred by assignment 19 May, 2015.

A robust Tor router must carefully balance ease of use against security. This document outlines the hardware and software technical requirements for a Tor enforcing privacy router tailored for portability and defense in depth.

Two modes for the Tor router are provided. The first hosting files on an onion, and the second enforcing Tor use by clients on the local network. Bridges or pluggable transports configured on device may be pushed to clients when direct access to the Tor network is not available.

A password free provisioning step activates the device, with either mode available for use once bootstrapped onto the Tor network. Visual signals on device are used to indicate failure or potential problems. Effort has been made to maximize stand-alone utility rather than always relying on administrative tether.

Issues that arise during use may be fatal, resulting in restart or shutdown of device. They may be errors which allow continued operation despite broken or missing functionality. Or they may be warnings of potential error ahead. Failures use a different signal color scheme than warnings, and informational signals a different color as well.

Failures should be investigated using diagnostics from the privacy director software. Warnings may call attention in case of further problems, however, warnings may also be safely ignored. Hardware experts may use the serial console for monitoring and administration.

Now they are, Yes! See the changes above for Bridge and Pluggable Transport users, including the friction free privacy director provisioning, and a manual verification step for standard Tor Browser users via Tor Launcher enhancement.

Two Local Area Network (LAN) ports separated by USB power port from a single Uplink port makes it easy to distinguish the Local ports from the Uplink port.

Also, when doing any tandem work with another person or device no additional switch or router is required.

RC4 is an unacceptable cipher in any current implementation. RC4 is supported by default in WPA2 with risk of catastrophic failure.

No, you cannot disable this behavior in any consumer WiFi devices. No, this is not TKIP (WPA). Yes, there will be more detail about this type of attack.

WPA2-Enterprise with EAP-TLS is still preferred mode, even with VPN over WiFi. Passwords are inherently insecure through commonality and re-use.

Additional benefits of VPN over WiFi include resistance to TCP RST injection and other DoS attacks, and better handling of transition onto or off of a Tor enforcing network provided by the Tor enforcing router.

No. For best performance of the Tor network as a whole, dedicated high capacity relays are more useful than small devices on limited bandwidth with less availability.

In the future, it might be useful to operate a device as bridge for a small number of users.

A primary high performance i.MX6 SoC is used to drive an AR9331 Ethernet and WiFi SoC, which is kept isolated from the memory of the primary where sensitive information resides. Compromise of networking drivers or IP protocol stacks does not expose keys protected by the primary SoC.

Booting the networking SoC directly from the i.MX6 via SPI AHB Slave fill, or EJTAG DDR fill, ensures that every cycle of the network SoC uses a signature verified current image. On AR9331 SPI_CS_0, SPI_CS_1, SPI_CS_2, SPI_CLK, SPI_MOSI, SPI_MISO, JTAG_TDI, JTAG_TDO, JTAG_TMS, and RESET GPIOs are driven by the i.MX6.

In the future, strong isolation between volatile memory, networking devices, and flash memory may be possible in a single SoC using ARM TrustZone and virtualization extensions.

Physical tamper resistance is difficult to defend against. While the i.MX6 supports this feature, a working implementation able to withstand realistic attacks is beyond scope.

The pocket friendly form factor encourages keeping a device with you to reduce risk of surreptitious tampering by an attacker with physical access to your device.

An early version of this document mentioned USB OTG port as power source. This has been corrected to micro-B USB port, with no OTG support. There is no micro-AB compatibility, and device only operates as peripheral-only B-device.

In the future, a different design might make use of USB OTG support to provide gadget modes of various peripherals, for example during configuration or as USB network link. USB 3.0 Micro-B type plug is also under consideration for increased power consumption.

Yes. We will add either an RP-SMA or H.FL port for external antenna attachment. Note that without manual configuration, the presence and use of an external antenna must be inferred by the driver, and selected automatically. This may interfere with intentions to use a high filter cap, for example, as the internal antenna would always be selected.

Use of external antenna is optional. User is responsible for all FCC or related compliance considerations for any external antenna configuration.

No. A hardware entropy source is used in combination with the default Linux kernel random scavening sources, the haveged collector in user space, and optional additional sources which are under consideration.

In addition, the device always incorporates unique device specific entropy into the pool during initialization, eliminating the possibility of insecure key generation if /dev/random is read immediately on first boot.

Re-provisioning device specific entropy is limited by the few slots of write-once, read-protected flash memory available to store such nonces with strong privacy.

The code signing key distributed with the device, like the device unique entropy above, is stored in write once flash memory. It is not cleared by zeroisation, and can only be updated a limited number of times given the small amount of protected storage available.

The device generates device keys for communication with the owner and privacy director software. These are cleared by zeroisation, and the device must be re-provisioned, as if new from factory, before returning to usable state.

The device generates storage keys for dm-crypt/LUKS on microSD storage devices. These disk keys (all slots) are cleared by zeroisation, and all data on the storage device with it.

The device generates various Tor state and hidden service keys, stored on microSD or flash memory, which is cleared by zeroisation.

The device generates various temporal / ephemeral keys in working memory, which are explicitly cleared by zeroisation. The presence of key material in RAM for seconds after loss of power, without an explicit clear, is unsolved and outside scope for this effort.

Secure boot ties a signing key stored in write-one fuse memory to bootloader validation. If an invalid or malicious image is somehow flashed to device, it will not boot.

Secure boot provides for an upstream signing key, and an owner signing key. These keys can only be updated a limited number of times due to the limited amount of fuse memory available.

Secure boot uses a device specific key to encrypt secondary keys, configuration, and other data at rest. This prevents an attacker from using off-line corruption of storage to compromise device on next use.

Detailed explanation of Thandy, Tor, User, and Device key management to follow.

Tuning this aspect of device operation is an ongoing effort. Right now, descriptors are aggressively fetched which extends the bootstrap duration getting device onto the Tor network, and also adds load to already contended resources.

In addition, it would be nice if users on the Local network could ask the device for consensus information, rather than fetching descriptors over the network per usual. This would need to fail-secure, and not introduce any partitioning attacks against Local users.

Ideas involving out-of-band consensus broadcast, like DVB-T or WiFi, would be useful for keeping this consensus mirroring overhead off the Tor network itself. These are all out of scope for current effort.

No. We do not plan to produce any more evaluation dev boards with test contacts and layout than needed for our own use. These designs are public and open licensed, meaning you are free to have a run of your own development PCBs fabricated.

If sufficient interest for development units presents itself they could be added to volume runs. In the future we would like to design the PCB layout with developer additions as a break-away from the base board. This would let us fulfill developer device orders with more flexibility.

Yes! Currently three methods are available for keying up onion services. The first and default method is to generate a new onion using the ephemeral ADD_ONION command for a One-time onion hostname that persists only as long as the device remains running. You must share the current hostname with others after each power cycle. See the onionwrap utility for example.

A second method involves the privacy director sending the onion service private key securely to the device, for the device to use going forward. This would allow Shallot vanity hostnames to be loaded into a device, for example. This is not quite "picking" your hostname, but rather choosing from a set of possibilities that opportunistic search discovered.

Finally, support for persistent onion hostnames is provided. If chosing to persist the hostname, or loading an onion service private key into the service, the private key is kept on encrypted microSD storage and retained across device power cycle.

No. Only zeroisation on owner command through privacy director, or physical long press of reset pushbutton can invoke zeroisation. This is done to prevent accidental erasure, and for simplicity.

In the future, it might be useful to trigger zeroisation upon a given date, or after some number of downloads, or if a dangerous MAC appears as client on the network, etc. These enhancements are out of scope.

The privacy director software provides each device owner with the means to perform key based administration of the device. It assists with checking for Tor Browser and device updates. It provides an administration channel based on end-to-end mutual authentication. None of which are appropriate for standard browser and a web based interface on a security device.

The captive portal web UI may be used to notify users on the Local network that they must install Tor Browser as only Tor traffic is allowed through an enforcing router. The captive web UI may link to local cached copies of the latest Tor Browser builds, and encourage users to verify signatures from Tor Project. The captive portal web UI is read-only and performs no administrative or persistent actions.

Finally, the privacy director software provides an intuitive, icon based indicator of status in the system tray / menu bar where it is easily observed upon change. It is recommended that all users behind a Tor enforcing router use the privacy director software, not just the owner, as the usability and update improvements are useful regardless.

Due to the cost of flash memory, some persistent state required for Tor and other software is kept on this external storage encrypted. It may be possible to not use the storage heavy features, and introduce a microSD free boot option, however, this is currently not supported.

In the future, it would be nice if more flash memory was available for a storage free mode with all of the usual features, including GeoIP dependent capabilities. Running without microSD card is not supported.

There are two flash memory chips on device, each providing 1024 bytes of one-time program (OTP) memory. This OTP area is divided into 32 individually locked areas of 32 bytes each. One of these areas contains the upstream boot signing key and unique device entropy, another the user boot signing key and device key, and some are used by the processor/flash controller for additional features.

The 3 occupied areas leave 61 others for use in re-generating signing keys or re-initializing after reset to factory defaults. How many times each of these actions may be performed is not yet determined; it will be less than 50 and more than 28.

Be default, all logging except bad exit reporting is disabled.

If explicitly enabled, course grained notice logging is kept on encrypted microSD. Log rotation by hour and by process lifecycle is maintained where possible. Logs are retained as long as there is storage to accommodate them.

Bad exit reports contain logging from the reporting client. These are kept as long as there is storage to accommodate them.

If explicitly enabled, Warnings and Errors as described above are recorded in an additional log file, and retained as long as there is storage to accommodate them.

Specific logging sources, log record types/content, sensitivity level, and retention behavior are yet to be defined in full; work in progress.

Yes. For best performance and security it is recommended that privacy director be run with elevated privileges, and able to modify egress filtering and disable services when on a Tor enforcing network.

It is possible to run without elevated privileges, and the per-user local installation option provides package installation and updates without administrative privileges either. While it is possible to run without elevated privileges, this negatively affects user experience. Filtering traffic and disabling services cannot be performed and some automatic behaviors become manual. E.g. auto detecting transition on or off of a Tor enforcing network does not work in some scenarios, and the privacy director menu must be used to explicitly update view.

There are tamper evident and tamper resistant features available on the i.MX6 SoC, or able to be driven by the SoC through I/O interfaces. The complexity and cost of defending against these types of attacks in a meaningful way, not as marketing check-point, is outside scope of this effort. We encourage technically savvy parties to consider these modifications for their own use, in their own environment, so that the scale of how hard this is to achieve could be explored to benefit of all.

There has been interest in positive pressure and sensor protections around a sealed enclosure, and inexpensive materials like conductive cloth and glitter nail polish, which may one day present a robust or even worthwhile defense against physical attacks on device. These techniques are all out of scope for this effort.

Like hardware tamper resistance and protection, tamper evidence for shipping is difficult and costly to do effectively, and outside scope of this effort. Customers accepting mail delivery accept the risks of interdiction. Be advised that USPS, FedEx, and UPS shipping of any time, even same day priority air, are subject to interdiction of sufficiently interesting targets.

In person direct pick-up or delivery is also an option on extremely limited basis. Cash sale at security or technical conferences has been suggested but involves logistics difficulties; conference sales not currently under consideration.

OpenVPN UDP works sufficiently well on Linux and Mac OS X. This must be installed as available service in order for restricted users to be able to bring up and tear down OpenVPN links to device. Alternatively, VPN GUIs on any can import existing OpenVPN configurations. OpenVPN can be managed by privacy director.

L2TP/IPsec RSA, and IPsec Xauth RSA are supported for Windows and mobile clients. RSA keys must be 2k or larger, preferably 4k. Some hardware VPN equipment fails on 4k keys; try 2k if 4k fails. IPsec can be managed by privacy director.

SAKey/AH/ESP manual drive - during key exchange with device, exchange series of rolling manual key schedule. This eliminates the need for public key based multi-step key agreement protocols like IKE. This was first used during the DEF CON 13 black box challenge over plain-text 802.11 with great success. Limited OS and networking support for this mode. Manual drive IPsec is out of scope for this effort.

No. While the Tor enforcing router will drop any exfiltration or leak packets the attacker may send directly to a collection host, there are plenty of other devastating attacks which can be used to identify you based on hardware or configuration information, which is then communicated to the attacker over Tor itself to Onion service, or a malicious relay directly communicating with targets.

It is recommended that Tor Browser be used in a virtual machine environment that reduces the scope of information that may be obtained in event of a Tor Browser compromise. Note that this too falls short of adequate protection against fingerprinting attacks.

While it is possible to do a deeper inspection of presumed Tor traffic, beyond just matching known relay IP and Port, these techniques may all be circumvented and are out of scope for this effort.

Access Point for local clients is supported. Station/client mode is supported as uplink to the Internet in addition to the Uplink Ethernet port. Monitor mode is used to detect injection attacks against clients when running as Access Point, or when as client itself.

Finally, raw frame injection is used to prevent AP spoofing attacks from succeeding against clients, resulting in a DoS instead, as long as attacker attempts to hijack traffic.

No. When multiple virtual adapters are created off of one physical device, there is still only one radio doing the work of RF receive, transmit, and host communication. For this reason, there is a limit to the number and type of wireless virtual adapter modes which can be used concurrently on a single device.

It is not required. Privacy director identifies and responds upon direct connection to device Uplink with opportunistic exchange that bootstraps secure keying for device driven bridge and PT configuration. This is seamless, and takes only seconds. For this reason it is recommended that bridge and PT using clients also install Privacy Director to automate this for them.

When the device owner puts the device into bridge mode, all clients on the Local network may use a bridge or PT configuration pushed to them by the device. The owner may also set this mode mandatory, blocking any destinations other than the device approved endpoints.

Thus users on the Local network of a device in mandatory bridge mode must use either the privacy director or Tor Launcher with pubkey file method to receive bridge or PT configuration and access the Tor network.

The user may also download a keyfile from captive portal on device when connected to Uplink for Bridge Up provisioning. This keyfile is then used during Tor Launcher start up to arrange secure communication with device for bridge information pushed to client for access to the network.

The user may also select a randomart or randomwords representation of the device pubkey digest. This would be compared with the Owner's view of device digest obtained via privacy director menu or direct device access.

This is under consideration and may involve a series of three Visprint images for each pubkey digest to verify against the Owner's display of the known good Visprints for this device. Three images avoids the occasional single non-distinct image, and also fits a widescreen aspect ratio nicely. Consider a wall projected display visible to many at once, as example.

The device software responds to loss of connection on port, and then resume of connection on port, to trigger a latency test via ARP. Latency to the client with a bridge or switch in path falls outside this threshold, in addition to not triggering port down up if the Uplink port is not used directly.

This is part of the detection used by Privacy Director to automate key exchange and respond to Bridge Up keying transparently.

Powerful cryptanalytic techniques utilizing power analysis, acoustic emanations, LED output levels, EMF emanations, and other types of side channel attack vectors are difficult to defend against with even the best technology.

Protection against cryptanalytic attacks such as these is outside the scope of this effort. SCIF not included! :)

Where possible Ed25519 is used. This has the benefit of mapping exactly to write once fuse memory segments, in addition to using safe curves.

Other credentials may be passed via session established with Ed25519 verified peer. Specifically VPN, WiFi, and Device Driven Configuration information.

No. The Secure Non-Volatile Storage, or fuse box, is used to configure the Central Security Unit and other sensitive information distinct from the owner, device, user, and code signing keys.

The pair of 128 byte arrays, with each fuse box 8 bits, contain the processor security configuration and sensitive information which is protected from access by the processor.

A display or screen on device may be useful for diagnostic and verification purposes, however, this is outside the scope of this effort. A speaker or audio emitter also outside scope.

No, there is no battery of any kind included. The device must always be powered via the micro-B USB port. It is fine to power device with an external Android charging pack, however.

No, not any Control Port or Tor Configuration command may be sent during Device Driven Configuration. This communication is established with device only or mutally identifying key exchange. The nature of the JSON based bridge and pluggable transport configuration directives is yet to be formally specified. However, the scope of what Device Driven Configuration may alter is limited to these few configuration settings, not any option or command at all.

No. This is an open board layout and software only, sourcing electronics components like the processor from manufacturers and suppliers. lowRISC on modern fab a better revision, once available and efficient.

Yes! With the usual transparent proxy caution still applied. Because PC-BSD mode blocks all traffic except Tor traffic, it can be used with a Tor enforcing router device.

There are interesting and useful Tor Trac Tickets! Device specific enhancements open to experiment.

Upstream projects expected to be incorporated into the implementation, or of use in new development provided below. Expected patches against upstream are minor, affecting application defaults and build behavior.

Must opt-in by MAC address mark target. Not allowed to toggle externally.

You must solve all application layer privacy risks yourself, unless only using Tor Browser in transparent proxy mode.

Launch Tails on bare metal or as VM guest instance over the Local network.

Running network boot instances is not recommended unless all local network participants are trusted.

With a device on your home network, and a public port mapping or onion host accessible, you can now access your home resources remotely. Bridge via UDP or TCP OpenVPN for best performance and no anonymity. Use an onion service to tunnel back with stronger privacy protections at cost of higher latency and lower throughput.

Provide ejabberd for XMPP communication through device. Host onionpad collaborative editing software; etherpad as onionpad, and ethersheet as onionsheet. Simple file and nested directory upload and download over onion. BigSun onion in pool, and/or mirror pre-cached on microSD (56G) with shipment.

This is a mode requested for integration into external physical security measures. The intent is to rely on interruption of power to signal breach of security perimeter and trigger zeroisation of sensitive material. Note that data remanence concerns, like cold-boot attack of device memory or direct flash memory reads, are still available to the attacker once access to device itself is achieved.

The assumption for this use is that an attacker may be able to "override" fusebox settings in processor, but not both fuse memory banks and the processor at exhaustion, where there are zero bits left of available fuse storage. By consuming all spare fuse memory, in a fashion similar to performing a series of factory reset operations, the last reset and subsequent start of device is truly Lastboot.

Note that this mode requires a reserve power source, like a capacitor, to enter best case continuous memory wipe via kexec until dead. If power is immediately and spontaneously removed, the dissipation delay for memory on device determines degree of exposure to coldboot style attacks. Data at rest is inaccessible, the keys securely zeroised before, and thus beyond the reach of coldboot or Volatility style memory visibility.

Loss of power may be indicated by owner with shell access; this initiates switch of execution into memory wipe kernel before power off. Loss of power may also be indicated by a peak over-voltage threshold held for 250ms and responded to when in Lastboot. Finally, power may simply cease to device without performing proactive key scrubbing before halt.

While useful application of this mode is complicated and esoteric, meaning: DO NOT RELY ON LASTBOOT AND ASSUME AN ATTACKER CANNOT BYPASS POWER! It is included as optional off-road feature for further experimentation.