Mission Improbable: Hardening Android for Security And Privacy

by mikeperry | November 16, 2016

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

After a long wait, the Tor project is happy to announce a refresh of our Tor-enabled Android phone prototype.

This prototype is meant to show a possible direction for Tor on mobile. While I use it myself for my personal communications, it has some rough edges, and installation and update will require familiarity with Linux.

The prototype is also meant to show that it is still possible to replace and modify your mobile phone's operating system while retaining verified boot security - though only just barely. The Android ecosystem is moving very fast, and in this rapid development, we are concerned that the freedom of users to use, study, share, and improve the operating system software on their phones is being threatened. If we lose these freedoms on mobile, we may never get them back. This is especially troubling as mobile access to the Internet becomes the primary form of Internet usage worldwide.

Quick Recap

We are trying to demonstrate that it is possible to build a phone that respects user choice and freedom, vastly reduces vulnerability surface, and sets a direction for the ecosystem with respect to how to meet the needs of high-security users. Obviously this is a large task. Just as with our earlier prototype, we are relying on suggestions and support from the wider community.

Help from the Community

When we released our first prototype, the Android community exceeded our wildest expectations with respect to their excitement and contributions. The comments on our initial blog post were filled with helpful suggestions.

Soon after that post went up, Cédric Jeanneret took my Droidwall scripts and adapted them into the very nice OrWall, which is exactly how we think a Tor-enabled phone should work in general. Users should have full control over what information applications can access on their phones, including Internet access, and have control over how that Internet access happens. OrWall provides the networking component of this access control. It allows the user to choose which apps route through Tor, which route through non-Tor, and which can't access the Internet at all. It also has an option to let a specific Voice over IP app, like Signal, bypass Tor for the UDP voice data channel, while still sending call setup information over Tor.

At around the time that our blog post went up, the Copperhead project began producing hardened builds of Android. The hardening features make it more difficult to exploit Android vulnerabilities, and also provides WiFi MAC address randomization, so that it is no longer trivial to track devices using this information.

Copperhead is also the only Android ROM that supports verified boot, which prevents exploits from modifying the boot, system, recovery, and vendor device partitions. Coppherhead has also extended this protection by preventing system applications from being overridden by Google Play Store apps, or from writing bytecode to writable partitions (where it could be modified and infected). This makes Copperhead an excellent choice for our base system.

The Copperhead Tor Phone Prototype

Upon the foundation of Copperhead, Orbot, Orwall, F-Droid, and other community contributions, we have built an installation process that installs a new Copperhead phone with Orbot, OrWall, SuperUser, Google Play, and MyAppList with a list of recommended apps from F-Droid.

We require SuperUser and OrWall instead of using the VPN APIs because the Android VPN APIs are still not as reliable as a firewall in terms of preventing leaks. Without a firewall-based solution, the VPN can leak at boot, or if Orbot is killed or crashes. Additionally, DNS leaks outside of Tor still occur with the VPN APIs on some systems.

We provide Google Play primarily because Signal still requires it, but also because some users probably also want apps from the Play Store. You do not need a Google account to use Signal, but then you need to download the Signal android package and sideload it manually (via adb install).

The need to install these components to the system partition means that we must re-sign the Copperhead image and updates if we want to keep the ability to have system integrity from Verified Boot.

Thankfully, the Nexus Devices supported by Copperhead allow the use of user-generated keys. The installation process simply takes a Copperhead image, installs our additional apps, and signs it with the new keys.

Systemic Threats to Software Freedom

Unfortunately, not only is Copperhead the only Android rebuild that supports Verified Boot, but the Google Nexus/Pixel hardware is the only Android hardware that allows the user to install their own keys to retain both the ability to modify the device, as well as have the filesystem security provided by verified boot.

This, combined with Google's increasing hostility towards Android as a fully Open Source platform, as well as the difficulty for external entities to keep up with Android's surprise release and opaque development processes, means that the ability for end-users to use, study, share, and improve the Android system are all in great jeopardy.

This all means that the Android platform is effectively moving to a "Look but don't touch" Shared Source model that Microsoft tried in the early 2000s. However, instead of being explicit about this, Google appears to be doing it surreptitiously. It is a very deeply disturbing trend.

It is unfortunate that Google seems to see locking down Android as the only solution to the fragmentation and resulting insecurity of the Android platform. We believe that more transparent development and release processes, along with deals for longer device firmware support from SoC vendors, would go a long way to ensuring that it is easier for good OEM players to stay up to date. Simply moving more components to Google Play, even though it will keep those components up to date, does not solve the systemic problem that there are still no OEM incentives to update the base system. Users of old AOSP base systems will always be vulnerable to library, daemon, and operating system issues. Simply giving them slightly more up to date apps is a bandaid that both reduces freedom and does not solve the root security problems. Moreover, as more components and apps are moved to closed source versions, Google is reducing its ability to resist the demand that backdoors be introduced. It is much harder to backdoor an open source component (especially with reproducible builds and binary transparency) than a closed source one.

If Google Play is to be used as a source of leverage to solve this problem, a far better approach would be to use it as a pressure point to mandate that OEMs keep their base system updated. If they fail to do so, their users will begin to lose Google Play functionality, with proper warning that notifies them that their vendor is not honoring their support agreement. In a more extreme version, the Android SDK itself could have compiled code that degrades app functionality or disables apps entirely when the base system becomes outdated.

Another option would be to change the license of AOSP itself to require that any parties that distribute binaries of the base system must provide updates to all devices for some minimum period of time. That would create a legal avenue for class-action lawsuits or other legal action against OEMs that make "fire and forget" devices that leave their users vulnerable, and endanger the Internet itself.

While extreme, both of these options would be preferable to completely giving up on free and open computing for the future of the Internet. Google should be competing on overall Google account integration experience, security, app selection, and media store features. They should use their competitive position to encourage/enforce good OEM behavior, not to create barriers and bandaids that end up enabling yet more fragmentation due to out of date (and insecure) devices.

It is for this reason that we believe that projects like Copperhead are incredibly important to support. Once we lose these freedoms on mobile, we may never get them back. It is especially troubling to imagine a future where mobile access to the Internet is the primary form of Internet usage, and for that usage, all users are forced to choose between having either security or freedom.

Hardware Choice

The hardware for this prototype is the Google Nexus 6P. While we would prefer to support lower end models for low income demographics, only the Nexus and Pixel lines support Verified Boot with user-controlled keys. We are not aware of any other models that allow this, but we would love to hear if there are any that do.

In theory, installation should work for any of the devices supported by Copperhead, but updating the device will require the addition of an updater-script and an adaptation of the releasetools.py for that device, to convert the radio and bootloader images to the OTA update format.

If you are not allergic to buying hardware online, we highly recommend that you order them from the Copperhead store. The devices are shipped with tamper-evident security tape, for what it's worth. Otherwise, if you're lucky, you might still be able to find a 6P at your local electronics retail store. Please consider donating to Copperhead anyway. The project is doing everything right, and could use your support.

Hopefully, we can add support for the newer Pixel devices as soon as AOSP (and Copperhead) supports them, too.

Installation

Before you dive in, remember that this is a prototype, and you will need to be familiar with Linux.

With the proper prerequisites, installation should be as simple as checking out the Mission Improbable git repository, and downloading a Copperhead factory image for your device.

The run_all.sh script should walk you through a series of steps, printing out instructions for unlocking the phone and flashing the system. Please read the instructions in the repository for full installation details.

The very first device boot after installation will take a while, so be patient. During this boot, you should note the fingerprint of your key on the yellow boot splash screen. That fingerprint is what authenticates the use of your key and the rest of the boot process.

Once the system is booted, after you have given Google Play Services the Location and Storage permissions (as per the instructions printed by the script), make sure you set the Date and Time accurately, or Orbot will not be able to connect to the Tor Network.

Then, you can start Orbot, and allow F-Droid, Download Manager, the Copperhead updater, Google Play Services (if you want to use Signal), and any other apps you want to access the network.

NOTE: To keep Orbot up to date, you will have to go into F-Droid Repositories option, and click Guardian Project Official Releases.

Installation: F-Droid apps

Once you have networking and F-Droid working, you can use MyAppList to install apps from F-Droid. Our installation provides a list of useful apps for MyAppList. The MyAppsList app will allow you to select the subset you want, and install those apps in succession by invoking F-Droid. Start this process by clicking on the upward arrow at the bottom right of the screen:

Alternately, you can add links to additional F-Droid packages in the apk url list prior to running the installation, and they will be downloaded and installed during run_all.sh.

NOTE: Do not update OrWall past 1.1.0 via F-Droid until issue 121 is fixed, or networking will break.

Installation: Signal

Signal is one of the most useful communications applications to have on your phone. Unfortunately, despite being open source itself, Signal is not included in F-Droid, for historical reasons. Near as we can tell, most of the issues behind the argument have actually been since resolved. Now that Signal is reproducible, we see no reason why it can't be included in some F-Droid repo, if not the F-Droid repo, so long as it is the same Signal with the same key. It is unfortunate to see so much disagreement over this point, though. Even if Signal won't make the criterion for the official F-Droid repo (or wherever that tirefire of a flamewar is at right now), we wish that at the very least it could meet the criterion for an alternate "Non-Free" repo, much like the Debian project provides. Nothing is preventing the redistribution of the official Signal apk.

For now, if you do not wish to use a Google account with Google Play, it is possible to download the Signal apks from one of the apk mirror sites (such as APK4fun, apkdot.com, or apkplz.com). To ensure that you have the official Signal apk, perform the following:

  1. Download the apk.
  2. Unzip the apk with unzip org.thoughtcrime.securesms.apk
  3. Verify that the signing key is the official key with keytool -printcert -file META-INF/CERT.RSA
  4. You should see a line with SHA256: 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0 EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
  5. Make sure that fingerprint matches (the space was added for formatting).
  6. Verify that the contents of that APK are properly signed by that cert with: jarsigner -verify org.thoughtcrime.securesms.apk. You should see jar verified printed out.

Then, you can install the Signal APK via adb with adb install org.thoughtcrime.securesms.apk. You can verify you're up to date with the version in the app store with ApkTrack.

For voice calls to work, select Signal as the SIP application in OrWall, and allow SIP access.

Updates

Because Verified Boot ensures filesystem integrity at the device block level, and because we modify the root and system filesystems, normal over the air updates will not work. The fact that we use different device keys will prevent the official updates from installing at all, but even if they did, they would remove the installation of Google Play, SuperUser, and the OrWall initial firewall script.

When the phone notifies you of an update, you should instead download the latest Copperhead factory image to the mission-improbable working directory, and use update.sh to convert it into a signed update zip that will get sideloaded and installed by the recovery. You need to have the same keys from the installation in the keys subdirectory.

The update.sh script should walk you through this process.

Updates may also reset the system clock, which must be accurate for Orbot to connect to the Tor network. If this happens, you may need to reset the clock manually under Date and Time Settings

Usage

I use this prototype for all of my personal communications - Email, Signal, XMPP+OTR, Mumble, offline maps and directions in OSMAnd, taking pictures, and reading news and books. I use Intent Intercept to avoid accidentally clicking on links, and to avoid surprising cross-app launching behavior.

For Internet access, I personally use a secondary phone that acts as a router for this phone while it is in airplane mode. That phone has an app store and I use it for less trusted, non-private applications, and for emergency situations should a bug with the device prevent it from functioning properly. However, it is also possible to use a cheap wifi cell router, or simply use the actual cell capabilities on the phone itself. In that case, you may want to look into CSipSimple, and a VoIP provider, but see the Future Work section about potential snags with using SIP and Signal at the same time.

I also often use Google Voice or SIP numbers instead of the number of my actual phone's SIM card just as a general protection measure. I give people this number instead of the phone number of my actual cell device, to prevent remote baseband exploits and other location tracking attacks from being trivial to pull off from a distance. This is a trade-off, though, as you are trusting the VoIP provider with your voice data, and on top of this, many of them do not support encryption for call signaling or voice data, and fewer still support SMS.

For situations where using the cell network at all is either undesirable or impossible (perhaps because it is disabled due to civil unrest), the mesh network messaging app Rumble shows a lot of promise. It supports both public and encrypted groups in a Twitter-like interface run over either a wifi or bluetooth ad-hoc mesh network. It could use some attention.

Future Work

Like the last post on the topic, this prototype obviously has a lot of unfinished pieces and unpolished corners. We've made a lot of progress as a community on many of the future work items from that last post, but many still remain.

Future work: More Device Support

As mentioned above, installation should work on all devices that Copperhead supports out of the box. However, updates require the addition of an updater-script and an adaptation of the releasetools.py for that device, to convert the radio and bootloader images to the OTA update format.

Future Work: MicroG support

Instead of Google Play Services, it might be nice to provide the Open Source MicroG replacements. This requires some hackery to spoof the Google Play Service Signature field, though. Unfortunately, this method creates a permission that any app can request to spoof signatures for any service. We'd be much happier about this if we could find a way for MicroG to be the only app to be able to spoof permissions, and only for the Google services it was replacing. This may be as simple as hardcoding those app ids in an updated version of one of these patches.

Future Work: Netfilter API (or better VPN APIs)

Back in the WhisperCore days, Moxie wrote a Netfilter module using libiptc that enabled apps to edit iptables rules if they had permissions for it. This would eliminate the need for iptables shell callouts for using OrWall, would be more stable and less leaky than the current VPN APIs, and would eliminate the need to have root access on the device (which is additional vulnerability surface). That API needs to be dusted off and updated for the Copperhead compatibility, and then Orwall would need to be updated to use it, if present.

Alternatively, the VPN API could be used, if there were ways to prevent leaks at boot, DNS leaks, and leaks if the app is killed or crashes. We'd also want the ability to control specific app network access, and allow bypass of UDP for VoIP apps.

Future Work: Fewer Binary Blobs

There are unfortunately quite a few binary blobs extracted from the Copperhead build tree in the repository. They are enumerated in the README. This was done for expedience. Building some of those components outside of the android build tree is fairly difficult. We would happily accept patches for this, or for replacement tools.

Future Work: F-Droid auto-updates, crash reporting, and install count analytics

These requests come from Moxie. Having these would make him much happier about F-Droid Signal installs.

It turns out that F-Droid supports full auto-updates with the Priviledged Extension, which Copperhead is working on including.

Future Work: Build Reproducibility

Copperhead itself is not yet built reproducibly. It's our opinion that this is the AOSP's responsibility, though. If it's not the core team at Google, they should at least fund Copperhead or some other entity to work on it for them. Reproducible builds should be an organizational priority for all software companies. Moreover, in combination with free software, they are an excellent deterrent against backdoors.

In this brave new world, even if we can trust that the NSA won't be ordered to attack American companies to insert backdoors, deteriorating relationships with China and other state actors may mean that their incentives to hold back on such attacks will be greatly reduced. Closed source components can also benefit from reproducible builds, since compromising multiple build systems/build teams is inherently harder than compromising just one.

Future Work: Orbot Stability

Unfortunately, the stability of Orbot itself still leaves a lot to be desired. It is fairly fragile to network disconnects. It often becomes stuck in states that require you to go into the Android Settings for Apps, and then Force Stop Orbot in order for it to be able to reconnect properly. The startup UI is also fragile to network connectivity.

Worse: If you tap the start button either too hard or multiple times while the network is disconnected or while the phone's clock is out of sync, Orbot can become confused and say that it is connected when it is not. Luckily, because the Tor network access security is enforce by Orwall (and the Android kernel), instabilities in Orbot do not risk Tor leaks.

Future Work: Backups and Remote Wipe

Unfortunately, backups are an unsolved problem. In theory, adb backup -all should work, but even the latest adb version from the official Android SDK appears to only backup and restore partial data. Apparently this is due to adb obeying manifest restrictions on apps that request not to be backed up. For the purposes of full device backup, it would be nice to have an adb version that really backed up everything.

Instead, I use the export feature of K-9 Mail, Contacts, and the Calendar Import-Export app to export that data to /sdcard, and then adb pull /sdcard. It would be nice to have an end-to-end encrypted remote backup app, though. Flock had promise, but was unfortunately discontinued.

Similarly, if a phone is lost, it would be nice to have a cryptographically secure remote wipe feature.

Future Work: Baseband Analysis (and Isolation)

Until phones with auditable baseband isolation are available (the Neo900 looks like a promising candidate), the baseband remains a problem on all of these phones. It is unknown if vulnerabilities or backdoors in the baseband can turn on the mic, make silent calls, or access device memory. Using a portable hotspot or secondary insecure phone is one option for now, but it is still unknown if the baseband is fully disabled in airplane mode. In the previous post, commenters recommended wiping the baseband, but on most phones, this seems to also disable GPS.

It would be useful to audit whether airplane mode fully disables the baseband using either OpenBTS, OsmocommBB, or a custom hardware monitoring device.

Future Work: Wifi AP Scanning Prevention

Copperhead may randomize the MAC address, but it is quite likely that it still tries to connect to configured APs, even if they are not there (see these two XDA threads). This can reveal information about your home and work networks, and any other networks you have configured.

There is a Wifi Privacy Police App in F-Droid, and Smarter WiFi may be other options, but we have not yet had time to audit/test either. Any reports would be useful here.

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 port is still incomplete, however. The Tor Project is working on obtaining funding to bring it on par with the desktop Tor Browser.

Future Work: Better SIP Support

Right now, it is difficult to use two or more SIP clients in OrWall. You basically have to switch between them in the settings, which is also fragile and error prone. It would be ideal if OrWall allowed multiple SIP apps to be selected.

Additionally, SIP providers and SIP clients have very poor support for TLS and SRTP encryption for call setup and voice data. I could find only two such providers that advertised this support, but I was unable to actually get TLS and SRTP working with CSipSimple or LinPhone for either of them.

Future Work: Installation and full OTA updates without Linux

In order for this to become a real end-user phone, we need to remove the requirement to use Linux in order to install and update it. Unfortunately, this is tricky. Technically, Google Play can't be distributed in a full Android firmware, so we'd have to get special approval for that. Alternatively, we could make the default install use MicroG, as above. In either case, it should just be a matter of taking the official Copperhead builds, modifying them, changing the update URL, and shipping those devices with Google Play/MicroG and the new OTA location. Copperhead or Tor could easily support multiple device install configurations this way without needing to rebuild everything for each one. So legal issues aside, users could easily have their choice of MicroG, Google Play, or neither.

Personally, I think the demand is higher for some level of Google account integration functionality than what MicroG provides, so it would be nice to find some way to make that work. But there are solid reasons for avoiding the use of a Google account (such as Google's mistreatment of Tor users, the unavailability of Google in certain areas of the world due to censorship of Google, and the technical capability of Google Play to send targeted backdoored versions of apps to specific accounts).

Future Work: Better Boot Key Representation/Authentication

The truncated fingerprint is not the best way to present a key to the user. It is both too short for security, and too hard to read. It would be better to use something like the SSH Randomart representation, or some other visual representation that encodes a cryptographically strong version of the key fingerprint, and asks the user to click through it to boot. Though obviously, if this boot process can also be modified, this may be insufficient.

Future Work: Faster GPS Lock

The GPS on these devices is device-only by default, which can mean it is very slow. It would be useful to find out if µg UnifiedNlp can help, and which of its backends are privacy preserving enough to recommend/enable by default.

Future Work: Sensor Management/Removal

As pointed out in great detail in one of the comments below, these devices have a large number of sensors on them that can be used to create side channels, gather information about the environment, and send it back. The original Mission Impossible post went into quite a bit of detail about how to remove the microphone from the device. This time around, I focused on software security. But like the commentor suggested, you can still go down the hardware modding rabbithole if you like. Just search YouTube for teardown nexus 6P, or similar.


Changes Since Initial Posting

Like the last post, this post will likely be updated for a while based on community feedback. Here is the list of those changes so far.

  1. Added information about secondary SIP/VoIP usage in the Usage section and the Future Work sections.
  2. Added a warning not to upgrade OrWall until Issue 121 is fixed.
  3. Describe how we could remove the Linux requirement and have OTA updates, as a Future Work item.
  4. Remind users to check their key fingerprint at installation and boot, and point out in the Future Work section that this UI could be better.
  5. Mention the Neo900 in the Future Work: Baseband Isolation section
  6. Wow, the Signal vs F-Droid issue is a stupid hot mess. Can't we all just get along and share the software? Don't make me sing the RMS song, people... I'll do it...
  7. Added a note that you need the Guardian Project F-Droid repo to update Orbot.
  8. Add a thought to the Systemic Threats to Software Freedom section about using licensing to enforce the update requirement in order to use the AOSP.
  9. Mention ApkTrack for monitoring for Signal updates, and Intent Intercept for avoiding risky clicks.
  10. Mention alternate location providers as Future Work, and that we need to pick a decent backend.
  11. Link to Conversations and some other apps in the usage section. Also add some other links here and there.
  12. Mention that Date and Time must be set correctly for Orbot to connect to the network.
  13. Added a link to Moxie's netfilter code to the Future Work section, should anyone want to try to dust it off and get it working with Orwall.
  14. Use keytool instead of sha256sum to verify the Signal key's fingerprint. The CERT.RSA file is not stable across versions.
  15. The latest Orbot 15.2.0-rc8 still has issues claiming that it is connected when it is not. This is easiest to observe if the system clock is wrong, but it can also happen on network disconnects.
  16. Add a Future Work section for sensor management/removal

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

Comments

Please note that the comment area below has been archived.

November 16, 2016

Permalink

I am absolutely in favor of a more open development from google accepting patches to manufacturers handing in drivers for the linux kernel which android is based on to the community enhancing the operating system with fm support, a cypher indicator for the network and so on, google seems to ignore some of the really cool things people like to see and have partially gotten to work.

Having updates only partially in the play service and system apps instead of the core operating system is sad.

About the cipher indicator... wasn't everyone advused to avoid ecommerce when the EXPORT cipher downgrade attack for HTTPS was found?
Wouldn't it be prudent to advise everyone against any phone services related to commerce or social security numbers until the EXPORT cipher downgrade attack in cellular connections is fixed? Will the NSA even allow this gaping hole to be fixed? Isn't it their mission to make America as insecure to attackers as possible?

November 16, 2016

Permalink

wow! thank you so very much for this excellent update! The original post was great guidance and extremely helpful and this update makes it even better.

November 16, 2016

Permalink

CSipSimple doesn't seem to be actively developed. Have you evaluated Linphone as an alternative?

LinPhone is easier to configure in some ways (especially for encrypted VoIP providers), but I found it to be a little unstable, and also had a more confusing/cumbersome UI to actually use.

November 16, 2016

Permalink

Would Google accept a patch to fix VPN?
It seems silly for each ROM to have to choose between maintaining its own VPN implementation or have a broken VPN that offefs nothing but a false sense of security.
Will NSA allow Google to offer secure VPN? I'm suprised NSA hasn't banned the Rust language, and/or banned HTTPS.

NSA has succeeded in damaging America's national security far more than ISIS ever could. A real fifth column, the NSA. No agency hates America, hates liberty, hates free trade, or hates democracy more.

Plus one.

NSA is the enemy of every person on the planet--- US persons above all.

FBI is catching up fast, however.

How wonderful of you, US Federal government.

_______________________
< Independency_for_COW! >
-----------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||

November 16, 2016

Permalink

I'm very happy to see this update. Thank you very much!

Having said that, I think it comes across as unfair to the F-Droid project under the section for Signal.
Signal is not being excluded from F-Droid because of the GCM dependency. They want the program there, and the reason it isn't included is that Moxie Marlinspike has firmly requested that it is not to be. See e.g. https://github.com/LibreSignal/LibreSignal/issues/37
I do agree it's very unfortunate though. Of all applications not currently available in F-Droid, Signal is the one I would most like to see there.

Moxie has good reasons to oppose both federation and alternate implementations. They both tend to make protocols difficult to update, and Moxie needs to be able to update the Signal protocol with the least possible amount of friction and overhead, since his team is so small. See http://dephekt.net/2016/11/10/managing-security-trade-offs-why-i-still-…

So I think the F-Droid people were wrong to fight so hard for both a fork and federation. I hear Moxie is investigating creating a release of Signal with the Google Play Services dependency removed, so hopefully this will all get resolved soon either way.

November 16, 2016

In reply to mikeperry

Permalink

Like Moxie himself I would love to see him proven wrong about the necessity of centralization for flexible development and deployment here, but unfortunately I agree he probably has an excellent point about that, at least until someone comes up with a way to circumvent it.
As you point out, OpenWhisperSystems have limited resources and are naturally ultimately entitled to decide where to spend them.
I haven't been part of the discussion about forks and alternatives to GCM, and I can't claim to followed it in its entirety, but I have seen enough to dislike the tone of some parts, and I think Moxie has receiving both some requests that OWS has no obligation catering to (though no doubt usually made with the best of intentions) and unfair criticism.

However, I see federation and replacing GCM as largely separate issues from publication on F-Droid.
F-Droid could (and according to my impression would) have published their own build of the standard Signal-Android, and to the best of my understanding the reason they were refused to do so was that Moxie considered F-Droid's security procedures too weak and didn't want to hand over the responsibility in a way that could jeopardize user safety. I don't pretend to know nearly enough to question his judgment in those matters, but looking at the continued discussion the (admittedly reasonable) concerns seem to have been addressed since then. These days OWS could alternatively provide their own version, built and signed with their own process, in their own repository. That would take additional work, certainly.
I'm persistently puzzled about how neither F-Droid maintaining it nor OWS maintaining a version for F-Droid would be acceptable. In my view the practical alternatives for someone who (again justifiably) wants to keep Google influence out of their phone (but would be prepared to accept, at least for now, the "tickle" from GCM for the sake of Signal) are likely to be far less secure, either by trusting entities much harder to verify or by relying on manual updates that are prone to get delayed sooner or later.

On the off chance there was any doubt, I have a great deal of respect for Moxie Marlinspike and the work of OWS and in no way mean to denigrate either.
I am sad to see the current situation in connection with F-Droid though. Once that resolution you mention arrives I welcome it.

Sorry if this carried the topic too far from your actual article, by the way. It strikes me as very impressive work, and that's where the attention belongs in this context.

The security issue that you mention is that previously, apps built by f-droid.org must have been signed by a key maintained by f-droid.org instead of the developer's key. This is no longer the case, apps can be submitted to f-droid as source only with a link to the developer's own signed binary. f-droid.org will then build the source, and if it matches the APK that the developer submitted, it will be included as a verified reproducible build. The only issue preventing Signal from being included in f-droid.org is that it includes Google's proprietary binary blob library for GCM.

Please forgive my ignorance but can't this be solved by linking to GCM dynamically instead of statically and using the simpler, less efficient method (Signal keeps a connection open constantly) when GCM is, for whatever reason, unavailable?

Moxie considered F-Droid's security procedures too weak and didn't want to hand over the responsibility in a way that could jeopardize user safety.

It not jeopardizes user safety more, than SMS account registration antiprivacy "feature" and Google Play services.

Moxie0 doesn't really think LibreSignal(deblobbed Signal) is less secure than Signal.
The only possible real reason for someone of his intelligence to make such claims, and to threaten to sue anyone who recompiles his GPL project without taking out all the URLs to central server (which it is useless without) is because he is anti-freedom and anti-liberty, like the NSA.

November 17, 2016

In reply to mikeperry

Permalink

Yes, but this is not what the post says. The post implies that F-droid could create a non-free repo to distribute Signal. They can't. Because Moxie doesn't want them to. Signal was at F-droid at some point. So that part of the post is totally inaccurate and unfair for F-droid.

Good point. Moxie originally blocked the distribution of a rebuilt Signal with a different key, which I also think was legitimate for him to do.

However, now that Signal is reproducible nothing should be stopping F-Droid from distributing the official Signal with the official key. Nothing is stopping anyone from redistributing the Signal apk in its original form, either.

I updated the post to reflect this.

Whisper Systems could easily run an F-Droid repository on their own website, then we could include it in F-Droid like we do the Guardian Project, and users would just need to flip a switch to enable it. They could also use the fdroidserver stack to have a fully reproducible build, which automatically feeds into that repository. This would work with the current source code as it is, with the proprietary Google GCM library in it. I'm happy to help anyone with this process.

November 16, 2016

Permalink

Would Google accept a patch to fix VPN?
It seems silly for each ROM to have to choose between maintaining its own VPN implementation or have a broken VPN that offefs nothing but a false sense of security.
Will NSA allow Google to offer secure VPN? I'm suprised NSA hasn't banned the Rust language, and/or banned HTTPS.

November 16, 2016

Permalink

> We provide Google Play primarily because Signal

We can haz pribacee if we comply wit ur controls.

Prob got dem autro-updates XD

E.T. phone home.

November 16, 2016

Permalink

Orwall is not updating anymore:
"Important announcement
After many thoughts, we have to put a term to orWall dev. The code won't be updated anymore (and hasn't be for ages), and it still has some security flaws as you might see in the opened issues."

https://orwall.org/

Hrmm. It was my understanding that OrWall maintenance was taken over by Henri Gourvest. But perhaps he stopped, too..

If so, we need a new OrWall maintainer... It would be sad to lose it.

November 22, 2016

In reply to mikeperry

Permalink

It looks like it may not be as dead as that site exists:

https://twitter.com/orWallApp

"orWall Application ‏@orWallApp Jun 27

Sad we had to announce EOL in order to get some people involved. But hey, project's not dead thanks to @hgourvest! A big thanks to him!"

I don't see that getting distributed with any Tor products until it is mainlined, but it's a great step in the right direction! I would definitely like to see Signal switch to an open transport mechanism.

I don't think this build works anymore, as Moxie asked them to stop distributing up-to-date versions. I used to use it, but it stopped working, so now I use the official Signal build alongside the gapps microG Google Play Services replacement. Maybe there's a new build that works on Eutopia now, but it certainly didn't for a while. Also I found the websockets version to be less reliable for prompt delivery and reception of messages.

November 16, 2016

Permalink

PS: the SnowdenBunnie approach (sleeve) is basically missing the point and probbaly also won't work the way Bunnie hopes for, due to technical reasons how iPhone manages antennas

November 17, 2016

Permalink

Make a TrustZone kernel without memory corruption or cipher implementation bugs and you can actually harden apps even on unpatched phones. ARM actually has really good isolation.

Even if this were true, unpatched phones are an externality that the end user and the Internet are forced to pay for.

But it's not true. All that has to happen is that the base system becomes compromised, and then there are plenty of microphones, sensors, wifi information, and other side channels to get plenty of valuable and damaging information about the user, and to attack other systems nearby.

Google's mismanagement of the ecosystem is disastrous beyond the point where bandaids like this will fix it. They should focus on competing with their competitors, not hamstringing people working with the base system, or fragmenting the platform. They should go scorched earth on $50 phone manufactures who don't provide updates. Users should be told that if they buy a $50 phone, it may stop working properly in 6 months when it is out of date. There is no other way to stop the race to the bottom.

Another alternative to using Google Play as a source of leverage is to create a new license for AOSP, such that it is a violation of the license to fail to provide updates for devices. That would create a legal avenue for Google and end-users to go after violators.

November 17, 2016

Permalink

I don't understand why I need Google Play Services or Signal to have a Tor enabled android phone.

Also Copperhead is nice, but it's not FOSS. You shoud check their license.

Replicant is good but also not completely free/libre (it requires proprietary baseband firmware). Replicant and CopperheadOS are the only roms anyone should run, given the choice, which sadly few are. Avoid Verizon at any cost if you value freedom and liberty. Get a Nexus or Pixel if you can.

Replicant itself is completely free, but yes, of course the baseband remains a problem. And it isn't particularly up-to-date at the moment, which carries its own risks (though they're making good progress on a version based on a newer android base). There are no ideal options at the moment, unfortunately, but as you say, Replicant do good work here, as do (from the looks of it) Copperhead.

November 17, 2016

Permalink

Please DO buy your device from CopperheadOS Store directly. They desperately need the funding (and contributors) to keep the project alive. For basics like servers, devices to port to and survival income for what's been an ongoing FULL-TIME development effort for a couple of years already. This project is too important to die. So do the right thing! At very least, send a considerable donation. It's more than well deserved.

November 17, 2016

Permalink

This does seem like quite a task because, as mentioned in the first post, it appears as though the goals of the Android project are almost the exact opposite of the Tor project from a privacy standpoint. I almost think Ubuntu for Phones would be an easier route since it uses a (more-so) mainline kernel, APT, Debian repos, Upstart/systemd, glibc, LXC (for Android drivers), theoretically SELinux, AppArmor, libseccomp2, etc., and many of the other projects we've come to know and have already developed code for on the desktop and server.

Sadly Canonical seems to have abandoned Ubuntu for Android in favor of partnering with OEMs to "sell" the vanilla (no Android drivers) OS preinstalled. While the Meizu Pro 5 is roughly on par with the Nexus 6P (iirc), there aren't many devices to choose from, and practically none if you're in the U.S. I attribute Ubuntu for Phones's failure (if you call it that) mostly to timing -- it came out alongside Firefox OS for Android, Tizen, Windows, and a few other mobile OSes at a time when Android had just reached Apple's market share bracket -- but so it is life.

It's sad to see Google pushing AOSP in the direction it is, but I commend the Tor and Copperhead projects for taking on such a giant task. With Rule 41 on its way fast, goodness knows we need it now more than ever.

Bonus points: is it theoretically possible to rebase Copperhead on Replicant (a blob-free Android distro with Debain-like free software policies) for devices that support it?

> With Rule 41 on its way fast,

There has been some confusion in the press about when the changes will take effect if Congress does not act. The date is Thu 1 Dec 2016, not Sat 31 Dec 2016.

I urge all Debian users to install apt-transport-tor which should help you continue to be able to access unbackdoored software, at least in the short term. A key issue here is that governments including the USG can obtain fake "root certs" enabling them to impersonate any site using https, but onion services can circumvent such state-sponsored MITM.

In the event that the USG declares encryption/tor/open-source illegal in coming months, I hope both Debian Project and Tor Project have a plan to protect critical keyrings, equipment, employees, volunteers and other infrastructure needed to ensure their survival (presumably in nations located far outside the USA).

This will be a time when US users will be required to either follow their core beliefs, even at the cost of "going underground" or attempting to circumvent US laws, or to cave into USG oppression.

Please don't risk your computer and/or risk your phone like this.
Set up QubesOS with IOMMU sandbox before connecting computer to phone.
If hou can flash a rom you can install QubesOS. It's really user-friendly and much safer than Debian. Not safe, but less dangerous.

Alas, I cannot flash a ROM.

@ Mike Perry:

Do we have some reason to think your phone will resist FBI hacking come 1 Dec 2016?

DOJ posted on their government blog calling for support for the changes; some Congress persons introduced a bill in the Senate (and the House?) to block the changes in Jul 2017, in order to give the next Congress some time to debate them. There may still be just enough time to stop this nightmare.

A recent article at motherboard.vice.com lists some of the countries where computers have already been attacked by FBI (without "authorization" under US law). An article in techdirt.com (I think) mentioned that FBI sent malware to *every user* or tormail.com, allegedly seeking to identify one person they thought might be using an account there. This indicates that we can expect a blizzard of "legally authorized" phishing of millions of webmail users who use smaller email providers or who have expressed support for BLM or criticism of the Surveillance State.

No, I can't make that guarantee. I am only pointing towards a possible future that allows us to retain any computer security in the long term.

In the short term, maybe use iOS. But it is only a matter of time before that is not enough. Here's how this plays out in the long term:

1. iOS becomes the dominant security platform for journalists, activists, dissidents, immigrants, Muslims, crim'nals, terr'ists, and anyone else marked with a colored triangle or two...
2. Some atrocity happens that gives the reactionary elements an excuse to renew their argument for backdoors.
3. The backdoor argument is won in our favor (again), but as a compromise, Apple is compelled to use the iOS app store to deliver targeted backdoors to anyone the police forces deem as undesirable.
4. This mechanism is hijacked by any number of state and non-state adversaries via bribes, exploits, social engineering, and other means, and everyone using the system is vulnerable.

Who knows, #4 may not ever even happen. But I'll bet all my bitcoin #1-3 will, unless something changes really soon. And in this Darkest Timeline, #1-3 should be enough to give us pause.

November 22, 2016

In reply to mikeperry

Permalink

dont let me dis-heart you...

sound like you could be trying to sell apple products ?

in the UK new laws being passed as i understand the new technical warrants that could be served could potentially allow to weaken lots of products such as apple.

i wish i know what the answer is to this new legal legislation to get around the new UK draconian laws.

November 23, 2016

In reply to mikeperry

Permalink

> No, I can't make that guarantee. I am only pointing towards a possible future that allows us to retain any computer security in the long term.

Understood. I believe our situation is now so desperate that we must try desperate measures, e.g. using "beta tests" for real.

> Here's how this plays out in the long term:
>
> 1. iOS becomes the dominant security platform for journalists, activists, dissidents, immigrants, Muslims, crim'nals, terr'ists, and anyone else marked with a colored triangle or two...

If you attend any political rallies, please report any overflying Cessna or other aircraft to ACLU. The FBI spyplanes often fly at very low altitudes (1000-1500 ft above ground level, lower than FAA likes for general aviation except very near an airport). They may circle counterclockwise, possibly in very wide circles so that marchers only see/hear them flying in what appears to be a "straight line", but returning every few minutes. They may also fly in tight circles. The planes may carry 1-3 people. FBI spends at least $300/hr to operate the plane, with salaries for the agents (typically a pilot and an observer, and often a liason with local police) on top of that. Pilots get extra hazard pay for night landings and low level flight near tall structures.

Look for a camera turret often mounted on a mounting arm under the left wing. This turret also contains an infrared laser target designator, as documents obtained by ACLU under FOIA confirm. The camera system can be used to "lock" on individual people in the crowd, and can be used to feed FBI's facial identification system. The laser designator can then be used to indicate to ground crews which person should be followed home, tackled by an arrest team on the ground, or even (worst case) "taken out" by an FBI sniper. This gives new meaning to "tagged", yes?

Not all of the planes carry the cameras, but you may be able to spot the mounting arm. The camera is detachable, so if one plane is in the shop, the agents can remount it on their backup spyplane. There are many pictures on the internet of planes identified as FBI spyplanes by Buzzfeed news reporters in their superb story. After that story appeared, Comey complained that he would have to buy an entirely new fleet (Buzzfeed documented more than 100 FBI spyplanes, not counting planes used by DEA and other federal agencies), and FBI appears to be doing just that. Some of the new planes are single engine planes not made by Cessna.

ACLU suspects that federal spy planes sometimes carry "cell-site simulators", aka IMSI catchers, e.g. Harris Stingray, Kingfish, or comparable gear from DST (NSA's favored purveyor), Cellebrite, or Cobham.

The planes have often been observed monitoring peaceful rallies such as "Islamic Day" or anti-Trump rallies. Sometimes with "comical" results, such as agents failing to observe a shooting several blocks away from the peaceful protest march.

> 2. Some atrocity happens that gives the reactionary elements an excuse to renew their argument for backdoors.

Yes, they already have their Op-Eds and letters to Congress drafted.

NSA and FBI had planned for something like 9/11 well before that happened, and quickly dusted off their plan when the hijackers struck. How nice of Bin Laden to cooperate with their plans.

> 3. The backdoor argument is won in our favor (again), but as a compromise, Apple is compelled to use the iOS app store to deliver targeted backdoors to anyone the police forces deem as undesirable.

Or Tor Project. Unless you all relocate, I fear you will be vulnerable to fascist pressure.

> 4. This mechanism is hijacked by any number of state and non-state adversaries via bribes, exploits, social engineering, and other means, and everyone using the system is vulnerable.
>
> Who knows, #4 may not ever even happen. But I'll bet all my bitcoin #1-3 will, unless something changes really soon. And in this Darkest Timeline, #1-3 should be enough to give us pause.

I have to agree with all that.

Desperate times, desperate times.

In a way, that might work for the resistance, because if enough people have read enough about the rise of the Third Reich to see the clear similarities (history never repeats itself but sometimes it follows a helical path, with the same oppressive and even genocidal ideas coming back with much greater technical sophistication) more people may be willing to take the extraordinary risks which will be required to oppose a vindictive US President who espouses racial/ethnic/religious hatred.

To leave or not to leave? It's an individual decision and I respect that, but I hope key Tor Project employees will seriously consider leaving while you still can.

November 23, 2016

In reply to mikeperry

Permalink

From ArsTechnica:

> During [US President-elect Donald Trump's post-election] video message—which lasted less than three minutes—Trump touched on a number of areas that are likely to be of interest to Ars readers. However, his only explicit mention of the digital world was of its darker side: "I will ask the Department of Defense, and the chairman of the joint chiefs of staff, to develop a comprehensive plan to protect America's vital infrastructure from cyberattacks."

Sounds like the same Committee Sen. John McCain is calling for, which will seek some way of backdooring everything while somehow reassuring us that no-one could possibly abuse the thing the government doesn't want anyone to call a "backdoor". Yeah, right...

>Do we have some reason to think your phone will resist FBI hacking come 1 Dec 2016?

That's not really the point here. We all well know here that nothing is hack-proof; the best we can do is make our software hack-resistant, and right now Copperhead seems to be the only option.

From the legislative perspective, it's unclear how much Rule 41 will change in practice: the FBI is already delivering malware to users based on catch-all search warrants authorized by magistrate judges in random jurisdictions. Read "The Playpen Story" blog article by the EFF.

The key part is that currently many judges are throwing away evidence on the grounds that the warrant was invalid. Rule 41 will prevent them from doing this in the future.

It's the old bait and switch: use it to catch child pornographers first and get everyone desensitized to law enforcement hacking or what-have-you, then begin using it on political dissidents and journalists and other "troublemakers."

> Please don't risk your computer and/or risk your phone like this.

Risk... "like this"? Like what precisely?

Are you claiming that Peter Palfrader (Debian Project and Tor Project) is mistaken to believe that updating over Tor is safer for at-risk users? (See the announcement some time ago in this blog.)

If so, can you be more specific about the technical risks you perceive?

If it helps, I use Debian mostly off-line, but it's important to update it even though I use Tails as much as possible.

Does anyone know if Shari is in touch with Sen. Wyden (D-OR) about the last ditch effort bipartisan bill he is cosponsoring which would block the changes to Rule 41 until July 2017, in order to give the next Congress the opportunity to debate the changes?

At least a dozen Senators seem to be sponsoring the bill--- see TheHill.com

> With Rule 41 on its way fast, goodness knows we need it now more than ever.

Plus one. Also: a last ditch bipartisan effort to delay the changes (which go into effect Thu 1 Dec 2016 unless Congress acts immediately) has been introduced in the Senate (with a counterpart bill in the House, I believe):

https://www.eff.org/deeplinks/2016/11/give-congress-time-debate-new-gov…
Give Congress Time to Debate New Government Hacking Rule
Kate Tummarello
17 Nov 2016

> If Congress doesn’t act soon, federal investigators will have access to new, sweeping hacking powers due to a rule change set to go into effect on Dec. 1.
>
> That’s why Sens. Chris Coons, Ron Wyden, Mike Lee, and others introduced a bipartisan bill today, the Review the Rule Act, which would push that rule change back to July 1. That would give our elected officials more time to debate whether law enforcement should be able to, with one warrant from one judge, hack into an untold number of computers and devices wherever they’re located.

Thanks for the tip. Looks like I'll be calling my senators and congressmen yet again. I can't seem to find a bill number for it. Am I missing something?

Senator Wyden's office said it doesn't have a Senate bill number yet, but the house version (by Ted Poe, with Wyden et al. as cosponsors) is H.R. 6341. So call your state's federal House representatives' Washington DC offices and tell them you support H.R. 6341 "Review the Rule Act”.

Good stuff, thanks.

Any word from Wyden's staffers about the progress of these bills? There is just one week left as I write, but sometimes Congress acts swiftly.

Check the wyden.senate.gov and Poe.house.gov blogs. You could call their offices and ask, but I don't know if they have any way of actually knowing what kind of progress it's making, or what kind of answer they could give you. Beyond that, Google is your friend. There is news about both bills on plenty of sites, but we won't actually know how much progress we're making until Dec 1st.

Seriously? On this thread someone would say "Google is your friend." ?! Google is no one's friend. Google's existence depends on creating behavioral profiles of everyone, which will always be vulnerable at some level; if not technically, then legally. Sheesh.

Aw, *#?!$^...

Congress has left for a five day weekend (as of 23 Nov 2016) without having done anything to move the Review the Rule Act forward.

Staffers won't be back until sometime around 9AM Mon 28 Nov 2016 EST, which gives them less than 48 hours to block the changes to Rule 41.

Seems like every time a baffled citizen assumes the risk of speaking out, saying "let's give the system a chance to do its job", the system does its level best to make us look like simpletons. Thank you very much, Congress.

Sheriff Dave Clarke of Milwaukee county would be thrilled by your words, because in numerous op-eds in major US news media he has claimed that the US is already in a state of "civil war" (his words).

Comparision with the horrors unfolding in Syria show rather starkly that Sheriff Clarke has lost contact with reality.

Vulture central doesn't hold out much hope for stopping Rule 41 with six days to go until FBI sends us all NIT malware, but Iain Thompson states well the essential point for Tor users all over the world:

http://www.theregister.co.uk/2016/11/23/fbi_rule_41/
FYI: The FBI is being awfully evasive about its fresh cyber-spy powers
Agents want to hack suspected Tor, VPN users at will – no big deal
Iain Thomson
23 Nov 2016

> Senior US senators have expressed concern that the FBI is not being clear about how it intends to use its enhanced powers to spy on American citizens. Those are the spying powers granted by Congressional inaction over an update to Rule 41 of the Federal Rules of Criminal Procedure. These changes will kick in on December 1 unless they are somehow stopped, and it's highly unlikely they will be challenged as we slide into the Thanksgiving weekend.
> ...
> This guilt-by-association concept is particularly worrying for Tor users who just like to anonymize their internet use because they don’t feel like handing over their online viewing data to advertisers, or because they might fear persecution. The US government partially funded Tor for this latter group.

FBI sent malware laden phishing emails to *every* tormail.com account. Come 1 Dec 2016, should we expect them to send malware laden phishing emails to *every* account at Riseup, NoLog, Boum, Yahoo, Google...? I fear we should.

November 17, 2016

Permalink

The latest release of Orbot has addressed the start/stop weirdness, and some of the hanging issues. That said, we are working to update the network listener code to the latest APIs available in Android 6/7. When you are building an app that does the unusual things that Tor requires, and it must run on over 10,000+ variations of devices across 10 releases of an operating system, sometimes things don't always work just perfect.

+n8fr8

I appreciate how overworked you are but please update it on F-droid not just Google Play, because Google Play allows arbitrary remote code execution by design (to anyone at Google, at your ISP, or who guesses your email password and installs malware through web interface).
Thank you for your great work.

Sorry if this is a stupid question but do you mean everyone should use the latest release version (15.1.2 very old, only exists in archives) or latest version released (15.2.0-rc8 presumably a release candidate)? Is there any non-horrible option for Android? Besides "don't use Android"?

While the UI is slightly better, I tried 15.2.0-rc-8 and it still has most of these issues. Try setting your clock to an incorrect time, or connecting while there is no Internet access, or from a WiFi access point that is unpluged from the Internet (aka the Tor network is censored). All of these things will cause the same type of failure on every phone model.

The frequent crashing I can understand may be due to Copperhead's unique memory management, but even that seems a bit odd... It is very frequent.

November 23, 2016

In reply to mikeperry

Permalink

Is the old, stable one or the new, release candidate one less likely to have remote code execution bugs?

November 17, 2016

Permalink

Mike Perry, you are my hero.

Thanks, as always, for pushing the envelope by continuing to work on free software for freedom to enable people to communicate securely.

In this case, I don't deserve the bulk of the credit. This phone relies on the work of many, many people. I merely put their work together in a unique way to make some points about free software, privacy, and security, and to raise awareness of the gaps and barriers to meeting those ideals and goals.

November 17, 2016

Permalink

Awesome! Thanks for all your hard work, Mike.

The other Mike (Pence) is a determined advocate of warrantless dragnet surveillance (he doesn't believe LEAs should need any warrant to search devices, track all phones, or anything else they might want to do for any reason), and it seems certain the changes to Rule 41 will go through, allowing FBI to attack any computer anywhere in the world for any reason. We know that they have already engaged in such ugly actions as sending malware to *every* tormail address, attacking computers in numerous countries outside the US, etc. FBI rank and file strongly support the fascistic ideas of DJT, Mike Pence, the odious Milwaukee County Sheriff Dave Clarke (who has been mentioned as a possible Attorney General or DHS chief in the Trump admin, and who insists that the US is already in a "civil war" [his words] with pro-democracy movements such as BLM). Former congressman Mike Rogers (a former FBI agent) has also been mentioned as a possible cabinet member in the Trump administration. Other potential picks include openly racist retired generals. This is *not* a "normal transition".

So we need technical defenses for all Tor users, but we also need key Tor Project employees to be safe from FBI harassment or worse. Hope you and other key people are discussing options with Shari.

You scoff, but it's not as if white society has generally truly cared about democracy. Democracy to white American society means when things are most comfortable for themselves.

Anyone who is not a committed fascist or racist should be a fervent supporter of BLM.

The government is fixing to kill all the dissidents regardless of race. And the alternative waiting to replace to the government is the gangs and the militias, who are also fixing to murder their way unto the extinction of humanity. BLM opposes brutality by police or by gang.

I see BLM as the most important grassroots movement opposed to American fascism.

The experience of black people in America over the past few centuries is a clear indication of what what all non-billionaires can expect to become their lot in Post-America. Progressive enslavement. Unbearable oppression. A choice between a fatal confrontation with the Man or pointless unbearable endless suffering.

How sad that the American experiment which began so bravely in 1775 has ended in such an awful spectacle, while the authoritarians cheer.

Will you take up arms with me Dec 1 if this fascist abuse of legislative loopholes is used to oush through rule 41 changes that change America from barely democratic to out-right authoritarian dictatorship? The processes being used to make this change were intended for minor errata only. The thugs abusing it are traitors to their country and the law calls for their execution.

As horrible as all that is, there are countless forums dedicated to such topics, and very few about keeping the Internet safe and secure in the face of totalitarian dictatorships (which the US is turning into and adguably already is).
Only the part about "presidential authority in times of war" really applies to information systems, as important as the rest of your post was. Sorry if this is rude of me, but I'm scared of j-trig operatives derailing infosdc discussions. Ldt's talk about solutions to how these madmen are ruining the Internet and destroying the Bill of Rights (and european equivalents liek the "right to be let alone").

November 17, 2016

Permalink

> It is unknown if vulnerabilities or backdoors in the baseband can turn on the mic, make silent calls, or access device memory.

One of the most needed consumer items (which FBI/NSA will hate and try to prevent from ever coming to market) is a dongle with audited open source SDR software which can produce a power spectrum in the range of perhaps 50 MHz to 6 GHz. Simply seeing a sudden spike at 2.4 GHz (for example) when the dongle is near your phone could indicate a silent call from the phone.

No doubt it would take much research and experience to begin to understand what is a "normal" kind of power spectrum in US cities, and what various spikes might indicate.

Just to clarify: consumers are coming to understand that they have a legitimate need to check up on what the devices they own (to the extent that "ownership" remains a meaningful concept) are doing.

Is your phone making a silent call without your knowledge? You thought you turned off Bluetooth for your computer, but did you really turn it off? You thought you secured your smart thermostat, but what if it is communicating with a neighbor's device without your knowledge? Is someone using a retro-reflector to spy on your consulate office? Has someone hidden a bug in your bedroom which is transmitting audio when someone speaks at 2.4 GHz?

There is an enormous variety of protocols and spectra to consider, and a power spectrum is a crude tool, but in real time, potentially very useful as an indication that some device appears to be doing something strange.

Modern cities are so noisy, especially in wavelengths used by WiFi internet and phones, that the dongle would become much more useful if you could also buy a Faraday cage and put both the suspect device and your laptop with dongle inside, to try to ensure that the suspect device really is responsible for a suspicious emission of RF energy.

@ Mike, Peter: please pressure Debian to upgrade the initrd bug. I believe this is much more serious for journalists, bloggers, human rights workers than they have yet recognized. It should be patched in stable.

The advantage of a crude spectrum analyzer over something smart enough to analyze signals and tell you if there's anything sketchy going on is that ghe former can be implemented with simple analog parts, with nothing re-programmable, and of course can be cheaper and easier for someone more skilled than myself to publish a guide on how to make your own with parts from Radioshack.

Making it directional can eliminate false positives from a noisy environment. If you put a compromised laptop in a faraday bag the malware in it may detect this and uninstall itself, and get reinstalled soon after with whatever 0day it used before. The NSA/PLA/other-nation-state-APT's are easily advanced enough to do this.

> The advantage of a crude spectrum analyzer over something smart enough to analyze signals and tell you if there's anything sketchy going on is that ghe former can be implemented with simple analog parts, with nothing re-programmable, and of course can be cheaper and easier for someone more skilled than myself to publish a guide on how to make your own with parts from Radioshack.
>
> Making it directional can eliminate false positives from a noisy environment.

Agree with all that, except that Radioshack is bankrupt and may not survive even after restructuring.

> If you put a compromised laptop in a faraday bag the malware in it may detect this and uninstall itself, and get reinstalled soon after with whatever 0day it used before. The NSA/PLA/other-nation-state-APT's are easily advanced enough to do this.

Yes, but we need to balance that with the fact that they have problems of their own. Their resources (money and especially technical talent) are not literally unlimited, they have to prioritize, and when they are asked for help by another agency, ancient rivalries can continue to affect whether they choose to help another agency attack citizens the other agency desires to target.

Researching the RF environment in US cities is one of the most important things US security researchers have by and large *not* been doing. This is very dangerous because the government (not just federal, but even municipal) are doing serious "research" of their own in this area.

Readers of a certain age may recall a cliche of World War II movies, in which we see a Gestapo radio direction finding vehicle pass by the Parisian house where OSS agent Gregory Peck is using his clandestine radio to contact the Free French. Suddenly Gestapo agents burst in spraying machine fire. Finito poor Peck.

Trump advisors such as Sheriff Dave Clarke of Milwaukee County very much want to bring that kind of action to US cities in the year 2017. Don't believe it because *I* say so. Believe it because *he* says so. Check out his numerous Op-Eds declaring that the US is already experiencing a "civil war". His words, not mine.

> @ Mike, Peter: please pressure Debian to upgrade the initrd bug. I believe this is much more serious for journalists, bloggers, human rights workers than they have yet recognized. It should be patched in stable.

I've tested it and the backdoor works just like the researchers claimed. When your LUKS encrypted device asks for the LUKS passphrase, simply repeatedly hit enter. After about 100 attempts, you will see the initrd shell, allowing you to replace the kernel or firmware with your own version or to plant a keylogger.

In Oct 2015 an unknown actor (even the university PD appeared to admit that the leading suspect is some current or former CIA officer, but the cops declined to question the CIA officer who is stationed on campus) picked the lock to the office of a human rights researcher with Center for Human Rights (University of Washington), which is suing the CIA for rampant human rights abuses during the "Dirty Wars" in Latin America. The intruder took the hard drive containing her legal case notes and left, relocking the office door. This MO is obviously completely unlike a criminal MO.

The same presumed current or former CIA agent could easily have spent a few extra moments exploiting the initrd bug, so that the next time the legit user booted her PC, her LUKS passphrase would be snagged, allowing easy untraceable access on repeat visits by the intruder.

thestranger.com
Two Weeks After It Sued the CIA, Data Is Stolen from the University of Washington's Center for Human Rights
Ansel Herz
21 Oct 2015

seattlepi.com
Break-in reported at UW center fighting CIA on El Salvador
Police investigating after professor’s computer goes missing
Levi Pulkkinen
21 Oct 2015

> One of the most needed consumer items (which FBI/NSA will hate and try to prevent from ever coming to market) is a dongle with audited open source SDR software which can produce a power spectrum in the range of perhaps 50 MHz to 6 GHz. Simply seeing a sudden spike at 2.4 GHz (for example) when the dongle is near your phone could indicate a silent call from the phone.

"Professional grade" spectrum analyzers are already widely used by companies and local, provincial and national governments.

For example, Landis+Gyr is a giant multinational corporation which has sold "smart meter" systems to city governments all over the world, including many of the largest US cities. Keep an eye out for Landis+Gyr trucks laden with surveillance gear, most prominently a very noticeable antenna (looks like an old style TV antenna, rotatable in horizontal plane) mounted on the left rear of the vehicle. These vehicles are performing spectrum analysis, supposedly to detect persons using equipment which might interfere with Landis+Gyr smart meters (c. 900 MHz), such as ordinary walkie-talkies. The directional antenna is used to triangulate the walkie-talkie users, who can then be referred for prosecution. Ironically, the people who are most likely to use the offending devices include: cops, construction workers, transportation workers, and schoolchildren. So this sets up a conflict between all those people and the newly repressive "cybersecurity" regime.

Vehicles operated by unknown entities which employ gear which can illicitly snoop directly (through unintentional EMF emanations) on laptop displays, laser printers, etc. (the kind of attack TEMPEST technology is intended to thwart), are also becoming much more common. The cost of the specialized equipment (thousands of US dollars) is easily within the range of millions of governments, companies, and hobbyists. Spycos are actively miniaturize such gear to mount on cheap microdrones, further increasing the threat.

November 17, 2016

Permalink

@ Mike:

What does a 80 yo renegade who has avoided e-commerce and smart phones owing to insecurities need to purchase the prototype? (This device sounds so promising some will rethink their data refusenik policies.)

At a guess, at a minimum you need all of these:

o current internet access

o current account with some wireless provider (do they all accept Android phones?)

o a commonly accepted valid credit card and sufficient knowledge to use it with minimal danger of being rooked

o sufficient funds to purchase a Google Nexus 6P (how much does it cost?)

o knowledge of e-commerce sufficient to order a Google Nexus 6P from Copperhead store

o some kind of Google store account (?) and sufficient knowledge to obtain the aps

You can buy a prepaid loadable credit card with cash almost anywhere, load it with cash, and buy a Nexus or Pixel from Google(at a public computer not tied to you), shipped to a vacant lot, and unless someone sees you go there to pick it up it won't be tied to you in any way.
Then just skip making a Google account (you only need one for Google Play, not for Google Cloud Services). You can download the Signal.apk from its official website over HTTPS without any accounts.
My personal recommendation is to only get software through F-Droid (https://f-droid.org/) but avoiding Google accounts is a good start.
Please only use this knowledge to spread freedom and democracy. Knowledge is power and can be used for good or bad.

> You can buy a prepaid loadable credit card with cash almost anywhere, load it with cash, and buy a Nexus or Pixel from Google(at a public computer not tied to you), shipped to a vacant lot and unless someone sees you go there to pick it up it won't be tied to you in any way.

You can't be serious. Is the delivery person supposed to leave the cardboard box lying out in the open for anyone to pick up? Seriously? Keeping all vacant lots in a large area under remote hidden video/domain-awareness surveillance is easily within the capability of the Surveillance State.

@ Mike: please keep trying, something is better than nothing, and I hope many journalists with major media jobs will use your scheme, but it seems that this scheme is not what grassroots organizers need to oppose foreclosure (San Francisco and many other US cities), police brutality (Chicago, IL and many other US cities), water poisoning (Flint, MI), nuclear weapons (many readers probably live near deployed "strategic" weapons and don't even know it), Post-American fascism ...

Mike, I hope you will relocate outside the US. I fear that your work is too dangerous to try to continue inside Post-America.

The scientists, engineers and intellectuals who survived the Hitler regime were mostly those who managed to get out in the late thirties, when many of their colleagues still preferred to believe that Hitler could not really mean to do what he said he meant to do. But of course he did, and so does Trump.

Do you have a better, serious suggestion for people in America with no desire or ability to leave?
We're talking about phones not explosives. If the fascists are that set on destroying all possibility of anyone having any degree of cybersecurity, offer a better option than "yours isn't perfect so boooo". No solution is perfect. Please give a better one.

I don't mean to argue, I'm not good at this stuff. Honestly, what is a less dangerous way than the abandoned lots ones (besides leaving the country)?

Current Nexus/Pixel is about $600 new, or around $100 used.
Used is more likely to have infections, infections which might not be possible to remove without special j-tag hardware.

Many political dissidents cannot possibly come up with $600, alas.

How sad that even dubious privacy has become a "luxury item" [sic].

Thank you, NSA/FBI/NCTC for ruining the world.

Search around and yoi'll find used Nexus 5's and such for around $100.
Run every kind of /data, cache, etc wipe you can on it. There's danger of e.g. virus in bootloader that might infect your computer when you plug it in tomuse adb/fastboot. IOMMU as in QubesOS is the easiest way to reduce this risk.

You need at least a Nexus 5X. The 5 is now unsupported, because the OEM stopped providing updates to the baseband and device drivers.

The 5X will be similarly unsupported in about a year, though.

November 22, 2016

In reply to mikeperry

Permalink

What about Nexus 7 (2nd gen 2013), the previous choice?
Can it still be reused for this new setup? With the same level of security?

> Search around and yoi'll find used Nexus 5's and such for around $100.

Not everyone can do on-line commerce, if that's what you mean.

> Run every kind of /data, cache, etc wipe you can on it

Don't know how. Not everyone has ever owne a smart phone.

In any case,

o several persons warned that used smart phones often contain malware (no idea whether that is based on actual statisics, personal bad experience, or ...)

o Mike says you need the more expensive model to use his scheme.

o recent news reports about Android BLU phones say that these have been caught sending sensitive data (geolocation, content of messages, contact lists) back to servers in China. One reporter commented "this could be for either marketing or espionage", which I think is suprisingly accurate--- these days there is really very little difference in methods or goals between "business intelligence"/"market research"/"oppo research" and professional state sponsored espionage.

With all the vulnerabilities in stock browsers (newest Google Pixel's Chrome browser hacked in 90 seconds), it's not safe to assume that a used phone hasn't been infected, unless you know the seller and greatly trust his prudence.

There are known instances of the NSA infecting read-only CD's in transit, not because the sender or receiver were suspected of any crime, but simply because of them showed evidence of bring intellectual. Source; https://www.wired.com/2015/02/kapersky-discovers-equation-group/
It would be easier to do this with phones(they're writable with normal tools), and anyone buying phones that have less permanent-unremovable-backdoors than most phones have is going to look even more "suspicious" than those poor scientists. The only known permanent backdoors in Nexus/Pixel are the baseband firmware.

Still, with new Chinese phones shipping with spyware as bad as Carrier IQ, a used Nexus might be safer than a new Xiao.

November 17, 2016

Permalink

Someone should mention that Signal has just passed a security audit, so it is very good that the prototype works with Signal.

November 17, 2016

Permalink

> In this brave new world, even if we can trust that the NSA won't be ordered to attack American companies to insert backdoors, deteriorating relationships with China and other state actors may mean that their incentives to hold back on such attacks will be greatly reduced.

Not just NSA. In the Trump admin, FBI and NCTC may become even bigger threats to the freedom of US persons. ("Freedom" as in: not yet incarcerated in preventative detention camps for "poor citizenship", i.e. dissing the Donald).

See The Intercept's stories on how CVE programs being ramped up by FBI and NCTC are rapidly creating a real-time database of "citizenship scores" on all US persons, especially aged 2-7, similar to what China has announced--- but unlike the Chinese version, the US version is being developed in deepest secrecy. However, investigative journalists are finding out some truly troubling facts and publishing leaked documents. Every American parent (and grandparent) should be watching these developments very closely.

To mention just one point everyone needs to bear in mind: these scoring databases remember everything a person has ever done, but the criteria for how much each act decreases your score is continuously updated, so that something which you thought would not be viewed as effectively a Crime against the State when your child did it back in 2015 could suddenly become grounds for indefinite incarceration in 2018.

November 17, 2016

Permalink

@ Peter P:

Thanks again for setting up some debian mirrors as onion sites! Can you cryptographically sign the list of onion site mirrors for debian.org? (Same for the onion site mirrors for torproject.org.)

Tip to Debian users: using Synaptic, remove "main" from the sections for the ordinary mirrors which now have onion counterparts, then add the new onion sites with only "main" section. If you omit the first step, apt is likely to become confused about where it should look for updates.

As I understand it, setting up an onion version of public websites can not only improve access from censored countries but also help everyone avoid the situation where some government inserts a rogue certificate into the CA system, potentially enabling the intelligence service of some country (Kenya, say) to "spoof" google.com to anyone anywhere. Can Tor Project reach out to ACLU, Amnesty, Human Rights Watch, and other groups to explain this and to help them set up onion site versions of the their public websites?

November 17, 2016

Permalink

Are there instructions for building without Google apps and without Signal (sorry I haven't RTFM yet)? I currently use Cyanogenmod without Google apps, I don't use Signal, and I don't want them on my phone. I hope the developers accommodate this use case :)

I completely agree with that sentiment but we must remember that this guide is for people just beginning to care about privacy and even though signal does have some shortcomings (GCM and phone numbers) it is the best trade off for security and convenience for the average person that isn't snowden. I know they aren't completely in the LIBRE/FLOSS movement but this a movement that calls for drastic change and frankly even minor change is a massive inconvenience for the average person so hopefully signal will be a gateway for people to care more about their privacy.
TLDR; Signal isn't perfect but it's way better for the common man than using google/standard unencrypted communication.

November 17, 2016

Permalink

Just a heads up to torproject and guardianproject that someone might want to check out the requests that orfox makes to mozilla's switchboard "experiments" telemetry program (switchboard.services.mozilla.com). Dont know of any documented config pref that can disable it, but these requests are made every time fennec (both mainline firefox and orfox) is opened. It would seem a good idea to prevent this and if there is no known way to disable it along with the other background experiments/telemetry requests specific to the fennec branch of firefox. Would be great if someone could work with mozilla on a pref to disable this to be included in a future build.

Given how much information firefox seems to collect on android by default, it would seem a good idea to take a close look at this.

Would you be willing to submit a bug report? That way it can be reviewed by the right people and tracked properly. You can use the "cipherpunks" username with pass "writecode" if you don't want to create an account. trac.torproject.org.

November 18, 2016

Permalink

Does Copperhead currently require a Linux machine to install or can it be done from Windows?

You can flash it from Windows with ADB/fastboot for Windows.
Make sure the computer you plug your new, clean ph9ne into is also clean though.
Windows is very dangerous. It's much safer to install from a computer that has IOMMU sandboxing like the user-friendly QubesOS which has a simple GUI and requires no terminal wizardry. This also makes it harder for the phone to infect the computer, if it's not a brand new phone never connected to the internet.

It's freer than Signal.
If you want to make a corporate branded version of CopperheadOS and sell commercial volumes of phones with it preinstalled, there are licensing fees now.

But the owner of Signal threatens to sue anyone who compiles Signal with the backdoor removed, even if you just use it under fair use(e.g. on your own phone, or give away the un-backdoor'd version for free)

Wow, I did not know this, thanks for sharing. All the more reason for motivated people to work on updating Replicant. It's a pity, CopperheadOS looked like they were doing good things.

November 18, 2016

Permalink

Signal should be treated with extreme skepticism and caution.

- Signal uses proprietary VoIP servers. No good reason has been given for this, despite widespread curiosity both outside and within the Signal user-base.
- Moxie prefers passive-aggressive communication and non-cooperation with the free software community at large (see both the F-Droid and the LibreSignal incidents), instead preferring Google on everything, completely arbitrarily. Over 3 years ago they had legitimate reasons for not having TextSecure/RedPhone on F-Droid due to some security issues of theirs, but that was mitigated within months. They still refuse to branch outside of the Googlenet. Their recent Signal Desktop makes this seem like a consistent pattern, it's only released as a Chrome extension. Firefox doesn't get shit.
- Signal will also most likely never have Tor support.

Alternative spheres of activity that could topple Signal's dominance:
XMPP: ChatSecure (soon to get OMEMO, the XMPP port of Axolotl/Signal Protocol)
Matrix: Riot. Olm (a fork of Axolotl/Signal Protocol) is planned to be integrated into the Matrix protocol to allow E2E encryption by default. the Matrix project are also very Tor friendly it seems. They're talking about integrating onion routing into core functionality as well.
P2P: Tox, Ricochet (Ricochet uses parts of Tox's code, it can be said that Ricochet is Tox anonymized but without file-sharing features as of right now).

Thank you for articulating my thoughts. I can't believe I'm seeing the Tor Project endorse a product like Signal when we already have plenty of tried and true open standards out there that serve almost exactly the same purpose. I just don't see any reason for the Tor Project to endorse Signal, much less go out of their way to build it into their upcoming OS as the expense of freedom (from Google apps, namely).

November 18, 2016

Permalink

I feel I'm preaching to the choir here.
Please, somebody tell me another place to warn people about the dangers of http://, EXPORT ciphers and Windows. Another place that will let me post without registering and without javascript. The word needs to get out or no progress towards safe computing can happen.

November 19, 2016

Permalink

Any guide on how to safely root or anyway take control of my personal own phone, is there any definity. I would really like to install something with things like vpn orwall and so on that allows me to decide what is mine and what is mine again. I don t wanna allow our life extraction. Big data are good but we need first to create the mentaloty economic and social values understanding to make big data a good thing. Today they want to extract them to target you and crush you or to keep consumersim and other stuff like patriarchalism and so on alive.

Please let me know if I can easily install a new OS on my phone thanks.

On almost any Android device you can be less UNsafe by downloading F-Droid at https://f-droid.org/ (you have to allow 3rd party .apk's sadly, but I think it's worth it).
Then enable the GuardianProject repository built in to F-Droid in the repositories menu.
Don't add any reposifories that aren't built in to it unless you jnow what you're doing.
After it reloads install the latest version of Orbot (if you don't enabke GuardianProject repo you'll get an outdated, unpatched, dangerous version of Orbot).
Goto F-Droid menu->options and set it to download everything through Tor from now on.
Then download Orfox and whatever else, through F-Droid.
Goto your apps list (varies from phone to phone) and disable and/or uninstall everything from Google, and everything that you installed through Google Play Store.
Make sure to get replacements in F-Droid. For example, before removing Google Keyboard search for "keyboard" in F-Droid and get one of the ones there. Everything in F-Droid is free as in speech, open source software without any tracking (or it has a big warning before you install it if there is tracking).
If you aren't rooted get NetGuard, a free no-root firewall.

The above is the same on a rooted device except that if rooted, you can get F-Droid Privileged Extension WHICH MEANS YOU DON'T HAVE TO ENABLE INSTALLATION FROM UNKNOWN SOURCES. This is one way rooting makes it more secure.
You can configure in F-Droid->options to show which apps need root. Orwall and AFWall+ are better than NetGuard but you only get them if you have root.

Exposed is a framework that needs root to install, and once installed it keeps working even if the root was only "temporary". Once you have Xposed framework you can get Xposed Privacy, which lets you have way better control over app permissions than the permission manager in Marshamallow/Nougat. Lollipop and earlier come with no permission manager at all.

How to root varies from device. Search for your device's model ID plus the word "root" or plus the word "xda".

Very few devices were meant to be rooted officially. UNOFFICIAL METHODS CAN SEEM TO WORK PERFECT BUT MIGHT MAKE IT EASY FOR GOVERNMENT OR EVEN RANDOM STREET HACKERS TO ACCESS YOUR DATA.

For installing another operating system, it is similar, but search device ID plus "bootloader" or plus "unlock bootloader" instead. The new OS is called a "rom". Only install CopperheadOS or Replicant roms. If you really insist on a custom rom and those two don't support your device, maybe try OmniRom of ParanoidAndroid, but it's a really bad idea, and CyanogenMod is probably worse.
If there is no official directions from ghe manufacturer of your phone THEN IT IS VERY DANGEROUS TO UNLOCK BOOTLOADER.
At the very least make sure all the adb/fastboot tools and the rom itself is downloaded by links starting with https://
Please look up how to verify signatures. This is very important. Same when downloading operating system for a coomputer e.g. QubesOS.
Consult device manuals and FAQs of large, well-known projects for more info. Be careful and stay safe.

Rooting/rom'ing the safest is if you has the Google Nexus, Google Pixel, or certain kind of Galaxy and certain HTC and certain Samsung. Researching a phone before buying it. Also trying not to buying used unless no other choice, since used phone's may have undetectable and unremovable spyware virus infection.
Never using .exe or .bat downloaded by the plain http://. https:// less dangerous than http://! Also try ask whoever you download from, ask them how verify signature!

November 19, 2016

Permalink

Is project BULLRUN limited to mobile devices and desktops or does it apply to self-driving automobiles like the hazardous material transport in Diehard4? Is BULLRUN being applied to the 787 Dreamliner or Airbus C350? Will the NSA make it so we see more airplanes flying into buildings? What about the three mile accident? Was it an accident or did BULLRUN make it easy for terrorists to make their own STUXNET-like nuclear-reactor-targetting malware? Isn't it treason for any US agency to sabotage US national security by going out of their way to make insecure algorithms like the dual-EC one into national (NIST) standards that critical US infrastructure depends on? In short; is NSA allied to ISIS and/or allied to al-queda?

November 20, 2016

Permalink

>>It would be useful to audit whether airplane mode fully disables the baseband using either OpenBTS, OsmocommBB, or a custom hardware monitoring device.<<

Note that neither could detect a more sophisticated rogue behavior of the modem, since even an active and listening-for-commands modem is generally not detectable by any of those means. They all would only yell when an unsolicited TX actually happens and then it's basically too late since none could stop that threat. A modem with specially crafted firmware could pretend to be off (airplane mode) even on RF/antenna and still record all audio to modem-internal storage, to sneak it out interleaved with normal traffic on next solicited/expected activity like doing a call or simply just ending airplane mode.

Since all modems nowadays allow OTA firmware update, no software audit of the firmware whatsoever will accomplish anything, the only approach is to get decent HARDware. Even the mandated by FSF/RYF "immutable firmware" is a red herring since firmware gets loaded to modem's RAM before executing it, so that image in RAM still can get modified OTA even if the modem would use ROM instead flash for storage.

/jOERG (Neo900)

November 20, 2016

Permalink

There can be no real security until some of the underlying binary blob and baseband isolation issues can be solved. There has been work to this end that I'd highly encourage you to check out.

We have the complete set of source code needed to utilize all critical functionality for the Allwinner A20 SOC. This is an older dual-core 2GB ram SOC although still more than adequate for a phone. There is a newer quad-core 1.6ghz processor with 4gb RAM SOC that appears to also be an option. Now this does not include full support for 3D acceleration although I know at least the Allwinner A20 does have usable desktop and video acceleration (it is being used in a laptop/desktop system with adequate desktop performance). The quad-core apparently should be much better and solve the 3D problem.

Now there is a project that has successfully designed, demo'd, and crowd funded a 100% free laptop and desktop and of which its work can be utilized to make a phone cost effective and feasible. The reason is standards. The main objective of the project was to cut the costs of designing and manufacturing devices via the development of a modular computing standard: EOMA68 is essentially a critical building block needed to develop and manufacture devices cost effectively in lower than typically needed quantities. The people and main financier behind EOMA68 have an agenda of enabling development of devices not dependent on any proprietary components. We're talking 100% free here. No modern laptop or desktop is 100% free right now- not even Minifree's Libreboot'd laptops. There are keyboard controller firmwares, hard disk firmwares, LCD controller firmwares, and similar that are all proprietary. EOMA68 is the interface standard and from that 'computer cards' manufactured to this standard will be compatible with any device that complies with the EOMA68 interface standard.

The first 100% free laptop, desktop, and EOMA68 computer card was designed thanks to funding from ThinkPenguin (a true free software friendly GNU/Linux hardware company) and a crowd funding campaign (http://crowdsupply.com/eoma68). The systems will be shipping in March.

Phones, tablets, and other devices are planned. If you are interested in getting behind a realistic cost effective effort to design a phone I'd get in touch with Luke (the lead guy of the standard). Everything is being published for these first devices in addition to the EOMA68 standard itself. A phone may require a slightly different modular computing standard than EOMA68 for the sake of keeping the size of the device small enough to be useful, but a basic smart phone is possible. It does limit the SOCs a bit further too, but ultimately this is the answer to the problems posed here. We do not necessarily need to build off Android and we do not necessarily need to depend on phones designed by those who do not care about privacy and security. We also can bring the costs of a privacy and security friendly phone down via modular standards. It's not the case that such projects have to flop or be insanely expensive (ie like Neo FreeRunner).

November 20, 2016

Permalink

Asking here since this seems the most likely place to post something and have NSA read and reply to it (and possibly some operative might have enough freedom to answer honestly if he believes his organization is doing something bad to America); Is project BULLRUN limited to mobile devices and desktops or does it apply to self-driving automobiles like the hazardous material transport in Diehard4? Is BULLRUN being applied to the 787 Dreamliner or Airbus 350? Will the NSA make it so we see more airplanes flying into buildings? What about the three mile accident? Was it an accident or did BULLRUN make it easy for terrorists to make their own STUXNET-like nuclear-reactor-targetting malware? Isn't it treason for any US agency to sabotage US national security by going out of their way to put insecure algorithms like dual-EC into national (NIST) standards that critical US infrastructure depends on? In short; is NSA helping (on purpose or by mistake) ISIS more than it's hurting them? How many actual bombings that were stopped couldn't have been stopped without the PATRIOT Act? How many that were allowed to happen were allowed because of government screwups rather than due to not enough mass surveillence?
Is decreasing everyone's security really making America safer?
More on topic; how many people needed to use their smartphones in life-threatening situations, such as to call 911, and were unable to because of malware that messed up their phones, malware that wouldn't have been able to ir security weren't being deliberately under ined by those paid to protect it?

November 23, 2016

In reply to by Anonymous (not verified)

Permalink

> [Signal's] owner, moxie0, threatened to sue anyone who dared to remove the backdoor from it. Moxie0 is with facebook, whatsapp, and big data harvesters in general (think NSA/GCHQ/PLA/BND).

That is a pretty inflammatory claim. Do you have any evidence to offer for any of this?

My understanding is that Moxie is employed by the company which owns Signal. I don't know whether he is also the owner of that company, and I haven't heard about him threatening anyone with anything. My understanding is that his reputation among people fighting the dragnet is generally excellent.

It is true that the Snowden leaks include a number of documents showing that NSA/GCHQ have attempted to introduce various things which could reasonably be described as "backdoors" in various places in critical internet infrastructure (e.g. tapping directly into the unencrypted "private" data cables between Google's many servers, secretly disabling firewalls in commercial telecom switches, munging the PRNG in NIST standards, etc.).

But other published documents from the Snowden trove show that (despite Roger's past temporary affiliation) Tor Project was *not* cooperating with NSA, and that NSA/GCHQ were having much difficulty attacking Tails as of roughly spring 2013. Tha situation may have changed since then, to be sure.

Snowden also gave us the NSA/GCHQ playbook for "disruption" of groups they target, and other documents show that the target list for "effects" campaigns includes the Tor community. The playbook suggests short repetitive posts exploiting pre-existing fears in some community (e.g. Tor users have good reason to fear NSA trickery including backdoors) which never attempt to provide any specific "evidence" (even disinformative "evidence"). So you have a high bar to overcome if you want to convince us that Moxie is a bad'un.

November 22, 2016

Permalink

We need technical countermeasures simply in order to express our support for the political opposition, or to stay in touch with nonpartisan civil rights groups like ACLU:

https://www.aclu.org/blog/speak-freely/president-obama-will-soon-turn-o…
President Obama Will Soon Turn Over the Keys to the Surveillance State to President-Elect Trump
Ashley Gorski, Staff Attorney, ACLU National Security Project
Patrick Toomey, Staff Attorney, ACLU National Security Project
21 Nov 2016

> On January 20, President Obama will hand Donald Trump the keys to the surveillance state. Not only will Trump have the NSA’s incredibly powerful technological tools at his disposal, but he’ll also have the benefit of the overbroad and unconstitutional surveillance authorities embraced by the Obama administration — authorities that give tremendous discretion to executive branch officials.
>
> These spying powers have long been cause for concern because they violate our core rights to privacy, freedom of expression, and freedom of association. But when wielded by a man who invited Russia to hack his political opponent, who reportedly eavesdropped on his own hotel guests, and who has called for expanded surveillance of Americans and especially American Muslims, they are all the more frightening. Fortunately, there are several ways to fight back against the surveillance state, including concrete steps you can take to protect yourself and your communications.

November 22, 2016

Permalink

CopperheadOS sounds like a nice project, but according to its website, it's non-free: "CopperheadOS source code and builds are made available under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license".

This means it's neither open source nor free software, as it bears restrictions of use (non-commercial), violating Free Software's essential freedom of unrestricted use.

While the project sounds great and is certainly better than a project the source of which is not shared at all, this is still not the full open source OS we need.

Maybe the Tor project, given its enormous recognition value and reputation for helping good causes, could guide the Copperhead team to release their project under a Free and open source license?

They did this to have the option to dual license their changes to commercial companies who might want to repackage and sell Copperhead. I think this is fine (though CC-NC-SA might not be the best choice for software...)

I believe the most important thing, as I said in the introduction, is that the Four Freedoms are honored. Above all else, users should be free to use, share, study, and improve the software they have. Selling that software to others is a different matter, though. For that, I feel that it is entirely reasonable to restrict commercial activity, to ensure that if someone wants to profit from your work by charging others for it, they must pay you too, or at least arrange a license from you that grants them permission to do this.

Obviously, this behavior fails in the Kantian sense. If every free software package did this, we would not have Ubuntu or Red Hat, since selling DVDs would become a nightmare. However, a project like Copperhead that is trying the impossible and has a lot of predators looking profit off their work for free deserves a little more leeway.

In general, I think it is time to revisit out FLOSS licenses. In addition to Android, the Internet of Shit is another nightmare of a cesspool where companies are taking free software, selling it, and not even providing updates, leaving users vulnerable. For cases like this, I believe it is entirely legitimate to forbid the redistribution of binary forms of the software, unless automatic security updates are provided.

"Exterminate All Dogma; Permit No Exceptions."

November 22, 2016

In reply to mikeperry

Permalink

> Above all else, users should be free to use, share, study, and improve the software they have. Selling that software to others is a different matter, though. For that, I feel that it is entirely reasonable to restrict commercial activity

All commercial activity, or just selling copies of the software? Prohibiting people from hiring programmers to improve the software would effectively disenfranchise those who can't program. Similarly, if people can't pay a computer-shop employee to flash an image for them, many won't be able to use it. (Plus it could make the whole idea of modifying/copying the software seem "shady".)

If we were really going to accept such restrictions, we'd need some solution to the problem of orphaned works too. If the company that wrote the software goes under (or are nominally extant but stuck in some sort of "development hell"), we can't just wait 130 years for the copyright to expire.

November 23, 2016

In reply to mikeperry

Permalink

I definitely respect your arguments.

Looking at existing cases, lots of device manufacturers avoid the GPL. Maybe making relevant parts of Copperhead GPL (perhaps dual-licensed with a proprietary license) could ultimately have the same effect.

Also, I am not aware of any device manufacturers just using Cyanogenmod, which is arguably superior to AOSP in many regards, without cooperating with established Cyanogenmod bodies. So their fear may be purely hypothetical and ultimately unnecessary.

I really hope they change their minds. That doesn't mean I don't think their efforts are laudable.

November 23, 2016

In reply to mikeperry

Permalink

Well, that's at least partly the fault of Linus and the Linux Foundation. Had Linux moved on to the GPL v3 and would start to enforce that drivers that are derived from their code and than linked with the kernel had to be under the GPL and would their by be accessible to the user -- it would be much easier to update the devices. (But of course, would Linus be a good Stallmanist and not a deviationist, google hadn't chosen Linux as their kernel of choice)

November 22, 2016

Permalink

Does anyone know whether it would be possible to create an MVNO providing anonymous access to the mobile network? Obviously we have the technology to anonymously route calls (cell tower ≅ entry node). We also know how to do anonymous billing (cf. "Untraceable Nym Creation on the Freedom 2.0 Network", "Blind signatures for untraceable payments"). Are the protocols flexible enough that a SIM could generate a new IMSI for every authentication and attach a zero-knowledge proof of payment that the MVNO could accept/reject?

November 23, 2016

Permalink

Hooray! A nice write-up just appeared in Ars:

http://arstechnica.com/security/2016/11/tor-phone-prototype-google-host…
Tor phone is antidote to Google “hostility” over Android, says developer
An Android phone hardened for privacy and security that plays Google at its own game.
J.M. Porup (UK) -
22 Nov 2016

> The Tor Project recently announced the release of its prototype for a Tor-enabled smartphone—an Android phone beefed up with privacy and security in mind, and intended as equal parts opsec kung fu and a gauntlet to Google. The new phone, designed by Tor developer Mike Perry, is based on Copperhead OS, the hardened Android distribution profiled first by Ars earlier this year.

This thing needs a name. Cottonmouth? No, NSA already took that for a bit of spyware. Ideas?

How about VeganBreath or IrateOnion? CurvedAcid? FrontSnarf? OnionShooter? korG? UnitedOnion? OnionBazarre? OnionVicar? SlickerVeggies?

November 23, 2016

Permalink

Great work guys!

There is another currently unmentioned "Future Work" point which is hardware modifications.

CopperheadOS supports only very few devices. This should allow us to work out detailed guides how to identify and physically remove or disable various build-in sensors and interfaces and propose additional modifications. I researched the LG Nexus 5X and was only able to identify some of the components of interest. My idea behind this is to have an encrypted and to some extend secure computer to carry around which still has restricted sensors/interfaces which could be turned against the user.

I think the following components could be of interest here:

  • microphones
    Risk/problem: Acoustical collection, potential passphrase or key leaks thought various side channels, various user monitoring.
    Caveats: This would require a workaround such as always carrying a headset with you if the device should still be used as phone. Hint, there are cables like "3,5mm Klinken Verlängerung 30cm" which can be used to block the mic of the headset if you only want to listen to something.
    Realization: Can be identified on the PCB easily and also as there are holes in the cover for them.
    Impact on the user: High
  • cameras and laser autofocus
    Risk/problem: Visual collection, potential passphrase leaks though various side channels, various user monitoring and reflections in objects like eyeballs and all that good stuff.
    Realization: Easily doable with a tape which is also very convenient if you still want to use the camera sometimes.
    Impact on the user: Medium
  • gyros, accelerometers
    Risk/problem: Potential passphrase leaks thought keyboard side channels, various user monitoring.
    Realization: I was not able to identify the ICs yet which implement this for the Nexus devices. Any help is appreciated.
    Caveats: Screen rotation will not work anymore.
    Impact on the user: Low
  • light sensor
    Risk/problem: Monitoring of device surroundings/environment. Various user monitoring.
    Realization: I was not able to identify the location of this sensor yet in the Nexus devices. Any help is appreciated.
    Caveats: Screen light adaption will not work anymore.
    Impact on the user: Low
  • proximity sensor
    Risk/problem: Monitoring of device surroundings/environment. Various user monitoring.
    Realization: Near the two microphones on the top according to https://www.youtube.com/watch?v=lhAFtP0F2Uk
    Caveats: If the device is still used as regular phone, the display will not look nor turn of if used to make a call.
    Impact on the user: Low
  • barometer
    Risk/problem: Monitoring of device surroundings/environment. Various user monitoring.
    Realization: Do the Nexus devices have one, if yes, where? Any help is appreciated.
  • fingerprint reader
    Risk/problem: If used (on purpose or not), biometric identifiable data of the user might be revealed.
    Realization: Easy to spot and remove. Only basic tools are required (screw driver and case opening).
    Impact on the user: Medium
  • baseband, WWAN RF
    Risk/problem: Baseband exploits, remote control over the phone.
    Realization: Remove antennas, RF amplifiers and all that stuff. Kill switches? Any help is appreciated.
    Impact on the user: Medium
  • WLAN, Bluetooth
    Risk/problem: Nearby RFID reading, potential other malicious uses.
    Realization: Remove antennas. I was not able to identify the ICs yet which implement this for the Nexus devices. Kill switches? Any help is appreciated.
    Impact on the user: High
  • NFC
    Risk/problem: Nearby RFID reading, potential other malicious uses.
    Realization: Remove antennas and NXP PN548 NFC Controller (SMD).
    Impact on the user: Low
  • GPS
    Risk/problem: Location anonymity if phone gets compromised, potential other malicious uses.
    Realization: Remove antennas. I was not able to identify the ICs yet which implement this for the Nexus devices. Kill switches? Any help is appreciated.
    Caveats: No practical navigation anymore.
    Impact on the user: Medium
  • compass
    Risk/problem: Various user monitoring.
    Realization: I was not able to identify the ICs yet which implement this for the Nexus devices. Any help is appreciated.
    Caveats: If not moving, navigation map can not be oriented.
    Impact on the user: Low
  • earpiece speaker, loud speaker
    Risk/problem: Potential acoustical collection, covert channel communication.
    Caveats: Limited user notification except vibration motor and LED light.
    Realization: Easy to spot and remove. Only basic tools are required (screw driver and case opening).
    Impact on the user: High
  • Add battery switch
    Risk/problem: To ensure that the device is really turned of.
    Realization: The battery is "not replaceable" and does not have durable connectors. Any help is appreciated.
    Impact on the user: Low
  • Add device monitoring (power analysis, RF activity, camera/sensor activity)
    Risk/problem: Allow the user to monitor what the device actually does.
    Realization: Anything practical in this regard?
    Impact on the user: High

Every user can make there own judgment what components they want to have and what are unneeded. Also, this is more of a defense in depth as CopperheadOS tries to avoid/mitigate exploitation in the first place. But why take unnecessary risks?

Resources:

Previous work: https://archive.fo/dbolo

Hopefully Gooligan won't work against "Mike's phone" aka Colloquy, but this story indicates both the challanges we face and the reasons why we need smarter phones:

http://arstechnica.com/security/2016/11/1-million-android-accounts-comp…
1 million Google accounts compromised by Android malware called Gooligan
86 apps available in third-party marketplaces can root 74 percent of Android phones.
Dan Goodin
30 Nov 2016

> Researchers say they've uncovered a family of Android-based malware that has compromised more than 1 million Google accounts, hundreds of them associated with enterprise users. Gooligan, as researchers from security firm Check Point Software Technologies have dubbed the malware, has been found in at least 86 apps available in third-party marketplaces. Once installed, it uses a process known as rooting to gain highly privileged system access to devices running version 4 (Ice Cream Sandwich, Jelly Bean, and KitKat) and version 5 (Lollipop) of Google's Android operating system. Together, the vulnerable versions account for about 74 percent of users.

Really nice work. I honestly think that CopperheadOS should release a phone or tablet similar to the Nexus/pixel series but with hardware switches sometime in the future.

I was looking librem phone (At this point, non-existent phone) discussion but they don't support OpenGapps or Microg. I understand their desire but what a bummer. Maybe Copperhead may try to port their OS to that theoretical phone in the future? Who know what will happen next.

November 26, 2016

Permalink

Did you see that the latest Signal version 3.23.0 has gained push-to-talk support? Torifiable mobile voice communication! Over and out.

> Torifiable mobile voice communication!

Bingo! Suddenly I understand why that fine fellow driving the Landis+Gyr surveillance vehicle was so worried about "walkie-talkies". He wasn't using a military grade spectral analyzer costing hundreds of thousands of dollars because he is worried about walkie-talkies interferring with smart meters. He is worried that BLM supporters might start using Torified push-to-talk at the next big demonstration. And he probably isn't a Landis+Gyr employee at all, but a fed.

Whenever I see hard evidence that the Man really really does not want myself specifically to possess some specific technical tool, I always know that specific tool is just what I need to have, in time for the next big demonstration.

Let's make it so!

November 28, 2016

Permalink

So much FOSS supporters here and in other forums are just treating this blog post as shit. Threats are not binary and not everyone needs to be such a high-level threat model as these extreme moralists.

All these talk from the rather one-sided forums posts and articles about a 2nd processor that controls everything on phones, laptops and desktops just borderlines with FUD. That is more of an unknown than a certainty (due to lack of proper evidence). People who are more concern about Mass Surveillance don't really need to care of such things.

If threat models are to be put into an rather arbitrary, one-dimensional scale, I can see this phone setup to be very useful for people who fall somewhere around the middle of said scale. One example of why is that so it's the combination of secure communication apps with Tor on a more secure custom ROM really adds to the security.

I always interpret irate posts criticizing Tor Project's latest innovation as a sign that someone is seriously ticked off by no longer being able to easily eavesdrop. That means Mike is on the track of Something Good!

Definitely something good!! Although I always perceive privacy tools and and our own precautions are mostly better than nothing regardless of their effectiveness.

November 30, 2016

Permalink

Of course, the changes to Rule 41 are irrelevant if prosecutors feel free to simply forge judges's signatures. Repeatedly, every 30 days. In order to spy on the other parties in a love triangle.

https://www.techdirt.com
Brooklyn Prosecutor Forged Judges' Signatures On Wiretap Warrants To Eavesdrop On A 'Love Interest'
from the rules-are-for-other-people dept
30 Nov 2016

>> A high-ranking prosecutor in the Brooklyn district attorney’s office was arrested this week on charges that she used an illegal wiretap to spy on a police detective and one of her colleagues in what a law-enforcement official described as a love triangle gone wrong.

Meanwhile, in distant Manhattan island, Cy Vance Jr. keeps screaming that he needs backdoors into all civilian encryption, so his own prosecutors can read everyone's mail.

November 30, 2016

Permalink

So our efforts were all for naught:

http://thehill.com/policy/cybersecurity/308088-last-ditch-effort-to-pre…
Last-ditch effort to prevent changes to law enforcement hacking rule fails
Joe Uchill
30 Nov 2016

> A last-ditch effort in the Senate to prevent changes to a rule that will ease the process for law enforcement to use hacking in investigations failed Wednesday morning, allowing the controversial updates to Rule 41 to take effect at midnight.

http://arstechnica.com/security/2016/11/firefox-0day-used-against-tor-u…
Firefox 0-day in the wild is being used to attack Tor users
Publicly released exploit works reliably against a wide range of Firefox versions.
Dan Goodin
30 Nov 2016

> There's a zero-day exploit in the wild that's being used to execute malicious code on the computers of people using Tor and possibly other users of the Firefox browser, officials of the anonymity service confirmed Tuesday. Word of the previously unknown Firefox vulnerability first surfaced in this post on the official Tor website. It included several hundred lines of JavaScript and an introduction that warned: "This is an [sic] JavaScript exploit actively used against TorBrowser NOW." Tor cofounder Roger Dingledine quickly confirmed the previously unknown vulnerability and said engineers from Mozilla were in the process of developing a patch. ... "It's basically almost EXACTLY the same as the payload used [by FBI] in 2013," TheWack0lian told Ars. "It exploits some vuln that executes code very similar to that used in the 2013 Tor browser exploit. Most of the code is identical, just small parts have changed."

I second this question. Mike?

Google shows Nexus 7 2013 is out of support. No new Android versions guaranteed, no Google security updates and no official Copperhead support. Is this a stopper?

What about continuing the use of Nexus 7 with Cyanomod - risky as well?

December 05, 2016

Permalink

re: Future Work: Wifi AP Scanning Prevention

In the blog post, mikeperry asked for feedback comparing the Wifi Privacy Police app in F-Droid to the Smarter WiFi app. That second app, i'll assume, is by Kismet and called Smarter Wifi Manager in the Silent Circle Store available to Blackphone1 users (maybe also in the SilentCircle store for Blackphone2, i dunno). I think that i did read that the developer of Smarter Wifi Manager (which i'll call Smarter Wifi here) was involved early on and for some time with the creation of the Blackphone, perhaps a founder and/or manager of some sort, but that he? has since left. Dont quote me on that, but it would make sense to me because when considering the function of the Smarter Wifi app, in my oppinion it was/is dangerously inferior to the function of the Wifi Police app (tho i hav not used or checked either app for changes in months and months).

Wifi Privacy Police prevents connecting to a previously used Wifi access point unless the name and password of that Wifi access point is as expected. If no match, u are so informed and given the opportunity to create a connection. In contrast, Smarter Wifi doesnt check for a password match and instead only checks to see if the name of the access point matches the expected geographical location of the access point, which seems to me quite inferior when trying to avoid an Evil Twin.

For example, along with ur expected access point to which u hav previously assigned a name and password and to which u hav previously successfully connected, what if there is a hidden, 2nd open access point (an Evil Twin) with same name and very strong signal (but no password) nearby ur expected access point? Unless a Wifi security app compares the Wifi passwords, u will unknowingly connect to the Evil Twin.

Im thinking that in the early days of the Blackphone, it was crucial to be able to trust the app developer, which im guessing maybe is why Silent Circle offered the Smarter Wifi app rather than the Wifi Privacy Police app in the Silent Store (ie, Silent Circle founders knew the Smarter Wifi developer, but didnt know the Wifi Police developer) (im guessing). I don kno either developer, and im not implying that the Smarter Wifi developer is malicious. I know nothing about these apps except their intended function. The Wifi Privacy Police worked for me as it claimed.

Orwall sounds like a firewall, and the other sounds like a VPN, which are two entirely different security measures which are generally not mutually exclusive. A firewall protects ur computing device from many different types of security breaches and threats, including privacy invasions, even when ur device is idle. A VPN is basically a way to hide ur Internet activity (ie, it mostly helps preserve ur privacy while u are on the web). Something like that. The two security measures are so different that there is no easy answer to ur question, and trying to answer ur question might derail the topic at hand, i dunno. Did u mean regarding security from state actors such as the NSA of the USA? Perhaps study up on the difference between firewalls and VPNs, then if u hav a more specific question about the difference, post an additional comment here?

December 06, 2016

Permalink

Boycott Google Pixel phones re: leaky modem

It's time to deal with the devil, and this 2016 winter holiday is the prime time. I suggest a two prong approach:

1) negotiate with Google to create a smartphone without baseband vulnerabilities (and verifiably so).

I'm not sure what to suggest here, it's not my expertise, perhaps opensource modem firmware and hardware, perhaps re-designing the smartphone so that modem processor does not control the application processor. Perhaps it will be necessary to create a new, secure, but backward-compatible subset of communication protocols and infrastructure. Whatever is necessary--Google now has the leverage to get this done.

2) Boycott the purchase of Google Pixel smartphones Internationally until the above is accomplished.

-----

It's time to play hardball. Google Android is the most popular OS worldwide. Google is now manufacturing their own smartphones (ie, the Pixel phones). Google is now a wireless network service provider.

Google may not (yet) own the physical wireless infrastructure (eg, cell towers) or manufacture the modem chips inside their smartphones (yet), but Google has the leverage to plug the pervasive vulnerability of smartphone modems, and we hav the levarage (via a boycott) to encourage Google to do so.

Power yields nothing without a demand.

I'm not that impressed with the Pixel smartphones anyway--there doesnt seem to be much new about them. This is the season of giving. Google has just launched its first made-only-by-Google smartphones. Google's wireless network service is still an infant. Google's bottom line (ie, profits) are now significantly dependent on its reputation. This is a relatively new development. Google is vulnerable to a boycott now like never before, and perhaps like never again.

Let's face it, all our smartphones are hacked via their modem. Can we verify that this is not so? Then in this post-Snowden world, we can be assured that it is true. This includes the Blackphone, the Tor Phone, the iPhones, feature phones, etc

What can we do about it? Cover the cameras, sure. Remove the microphones, check. Better disconnect the gyro sensor also (it can also hear u). Airplane mode? ha, how can we kno it works? Anyway, snooped data can be recorded, saved, and transfered later when connectivity is re-enabled. Can we even verifiably disable GPS on modern smartphones? Hardware switches for mobile data, and Wifi, and Bluetooth...can we see where this is going? We are spending tons of time, energy, and limited resources patching sinking ships that we buy brand new. Im not saying that the effort is useless. I'm saying let's be more aggressive.

Where should this be posted? It's a bit off-topic here i think, and probably deserves its own blog post somewhere for discussion. Alternatively, copy and paste to wherever--u hav my blessing.

December 06, 2016

Permalink

Re: Google Pixel smartphones boycott

Instead of competing with Apple for the highest-priced, best looking pocket-sized spying device, we need Google to not be evil.

To isolate the smartphone modem, Google may only need to switch from using Quallcomm to Mediatek, or threaten to do so, as Mediatek has previously gotten it right:

2-year-old post from Hacker News
re: Reverse engineering a Qualcomm baseband processor (PDF)
at https://news.ycombinator.com/item?id=8813098

Reply to "baseband processor is usually the master,
and the app processor is a slave"

Posted by userbinator 707 days ago:

For the Mediatek platforms I don't think this is true - the AP is the one that boots up first and loads firmware into the baseband, and at least for the MT6589/6582 the AP can enable protection so that the baseband processor(s) can't access anything outside of the configured ranges. You can look at  

https://github.com/varunchitre15/MT6589_kernel_source/blob/master/media…

which is the code that initialises the baseband modems by loading their firmware (there are two CPUs in the baseband since this is a dual-SIM SoC), and see the enable_mem_access_protection function at line 863. The table there also shows that properly set up, MD0 and MD1 can only access their respective areas and the small amount of shared memory they use to communicate with the AP.

Confirmed by kefka 708 days ago:

You are very correct. I'm also running a MT6589 on my own modded android install....My phone is a HaiPai Noble N7889...I have complete control over my phone (baseband and userspace)...

December 06, 2016

Permalink

Wikipedia Google Pixel (smartphones)#History:

Sales were brisk following the initial release, and it seemed like Google might finally surpass Apple in the high-end smartphone market. But then a small group of privacy advocates at the Tor Phone Project claimed that the Pixel Smartphones had a severe security vulnerability that could not easily be fixed by an over-the-air update. The problem was Google's choice of internal hardware--specifically, the wireless modem which basically connects the phone's internal antenna to the Android operating system. That modem had a separate operating system (name unknown) which was not publicized and which controlled the Android operating system. Malware sent wirelessly to the phone could allow an attacker to control the phone remotely and secretly. The modem chip was manufactured by Quallcomm (headquartered in the USA) who also owned the proprietary operating system of the modem. Google recalled all the Pixel smartphones and replaced them with new hardware including a modem from Mediatek of Taiwan. The replacement phones (the Pixel 2 series) soon became extremely popular and was further modified by the privacy advocates at the Tor Phone Project to be even more secure. The Tor Phone set the standard for the modern mobile phone we hav today.

December 07, 2016

Permalink

Google is no stranger to the ongoing conflict regarding seperation of church and state. I mean userspace vs baseband software. Whats the difference?

Google managed the sale of (a few million?) "Android One" smartphones to the developing world in the last two years, and Google's original reference design for that smartphone was basically the 3G Motto E (E=economy) with the privacy-friendly Taiwanese Mediatek MT6582 System-on-Chip replacing the System-on-Chip from Quallcomm of USA.

Google wasn't going into India, Indonesia and Pakistan with a smartphone that obviously enabled Uncle Sam to spy on their masses. That would be very bad public relations (ie, dangerous for Google). But after the natives accepted Google's smartphones and accessory trinkits, Google had a foothold there and in mid-2015 began switching back to using a Qualcomm System-on-Chip, which is what we are stuck with here in the USA.

We arent going to slow Google down by crying foul and forcing Google to recall its Pixel smartphones due to their modem vulnerabilities. I mean, let's make some noise about it now, but the subsequent recall of Pixel smartphones wont harm Google much. Google can absorb the cost and Google doesnt even depend on the smartphone modem vulnerability to spy on people--Google can do that via the smartphone userspace. Its Big Oil and their three-letter USA spy agencies that wish to preserve that smartphone modem backdoor, which is how Big Oil remains competititive in these days of irreversible climate change.

Quallcomm might even welcome the chance to open-source their baseband software stacks (depending on how evil they are--i dunno). Qualcomm is probably tired of never updating their ancient bug-ridden modem operating systems just to please Big Oil. That has to make the application of new code difficult and unreliable, no?

What im saying here is hav no fear. We are the professionals who are expected to speak up about this baseband vulnerabity which, with modern tools and modern armies of state-sponsored hackers, is now THE most glaring hole in smartphone security. Sure, we've been saying it all along, but now we hav a shining example to point to (ie, the Google Pixel smartphones). What about the Nexus 5x and 6p? What about Apple phones? Let Google decide how they want to handle our public accusation of the Pixel smartphones.

Will we be discredited? I doubt it. Just assign a CVE number to this issue and give it the priority it truely deserves. Call a press conference to announce the vulnerability like u usually do. Ur just doing ur job. Ho hum. Yes, Google's first phones hav a fatal flaw, but look at the Samaung Galaxy Note 7--these things happen, its terribly inconvenient for some, but we all benefit in the long run, blah blah, tweet tweet. Will Google need to recall their Pixel phones? It seems likely. End of story.

There is no reason that plugging this security hole should cause our phones to slow down or reduce ur driving range or raise the price of stinkin oil. This is a minor battle we hav to fight before we can even reach the front lines of evolutionary change. We hav to be able to communicate in private! We cant use our phones for that if we refuse to aknowledge the underlying technical problem staring us in the face.

December 13, 2016

Permalink

Im not mike, but unlike the Nexus 6p (and 5x and newer Pixel phones), the 2013 Nexus 7 doesnt hav a 64-bit application processor and thus doesnt hav verified boot--something like that i think which yes, is a showstopper because of the resulting security vulnerability. However, as mentioned in the post regarding future work, there are other, remaining vulnerabilities in the Tor Phone such as the baseband processor and its associated OS being the master of the application processor and its associated Android OS. The idea is to plug the security holes that we can, when we can, and not throw up our hands and backtrack just because there is so much more work to be done to secure a smartphone. And there is a ton of more work to do.

A lot of work indeed. The thing is that we're trying to add security to something that wasn't created with security in mind. AME 2000 supposedly is very secure but isn't available for the layman.

December 25, 2016

Permalink

is it possible to verify signal apk without using Java JRE/JDK ?
I just want to install it on my phone without using a google account and need an alternative means of verifying the file

December 27, 2016

Permalink

>Signal

Do you really advertise a messenger which requires a user to prove his identity? I'm very disappointed.

December 28, 2016

Permalink

Sounds like good news. Hopefully there's a secure OS that is supported by phone hardware that doesn't make my wallet cry.

January 03, 2017

Permalink

First of all, sincere apologies if this is not the right place to ask for help, I don't know the 'rules' nor where else to go. Thank you for your understanding. Or/and for your help, or directions to another place, please...?

Hanging out in China regularly, and, equally non-private as far as I am concerned, the USA and the UK, I bought a Nexus P6 especially to install this prototype project when I read about it, but I got stuck at the ./run-all.sh and can't figure out how to solve it/finish properly by myself. I use Arch GNU&Linux, but I am not a developer at all. Following the instructions on github and issuing ./run_all.sh angler-nmf26q (using angler-factory-2016.12.25.22.27.39.tar.xz which I put and extracted in ~/mission-improbable/) halts. These lines are the problematic ones, I believe, before I am thrown back to the command prompt:

./make_keys.sh: line 6: ~/mission-improbable/helper-repos/android-simg2img/generate_verity_key: No such file or directory
...
...
...
Copperhead successfully installed!
~/mission-improbable/angler-nmf26q ~/mission-improbable
~/mission-improbable
cp: cannot stat 'keys/verity_key.pub': No such file or directory

I tried editing 'generate_verity_key' in that line 6 to 'generate_verity_key.c', as that is the name of the file in helper-repos/android-simg2img/ and I renamed that file to 'generate_verity_key'. But to no avail, and that is how far my creativity and logic reach - regarding this one at least...

Thank you all very much for this wonderful project, both Tor and Copperhead. I will happily continue to donate to Tor - and to Copperhead, once I get my P6 working like Mike Perry's! :-)