
Mission Impossible: Hardening Android for Security and Privacy - joelanders
https://blog.torproject.org/blog/mission-impossible-hardening-android-security-and-privacy
======
rsync
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 ...

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

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

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

------
joelanders
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_-_...](http://media.ccc.de/browse/congress/2013/30C3_-_5529_-_en_-
_saal_2_-_201312271830_-_hardening_hardware_and_choosing_a_goodbios_-
_peter_stuge.html)

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

[https://blog.patternsinthevoid.net/replacing-a-
thinkpad-x60-...](https://blog.patternsinthevoid.net/replacing-a-
thinkpad-x60-bootflash-chip.html)

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

