[kwlug-disc] cell phone security and privacy

[Chris Irwin]

On Tue, Jul 26, 2022 at 06:58:07PM -0400, Doug Moen wrote:
>
>* Pinephone is not the answer. Even though Pinephone advertises 
>freedom, privacy and security, it doesn't have proper hardware security 
>support. There's no secure boot. There's no trustworthy, secure mobile 
>OS (of the stature of Graphene) available for Pinephone. Instead I see 
>embarrassing things like this: 
><https://nns.ee/blog/2021/04/03/modem-rce.html>.

A few points on this: This is a local compromise of the modem from the 
pinephone, which isn't good, but isn't bad either. I'll explain:

The pinephone uses a USB-attached modem, instead of an on-package modem 
like you have with pretty much any android phone (I believe they're 
following an example set by the librem5 on this).

All modems run a proprietary firmware that potentially has full access 
to the system and data. If this modem is included in your CPU package, 
that is *your* system and data. Not ideal.

So the pinephone instead has a USB-attached modem, which the linux OS 
talks to via AT commands. IF you can picture an old serial-attached 
dial-up modem, it's basically that.

This means the kill switch doesn't just disconnect an antenna, or 
politely ask the modem to disable itself. It actually cuts the power to 
the entire device, just as unplugging it would. If you're into hardware 
kill switches, this is good.

So the compromise here is that to process those AT commands, the modem 
firmware includes it's own minimal android build, which is the source of 
the compromise above.

On the plus side, there *are* alternative, open firmwares for the 
pinephone modem. They don't distribute them because they're illegal to 
use in some countries, and they just don't want to get involved.


>I see Pinephone fans arguing the absence of secure boot is a feature: 
>that it takes away your freedom.

It's probably best to ignore those people. They're arguing a different 
point, and no middle ground will be met.

Put their arguments into the file with "RMS says passwords are a user 
restriction" and "HTTPS is unnecessary bloat on the Internet"

>[...] Not true. On my new phone, secure boot means that it is 
>impossible to install a different operating system without wiping the 
>previous operating system and all its user data.  This is a security 
>policy I have deliberately enabled, and it's enforced by hardware.

Unfortunately, there's an issue here. Android uses some components we're 
familiar with, but is architected from the ground up to be totally 
different, and rely on those differences.

Android systems are read-only once booted, and rely on dm-verity to 
verify integrity of the OS. This works because all extra software is 
installed via apps which are designed specifically to work with those 
restrictions. They didn't have to deal with legacy software, etc.

Pinephone's goals are to get a more distro-like install onto a phone. At 
the moment, these restrictions *do not* work for desktop linux. There's 
a lot of ground work that needs to be done to get it there. There's not 
a *ton* of effort there because of the whole chicken-and-egg problem of 
users not using linux phones.

Keep in mind secure boot on desktop linux isn't really secure, either.  
Sure, you can trust your system firmware, and it verifies your kernel is 
signed, and it verifies modules loaded are signed, and you can even load 
your own keys and do your own signing. But that's ignoring the untrusted 
initrd that does a lot of heavy lifting in the early boot process 
(including handling your typed encryption passphrase)

If you're interested in seeing what a "trustable" (for lack of a better 
term) desktop linux would look like, you may want to check out Fedora 
Silverblue, which is the closest approach, at least so far. The OS is 
read-only(-ish), while all apps are installed via flatpak & toolbox.  

Silverblue still only gets half-way towards a secure OS, but Lennart 
Poettering recently posted an interesting blueprint for the rest of the 
tasks:

     https://0pointer.net/blog/fitting-everything-together.html

If any security for "desktop linux" was possible on phone hardware 
currently, I'd imagine purism would be doing it on the librem5. For 
their laptops, they've written their own secure bootloader, will ship 
hardware tokens separately, and will go as far as to use nail polish on 
screws and seams to identify tampering in shipment (verifiable via 
photos of said polish they'll email). I'd imagine they'd be eager to 
introduce these features.

>I also have the option of permanently locking my phone, so that it is 
>impossible to replace Graphene OS with something else, but I haven't 
>exercised that option yet[*]. If somebody permanently locks your phone 
>to a particular OS before selling it to you, then yes your freedom has 
>been taken away.

Do you have more information about this? I was under the impression 
there were only three lockdowns in effect:

* SIM unlocking -- not applicable to this discussion.

* Bootloader Unlock -- requires you to have control of the device (ex: 
   get past the lock screen), not just posession. Unlocking the 
   bootloader wipes the disk decryption keys, so data can't be leaked to 
   an unsecure environment.

* Factory Reset Protection -- Requires that even after a factory reset, 
   a device can only be unlocked by the owner's google account. This 
   isn't default afaik.

I wasn't aware of another level that (if I understand you correctly) 
permanently prevented bootloader unlocks.

>So Pinephone is a security nightmare. You can't trust the software to 
>enforce your privacy policies. To compensate for this, Pinephone has 
>hardware kill switches for the cam, mic, LTE, bluetooth, wifi. Okay, 
>but Graphene provides these switches in software, and it has a 
>hardware-backed security architecture that makes them trustworthy.

Ehh, soft switches != hard switches. They're really serving different 
purposes, and I think there's an argument to be made that we should have 
both.

Also, graphene can do this because it's Android, and to access a device 
(e.g., Microphone), the app has to use a particular API to do it, which 
graphene can handle on an app-by-app basis.

With a desktop-linux model, you could have a modern GNOME app that 
respects the permission toggles in GNOME settings. OR, you could also 
have an app that opens /dev/dsp directly (OSS nomenclature, but you get 
my point).

> And I can trust Graphene not to leak my PII even when my LTE or wifi 
>are turned on.

You technically can't, due to the on-package modem. But You're probably 
not a target of a three-letter-agency that could compel your wireless 
provider to do this.

>Get a Pinephone so that you can run desktop FOSS linux software, not 
>because it has the best privacy and security.

The biggest reason I don't use my pine phone is because it is *slow*.  
Excruciatingly so.

>[*Footnote: Interestingly, locking my phone would violate the GPL 3 (by 
>denying an adversary with temporary possession of my phone the right to 
>hack it and insert malware), but only if Graphene used GPL 3. Graphene 
>uses a permissive licence specifically to ensure my right to protect 
>myself.]

This is FUD, but lots of people believe this sort of stuff.

>* Graphene OS is the open source Android clone with the best security, 
>famously endorsed by Ed Snowdon.

This is only half of the first tweet covering his recommendation:

> If I were configuring a smartphone today, I'd use @DanielMicay's 
> @GrapheneOS as the base operating system. I'd desolder the microphones 
> and keep the radios (cellular, wifi, and bluetooth) turned off when I 
> didn't need them. I would route traffic through the @torproject 
> network.
> https://twitter.com/Snowden/status/1175430722733129729

Even with graphene, he still recommends removing the camera, and 
desoldering the mic, and attaching an external mic only when required.  
(Hardware kill switches would have been easier ;)

He goes on to also recommends to not use wifi, javascript, email, and 
web browsing in general. YMMV.

Besides, I doubt he's personally reviewed graphene code. There's a 
better argument to trust graphene:

>It has an 8 year history (previously called Copperhead);

Daniel Micay was a co-founder and primary developer of copperhead. He 
was fired after a disagreement about licensing, and deleted the signing 
keys, as he now considered the organization compromised.

There's a lot of that story to unpack and research. It's difficult 
because a lot of information sharing happened over twitter and reddit, 
which have since had posts deleted and accounts suspended (aside from 
the general pain trying to follow parallel live discussions 
retrospectively)

Anyway, a few years later he released Graphene. I'd trust him to go 
nuclear again to maintain trust. He's done it before.

-- 
Chris Irwin

email:   chris at chrisirwin.ca
  xmpp:   chris at chrisirwin.ca
   web: https://chrisirwin.ca