Tor Enforcing Privacy Router serqet345qt265xp.onion Copyright © 2015 Tor Project, Inc. by assignment Tue May 19 00:48:03 UTC 2015 __________________________________________________________________ Table of Contents [1]1. Tor enforcing privacy router device and software [2]1.1. NOTICE: This work is not affiliated with, nor approved of by Tor Project, Inc. [3]1.2. Not the typical Tor router! [4]1.3. Why use this? [5]1.4. Uses [6]1.5. Error handling [7]2. Solution scope [8]2.1. Threat model [9]2.2. Device hardware technical requirements [10]2.3. General software requirements for devices and clients [11]2.4. Device software and configuration technical requirements [12]2.5. Privacy director system tray icon and menu [13]2.6. Privacy director technical requirements [14]2.7. Security and performance testing technical requirements [15]3. Bill of materials - major components [16]4. Frequently asked questions [17]4.1. Are Tor bridges supported? [18]4.2. Why three Ethernet ports? [19]4.3. Why is VPN required over WiFi with WPA2? [20]4.4. Can my device act as a relay or exit node? [21]4.5. Why are there two processors on one device? [22]4.6. If device is opened can alarm or zeroise trigger? [23]4.7. What was this about USB OTG for power? [24]4.8. Is it possible to attach an external WiFi antenna? [25]4.9. Is the hardware random number generator the only entropy source? [26]4.10. What key material is erased by zeroise / factory reset? [27]4.11. What do you mean by secure boot? Who gets to sign? [28]4.12. How does the device keep consensus current and complete? [29]4.13. Will you also make development and test boards available? [30]4.14. Can I pick my onion hostname? How are they generated? [31]4.15. Can secure factory reset / zeroisation be tied to some event or date? [32]4.16. Why is Privacy Director software required instead of using a Web Admin UI? [33]4.17. Will the device boot if there is no microSD card inserted? [34]4.18. How much protected flash memory is available? [35]4.19. What audit and debug logging is available? How long is it saved? [36]4.20. Does the firewall modification by privacy director require elevated privileges? [37]4.21. Do you protect against an attacker with physical access to device itself? [38]4.22. Will you provide tamper evident packaging for devices shipped through mail? [39]4.23. What specific VPN protocols are supported to device? [40]4.24. If the attacker exploits my Browser, am I still protected? [41]4.25. Which 802.11 WiFi modes are supported? [42]4.26. Can I use an Access Point and two Client/Station connections at once? [43]4.27. Why is privacy director required for bridge or PT use? [44]4.28. Are there other keying methods for bridge users? [45]4.29. What about using Visprint SHA images for bridge users? [46]4.30. How does the device know when Uplink is not directly connected for Bridge Up? [47]4.31. Does the device resist power, EMF, or acoustic cryptanalysis? [48]4.32. What signature algorithm is used to verify owner, device, users, and code? [49]4.33. Are keys also stored in the i.MX6 processor fusebox? [50]4.34. Will secure display be included, like an LCD read-out on device? [51]4.35. Is battery power included on device? [52]4.36. Can the device tell my Tor Launcher to use only specific relays? [53]4.37. Is the device design and processor 100% Open Hardware? [54]4.38. Will PC-BSD Tor mode work with the device? [55]4.39. What other enhancements for Tor and related software? [56]5. Additional resources [57]5.1. Software resources [58]5.2. Hardware resources [59]5.3. Research and testing [60]6. Off-road options [61]6.1. Transparent DNS and TCP Tor proxy gateway [62]6.2. PXE boot targets for local clients [63]6.3. Home network bridge over VPN or onion service [64]6.4. Expanded onion services [65]6.5. Lastboot [66]7. Legal notice [serqet.jpg] 1. Tor enforcing privacy router device and software 1.1. NOTICE: This work is not affiliated with, nor approved of by Tor Project, Inc. Copyright ownership [67]transferred by assignment 19 May, 2015. 1.2. Not the typical Tor router! 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. * Additional defense for [68]Tor Browser; drop and warn upon Tor bypass or DNS leak. * Not a replacement for Tor run by each client; no additional stream isolation concerns. * Not a magic transparent proxy gateway. [69]Application layer is critical privacy ground! * Easy to use without compromising robustness. 1.3. Why use this? * May save your skin! Having back-up always useful. * Keep Tor Browser, Tor Birdy, Tails, other software on hand and up to date. * Easily share files on an Onion service with others. * Seamlessly provision a room of Bridge users behind fascist firewalls. * Even for no reason other than supporting Tor Project and providing cover! :) 1.4. Uses 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. First time setup * On Windows, Mac OS X, or Linux client install privacy director software * Directly connect client computer to Ethernet jack on device * Provide power and boot device without microSD card inserted * Wait for initialization pending signal * Insert microSD card back into device * Wait for keygen complete signal * Confirm device setup actions via privacy director menu Portable privacy * Provide power and wait for ready light * Connect to local network via WiFi or Ethernet jack on device * Check for software updates via privacy director menu * Launch current Tor Browser * Confirm Tor is working correctly via check site Onion filehost * Provide power and wait for ready light * Connect to local network via WiFi or Ethernet jack on device * Copy files to local staging folder * Initiate copy to device from this folder via privacy director menu * Alternatively mount as network filesystem via privacy director * Copy onion URL into copy/paste buffer via privacy director menu * Confirm content is accessible on your onion using Tor Browser Local user * Connect to local network via WiFi or Ethernet and obtain DHCP lease * Observe failed connections or captive portal redirect * Navigate to captive portal and download Tor Browser * Also download Tor Browser signature and verify before use * Launch current Tor Browser * Confirm Tor is working correctly via check site Public bridge user * Connect to local network via WiFi or Ethernet and obtain DHCP lease * Observe failed connections or captive portal redirect * Navigate to captive portal and download Tor Browser * Also download Tor Browser signature and verify before use * Launch current Tor Browser * Enter a public bridge configuration during Tor Launcher network setup * Confirm Tor is working correctly via check site Bridge and pluggable transport users * Owner connects to Local network via WiFi or Ethernet and privacy director * Owner selects Bridge or Pluggable Transport mode and endpoints, disconnect Uplink * Device signals transition into Bridge Up to Owner and via LED emitter * User connects directly, no switches, to Uplink port with privacy director * Observe successful exchange of bridge user pair with device * Disconnect from Uplink port, connect to Local WiFi or Ethernet, pass Uplink to next * Launch current Tor Browser configured to pull bridge or PT config from device * Confirm Tor is working correctly via check site Secure factory reset * For when you need to wipe keys and media * Owner sends secure factory reset signal via privacy director menu * Alternatively owner accesses device and holds factory reset pushbutton for long press * Keys purged off device, zeroised fatal error is signaled once complete * Device must be re-provisioned to restore service! 1.5. Error handling 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. FATAL conditions * Not initialized * No Tor network, unable to build circuits * Hardware failure * Zeroised * Fuse storage depleted Failure conditions * Network upstream error * Date/time error * LAN error * Wireless error * Malicious local network activity * microSD media error * Service/Watchdog error * Update error Warning conditions * Client privacy leak detected * Low remaining free space on microSD card * Slow to bootstrap onto Tor network * Transient upstream issue * LAN contended * Wireless congested * High CPU load * High temperature reported * Timeout trying to check for or download updates 2. Solution scope Requirements span device hardware, device software, and client software. Additional test requirements may be provided for security oriented elements. 2.1. Threat model * Include the [70]Tor Browser and [71]Tor Button model; enforce Tor at each client, not transparent gateway. * Attacker is able to bypass Tor Browser proxy settings and transparent proxy rules on a client system. * The local network is un-trusted; a plain-text wireless hop presumed in path. * Passwords are inherently vulnerable through commonality and re-use. Key based authentication required. * Users behind the Tor router may be co-opted to attack others on the Local network. * Attacker has capabilities against reduced key space and poor entropy. * Active defense to mitigate LAN middle attacks - resulting in denial of service instead - is acceptable. * Remainder similar to many [72]Internet threat models, and omitted for brevity ... 2.2. Device hardware technical requirements Mandatory components * Hardware entropy generator with access to un-whitened output * Secure boot sequence * Dual flash bootrom and protected storage * Once write and read protected memory in processor and flash * At least 32MByte of flash memory for firmware * At least 512MByte of working memory (RAM) * At least 16GByte external microSD storage * Wi-Fi and Ethernet System-On-Chip 802.11b/g/n , 10/100 * Two or more Ethernet ports; dynamic set Upstream / Local roles * USB port for DC power User interaction and indication * Tri-color Red, Amber, Blue LED, PWM drive - unless set silent * Errors flash Red; FATAL is solid Red three seconds before cycle * Amber indicates warnings; may be disabled * Blue means ready when solid; pending action when flashing * All emitters solid On - holiday lamp style - is zeroised signal Open hardware * Device schematics available under open license * Board layouts available under open license * PCB runs manufactured domestically * Processor, memory, and other surface mount components sourced via 3rd parties with discretion. 2.3. General software requirements for devices and clients * Format hardening * Fortify source hardening * Stack protector hardening * PIE and RANDUSTACK hardening * RELRO and MPROTECT hardening * BINDNOW hardening * PAGEEXEC / NX hardening * ring0 ExecShield / KERNEXEC hardening * ring0 ASLR with RANDMMAP and RANDKSTACK hardening * non-SOFTMODE PaX * Verified signatures on upstream dependencies * Signed builds and packages for every build and package * Reproducible builds on all platforms 2.4. Device software and configuration technical requirements * Mix device unique entropy from fuse mem at start * Run rng daemon at boot using hardware entropy source * Require VPN on local WiFi and Ethernet network * Signature and digest verification for Tor Browser, other extensions * Full device encryption for microSD storage * Network ports identified Upstream or Local ports based on broadcast peers, perspective * Secure factory reset with zeroisation of all sensitive key material 2.5. Privacy director system tray icon and menu * All privacy director interaction is achieved through tray icon and menu * Show notactive, waiting, warning, error, and ready state via icon effects * Detect network access and expand menu if device owner * Bad exit behavior reporting * Add to or wipe microSD storage for files if owner; no delta sync * Secure factory reset command if owner 2.6. Privacy director technical requirements * Support Windows, Mac OS X, and Linux systems * Provide a system tray icon with menu behavior as above * First time setup of new device using bootstrap protocol * Diagnostics and error reporting from device * Filter local traffic that is not Tor when active * Services and tasks disabled when active * Check for Tor software updates and signal user; install or defer until restart * Auto-startup Tor Browser when connected to Tor enforcing network 2.7. Security and performance testing technical requirements * Network routing validation tests * Stress testing LAN capacity * Stress testing onion host capacity * LAN hijack ARP injection tests * WiFi access point impersonation tests * Concurrent connection peak tests * Tor consensus update and expiry tests 3. Bill of materials - major components * Freescale i.MX6 Solo BGA SoC [73][octopart] [74][spec] * Atheros 9331 LPCC WiFi SoC [75][octopart] [76][spec] * 2G, 1.35V, DDR3L, 128Mx16, 96 ball BGA [77][octopart] * 2 x SPI NOR Flash 3V/3.3V 256M-bit 256M x 1 8ns 24-Pin BGA Tray [78][octopart] * DDR2 SDRAM 1G-Bit 64Mx16 1.8V 84-Pin FBGA Tray to WiFi SoC [79][octopart] * 3 x RJ-45 Integrated Magnetics Thru-Hole 8 Terminal 1 Port Cat 5/Cat 6 [80][octopart] * 4 as Red, Amber, Blue, CoolWhite SMT LEDs [81][octopart] [82][spec] | alt: [83][octopart] [84][spec] * 2 x H.FL-R-SMT WiFi 2.4Ghz and 4.8Ghz antenna connectors [85][octopart] 4. Frequently asked questions 4.1. Are Tor bridges supported? 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. 4.2. Why three Ethernet ports? 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. 4.3. Why is VPN required over WiFi with WPA2? [86]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. 4.4. Can my device act as a relay or exit node? 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. 4.5. Why are there two processors on one device? 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 [87]ARM TrustZone and virtualization extensions. 4.6. If device is opened can alarm or zeroise trigger? 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. 4.7. What was this about USB OTG for power? 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. 4.8. Is it possible to attach an external WiFi antenna? 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. 4.9. Is the hardware random number generator the only entropy source? 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. 4.10. What key material is erased by zeroise / factory reset? 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. 4.11. What do you mean by secure boot? Who gets to sign? 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. 4.12. How does the device keep consensus current and complete? 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. 4.13. Will you also make development and test boards available? 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. 4.14. Can I pick my onion hostname? How are they generated? 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 [88]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. 4.15. Can secure factory reset / zeroisation be tied to some event or date? 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. 4.16. Why is Privacy Director software required instead of using a Web Admin UI? 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. 4.17. Will the device boot if there is no microSD card inserted? 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. 4.18. How much protected flash memory is available? 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. 4.19. What audit and debug logging is available? How long is it saved? 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. 4.20. Does the firewall modification by privacy director require elevated privileges? 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. 4.21. Do you protect against an attacker with physical access to device itself? 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 [89]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. 4.22. Will you provide tamper evident packaging for devices shipped through mail? 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. 4.23. What specific VPN protocols are supported to device? 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. 4.24. If the attacker exploits my Browser, am I still protected? 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. 4.25. Which 802.11 WiFi modes are supported? 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. 4.26. Can I use an Access Point and two Client/Station connections at once? 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. 4.27. Why is privacy director required for bridge or PT use? 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. 4.28. Are there other keying methods for bridge users? 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. 4.29. What about using Visprint SHA images for bridge users? This is under consideration and may involve a series of three [90]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. 4.30. How does the device know when Uplink is not directly connected for Bridge Up? 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. 4.31. Does the device resist power, EMF, or acoustic cryptanalysis? Powerful cryptanalytic techniques utilizing [91]power analysis, [92]acoustic emanations, LED output levels, [93]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! :) 4.32. What signature algorithm is used to verify owner, device, users, and code? Where possible [94]Ed25519 is used. This has the benefit of mapping exactly to write once fuse memory segments, in addition to using [95]safe curves. Other credentials may be passed via session established with Ed25519 verified peer. Specifically VPN, WiFi, and Device Driven Configuration information. 4.33. Are keys also stored in the i.MX6 processor fusebox? 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. 4.34. Will secure display be included, like an LCD read-out on device? 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. 4.35. Is battery power included on device? 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. 4.36. Can the device tell my Tor Launcher to use only specific relays? 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. 4.37. Is the device design and processor 100% Open Hardware? No. This is an open board layout and software only, sourcing electronics components like the processor from manufacturers and suppliers. [96]lowRISC on modern fab a better revision, once available and efficient. 4.38. Will PC-BSD Tor mode work with the device? 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. 4.39. What other enhancements for Tor and related software? [97]There are interesting and useful Tor Trac Tickets! Device specific enhancements open to experiment. 5. Additional resources 5.1. Software resources 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. [98]Official tor, tor-launcher, tor-browser, torbutton, torbirdy, tor-messenger, torsocks, all pluggable-transports, stem. [99]Thandy, TUF, Firefox Updater . Thandy well suited to package management on Windows as well as stand-alone network installer with BitTorrent and HTTP support. See also, [100]Tor VM archive 2009. [101]Das U-Boot and [102]Genode OS framework with Linux. [103]GNU Privacy Guard, [104]OpenVPN, [105]OpenSSL. 5.2. Hardware resources [106]KiCad electronic design automation. EAGLE to be avoided. [107]USB Armory a useful reference; schematics and layout in KiCad using the predecessor i.MX53 processor in BGA package. 5.3. Research and testing [108]Security Audit of Safeplug "Tor in a Box" [109]Chattering Laptops [110]A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients [111]Performance and Security Improvements for Tor: A Survey 6. Off-road options THESE CONFIGURATIONS ARE NOT SUPPORTED AND MAY PUT YOU AT RISK. Off-road options require ssh and console skills to apply. Use at your own peril! You have been warned... :) 6.1. Transparent DNS and TCP Tor proxy gateway Must opt-in by MAC address mark target. Not allowed to toggle externally. You must solve all [112]application layer privacy risks yourself, unless only using Tor Browser in [113]transparent proxy mode. 6.2. PXE boot targets for local clients 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. 6.3. Home network bridge over VPN or onion service 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. 6.4. Expanded onion services 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. 6.5. Lastboot 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. 7. Legal notice You may distribute or modify this document according to the terms of the [114]Creative Commons Attribution 4.0 International License. Copyright assigned by owner to Tor Project, Inc. "Tor® is a registered trademark of The Tor Project, Inc." "Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries." "Mac OS X® is a registered trademark of Apple Inc." "Windows® is a registered trademark of Microsoft Corporation in the United States and other countries." [nodikpic-director.png] References Visible links 1. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#mainbody 2. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#stddisclaimer 3. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#overview 4. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#thepitch 5. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#uses 6. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#conditions 7. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#scope 8. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#threatmodel 9. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#hwreqs 10. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#genreqs 11. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#swreqs 12. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#pdirtray 13. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#pdirreqs 14. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#testreqs 15. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#bom 16. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faq 17. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqbridges 18. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqthreeport 19. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqwpa2sucks 20. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqnorelay 21. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqtwoproc 22. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqintrusion 23. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqpower 24. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqextantenna 25. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqentropy 26. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqzeroise 27. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqkeyswhowhat 28. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqconsenus 29. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqdevboards 30. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqonions 31. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqtrigger 32. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqwebui 33. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqlightboot 34. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqprotectedmem 35. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqlogging 36. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqrequiresroot 37. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqphysicaltamper 38. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqtamperevidence 39. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqvpnfauna 40. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqclientsec 41. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqwifimodes 42. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqwifimany 43. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqbridgekeying 44. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqmanualkeying 45. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqmanualvisprint 46. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqtricksyuplinksy 47. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqsidechannel 48. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqcsuite 49. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqprocfusebox 50. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqsecuredisplay 51. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqbattery 52. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqdevicedriveall 53. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqopenhw 54. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqbsdtrans 55. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#faqtortrac 56. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#seealso 57. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#software 58. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#hardware 59. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#research 60. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#offroad 61. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#offtransproxy 62. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#offpixieboot 63. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#offbounce 64. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#onionsvcs 65. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#lastboot 66. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html#idp42186320 67. https://lists.torproject.org/pipermail/tor-dev/2015-May/008766.html 68. https://www.torproject.org/projects/torbrowser/design/ 69. https://www.torproject.org/docs/torbutton/en/design/#fingerprinting 70. https://www.torproject.org/projects/torbrowser/design/#adversary 71. https://www.torproject.org/docs/torbutton/en/design/#adversary 72. https://tools.ietf.org/html/rfc7258 73. https://octopart.com/mcimx6l3dvn10aa-freescale+semiconductor-24100887 74. http://datasheet.octopart.com/MCIMX6L3DVN10AA-Freescale-Semiconductor-datasheet-12593765.pdf 75. https://octopart.com/ar9331-al1a-atheros-25896507 76. https://www.openhacks.com/uploadsproductos/ar9331_datasheet.pdf 77. https://octopart.com/is43tr16128bl-125kbl-tr-issi-34842436 78. https://octopart.com/s25fl256sagbhic00-spansion-25647521 79. https://octopart.com/mt47h64m16hr-25%3Ah-micron-12682910 80. https://octopart.com/j00-0064-pulse-283932 81. https://octopart.com/latbt66b-z-osram+sylvania-41146958 82. http://datasheet.octopart.com/LATBT66B-Z-Osram-datasheet-502232.pdf 83. https://octopart.com/lz4-00ma10-ledengin-11809579 84. http://datasheet.octopart.com/LZ4-00MA10-LedEngin-datasheet-8642921.pdf 85. https://octopart.com/h.fl-r-smt%2801%29-hirose-39537126 86. https://www.lightbluetouchpaper.org/2015/05/02/meeting-snowden-in-princeton/ 87. http://genode.org/documentation/articles/arm_virtualization 88. https://github.com/yawning/onionwrap 89. https://gnunet.org/benes2014panic 90. http://www.tastyrabbit.net/visprint/ 91. https://github.com/newaetech/chipwhisperer 92. https://en.wikipedia.org/wiki/Acoustic_cryptanalysis 93. https://en.wikipedia.org/wiki/Van_Eck_phreaking 94. http://ed25519.cr.yp.to/ 95. http://safecurves.cr.yp.to/ 96. http://www.lowrisc.org/docs/tutorial/ 97. https://trac.torproject.org/projects/tor/wiki/AnonOnWikiFavs 98. https://gitweb.torproject.org/ 99. https://lists.torproject.org/pipermail/tor-dev/2013-August/005228.html 100. https://peertech.org/files/torvm-dl-cache.tar.xz#sha256-049710dc66154411e43b7989e388ba6064d730b9a9281d0b38371260f697ecfb 101. http://www.denx.de/wiki/U-Boot 102. http://genode.org/ 103. https://gnupg.org/ 104. https://openvpn.net/ 105. https://openssl.org/ 106. http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite 107. https://github.com/inversepath/usbarmory 108. https://www.usenix.org/conference/foci14/workshop-program/presentation/edmundson 109. http://www.chiark.greenend.org.uk/~mroe/research/pets2008.pdf 110. http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf 111. https://eprint.iacr.org/2015/235.pdf 112. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html 113. file:///var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html 114. http://creativecommons.org/licenses/by/4.0/ Hidden links: 116. file://localhost/var/lib/mailman/archives/private/cypherpunks/attachments/20191013/c1539a82/attachment-tmp.html