Mission Impossible: Hardening Android for Security and Privacy | Hacker News Reader

Mission Impossible: Hardening Android for Security and Privacy

blog.torproject.org

61 pointsjoelanders14 comments

Unless there is an open baseband chipset, there is nothing that tor, or anyone else, can do to secure an android phone[1].

Depending on the implementation of the SOC, etc., the baseband chipset, which can be controlled over the air by your carrier (independently of the computer you're holding in your hand) can have full DMA access to the phone.

Read that again: the carrier, through special over the air interfaces that you cannot be a part of, can control your entire phones memory - reading and writing bit by bit any piece they want. There's no software, or OS, that will save you on a device like that.

Note that not all baseband chipsets are quite as dangerous, but they're all a closed source, third-party controlled device-within-a-device that is run over an out of band interface that you can't control.

[1] ... or any other phone ...

The very first part of the article, "Hardware Selection", covers this point and recommends that the secure device not have a baseband. They use a wifi-only Nexus 7.

I really wish you could get wifi only phones. The Samsung galaxy player was a good candidate a few years ago, but that's quite old now and doesn't appear to be a trend that continued.

A wifi only phone with a full size USB and a very small GSM thumb drive ... that would be workable. Also: fantasy.

OR: a normal phone with a GSM sim module that you could add/remove quickly, like a SD card - without opening the device.

> OR: a normal phone with a GSM sim module that you could add/remove quickly, like a SD card - without opening the device.

I've got a Motorola Razr Mini and, if I didn't have a case, the SIM card is removed by stabbing a fingernail into the volume control and pulling.

First time I did it, I was so surprised at the ease that I dropped everything.

Aren't things like the iPod touch and many tablets basically "wifi only" phones?

What if we had a killer phone-over-wifi app, to allow this segment of the market to take off?

> What if we had a killer phone-over-wifi app, to allow this segment of the market to take off?

It's called VoIP. The carriers do everything they can to kill it (to keep you buying cellular service for voice), but it's not like the technology doesn't exist.

Yeah, the technology has been around for a while, but there were a lot of limiting factors (there may still be) for pulling somethings off that might be worth revisiting now.

Meta: My dad works on VoIP systems for BT and I was telling him he'll probably be on the front lines in a couple of years when mesh-networking (well he calls it a buzz word for peer-networking) takes off and efficient packet routing on decentralized nodes that could come on/go offline at anytime.

Facetime, as an example, is a voice-and/or-video protocol which works over wifi and is not trace-able/snoop-able by Apple (according to their recent document about their law enforcement compliance).

You should be able to get that once ARA phones arrive. Just get one without a baseband, or take it out and only use it when you need it.

That's an exaggeration. The carrier cannot get access to the application processor memory, even if the baseband processor itself has access. There is no such standard interface for that, and no baseband maker would do it. Why take the responsibility for a backdoor that you don't even control? There were no such things on the BB I've worked on. Of course if the BB CPU has access to the whole system memory then a bug in the protocol stack can be exploited to get its content. But that's not specific to a carrier. And all peripherals embedding a CPU have the same weakness, it's hardly specific to cellular BB.

Also, limiting the access of the BB CPU (or CPUs nowadays) to the system memory is perfectly possible: put the BB IP behind an IOMMU (SMU in the ARM world). Then just like a MMU can restrict a process access to the system physical memory, the IOMMU can be used to sandbox the BB and limit its access to the memory to its own dedicated range and nothing else. This makes sense even when the same company does the AP and BB part, for robustness. Just like complex applications are split into independent processes for fault isolation and security.

Instead of making exaggerated claims, it seems to me it would be more productive to put pressure on AP vendors for such SMUs to become standard. It's not that common yet in the ARM world (each additional IP adds some cost), but it should and all master capable IPs should be behind one IMHO.

That won't provide perfect security --- there could always be some backdoor. But in practice it would be good enough. And if there's a backdoor the BB is nothing special: better to make the backdoor accessible through any external interfaces.

Sorry if I'm a bit blunt there, but as a person working in cellular I'm a bit fed up by all the (misplaced) paranoia. If you don't like the telcos, fine, but no need to go all tinfoil hat. To spy on you there is no need for any backdoor in the device: the network can and even must, per the law, be able to intercept everything. And that's part of the standard.

>To spy on you there is no need for any backdoor in the device: the network can and even must, per the law, be able to intercept everything. And that's part of the standard.

CALEA/LI are irrelevant; you should always assume the network is tapped. Lawful intercept does not give the same kind of access at all as a baseband processor exploit.

There is definitely a need for a backdoor in the device, otherwise all an attacker will get is encrypted data.

Lawful intercept gives access to all communications going through the BB in clear, as well as position. On top of that a BB exploit could in theory (with no IOMMU protection) provide access to the full system memory, and I agree with this. But my point remains: there is no need to single out the BB there. And putting a backdoor in the BB doesn't make sense to me from an engineering point of view (and doesn't match my experience in the area either).

We're talking about integrated BB where the BB is on the same die as the rest of the system. Just put the backdoor function at the system level, accessible from any interface. Why do a special case for the BB? There's no point in that, as there's no gain. If anyone goes to the trouble to insert such a backdoor, isn't it better to make it accessible remotely thought any interface, and through all local interfaces?

Even better, call it a secure remote management function, with remotely upgradable firmware, and make it usable for professional use cases. And still being usable as a backdoor. What's better than hiding in plain sight?

So I don't dispute the notion that there could be backdoors in chips. What I find illogical is to single out the BB for this. Any interface with bus master ability and a local CPU (WiFi, BT, cellular...) can on principle be exploited in the same way, on a SoC with no IOMMU protection. So instead of making juicy story with backdoored BBs and nasty telcos, why not address the general case and insist on having systems with an IOMMU controlled by the main CPU? Then an open source system can protect the main CPU and system memory against bugs in any peripheral behind the IOMMU.

That won't protect against a "security/management function" designed to bypass the IOMMU of course. At some point there is no substitute for trusting (or not...) the chip maker. But at least that would protect against a whole class of bugs, which is a win IMHO.

If you like this, you'll also like Peter Stuge's 30c3 talk: Hardening hardware and choosing a #goodBIOS

"A commodity laptop is analyzed to identify exposed attack surfaces and is then secured on both the hardware and the firmware level against permanent modifications by malicious software as well as quick drive-by hardware attacks by evil maids, ensuring that the machine always powers up to a known good state and significantly raising the bar for an attacker who wants to use the machine against its owner."

http://media.ccc.de/browse/congress/2013/30C3_-_5529_-_en_-_...

And this is the best blog post I know of on the above:

https://blog.patternsinthevoid.net/replacing-a-thinkpad-x60-...

100+ steps are needed to add some privacy to Android.

Impressive work and I'm eager to try this out on a rainy day. Hopefully this will become easier and realistic for many more people soon to have.

Reply on news.ycombinator.com