Tag: GrapheneOS

It’s a Tracking Device, Not a Smartphone

I like to refer smartphones as voluntary tracking devices. Cellular technology provides your location to the network provide as a side effect. Smartphones can also leak your location through other means. But location isn’t the only type of information collected by smartphones. Android has a sordid reputation when it comes to data collection. Part of this is because Google’s primary business is collecting information to sell to advertisers. Another part is that handset manufacturers can bake additional data collection into their Android devices. Another part is that Android lacked granular application permissions until more recent versions, which allowed application developers to collect more information.

Apple on the other hand has enjoyed a much better reputation. Part of this is because Apple’s primary business model was selling hardware (now its primary business model is selling services). But Apple also invested a lot in securing its platform. iOS provided users more granular control over what applications could access earlier than Android. It also included a lot of privacy enhancements. However, Apple’s reputation isn’t as deserved as one might think. Research shows that iOS collects a lot of information:

“Both iOS and Google Android share data with Apple/Google on average every 4.5 [minutes],” a research paper published last week by Trinity College in Dublin says. “The ‘essential’ data collection is extensive, and likely at odds with reasonable user expectations.”

Much of this data collection takes place after the phone is first turned on, before the user logs into an Apple or Google account, and even when all optional data-sharing settings are disabled.

“Both iOS and Google Android transmit telemetry, despite the user explicitly opting out of this,” the paper adds. “However, Google collects a notably larger volume of handset data than Apple.”

I can’t say that this surprises me. Apple is a publicly traded company, which means its executives are beholden to share holders interested almost exclusively in increasing the price of their shares. That means Apple’s executives needs to constantly increase the company’s revenue. User information is incredibly valuable. Mark Zuckerberg made a multi-billion dollar company out of collective user information. So it was unrealistic to expect Apple to leave that kind of potential revenue on the table. Even if Apple isn’t currently selling the information, it can start at any time. Moreover, if it has the information, it can be obtained by state agents via a warrant.

This brings up an obvious question. What smartphone should individuals concerned about privacy get? Unfortunately, Android and iOS are the two biggest players in the smartphone market. They are also the only two players readily available to consumers who aren’t tech savvy. GrapheneOS is an example of an Android version that offers better privacy than the stock versions found on most devices. But using it requires buying a supported Pixel and flashing GrapheneOS to it yourself. There are also phones that run mainline Linux such as the PinePhone and Librem 5. The problem with those devices is the state of the available software. Mainline Linux distributions designed for those phones are still in development and likely won’t meet the needs of most consumers.

Right now the market looks grim if you want a smartphone, are concerned about privacy, and aren’t tech savvy enough to flash third-party firmware to your phone.

Before and After First Unlock

If you’ve used a desktop operating system, you may have encountered full-disk encryption. The name is self explanatory. When full-disk encryption is used on a desktop or laptop, the entire contents of the hard drive (minus whatever is needed to properly boot the system far enough to enter the decryption key) are encrypted. The contents are only accessible after the decryption key has been provided during boot up.

iOS and modern versions of Android use a different model called file-based encryption. Rather than encrypt the entire contents of the device, files are encrypted individually per a policy. This is why you can make a call on an iOS or Android phone after is has been booted but before it has been unlocked. But like with full-disk encryption, the encrypted files are only accessible after the device is first unlocked after a boot up.

The states where encrypted data is inaccessible and accessible are referred to as before and after first unlock respectively. Before the first unlock data is considered at rest. The device is unable to decrypt the encrypted data because the necessary decryption key hasn’t been provided by the owner. After the first unlock the device stores the decryption key so it can decrypt and access the encrypted data. How the keys are stored varies. Many devices store the decryption keys in memory, but the more secure method is to store decryption keys in a secure chip such as the Secure Enclave hardware on iPhones or the Titan M chip on Pixel devices (technically the decryption key is usually derived by the secure chip using the provided decryption key and other inputs, but I’ll skip over those details in this post). Using a secure chip adds a barrier between the decryption key and malicious software or hardware able to gain unfettered access to system memory.

When you read stories about law enforcers extracting encrypted data from a device without the owner’s cooperation, they are almost always extracting the data after the first unlock:

The main difference between Complete Protection and AFU relates to how quick and easy it is for applications to access the keys to decrypt data. When data is in the Complete Protection state, the keys to decrypt it are stored deep within the operating system and encrypted themselves. But once you unlock your device the first time after reboot, lots of encryption keys start getting stored in quick access memory, even while the phone is locked. At this point an attacker could find and exploit certain types of security vulnerabilities in iOS to grab encryption keys that are accessible in memory and decrypt big chunks of data from the phone.

Based on available reports about smartphone access tools, like those from the Israeli law enforcement contractor Cellebrite and US-based forensic access firm Grayshift, the researchers realized that this is how almost all smartphone access tools likely work right now. It’s true that you need a specific type of operating system vulnerability to grab the keys—and both Apple and Google patch as many of those flaws as possible—but if you can find it, the keys are available, too.

When law enforcers confiscate a device, it’s common practice to both prevent the device from powering off and to isolate it from any network access. This prevents the device from entering before the first unlock state and from being remotely wiped. Mobile phones have their own batteries, which increases the time law enforcers have between confiscation and connecting it to a secondary power source. Placing the phone into a Faraday bag isolates it from network access. Once a device has been prevented from powering off or being remotely wiped, law enforcers can work to decrypt the contents of the phone at their leisure.

Before continuing I will note that law enforcers aren’t the only individuals interested in gaining unauthorized access to the encrypted contents on a device. I’m highlighting them because they receive the most press coverage. Keep in mind that many unauthorized parties such as abusers and stalkers have the same interest albeit for different reasons.

The safest state for encrypted content is at rest. This is why I always recommend people power down their devices before entering airport checkpoints or border crossings. Those are situations where encounters with law enforcers are guaranteed and the chances of devices being confiscated is higher than average. I also recommend people power down their desktops and especially laptops when not in use. That way if the device is stolen, the contents remain inaccessible to the thief. However, powering down devices isn’t always practical, especially when the device in question is a smartphone. If you’re meeting somebody at an airport, you might need to keep your phone powered on in case the party with whom you’re meeting needs to contact you (although I will argue that proper planning can avoid this scenario and, if not, rebooting the device and leaving it in before the first unlock state will allow you to be accessible while keeping your data at rest). If a mugger demands your smartphone, they probably won’t allow you to power it down before handing it over.

This is why I was happy to discover a feature in GrapheneOS. In the settings application under the Security category there is an option called Auto reboot. By default this is disabled, but if you tap on it, you’ll be greeted with a dialog box offering different lengths of time. If you select one of those options, the phone will automatically reboot if it hasn’t been unlocked in the selected period of time. This ensures that the device will return to before the first unlock state after you haven’t unlocked it for the selected period of time. If you unlock your device frequently and don’t mind entering your password when you wake up in the morning, you can select a short time period. If you don’t want to enter the password every morning, you can select eight hours (or slightly more than however many hours you typically sleep). This feature creates a specific window of time between when a device is confiscated or stolen and when it returns to before the first unlock state.

This is a security feature I would like to see adopted by other operating systems. Knowing my laptop had a finite period of time between when I last unlocked it and when it returns to before the first unlock state would give me the convenience of putting it in sleep mode rather than powering it down completely when transporting it (I fully admit powering down isn’t a huge inconvenience for me since I don’t transport my laptop frequently, but a lot of people transport their laptop between home and work twice a day).

My Thoughts on the Pixel 4a Running GrapheneOS

As I noted in my last post covering the fiasco that is today’s Apple, I ordered a Pixel 4a with the intention of flashing GrapheneOS on it. For those of you who are unfamiliar with GrapheneOS, it is an Android Open Source Project (AOSP) operating system that focuses on security. The list of security features included in GrapheneOS is quite long so instead of trying to summarize it, I’ll point you to the project’s feature list.

GrapheneOS only runs on Pixel devices. This is because Pixel devices implement several hardware security features including the Titan M security chip (a similar idea to Apple’s Secure Enclave). Pixel devices also support Android Verified Boot (AVB) 2.0 with third-party signing keys. AVB 2.0 cryptographically verifies that the operating system you’re booting hasn’t been altered. When properly setup, this allows non-Google firmware to boot from a locked boot loader. GrapheneOS supports AVB 2.0 and relocking the boot loader is actually part of the installation process. This is a GrapheneOS advantage since most AOSP operating systems can only boot from an unlocked boot loader. An unlocked boot loader is a majority security weakness.

Installing GrapheneOS is about as easy as installing a third-party operating system on a phone can be. There are two supported methods: a web based installer and a command line based installer. I chose the latter. Both are made straight forward by the step-by-step guides. When you boot GrapheneOS the first time, you’re greeted with a bare bones installation. I prefer minimal operating system installations so I consider the bare bones nature of the default GrapheneOS is a plus.

I installed the same applications on this device as I installed on my Teracube 2e. GrapheneOS doesn’t include a calendar application so I installed Etar, which is the calendar application included in LineageOS.

One of the notable features of the Pixel 4a is the camera. However, you probably won’t be terribly impressed by pictures taken with the camera application included with GrapheneOS. This is because the high quality pictures you see in Pixel 4a reviews requires a combination of hardware and software. The software is Google Camera. Google Camera applies software enhancements to improve the quality of pictures taken with Pixel hardware. Not surprisingly it requires Google Play Services. A recent addition to GrapheneOS is support for fully sandboxed Google Play Services. This allows you to install Google Play Services without granting permissions greater than any other app (normally Google Play Services enjoys additional privileges). If you need Google Play Services, I believe this is a better solution than microG, an alternative used by a number of AOSP operating systems.

I wanted Google Camera without all the additional Google cruft so instead of installing Google Play Services I installed Gcam Services Provider. Gcam Services Provider is a shim that implements just enough of Google Play Services to run Google Camera. GrapheneOS with Gcam Services Provider isn’t enough to run Google Camera though. Launching Google Camera with this configuration will only result in a black screen (information about this behavior can be found here. I resorted to installing a modded versions of Google Camera of which there are quite a few. I settled on this version because it works with Gcam Services Provider and allows me to use a gallery application other than Google Photos (the official Google Camera application is hard coded to display recently taken pictures with Google Photos and I have no interest in installing that).

The installation process for Google Camera that I just described is the only thing on my setup that feels hacky. GrapheneOS is polished. It actually feels like a first-party operating system on the Pixel 4a. It is a major improvement over the user experience of LineageOS on a Teracube 2e (because the version of LineageOS for the Teracube 2e is still unofficial, I didn’t expect a polished user experience, I’m just noting the comparison here because it’s the only baseline I have). I will go so far as to say that GrapheneOS offers a user experience comparable to iOS on an iPhone (and probably the stock firmware on the Pixel 4a, but I didn’t spend any time using that) with the caveat that applications that rely on Google Play Services may not work if you don’t install Google Play Services (thanks to sandboxing doing so isn’t as dangerous on GrapheneOS as it is on other AOSP operating systems). The user experience is so good that my wife, who is not a technical user, is happy with it.

GrapheneOS is a great option for iOS users wanting to flee the panopticon that Apple is dead set on inflicting on iOS users (and probably macOS users).