The 4th USENIX Workshop on Free and Open Communications on the Internet is calling for papers. The workshop will be held on August 18, 2014 and seeks to bring together researchers and practitioners working on means to study, detect, or circumvent Internet censorship.

Past iterations of the workshop featured a number of great Tor research papers including a proposal for cloud-based onion routing, our OONI design paper, an analysis of how the GFW blocks Tor, a censorship analyzer for Tor, and a proposal for latency reduction in Tor circuits.

Given the past success of the FOCI series, we are looking forward to another round of great Tor papers.

Paper submissions are due on Tuesday, May 13, 2014, 11:59 p.m. PDT.

Welcome to the fifteenth issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community.

New beta version of Tor Browser 3.6

The second beta version of the next major Tor Browser release is out. Version 3.6 main highlight is the seamless integration of pluggable transports in the browser.

The update is important to users already using version 3.6-beta1 as it contains an updated OpenSSL to address potential client-side vectors for CVE-2014-0160 (also known as “Heartbleed”).

The new beta also features “a Turkish language bundle, experimental Javascript hardening options, fixes for pluggable transport issues, and a fix for improper update notification while extracting the bundle over an already existing copy.”

Jump to the release announcement to know more. Enjoy the update and report any bug you may find.

Key rotation at every level

The “Heartbleed” issue forces system administrators to consider private keys of network-facing applications affected by the bug as compromised. As Tor has no shortage of private keys in its design, a serious number of new keys has to be generated.

Roger Dingledine prompted relay operators to get new identity keys, “especially from the big relays, and we’ll be happier tolerating a couple of bumpy days while the network recovers”. Switching to a new relay identity key means that the relay is seen as new to the authorities again: they will lose their Guard status and bandwidth measurement. It seems that a number of operators followed the advice, as the network lost around 1 Gbit/s of advertised capacity between April 7th and April 10th.

For a brighter future if such massive RSA1024 relay key migration is ever again in order, Nick Mathewson wrote proposal 230. The proposal describes a mechanism for relays to advertise their old identity to directory authorities and clients.

Directory authorities can currently tie a relay’s nickname to its identity key with the Named flag. That feature proved to be less helpful than it seemed, and can subject its users to impersonation attacks. As relays switch to new identity keys, those who keep the same name will lose their Named flag for the next six months. So now seems a good time to “throw out the Named and Unnamed flags entirely”. Sebastian Hahn acted on the idea and started a draft proposal.

How should potentially compromised relays which have not switched to a new key be handled? On April 8th, grarpamp observed that more than 3000 relays had been restarted — hopefully to use the fixed version of OpenSSL. It is unknown how many of those relays have switched to a new key since. Andrea Shepard has been working on a survey to identify them. What is known though are relays that are unfortunately still vulnerable. Sina Rabbani has set up a visible list for guards and exits. To protect Tor users, directory authority operators have started to reject descriptors for vulnerable relays.

The identity keys for directory authorities are kept offline. But they are used to certify medium-term signing keys. Roger Dingledine’s
analysis reports “two (moria1 and urras) of the directory authorities were unaffected by the openssl bug, and seven were affected”.

At the time of writing, five of the seven affected authorities had new signing keys. In the meantime, Nick and Andrea have been busy writing code to prevent the old keys from being accepted by Tor clients.

Changing the relay identity keys of the directory authorities has not been done so far “because current clients expect them to be at their current IP:port:fingerprint and would scream in their logs and refuse to connect if the relay identity key changes”. The specification of the missing piece of code to allow a smoother transition has been written by Nick Mathewson in proposal 231.

Finally, hidden service operators are also generating new keys. Unfortunately, this forces every user of the service to update the address in their bookmarks or configuration.

As Roger summarized it: “fun times”.

More monthly status reports for March 2014

The wave of regular monthly reports from Tor project members for the month of March continued, with submissions from Andrew Lewman, Roger Dingledine, and Kelley Misata.

Roger also sent out the report for SponsorF, and the Tails team reported on its progress.

Miscellaneous news

CVE-2014-0160 prompted Anthony Basile to release version 20140409 of Tor-ramdisk. OpenSSL has been updated and so has the kernel. Upgrading is strongly recommended.

David Fifield released new browser bundles configured to use the meek transport automatically. These bundles “use a web browser extension to make the HTTPS requests, so that the TLS layer looks like Firefox” — because it is Firefox. Meek is a promising censorship circumvention solution, so please try them!

The Tails developers announced that Tchou’s proposal is the winner of the recent Tails logo contest: “in the coming days we will keep on fine-tuning it and integrating it in time for Tails 1.0. So don’t hesitate to comment on it.”

Andrew Lewman reported on his week in Stockholm for the Civil Rights Defender’s Defender’s Days where he trained activists and “learned more about the situation in Moldova, Transnistria, Burma, Vietnam, and Bahrain”.

Andrew also updated the instructions for mirror operators wishing to have their sites listed on the Tor Project website. Thanks to Andreas Reich, Sebastian M. Bobrecki, and Jeremy L. Gaddis  for running new mirrors!

Arlo Breault announced the release of Bulb, a Tor relay web status dashboard. “There’s not much to it yet, but I thought I’d share […] Contributions welcome!”

Alan Shreve requested feedback on “Shroud”, a proposal for “a new system to provide public hidden services […] whose network location cannot be determined (like Tor hidden services) but are accessible by any client on the internet”.

Tor help desk roundup

Users often ask for steps they can take to maximize their anonymity while using Tor. Tips for staying anonymous when using Tor are visible on the download page.

News from Tor StackExchange

Jack Gundo uses Windows 7 with the built-in firewall and wants to block all traffic except Tor traffic. Guest suggested that on a closed-source system one can never be sure that all traffic really is blocked, so the original poster might be better off using a router which does the job. Another possible solution is PeerBlock, which also allows you to block all traffic from a machine.

Broot uses obfs3 to route OpenVPN traffic and can’t get obfsproxy running because the latest version only implements SOCKS4. Yawning Angel answered that version 0.2.7 of obfsproxy uses SOCKS5 and works with OpenVPN. However there is a bug that needs to be worked around.

---

This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt Pagan, qbi, Roger Dingledine, Karsten Loesing and the Tails team.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

The Tor Browser Team is proud to announce the second beta in the 3.6 series. Packages are available from the Tor Browser Project page and also from our distribution directory.

This release is an important security update over 3.6-beta-1. This release updates OpenSSL to version 1.0.1g, to address potential client-side vectors for CVE-2014-0160.

The browser itself does not use OpenSSL, and is not vulnerable to this CVE. However, this release is still considered an important security update, because it is theoretically possible to extract sensitive information from the Tor client sub-process.

This beta also features a Turkish language bundle, experimental Javascript hardening options, fixes for pluggable transport issues, and a fix for improper update notification while extracting the bundle over an already existing copy.

Here is the complete changelog since 3.6-beta-1:

• All Platforms
  • Update OpenSSL to 1.0.1g
  • Bug 9010: Add Turkish language support.
  • Bug 9387 testing: Disable JS JIT, type inference, asmjs, and ion.
  • Update fte transport to 0.2.12
  • Update NoScript to 2.6.8.19
  • Update Torbutton to 1.6.8.1
    • Bug 11242: Fix improper "update needed" message after in-place upgrade.
    • Bug 10398: Ease translation of about:tor page elements
  • Update Tor Launcher to 0.2.5.3
    • Bug 9665: Localize Tor's unreachable bridges bootstrap error
  • Backport Pending Tor Patches:
    • Bug 9665: Report a bootstrap error if all bridges are unreachable
    • Bug 11200: Prevent spurious error message prior to enabling network.
• Linux:
  • Bug 11190: Switch linux PT build process to python2
  • Bug 10383: Enable NIST P224 and P256 accel support for 64bit builds.
• Windows:
  • Bug 11286: Fix fte transport launch error

A list of frequently encountered known issues with the Tor Browser can be found on our bugtracker. Please check that list and help us diagnose and arrive at solutions for those issues before contacting support.

Welcome to the fourteenth issue of Tor Weekly News in 2014, the weekly newsletter that covers what’s happening in the Tor community.

The Heartbleed Bug and Tor

OpenSSL bug CVE-2014-0160, also known as the Heartbleed bug, “allows anyone on the Internet to read the memory of systems protected by the vulnerable versions of the OpenSSL software”, potentially enabling the compromise of information including “user names and passwords, instant messages, emails, and business critical documents and communication”. Tor is one of the very many networking programs that use OpenSSL to communicate over the Internet, so within a few hours of the bug’s disclosure Roger Dingledine posted a security advisory describing how it affects different areas of the Tor ecosystem.

“The short version is: upgrade your openssl”. Tor Browser users should upgrade as soon as possible to the new 3.5.4 release, which includes OpenSSL 1.0.1g, fixing the vulnerability. “The browser itself does not use OpenSSL…however, this release is still considered an important security update, because it is theoretically possible to extract sensitive information from the Tor client sub-process”, wrote Mike Perry.

Those using a system Tor should upgrade their OpenSSL version and manually restart their Tor process. For relay operators, “best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys”, and for hidden service administrators, “to move to a new hidden-service address at your convenience”. Clients, relays, and services using an older version of OpenSSL, including Tails, are not affected by this bug.

For mobile devices, Nathan Freitas called for immediate testing of Orbot 13.0.6-beta-3, which not only upgrades OpenSSL but also contains a fix for the transproxy leak described by Mike Perry two weeks ago, in addition to smaller fixes and improvements from 13.0.6-beta-1 and subsequently. You can obtain a copy of the .apk file directly from the Guardian Project’s distribution page.

Ultimately, “if you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.” Be sure to read Roger’s post in full for a more detailed explanation if you are unsure what this bug might mean for you.

A hall of Tor mirrors

Users the world over are increasingly aware of Tor’s leading reputation as a well-researched and -developed censorship circumvention tool — and, regrettably, so are censorship authorities. Events such as last month’s (short-lived) disruption of access to the main Tor Project website from some Turkish internet connections have reaffirmed the need for multiple distribution channels that users can turn to during a censorship event in order to acquire a copy of the Tor Browser, secure their browsing, and beat the censors. One of the simplest ways of ensuring this is to make a copy of the entire website and put it somewhere else.

Recent days have seen the establishment of a large number of new Tor website mirrors, for which thanks must go to Max Jakob Maass, Ahmad Zoughbi, Darren Meyer, Piratenpartei Bayern, Bernd Fix, Florian Walther, the Electronic Frontier Foundation (on a subdomain formerly housing the Tor Project’s official site), the Freedom of the Press Foundation, Caleb Xu, George Kargiotakis, and Tobias Markus, as well as to all the mirror operators of longer standing.

If you’d like to participate in the effort to render blocking of the Tor website even more futile, please see the instructions for running a mirror, and then come to the tor-mirrors mailing list to notify the community!

Mission Impossible: Hardening Android for Security and Privacy

On the Tor Blog, Mike Perry posted another large and comprehensive hacking guide, this time describing “the installation and configuration of a prototype of a secure, full-featured, Android telecommunications device with full Tor support, individual application firewalling, true cell network baseband isolation, and optional ZRTP encrypted voice and video support.” The walkthrough covers hardware selection and setup, recommended software, Google-free backups, and disabling the built-in microphone of a Nexus 7 tablet (with a screwdriver).

As it stands, following this guide may require a certain level of patience, but as Mike wrote, “it is our hope that this work can be replicated and eventually fully automated, given a good UI, and rolled into a single ROM or ROM addon package for ease of use. Ultimately, there is no reason why this system could not become a full fledged off the shelf product, given proper hardware support and good UI for the more technical bits.”

Mike has already added to and improved parts of the guide following contributions from users in the comments beneath the post. If you would like to work (or already are working) at the cutting-edge of research into mobile device security and usability, take a look at Mike’s suggestions for future work at the bottom of the guide, and please share your ideas with the community.

More monthly status reports for March 2014

The wave of regular monthly reports from Tor project members for the month of March continued, with submissions from Arlo Breault, Colin Childs, George Kadianakis, Michael Schloh von Bennewitz, Philipp Winter, and Kevin Dyer.

Arturo Filastò reported on behalf of the OONI team, while Mike Perry did likewise for the Tor Browser team.

Miscellaneous news

David Goulet announced the seventh release candidate for Torsocks 2.0.0, the updated version of the wrapper for safely using network applications with Tor. “Nothing major, fixes and some code refactoring went in”, said David. Please review, test, and report any issues you find.

Nathan Freitas posted a brief analysis of the role played by Orbot in the recent Turkish internet service disruption: “it might be good to think about Turkey’s Twitter block as a “censorship-lite” event, not unlike the UK or Indonesia, and then figure out how we can encourage more adoption.”

Jann Horn drew attention to a potential issue caused by some Tor relays sending out globally-sequential IP IDs. Roger Dingledine linked to an academic paper connected with the same question, while Daniel Bilik suggested one method of preventing this from happening on FreeBSD. Exactly how significant this issue is (or is not) for the Tor network is very much an open question; further research into which operating systems it affects, and how it might be related to known attacks against anonymity, would be very welcome.

As part of their current campaign to fund usable encryption tools (including Tor) for journalists, the Freedom of the Press Foundation published a blog post on the “little-known” Tails operating system, featuring quotes from three of the journalists most prominently associated with the recent Snowden disclosures (Laura Poitras, Glenn Greenwald, and Barton Gellman) attesting to the important role Tails has played in their ability to carry out their work. If you’re impressed by what you read, please donate to the campaign — or become a Tails contributor!

Two Tor-affiliated projects — the Open Observatory of Network Interference and Tails — have each submitted a proposal to this year’s Knight News Challenge. The OONI proposal involves further developing the ooni-probe software suite and deploying it in countries around the world, as well as working on analysis and visualization of the data gathered, in collaboration with the Chokepoint Project; while Tails’ submission proposes to “improve Tails to limit the impact of security flaws, isolate critical applications, and provide same-day security updates”. Voting is limited to the Knight Foundation’s trustees, but feel free to read each submission and leave your comments for the developers.

Robert posted a short proposal for “a prototype of a next-generation Tor control interface, aiming to combine the strengths of both the present control protocol and the state-of-the-art libraries”. The idea was originally destined for this year’s GSoC season, but in the end Robert opted instead to “get some feedback and let the idea evolve.”

After the end of the Tails logo contest last week, sajolida announced that the winner will be declared by April 9th, after a week of voting by the most active Tails contributors.

Following last week’s progress on the Tor website redesign campaign, William Papper presented a functioning beta version of the new download page that he and a team of contributors have been building. Have a look, and let the www-team list know what works and what doesn’t!

Michael Schloh von Bennewitz began work on a guide to configuring a virtual machine for building the Tor Browser Bundle, and another to building with Gitian.

Tor help desk roundup

Tor Browser users often try to set a proxy when they don’t need to. Many users think they can circumvent website bans or get additional security by doing this. Discussion on clarifying the tor-launcher interface is taking place on the bug tracker.

News from Tor StackExchange

Tor’s StackExchange did its second site self-evaluation . Users were asked to review ten questions and their respective answers. This should help to improve the site's overall quality.

The question “Why does GnuPG show the signature of Erinn Clark as not trusted?” got the best rating. When a user verified the downloaded copy of Tor Browser Bundle, GnuPG showed Erinn’s signature as not-trusted. Jens Kubieziel explained the trust model of GnuPG in his answer, and gapz referred to the handbook.

The following questions need better answers: “How to validate certificates?”; “Why does Atlas sometimes show a different IP address from https://check.torproject.org?”; “Site login does not persist”; and “My Atlas page is blank”.

If you know good answers to these questions, please help the users of Tor StackExchange.

---

This issue of Tor Weekly News has been assembled by harmony, Matt Pagan, qbi, Lunar, Roger Dingledine, and Karsten Loesing.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

The 3.5.4-stable release of the Tor Browser is now available on the Download page. You can also download the bundles directly from the distribution directory.

This release updates only OpenSSL to version 1.0.1g, to address potential client-side vectors for CVE-2014-0160.

The browser itself does not use OpenSSL, and is not vulnerable to this CVE. However, this release is still considered an important security update, because it is theoretically possible to extract sensitive information from the Tor client sub-process.

Here is the changelog:

• All Platforms
• Update OpenSSL to 1.0.1g

A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server.

If you're using an older OpenSSL version, you're safe.

Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.

Here are our first thoughts on what Tor components are affected:

1. Clients: The browser part of Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But the Tor client part is: Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor.
2. Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. (You will need to update your MyFamily torrc lines if you run multiple relays.)
3. Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, this shouldn't allow an attacker to identify the location of the hidden service [edit: if it's your entry guard that extracted your key, they know where they got it from]. Also, an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.
4. Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.
5. Tails is still tracking Debian oldstable, so it should not be affected by this bug.
6. Orbot looks vulnerable; they have some new packages available for testing.
7. The webservers in the https://www.torproject.org/ rotation needed (and got) upgrades. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.

Updates: See the Changes section for a list of changes since initial posting.

Executive Summary

The future is here, and ahead of schedule. Come join us, the weather's nice.

This blog post describes the installation and configuration of a prototype of a secure, full-featured, Android telecommunications device with full Tor support, individual application firewalling, true cell network baseband isolation, and optional ZRTP encrypted voice and video support. ZRTP does run over UDP which is not yet possible to send over Tor, but we are able to send SIP account login and call setup over Tor independently.

The SIP client we recommend also supports dialing normal telephone numbers, but that is also UDP+ZRTP, and the normal telephone network side of the connection is obviously not encrypted.

Aside from a handful of binary blobs to manage the device firmware and graphics acceleration, the entire system can be assembled (and recompiled) using only FOSS components. However, as an added bonus, we will describe how to handle the Google Play store as well, to mitigate the two infamous Google Play Backdoors.

Introduction

Android is the most popular mobile platform in the world, with a wide variety of applications, including many applications that aid in communications security, censorship circumvention, and activist organization. Moreover, the core of the Android platform is Open Source, auditable, and modifiable by anyone.

Unfortunately though, mobile devices in general and Android devices in particular have not been designed with privacy in mind. In fact, they've seemingly been designed with nearly the opposite goal: to make it easy for third parties, telecommunications companies, sophisticated state-sized adversaries, and even random hackers to extract all manner of personal information from the user. This includes the full content of personal communications with business partners and loved ones. Worse still, by default, the user is given very little in the way of control or even informed consent about what information is being collected and how.

This post aims to address this, but we must first admit we stand on the shoulders of giants. Organizations like Cyanogen, F-Droid, the Guardian Project, and many others have done a great deal of work to try to improve this situation by restoring control of Android devices to the user, and to ensure the integrity of our personal communications. However, all of these projects have shortcomings and often leave gaps in what they provide and protect. Even in cases where proper security and privacy features exist, they typically require extensive configuration to use safely, securely, and correctly.

This blog post enumerates and documents these gaps, describes workarounds for serious shortcomings, and provides suggestions for future work.

It is also meant to serve as a HOWTO to walk interested, technically capable people through the end-to-end installation and configuration of a prototype of a secure and private Android device, where access to the network is restricted to an approved list of applications, and all traffic is routed through the Tor network.

It is our hope that this work can be replicated and eventually fully automated, given a good UI, and rolled into a single ROM or ROM addon package for ease of use. Ultimately, there is no reason why this system could not become a full fledged off the shelf product, given proper hardware support and good UI for the more technical bits.

The remainder of this document is divided into the following sections:

1. Hardware Selection
2. Installation and Setup
3. Google Apps Setup
4. Recommended Software
5. Device Backup Procedure
6. Removing the Built-in Microphone
7. Removing Baseband Remnants
8. Future Work
9. Changes Since Initial Posting

Hardware Selection

If you truly wish to secure your mobile device from remote compromise, it is necessary to carefully select your hardware. First and foremost, it is absolutely essential that the carrier's baseband firmware is completely isolated from the rest of the platform. Because your cell phone baseband does not authenticate the network (in part to allow roaming), any random hacker with their own cell network can exploit these backdoors and use them to install malware on your device.

While there are projects underway to determine which handsets actually provide true hardware baseband isolation, at the time of this writing there is very little public information available on this topic. Hence, the only safe option remains a device with no cell network support at all (though cell network connectivity can still be provided by a separate device). For the purposes of this post, the reference device is the WiFi-only version of the 2013 Google Nexus 7 tablet.

For users who wish to retain full mobile access, we recommend obtaining a cell modem device that provides a WiFi access point for data services only. These devices do not have microphones and in some cases do not even have fine-grained GPS units (because they are not able to make emergency calls). They are also available with prepaid plans, for rates around $20-30 USD per month, for about 2GB/month of 4G data. If coverage and reliability is important to you though, you may want to go with a slightly more expensive carrier. In the US, T-Mobile isn't bad, but Verizon is superb.

To increase battery life of your cell connection, you can connect this access point to an external mobile USB battery pack, which typically will provide 36-48 hours of continuous use with a 6000mAh battery.

The total cost of a Wifi-only tablet with cell modem and battery pack is only roughly USD $50 more than the 4G LTE version of the same device.

In this way, you achieve true baseband isolation, with no risk of audio or network surveillance, baseband exploits, or provider backdoors. Effectively, this cell modem is just another untrusted router in a long, long chain of untrustworthy Internet infrastructure.

However, do note though that even if the cell unit does not contain a fine-grained GPS, you still sacrifice location privacy while using it. Over an extended period of time, it will be possible to make inferences about your physical activity, behavior and personal preferences, and your identity, based on cell tower use alone.

Installation and Setup

We will focus on the installation of Cyanogenmod 11 using Team Win Recovery Project, both to give this HOWTO some shelf life, and because Cyanogenmod 11 features full SELinux support (Dear NSA: What happened to you guys? You used to be cool. Well, some of you. Some of the time. Maybe. Or maybe not).

The use of Google Apps and Google Play services is not recommended due to security issues with Google Play. However, we do provide workarounds for mitigating those issues, if Google Play is required for your use case.

Installation and Setup: ROM and Core App Installation

With the 2013 Google Nexus 7 tablet, installation is fairly straight-forward. In fact, it is actually possible to install and use the device before associating it with a Google Account in any way. This is a desirable property, because by default, the otherwise mandatory initial setup process of the stock Google ROM sends your device MAC address directly to Google and links it to your Google account (all without using Tor, of course).

The official Cyanogenmod installation instructions are available online, but with a fresh out of the box device, here are the key steps for installation without activating the default ROM code at all (using Team Win Recovery Project instead of ClockWorkMod).

First, on your desktop/laptop computer (preferably Linux), perform the following:

1. Download the latest CyanogenMod 11 release (we used cm-11-20140308-SNAPSHOT-M4)
2. Download the latest Team Win Recovery Project image (we used 2.7.0.0)
3. Download the F-Droid package (we used 0.63)
4. Download the Orbot package from F-Droid (we used 13.0.5)
5. Download the Droidwall package from F-Droid (we used 1.5.7)
6. Download the Droidwall Firewall Scripts attached to this blogpost
7. Download the Google Apps for Cyanogenmod 11 (optional)

Because the download integrity for all of these packages is abysmal, here is a signed set of SHA256 hashes I've observed for those packages.

Once you have all of those packages, boot your tablet into fastboot mode by holding the Power button and the Volume Down button during a cold boot. Then, attach it to your desktop/laptop machine with a USB cable and run the following commands, as root:

 apt-get install android-tools-adb android-tools-fastboot
 fastboot devices
 fastboot oem unlock
 fastboot flash recovery openrecovery-twrp-2.7.0.0-flo.img

After the recovery firmware is flashed successfully, use the volume keys to select Recovery and hit the power button to reboot the device (or power it off, and then boot holding Power and Volume Up).

Once Team Win boots, go into Wipe and select Advanced Wipe. Select all checkboxes except for USB-OTG, and slide to wipe. Once the wipe is done, click Format Data. After the format completes, issue these commands from your Linux root shell:

 adb server start
 adb push cm-11-20140308-SNAPSHOT-M4-flo.zip /sdcard/
 adb push gapps-kk-20140105-signed.zip /sdcard/ # Optional

After this push process completes, go to the Install menu, and select the Cyanogen zip, and optionally the gapps zip for installation. Then click Reboot, and select System.

After rebooting into your new installation, skip all CyanogenMod and Google setup, disable location reporting, and immediately disable WiFi and turn on Airplane mode.

Then, go into Settings -> About Tablet and scroll to the bottom and click the greyed out Build number 5 times until developer mode is enabled. Then go into Settings -> Developer Options and turn on USB Debugging.

After that, run the following commands from your Linux root shell:

 adb install FDroid.apk
 adb install org.torproject.android_70.apk
 adb install com.googlecode.droidwall_157.apk

You will need to approve the ADB connection for the first package, and then they should install normally.

VERY IMPORTANT: Whenever you finish using adb, always remember to disable USB Debugging and restore Root Access to Apps only. While Android 4.2+ ROMs now prompt you to authorize an RSA key fingerprint before allowing a debugging connection (thus mitigating adb exploit tools that bypass screen lock and can install root apps), you still risk additional vulnerability surface by leaving debugging enabled.

Installation and Setup: Initial Configuration

After the base packages are installed, go into the Settings app, and make the following changes:

1. Location Access -> Off
2. Language & Input =>
• Spell Checker -> Android Spell Checker -> Disable Contact Names
• Disable Google Voice Typing
• Android Keyboard (AOSP) =>
  • Disable AOSP next-word suggestion (do this first!)
  • Auto-correction -> Off
3. Backup & reset =>
• Enable Back up my data (just temporarily, for the next step)
• Uncheck Automatic restore
• Disable Backup my data
4. About Tablet -> Cyanogenmod Statistics -> Disable reporting
5. Developer Options -> Device Hostname -> localhost
6. SuperUser -> Settings (three dots) -> Notifications -> Notification (not toast)
7. Privacy -> Privacy Guard =>
   • Enabled by default
   • Settings (three dots) -> Show Built In Apps
   • Enable Privacy Guard for every app with the following exceptions:
     • Calendar
     • Config Updater
     • Google Account Manager (long press)
     • Modify Settings -> Off
     • Wifi Change -> Off
     • Data Change -> Off
     • Google Play Services (long press)
     • Location -> Off
     • Modify Settings -> Off
     • Draw on top -> Off
     • Record Audio -> Off
     • Wifi Change -> Off
     • Google Play Store (long press)
     • Location -> Off
     • Send SMS -> Off
     • Modify Settings -> Off
     • Data change -> Off
     • Google Services Framework (long press)
     • Modify Settings -> Off
     • Wifi Change -> Off
     • Data Change -> Off
     • Trebuchet
8. Security =>
   • PIN screen Lock
   • Allow Unknown Sources (For F-Droid)
   • Encrypt Tablet

After that last step, your tablet will reboot and encrypt itself. It is important to do this step early, as I have noticed additional apps and configuration tweaks can make this process fail later on. You can and should also change the boot password to be different from the screen unlock PIN later on, to mitigate compromise of this password from shoulder surfers, and to allow the use of a much longer (and non-numeric) password that you would prefer not to type every time you unlock the screen.

To do this, open the Terminal app, and type the following commands:

su
vdc cryptfs changepw NewMoreSecurePassword

Watch for typos! That command does not ask you to re-type that password for confirmation.

Installation and Setup: Disabling Invasive Apps and Services

Before you configure the Firewall or enable the network, you likely want to disable at least a subset of the following built-in apps and services, by using Settings -> Apps -> All, and then clicking on each app and hitting the Disable button:

• com.android.smspush
• com.google.android.voicesearch
• Face Unlock
• Google Backup Transport
• Google Calendar Sync
• Google One Time Init
• Google Partner Setup
• Google Contacts Sync
• Google Search
• Hangouts
• Market Feedback Agent
• News & Weather
• One Time Init
• Picasa Updater
• Sound Search for Google Play
• TalkBack

Installation and Setup: Tor and Firewall configuration

Ok, now let's install the firewall and tor support scripts. Go back into Settings -> Developer Options and enable USB Debugging and change Root Access to Apps and ADB. Then, unzip the android-firewall.zip on your laptop, and run the installation script:

./install-firewall.sh

That firewall installation provides several key scripts that provide functionality that is currently impossible to achieve with any app (including Orbot):

1. It installs a userinit script to block all network access during boot.
2. It disables "Google Captive Portal Detection", which involves connection attempts to Google servers upon Wifi assocation (these requests are made by the Android Settings UID, which should normally be blocked from the network, unless you are first registering for Google Play).
3. It contains a Droidwall script that configures Tor transproxy rules to send all of your traffic through Tor. These rules include a fix for a Linux kernel Tor transproxy packet leak issue.
4. The main firewall-tor.sh Droidwall script also includes an input firewall, to block all inbound connections to the device. It also fixes a Droidwall permissions vulnerability
5. It installs an optional script to allow the Browser app to bypass Tor for logging into WiFi captive portals.
6. It installs an optional script to temporarily allow network adb access when you need it (if you are paranoid about USB exploits, which you should be).
7. It provides an optional script to allow the UDP activity of LinPhone to bypass Tor, to allow ZRTP-encrypted Voice and Video SIP/VoIP calls. SIP account login/registration and call setup/signaling can be done over TCP, and Linphone's TCP activity is still sent through Tor with this script.

Note that with the exception of the userinit network blocking script, installing these scripts does not activate them. You still need to configure Droidwall to use them.

We use Droidwall instead of Orbot or AFPWall+ for five reasons:

1. Droidwall's app-based firewall and Orbot's transproxy are known to conflict and reset one another.
2. Droidwall does not randomly drop transproxy rules when switching networks (Orbot has had several of these types of bugs).
3. Unlike AFWall+, Droidwall is able to auto-launch at "boot" (though still not before the network and Android Services come online and make connections).
4. AFWall+'s "fix" for this startup data leak problem does not work on Cyanogenmod (hence our userinit script instead).
5. Aside from the permissions issue fixed by our firewall-tor.sh script, AFWall+ provides no additional security fixes over the stock Droidwall.

To make use of the firewall scripts, open up Droidwall and hit the config button (the vertical three dots), go to More -> Set Custom Script. Enter the following:

. /data/local/firewall-tor.sh
#. /data/local/firewall-adb.sh
#. /data/local/firewall-linphone.sh
#. /data/local/firewall-capportal.sh

Note that these scripts have been installed into a readonly root directory. Because they are run as root, installing them to a world-writable location like /sdcard/ is extremely unwise.

Later, if you want to enable one of network adb, LinPhone UDP, or captive portal login, go back into this window and remove the leading comment ('#') from the appropriate lines (this is obviously one of the many aspects of this prototype that could benefit from real UI).

Then, configure the apps you want to allow to access the network. Note that the only Android system apps that must access the network are:

• CM Updater
• Downloads, Media Storage, Download Manager
• F-Droid

Orbot's network access is handled via the main firewall-tor.sh script. You do not need to enable full network access to Orbot in Droidwall.

The rest of the apps you can enable at your discretion. They will all be routed through Tor automatically.

Once the Droidwall is configured, you can enable Orbot. Do not grant Orbot superuser access. It still opens the transproxy ports you need without root, and Droidwall is managing installation of the transproxy rules, not Orbot.

You are now ready to enable Wifi and network access on your device. For vulnerability surface reduction, you may want to use the Advanced Options -> Static IP to manually enter an IP address for your device to avoid using dhclient. You do not need a DNS server, and can safely set it to 127.0.0.1.

Google Apps Setup

If you installed the Google Apps zip, you need to do a few things now to set it up, and to further harden your device. If you opted out of Google Apps, you can skip to the next section.

Google Apps Setup: Initializing Google Play

The first time you use Google Play, you will need to enable three apps in Droidwall: "Google Account Manager, Google Play Services...", "Settings, Dev Tools, Fused Location...", and "Google Play" itself.

If you do not have a Google account, your best bet is to find open wifi to create one, as Google will often block accounts created through Tor, even if you use an Android device.

After you log in for the first time, you should be able to disable the "Google Account Manager, Google Play Services..." and the "Settings..." apps in Droidwall, but your authentication tokens in Google Play may expire periodically. If this happens, you should only need to temporarily enable the "Google Account Manager, Google Play Services..." app in Droidwall to obtain new ones.

Google Apps Setup: Mitigating the Google Play Backdoors

If you do choose to use Google Play, you need to be very careful about how you allow it to access the network. In addition to the risks associated with using a proprietary App Store that can send you targeted malware-infected packages based on your Google Account, it has at least two major user experience flaws:

1. Anyone who is able to gain access to your Google account can silently install root or full permission apps without any user interaction what-so-ever. Once installed, these apps can retroactively clear what little installation notification and UI-based evidence of their existence there was in the first place.
2. The Android Update Process does not inform the user of changes in permissions of pending update apps that happen to get installed after an Android upgrade.

The first issue can be mitigated by ensuring that Google Play does not have access to the network when not in use, by disabling it in Droidwall. If you do not do this, apps can be installed silently behind your back. Welcome to the Google Experience.

For the second issue, you can install the SecCheck utility, to monitor your apps for changes in permissions during a device upgrade.

Google Apps Setup: Disabling Google Cloud Messaging

If you have installed the Google Apps zip, you have also enabled a feature called Google Cloud Messaging.

The Google Cloud Messaging Service allows apps to register for asynchronous remote push notifications from Google, as well as send outbound messages through Google.

Notification registration and outbound messages are sent via the app's own UID, so using Droidwall to disable network access by an app is enough to prevent outbound data, and notification registration. However, if you ever allow network access to an app, and it does successfully register for notifications, these notifications can be delivered even when the app is once again blocked from accessing the network by Droidwall.

These inbound notifications can be blocked by disabling network access to the "Google Account Manager, Google Play Services, Google Services Framework, Google Contacts Sync" in Droidwall. In fact, the only reason you should ever need to enable network access by this service is if you need to log in to Google Play again if your authentication tokens ever expire.

If you would like to test your ability to control Google Cloud Messaging, there are two apps in the Google Play store than can help with this. GCM Test allows for simple send and receive pings through GCM. Push Notification Tester will allow you to test registration and asynchronous GCM notification.

Recommended Privacy and Auditing Software

Ok, so now that we have locked down our Android device, now for the fun bit: secure communications!

We recommend the following apps from F-Droid:

1. Xabber

Xabber is a full Java implementation of XMPP, and supports both OTR and Tor. Its UI is a bit more streamlined than Guardian Project's ChatSecure, and it does not make use of any native code components (which are more vulnerable to code execution exploits than pure Java code). Unfortunately, this means it lacks some of ChatSecure's nicer features, such as push-to-talk voice and file transfer.

Despite better protection against code execution, it does have several insecure default settings. In particular, you want to make the following changes:

• Notifications -> Message text in Notifications -> Off (notifications can be read by other apps!)
• Accounts -> Integration into system accounts -> Off
• Accounts -> Store message history -> Don't Store
• Security -> Store History -> Off
• Security -> Check Server Certificate
• Chat -> Show Typing Notifications -> Off
• Connection Settings -> Auto-away -> disabled
• Connection Settings -> Extended away when idle -> Disabled
• Keep Wifi Awake -> On
• Prevent sleep Mode -> On
2. Offline Calendar

Offline Calendar is a hack to allow you to create a fake local Google account that does not sync to Google. This allows you to use the Calendar App without risk of leaking your activities to Google. Note that you must exempt both this app and Calendar from Privacy Guard for it to function properly.

3. LinPhone

LinPhone is a FOSS SIP client that supports TCP TLS signaling and ZRTP. Note that neither TLS nor ZRTP are enabled by default. You must manually enable them in Settings -> Network -> Transport and Settings -> Network -> Media Encryption.

ostel.co is a free SIP service run by the Guardian Project that supports only TLS and ZRTP, but does not allow outdialing to normal PSTN telephone numbers. While Bitcoin has many privacy issues of its own, the Bitcoin community maintains a couple lists of "trunking" providers that allow you to obtain a PSTN phone number in exchange for Bitcoin payment.


4. OSMAnd~

A free offline mapping tool. While the UI is a little clunky, it does support voice navigation and driving directions, and is a handy, private alternative to Google Maps.

5. VLC

   The VLC port in F-Droid is a fully capable media player. It can play mp3s and most video formats in use today. It is a handy, private alternative to Google Music and other closed-source players that often report your activity to third party advertisers. VLC does not need network access to function.

6. Firefox

We do not yet have a port of Tor Browser for Android (though one is underway -- see the Future Work section). Unless you want to use Google Play to get Chrome, Firefox is your best bet for a web browser that receives regular updates (the built in Browser app does not). HTTPS-Everywhere and NoScript are available, at least.

7. Bitcoin

Bitcoin might not be the most private currency in the world. In fact, you might even say it's the least private currency in the world. But, it is a neat toy.

8. Launch App Ops

   The Launch App Ops app is a simple shortcut into the hidden application permissions editor in Android. A similar interface is available through Settings -> Privacy -> Privacy Guard, but a direct shortcut to edit permissions is handy. It also displays some additional system apps that Privacy Guard omits.

9. Permissions

   The Permissions app gives you a view of all Android permissions, and shows you which apps have requested a given permission. This is particularly useful to disable the record audio permission for apps that you don't want to suddenly decide to listen to you. (Interestingly, the Record Audio permission disable feature was broken in all Android ROMs I tested, aside from Cyanogenmod 11. You can test this yourself by revoking the permission from the Sound Recorder app, and verifying that it cannot record.)

10. CatLog

In addition to being supercute, CatLog is an excellent Android monitoring and debugging tool. It allows you to monitor and record the full set of Android log events, which can be helpful in diagnosing issues with apps.

11. OS Monitor

OS Monitor is an excellent Android process and connection monitoring app, that can help you watch for CPU usage and connection attempts by your apps.

12. Intent Intercept

Intent Intercept allows you to inspect and extract Android Intent content without allowing it to get forwarded to an actual app. This is useful for monitoring how apps attempt to communicate with eachother, though be aware it only covers one of the mechanisms of inter-app communication in Android.

Backing up Your Device Without Google

Now that your device is fully configured and installed, you probably want to know how to back it up without sending all of your private information directly to Google. While the Team Win Recovery Project will back up all of your system settings and apps (even if your device is encrypted), it currently does not back up the contents of your virtualized /sdcard. Remembering to do a couple adb pulls of key directories can save you a lot of heartache should you suffer some kind of data loss or hardware failure (or simply drop your tablet on a bridge while in a rush to catch a train).

The backup.sh script uses adb to pull your Download and Pictures directories from the /sdcard, as well as pulls the entire TWRP backup directory.

Before you use that script, you probably want to delete old TWRP backup folders so as to only pull one backup, to reduce pull time. These live in /sdcard/TWRP/BACKUPS/, which is also known as /storage/emulated/0/TWRP/BACKUPS in the File Manager app.

To use this script over the network without a usb cable, enable both USB Debugging and ADB Over Network in your developer settings. The script does not require you to enable root access from adb, and you should not enable root because it takes quite a while to run a backup, especially if you are using network adb.

Prior to using network adb, you must edit your Droidwall custom scripts to allow it (by removing the '#' in the #. /data/local/firewall-adb.sh line you entered earlier), and then run the following commands from a non-root Linux shell on your desktop/laptop (the ADB Over Network setting will tell you the IP and port):

killall adb
adb connect ip:5555

Network adb also has the advantage of not requiring root on your desktop/Laptop.

VERY IMPORTANT: Don't forget to disable USB Debugging, as well as the Droidwall adb exemption when you are done with the backup!

Removing the Built-in Microphone

If you would really like to ensure that your device cannot listen to you even if it is exploited, it turns out it is very straight-forward to remove the built-in microphone in the Nexus 7. There is only one mic on the 2013 model, and it is located just below the volume buttons (the tiny hole).

To remove it, all you need to do is pop off the the back panel (this can be done with your fingernails, or a tiny screwdriver), and then you can shave the microphone right off that circuit board, and reattach the panel. I have done this to one of my devices, and it was subsequently unable to record audio at all, without otherwise affecting functionality.

You can still use apps that require a microphone by plugging in headphone headset that contains a mic built in (these cost around $20 and you can get them from nearly any consumer electronics store). I have also tested this, and was still able to make a Linphone call from a device with the built in microphone removed, but with an external headset. Note that the 2012 Nexus 7 does not support these combination microphone+headphone jacks (and it has a secondary microphone as well). You must have the 2013 model.

The 2013 Nexus 7 Teardown video can give you an idea of what this looks like before you try it (Opt-In to HTML5 to view in Tor Browser without flash). Again you do not need to fully disassemble the device - you only need to remove the back cover.

Pro-Tip: Before you go too crazy and start ripping out the cameras too, remember that you can cover the cameras with a sticker or tape when not in use. I have found that regular old black electrical tape applies seamlessly, is non-obvious to casual onlookers, and is easy to remove without smudging or gunking up the lenses. Better still, it can be removed and reapplied many times without losing its adhesive.

Removing the Remnants of the Baseband

There is one more semi-hardware mod you may want to make, though.

It turns out that the 2013 Wifi Nexus 7 does actually have a partition that contains a cell network baseband firmware on it, located on the filesystem as the block device /dev/block/platform/msm_sdcc.1/by-name/radio. If you run strings on that block device from the shell, you can see all manner of CDMA and GSM log messages, comments, and symbols are present in that partition.

According to ADB logs, Cyanogenmod 11 actually does try to bring up a cell network radio at boot on my Wifi-only Nexus 7, but fails due to it being disabled. There is also a strong economic incentive for Asus and Google to make it extremely difficult to activate the baseband even if the hardware is otherwise identical for manufacturing reasons, since they sell the WiFi-only version for $100 less. If it were easy to re-enable the baseband, HOWTOs would exist (which they do not seem to, at least not yet), and they would cut into their LTE device sales.

Even so, since we lack public schematics for the Nexus 7 to verify that cell components are actually missing or hardware-disabled, it may be wise to wipe this radio firmware as well, as defense in depth.

To do this, open the Terminal app, and run:

su
cd /dev/block/platform/msm_sdcc.1/by-name
dd if=/dev/zero of=./radio

I have wiped that partition while the device was running without any issue, or any additional errors from ADB logs.

Note that an anonymous commenter also suggested it is possible to disable the baseband of a cell-enabled device using a series of Android service disable commands, and by wiping that radio block device. I have not tested this on a device other than the WiFI-only Nexus 7, though, so proceed with caution. If you try those steps on a cell-enabled device, you should archive a copy of your radio firmware first by doing something like the following from that dev directory that contains the radio firmware block device.

dd if=./radio of=/sdcard/radio.img

If anything goes wrong, you can restore that image with:

dd if=/sdcard/radio.img of=./radio

Future Work

In addition to streamlining the contents of this post into a single additional Cyanogenmod installation zip or alternative ROM, the following problems remain unsolved.

Future Work: Better Usability

While arguably very secure, this system is obviously nowhere near usable. Here are some potential improvements to the user interface, based on a brainstorming session I had with another interested developer.

First of all, the AFWall+/Droidwall UI should be changed to be a tri-state: It should allow you to send app traffic over Tor, over your normal internet connection, or block it entirely.

Next, during app installation from either F-Droid or Google Play (this is an Intent another addon app can actually listen for), the user should be given the chance to decide if they would like that app's traffic to be routed over Tor, use the normal Internet connection, or be blocked entirely from accessing the network. Currently, the Droidwall default for new apps is "no network", which is a great default, but it would be nice to ask users what they would like to do during actual app installation.

Moreover, users should also be given a chance to edit the app's permissions upon installation as well, should they desire to do so.

The Google Play situation could also be vastly improved, should Google itself still prove unwilling to improve the situation. Google Play could be wrapped in a launcher app that automatically grants it network access prior to launch, and then disables it upon leaving the window.

A similar UI could be added to LinPhone. Because the actual voice and video transport for LinPhone does not use Tor, it is possible for an adversary to learn your SIP ID or phone number, and then call you just for the purposes of learning your IP. Because we handle call setup over Tor, we can prevent LinPhone from performing any UDP activity, or divulging your IP to the calling party prior to user approval of the call, prior to user approval. Ideally, we would also want to somehow inform the user of the fact that incoming calls can be used to obtain information about them, at least prior to accepting their first call from an unknown party.

Future Work: Find Hardware with Actual Isolated Basebands

Related to usability, it would be nice if we could have a serious community effort to audit the baseband isolation properties of existing cell phones, so we all don't have to carry around these ridiculous battery packs and sketch-ass wifi bridges. There is no engineering reason why this prototype could not be just as secure as a single piece of hardware. We just need to find the right hardware.

A random commenter claimed that the Galaxy Nexus might actually have exactly the type of baseband isolation we want, but the comment was from memory, and based on software reverse engineering efforts that were not publicly documented. We need to do better than this.

Future Work: Bug Bounty Program

If there is sufficient interest in this prototype, and/or if it gets transformed into a usable addon package or ROM, we may consider running a bug bounty program where we accept donations to a dedicated Bitcoin address, and award the contents of that wallet to anyone who discovers a Tor proxy bypass issue or remote code execution vulnerability in any of the network-enabled apps mentioned in this post (except for the Browser app, which does not receive security updates).

Future Work: Port Tor Browser to Android

The Guardian Project is undertaking a port of Tor Browser to Android as part of their OrFox project. This will greatly improve the privacy of your web browsing experience on the Android device over both Firefox and Chrome. We look forward to helping them in any way we can with this effort.

Future Work: WiFi MAC Address Randomization

It is actually possible to randomize the WiFi MAC address on the Google Nexus 7. The closed-source root app Mac Spoofer is able to modify the device MAC address using Qualcomm-specific methods in such a way that the entire Android OS becomes convinced that this is your actual MAC.

However, doing this requires installation of a root-enabled, closed-source application from the Google Play Store, which we believe is extremely unwise on a device you need to be able to trust. Moreover, this app cannot be autorun on boot, and your MAC address will also reset every time you disable the WiFi interface (which is easy to do accidentally). It also supports using only a single, manually entered MAC address.

Hardware-independent techniques (such as a the Terminal command busybox ifconfig wlan0 hw ether <mac>) appear to interfere with the WiFi management system and prevent it from associating. Moreover, they do not cause the Android system to report the new MAC address, either (visible under Settings -> About Tablet -> Status).

Obviously, an Open Source F-Droid app that properly resets (and automatically randomizes) the MAC every time the WiFi interface is brought up is badly needed.

Future Work: Disable Probes for Configured Wifi Networks

The Android OS currently probes for all of your configured WiFi networks while looking for open wifi to connect to. Configured networks should not be probed for explictly unless activity for their BSSID is seen. The xda-developers forum has a limited fix to change scanning behavior, but users report that it does not disable the active probing behavior for any "hidden" networks that you have configured.

Future Work: Recovery ROM Password Protection

An unlocked recovery ROM is a huge vulnerability surface for Android. While disk encryption protects your applications and data, it does not protect many key system binaries and boot programs. With physical access, it is possible to modify these binaries through your recovery ROM.

The ability to set a password for the Team Win recovery ROM in such a way that a simple "fastboot flash recovery" would overwrite would go a long way to improving device security. At least it would become evident to you if your recovery ROM has been replaced, in this case (due to the absence of the password).

It may also be possible to restore your bootloader lock as an alternative, but then you lose the ability to make backups of your system using Team Win.

Future Work: Disk Encryption via TPM or Clever Hacks

Unfortunately, even disk encryption and a secure recovery firmware is not enough to fully defend against an adversary with an extended period of physical access to your device.

Cold Boot Attacks are still very much a reality against any form of disk encryption, and the best way to eliminate them is through hardware-assisted secure key storage, such as through a TPM chip on the device itself.

It may also be possible to mitigate these attacks by placing key material in SRAM memory locations that will be overwritten as part of the ARM boot process. If these physical memory locations are stable (and for ARM systems that use the SoC SRAM to boot, they will be), rebooting the device to extract key material will always end up overwriting it. Similar ARM CPU-based encryption defenses have also been explored in the research literature.

Future Work: Download and Build Process Integrity

Beyond the download integrity issues mentioned above, better build security is also deeply needed by all of these projects. A Gitian descriptor that is capable of building Cyanogenmod and arbitrary F-Droid packages in a reproducible fashion is one way to go about achieving this property.

Future Work: Removing Binary Blobs

If you read the Cyanogenmod build instructions closely, you can see that it requires extracting the binary blobs from some random phone, and shipping them out. This is the case with most ROMs. In fact, only the Replicant Project seems concerned with this practice, but regrettably they do not support any wifi-only devices. This is rather unfortunate, because no matter what they do with the Android OS on existing cell-enabled devices, they will always be stuck with a closed source, backdoored baseband that has direct access to the microphone, if not the RAM and the entire Android OS.

Kudos to them for finding one of the backdoors though, at least.

Changes Since Initial Posting

1. Updated firewall scripts to fix Droidwall permissions vulnerability.
2. Updated Applications List to recommend VLC as a free media player.
3. Mention the Guardian Project's planned Tor Browser port (called OrFox) as Future Work.
4. Mention disabling configured WiFi network auto-probing as Future Work
5. Updated the firewall install script (and the android-firewall.zip that contains it) to disable "Captive Portal detection" connections to Google upon WiFi association. These connections are made by the Settings service user, which should normally be blocked unless you are Activating Google Play for the first time.
6. Updated the Executive Summary section to make it clear that our SIP client can actually also make normal phone calls, too.
7. Document removing the built-in microphone, for the truly paranoid folk out there.
8. Document removing the remnants of the baseband, or disabling an existing baseband.
9. Update SHA256SUM of FDroid.apk for 0.63
10. Remove multiport usage from firewall-tor.sh script (and update android-firewall.zip).
11. Add pro-tip to the microphone removal section: Don't remove your cameras. Black electrical tape works just fine, and can be removed and reapplied many times without smudges.
12. Update android-firewall.zip installation and documentation to use /data/local instead of /etc. CM updates will wipe /etc, of course. Woops. If this happened to you while updating to CM-11-M5, download that new android-firewall.zip and run install-firewall.sh again as per the instructions above, and update your Droidwall custom script locations to use /data/local.
13. Update the Future work section to describe some specific UI improvements.
14. Update the Future work section to mention that we need to find hardware with actual isolated basebands. Duh. This should have been in there much earlier.

Welcome to the thirteenth issue of Tor Weekly News in 2014, the weekly newsletter that covers what is happening in the Tor community.

Tor Project website redesign takes two steps forward

Andrew Lewman put out two calls for help with the ongoing Tor Project
website redesign: one for the sponsor page, and another for the download area. Both were immediately met with proposals and design suggestions from the www-team mailing list: Olssy produced two mock-ups of the sponsorship page as possible models for further work, while William Papper and Lance Tuller have been working on a repository for the download page, with comments from other list members on topics such as the use of Javascript and possible layout decisions.

If you’d like to give the website redesign further momentum, please see the dedicated project page on the wiki for open tickets and advice on how to contribute, then come to the www-team mailing list and join in!

QR codes for bridge addresses

Since most pocket computers (sometimes called “phones”) and laptops began incorporating cameras, QR codes have become a ubiquitous way to enter short sequences of data into our devices. URLs are the canonical example, but the process also works for Bitcoin addresses or OpenPGP fingerprints.

Bridges are the standard tool for circumventing filters that prevent access to the Tor network. Users currently enter bridge addresses in Tor by copy/pasting from the BridgeDB web page or auto-responder email. But manually giving IP addresses and fingerprints to Orbot on keyboard-less devices is an error-prone process.

QR codes might be a solution to this problem. They could also enable peer-to-peer exchange among friends, or circumvention strategies involving IPv6 addresses and paper. According to Isis Lovecruft, adding QR codes to the BridgeDB web interface would be easy. Would any reader feel like hacking Orbot or the Tor Launcher Firefox extension (see relevant documentation and API)?

Client identification in hidden service applications

Applications behind hidden services currently cannot easily differentiate between client connections. Tor will make a different local TCP connection for each connections it receives, but the software is unable to tell if they are coming from the same circuit. Harry SeventyOne felt the latter would be useful to enable applications for diagnostic log analysis, identifying traffic trends, rate-limiting or temporarily blocking operations coming from the same client.

Harry sent a very rough patch to the Tor development mailing which enables circuit distinction by using a different source IP address from the IPv4 localhost pool (127.0.0.0/8) for each circuit. Nick Mathewson liked the idea and gave several comments about the preliminary patch. Hopefully this work will make the life of hidden service operators easier in the future.

Monthly status reports for March 2014

The wave of regular monthly reports from Tor project members for the month of March has begun. Georg Koppen released his report first, followed by reports from Pearl Crescent, Damian Johnson, Sherief Alaa, Nick Mathewson, Matt Pagan, Lunar, and Karsten Loesing.

Lunar also reported help desk statistics.

Miscellaneous news

An extensive guide to hacking on Tor Browser was posted to the Tor Project’s wiki by Mike Perry. Among other things, it covers the browser’s build instructions, design principles and testing procedures, as well as a summary of how browser team members organize and communicate. If you’d like to get involved in Tor Browser development, please take a look!

Nicholas Hopper followed up on George Kadianakis’ research on switching to a single guard. He used Aaron Johnson’s TorPS simulator to find out the “typical” bandwidth for a client. The conclusions match George’s: a single guard and a bandwidth cutoff of 2 Mbit/s would improve over the current situation. George subsequently sent an initial draft proposal to start the formal process.

BridgeDB version 1.6 was deployed on March 26th. Thanks to Isis Lovecruft, users should now be able to solve the CAPTCHA again. A custom solution is now used instead of Google’s reCAPTCHA services which will give more flexibility in the future.

John Brooks presented Torsion, “a ready-to-use hidden service instant messaging client”. “I’m looking for people to try it out, validate my ideas and implementation, and help plan the future”, wrote John. You can consult the design documentation and build instructions on Github; please share your comments with the community!

Martin Weinelt shared a plugin that generates graphs in the Munin network monitoring tool from data provided by Tor, using Stem. “At the moment it supports a connection graph, getting its data from orconn-status. More graphs are possible, but not yet implemented. Ideas are welcome,” wrote Martin.

Amid the ongoing censorship of internet services in Turkey, there were reports that the Tor Project’s website was unavailable over connections supplied by some Turkish ISPs. Feel free to try one of the mirrors!

Karsten Loesing published a draft of a guide to running a blog over a Tor hidden service using the Jekyll static site generator. “The intended audience are bloggers who can handle a terminal window but who don’t know the typical pitfalls of securely setting up a web server over a hidden service”, he wrote. However, the guide is in its first stages, and “may contain severe problems harming your privacy!” Feedback on its content, wording, and layout would be greatly appreciated.

Yawning Angel called for help with testing obfsclient 0.0.2, a C++ implementation of the obfs3 and ScrambleSuit pluggable transports: “This is mostly a bug fix release that addresses issues found in testing/actual use […] Questions, comments, feedback appreciated as always.”

Michael Rogers has been “working on a messaging app that uses Tor hidden services to provide unlinkability (from the point of view of a network observer) between users and their contacts”. But as “users know who their contacts are”, the mutual anonymity provided by hidden services is not a requirement. Michael asked how hidden services performance could be improved for this use case.

On the Tor Blog, Sukhbir Singh posted a round-up of the various methods by which users can download and run the Tor Browser, covering download mirrors, GetTor, bridge address distribution, and pluggable transports usage. If you’re having trouble acquiring or using a copy of the Tor Browser, please look here for links and guidance.

Mike Perry discovered “that the Linux kernel appears to have a leak in how it applies transproxy rules to the TCP CLOSE_WAIT shutdown condition under certain circumstances”. Be sure to look at Mike’s email if you use Tor’s TransProxy feature. velope later improved the original mitigating firewall rule.

As part of the ongoing project to rewrite the Tor Weather service, Sreenatha Bhatlapenumarthi and Karsten Loesing collaborated to produce a Python script that enables it to determine whether or not relay operators have fulfilled the requirements for a free Tor T-shirt.

Lukas Erlacher announced the avaibility of OnionPy, “a Python wrapper for OnionOO with support for transparently caching OnionOO replies in memcached”. It should be useful to the on-going rewrite of the Tor Weather service.

The deadline for submissions to the Tails logo contest passed on March 31st; you can review all of the proposed designs, from the minimalist to the psychedelic, on the Tails website.

Tor help desk roundup

The help desk often gets confusing reports that after being directed to download the latest Tor Browser version by a flashing TorBrowserButton, users still sometimes see a message that their Tor Browser is out of date. This happens when the new Tor Browser version was installed over the previous one. Fortunately the underlying bug will be fixed in the next Tor Browser release. We recommend extracting each Tor Browser update to an empty directory rather than overwriting the old one, to prevent similar unexpected behaviors. The longer-term solution for issues like this is an auto-updating Tor Browser.

News from Tor StackExchange

saurav wanted to know the total bandwidth of all guard nodes in the current network. gacar pointed to the bandwidth.csv file and explained the format of the file.

Tor’s StackExchange site is doing a self-evaluation. If you have an account, please log in and evaluate the questions as well as their answers. It helps to improve the answers and the site in general.

Furthermore, if you happen to visit the site, check the list of unanswered questions. If you know an answer, please share your knowledge with the people.

---

This issue of Tor Weekly News has been assembled by Lunar, harmony, David Fifield, Matt Pagan, qbi and Karsten Loesing.

Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report
important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!