Securing a Personal Android Phone

It's been far too long since I've made time to sit down and write. I recently went through the ritual of swapping phones, so I will use the opportunity to jot some notes down.

I keep separate devices for work and personal usage. For the last several years, my personal device has exclusively run GrapheneOS, an Android Open Source Project (AOSP) focused on security and privacy.

Threat Model

Let's start by defining the threat model used in this post.

I am looking to defend against, to the extent possible via commercially-available hardware and software:

• Interception or man-in-the-middling of communications or network traffic (e.g., HTTP, text chat, video/audio chat, etc.)
• Targeted or opportunistic exploitation of commonly-abused services (e.g., zero-click exploits in SMS, web browsers, installed applications, etc.)
• Device imaging, data exfiltration, or other attacks (e.g., evil maid) conducted via physical access of a powered-on device.  

From a privacy perspective, I wish:

• To avoid highly-invasive Google products.
• To limit the data that can be collected from my device by an installed application.
• To avoid eavesdropping of network traffic or DNS resolution by local networks and internet service providers.
• To avoid making my device identifiable via broadcast characteristics or behaviors (e.g., MAC addresses for Bluetooth and Wi-Fi radios).
• To avoid IP-based tracking or fingerprinting by remote web servers.

About GrapheneOS

The GrapheneOS page does a great job of summarizing how the project improves security and privacy over stock android:

GrapheneOS improves the privacy and security of the OS from the bottom up. It deploys technologies to mitigate whole classes of vulnerabilities and make exploiting the most common sources of vulnerabilities substantially more difficult. It improves the security of both the OS and the apps running on it. The app sandbox and other security boundaries are fortified. GrapheneOS tries to avoid impacting the user experience with the privacy and security features. Ideally, the features can be designed so that they're always enabled with no impact on the user experience and no additional complexity like configuration options. It's not always feasible, and GrapheneOS does add various toggles for features like the Network permission, Sensors permission, restrictions when the device is locked (USB peripherals, camera, quick tiles), etc. along with more complex user-facing privacy and security features with their own UX.

From a security perspective, GrapheneOS has several significant advantages over stock Android:

• Security is treated as a first-class principle which filters down to all design and architecture choices.
• More complete security patching, including fixes for vulnerabilities and bugs that have not yet been patched upstream.  
• The available attack surface is heavily reduced by removing unnecessary or extraneous code and features.
• Anti-exploitation techniques including hardened application runtimes, stack canaries, hardened memory allocators, zero-on-free, improved SELinux rules, etc.

From a privacy perspective, GrapheneOS has several significant advantages over stock Android:

• The operating system is entirely de-Googled by default. You may choose to optionally install Play Services, or other Google applications, but none are included by default.
• Where possible, uniquely identifiable attributes related to your device are obfuscated, removed, or altered for privacy. This includes MAC address randomization.
• Improved application sandboxing, and associated application controls, allow you to more granularly control what data installed apps can access. This is especially useful for managing filesystem access via Storage Scopes.

A comprehensive list of features can be found on the GrapheneOS website.

Selecting Hardware

GrapheneOS only supports Pixel hardware, which means a relatively limited list of devices to choose from. Each generation of Pixel has a standard flagship phone (e.g., the Pixel 6) and one or more variations (e.g., Pixel 6 Pro, Pixel 6a). Aside from hardware differences between devices, it is important to consider longer-term software update support. For the most recent generation of Pixel phones, you'll receive up to 5 years of post-launch security updates. This window tells you how long you can expect to run GrapheneOS on the device before you'll stop receiving security updates.

When deciding on which device to procure, the most important feature to me was presence of the Google Tensor SOC and Titan M2 chips, which work together to provide significant hardware-backed security capabilities. These chips were introduced in the 6th generation Pixels and provide the strongest security primitives available on Android to-date.

Under the hood, the Pixel 6 phones have a trusted execution environment (TEE) running an open-source operating system called Trusty. The TEE runs in a parallel, isolated manner from the Android operating system, and provides enhanced security, validation, and reporting. The TEE uses hardware isolation to prevent compromise from the Android kernel itself; this is similar to Virtualization-Based Security (VBS) in Windows.

The Titan M2 chip is an external RISC-V coprocessor that handles security-critical functions such as key management, cryptographic acceleration, and StrongBox. Titan M2 runs Trusty, and works directly with the Tensor SoC on security-critical tasks.

Another great feature of the Pixel line of hardware is their support for Verified Boot. Verified Boot requires cryptographically verifying all executable code and data that is part of the Android version being booted before it is used. GrapheneOS implements a custom root of trust, and all subsequent code and data must pass verification checks before it can load into memory. This ensures that the operating system cannot be tampered with by an adversary.

Without delving too much further, it's important to highlight that the security value of the Pixel hardware cannot be overstated. As such, I opted for a Pixel 6a for my personal device.

Selecting a Carrier

My goal is to make it substantially more difficult for a dedicated adversary to target my device by reducing static indicators.

Whenever I acquire a new phone, I will typically also select a new mobile carrier account. I solely use pre-paid mobile accounts, typically mobile virtual network operators (MVNOs). For this round, I procured a Mint Mobile (TMobile) SIM card with cash, and wired it up to a Privacy.com card. For $30/month, it provides unlimited* 4G/5G domestic data with relatively little attributable information on the account (e.g., no name, SSN, etc.)

Don't forget that you can also use your Calyx hotspot for unlimited, unthrottled, anonymous connectivity.

A new device, a clean IMEI, and a new carrier account offer fairly reasonable security and privacy benefits. For example, if one were concerned about targeted mobile attacks (e.g., NSO Group), this hygiene measure can make it significantly more difficult for an adversary to successfully target them.

Using Pegasus malware as a case study, most initial attack vectors relied on direct targeting of an individual via a carrier-based identifier (e.g., phone number, account name). As most people do not periodically rotate these identifiers, it becomes trivial to acquire them via third-party sources. In many cases, an adversary may not even need to compromise a carrier; third-party data brokers and aggregators may have the information they're looking for.

Assuming each device is used on a new MVNO account with minimal personal information, it becomes significantly harder to target the intended victim. An adversary needs to go to more extreme lengths to unmask their target, or they need to perform less-targeted exploitation and hope they find the right device.

There are significant usability downsides to this approach. For this to be effective, you must treat your MVNO account as completely disposable. This means you must avoid sharing your "actual" number with other people or using it for services. This can be incredibly challenging, and requires significant forethought and planning. To make this work for me, I exclusively use Signal with a VOIP number for communications. I have also set up SIP and SMS forwarders for old numbers that people may still hang on to, or for stubborn services that require SMS for two-factor authentication, or account verification purposes.

Lastly, this is not a panacea. Using a disposable MVNO carrier account does not stop pattern of life analysis, such as identifying the user by analyzing how a phone travels between home and work. It also does not stop collection or identification based on other attributes (e.g., network traffic, roaming, device information), nor does it prevent carrier or baseband attacks (e.g., SS7). Treat it as an additional layer of obfuscation, not a defensive boundary.

Installing GrapheneOS

GrapheneOS has an exceptional web-based installer that works out of the box for the Pixel 6a.

Refer to their documentation on how to flash GrapheneOS onto your device.

Post-Installation Configuration

Once GrapheneOS is installed, it's time to configure it.

First, ensure the bootloader is locked. Start by applying any pending OS updates and rebooting your phone. Once it's all up-to-date, proceed with the following steps.

Lock Screen

Your threat model should include a confiscated device subjected to a GrayKey performing brute-force and dictionary attacks against your passphrase. Therefore, choosing a good password for your device is critical. Do not use a simple numeric PIN or password. Use a diceware passphrase of at least 4 to 8 words. The longer (more words), the better.

You can opt to use biometric unlock mechanisms (e.g., optical fingerprint) for convenience. However, a biometric unlock mechanism isn't protected under the 4th amendment in the same way that a passphrase is. If your device is confiscated, you may be compelled to unlock it via biometrics. This is further compounded by the tens of thousands of warantless phone searches conducted by DHS at U.S. border crossings each year.

Once you've picked a strong passphrase, ensure the power button instantly locks, and your phone locks immediately after timeout in Settings -> Security -> Screen Lock.

I'd also recommend disabling Screen Lock Camera Access, as it could potentially be used as part of a bypass, as has been the case historically with both Android and iOS.

It's also a good idea to ensure that you have minimal - if any - notifications visible on your lockscreen.

You can control the settings under Settings -> Privacy. It is recommended not to show any notifications on the lockscreen.

Hostname

The hostname may be periodically broadcast or inadvertently leaked. As such, it's good to rename your hostname to something innocuous like localhost or iPhone. The more generic the hostname, the better.

You can set a hostname in Settings -> About Phone -> Device Name.

Periodic Reboots

It may sound silly, but periodic reboots are one of the best defenses against mobile malware. A zero-click remote code execution exploit is pretty hard to pull off. Maintaining stealthy persistence after successful infection is even more difficult. As such, periodically rebooting your device could wipe memory-resident implants.

First, you'll want to set an auto reboot threshold. This ensures the device will automatically reboot if it hasn't been unlocked within a specific threshold. This is most useful for a lost, misplaced, or confiscated device. I personally use 12 hours.

You can set this under Settings -> Security -> Auto Reboot.

Aside from setting the periodic reboot threshold, it's important to develop your own habit. Whether you reboot once before bed, as soon as you wake up, or as a Friday ritual, it may unknowingly benefit you.

Camera and Microphone Security

Android 12 introduced a new feature which allows you to globally enable or disable the microphone and camera within the operating system.

Even if microphone or camera permissions are granted to an application, they will be unable to use them if the setting is globally disabled.

While not a replacement for a camera privacy cover or leaving your phone away from you during sensitive conversations, it's another tool in the toolbelt. It's a good idea to leave both of these toggles disabled until you explicitly need them.

Network Security

Carrier Security

GrapheneOS allows you to take control of normally restricted carrier settings. This includes manually modifying your APN, or even selecting which networks your phone will connect to.

If you are in a location where you have stellar carrier connectivity, you can disable legacy 2G communications. You can take this one step further and force 4G/LTE only, which will disable 2G, 3G, and 5G. As highlighted in the GrapheneOS documentation, this will dramatically reduce legacy code that could potentially be exploited or abused by adversaries.

MAC Address Spoofing

By default, GrapheneOS will automatically randomize your MAC address for WiFi networks on a per-connection basis. No further action is required for this to be enabled.

For paid wireless networks with captive portals, you may need to temporarily disable this feature. Luckily, that's also natively supported.

Open up the wireless network under Settings -> Network & Internet -> Internet -> Network Preferences. You can then set a default behavior for that network, to include a per-network randomized MAC address (as opposed to per-connection).

It is generally ill-advised to use the actual device MAC address on any network except those you strictly trust.

Private DNS

It's highly recommended to use a Private DNS provider. I use NextDNS. NextDNS will encrypt (and optionally log) DNS requests and responses via DoH/DoT, and allow you to apply security/content filtering.

Within NextDNS, you can easily configure category-based blocking. This can include security blocklists (e.g., threat intelligence) as well as privacy (e.g., EasyList, EasyPrivacy).

Configure your DNS endpoint (e.g., yourid.dns.nextdns.io) in Settings -> Network & Internet -> Private DNS.

Virtual Private Network

Usage of commercial VPN technologies can be a very divisive and contentious subject. Using a VPN can reduce some risks (e.g., eavesdropping/Man-In-The-Midddle by your ISP) at the expense of increasing some risks (e.g., you're trusting a third party VPN provider with your network traffic).

Firstly, let's start with the obvious: a VPN does not make you anonymous. You can use a VPN to help defeat certain attacks (e.g., preventing man-in-the-middle on an insecure wireless network) or improve privacy in some areas (e.g., defeat IP address monitoring on a remote website). However, we have other layers of defense that can help protect against these attacks (e.g., Transport Layer Encryption, TOR, etc.)

Using a VPN should be a well-considered part of your threat model. For me personally, I care a great deal about (a) protecting my traffic from eavesdropping and collection on backend internet service providers, and (b) mixing my traffic with valid traffic from other users. As such, I find a commercial VPN to be worthwhile. I can always split-tunnel specific applications, or use Tor, if I don't want to trust the VPN provider with my traffic.

Now, how does one select a reasonable VPN provider? Answering that question is beyond the scope of this article, so I'll jump straight to my answer: consider Mullvad.

Mullvad has native support for Wireguard, has reasonable security and privacy policies (not that you should trust those too much), and has undergone third-party review of their infrastructure. Mullvad also allows you to pay for their services in an anonymous or pseudonymous manner. You can use cryptocurrency (e.g., Monero), credit cards (e.g., Privacy.com), or even mail them cash in an envelope. Your account is simply a numeric number and, if you pay for it appropriately, has no personally identifiable information related to you.

If using a commercial VPN provider is not your cup of tea, you can always run your own VPN endpoint. Algo VPN is the golden standard, and can provide substantive benefits without relying on a shady VPN provider. However, self-running a VPN host likely means all of your traffic has a static egress IP address, which can be tracked back to you quite easily. Good for protecting against ISP-level eavesdropping, but perhaps not so great against a more sophisticated adversary.

Regardless of which VPN provider you choose to use, ensure it is set to Always On, and Block connectivity when disconnected. You can use the native VPN DNS provider if you're really concerned about blending in, but I recommend sticking with your NextDNS provider.

USB Devices

USB connectivity pose a significant risk for physical acquisition. The safest option is to prohibit loading USB devices within the operating system, even if unlocked. This can be toggled on an as-needed basis in Settings -> Security -> USB Accessories.

It is highly recommended not to use USB devices for file transfer to your phone. Rely on an end-to-end encrypted application for transferring sensitive information, as opposed to flash drives, or other mass storage devices.

Developer Mode

If you've already enabled it, navigate to Settings -> System -> Developer and uncheck it.

It's also worth disabling Native Code Debugging in Settings -> System -> Security as a defense-in-depth control.

Google Play Services

GrapheneOS has support for highly sandboxed Google Play services. This allows you to use some critical Google services (e.g., notifications, app store) without compromising the privacy of your entire device.

If desired, Google Play Services can be installed via the GrapheneOS Apps application. For the purposes of this guide, we'll proceed to install it.

There are some significant privacy and security tradeoffs to consider when evaluating Google Play Services. Firstly, it is required for a variety of applications to function effectively. Without Play Services, applications may not run effectively, or may not function at all.

Secondly, your device will require a verified Google account. Some information about your device, including model, installed applications, and IP addresses, will be periodically sent to the mother-ship. Burner e-mail address and SMS services can be used to create a verified Google account without personal attribution. However, beware; you will be at the mercy of these services if/when Google requires you to re-validate yourself.  

Once Google Play Services are installed, it will generate an Advertising ID that is used for uniquely identifying and tracking your device. Let's purge it.

Go to Settings -> Apps -> Sandboxed Google Play -> Google Settings -> Ads -> Delete Advertising ID.

Once this has been deleted, go through the other Sandboxed Google Play settings and disable any other undesirable features.

Google Account Security

Depending on your threat model, you may choose to use no Google services, use a personal Google account, or use a burner account.

Whether you're using a personal or burner account, it's important to ensure you have multi-factor authentication enabled. For the maximum level of security, you can opt-in to the Advanced Protection Program, which forces strong authentication (e.g., passwordless) and hardens your account to the greatest extent possible.

Beyond strong authentication, you should conduct a Privacy Assessment and ensure personalized advertisements, search query collection, and other forms of logging or personalization are disabled and minimized. Google will still collect all your data - but it's best to turn the knobs and dials we can.

For security and privacy reasons, it is highly recommended not to reuse this account on a new device; treat these Google accounts as disposable as your carrier accounts.

Browser Security

Vanadium comes stock with GrapheneOS and is highly recommended for general browsing. Bromite is a great alternative that has ad-blocking, but this comes at the cost of security. There is an exceptional writeup on the state of browser security on the GrapheneOS website.

In either scenario, it's best to ensure location access, third-party cookies,and javascript just-in-time (JIT) are disabled for your browsers. It's highly recommended to also disable javascript (JS) wholesale, but this comes at an extreme usability cost.

Applications

To improve privacy, reduce attack surface, and mitigate against surreptitious tracking, you should install the minimum set of applications you need. Where possible, you should use your browser to access online services.

Installing Applications

You have several methods of installing Applications on your device, each with their own privacy and security tradeoffs:

• Google Play Store (requires Google account)
• Aurora Store (Google Play Proxy)
• F-Droid (Open Source Store)
• Sideloading APKs

The Google Play Store is the most secure and trustworthy way of installing and managing applications. Unless you are strictly trying to avoid ALL Google services, using a burner account with the Play Store is strongly preferable.

While Aurora Store and F-Droid are popular, I don't trust them enough to exclusively rely on them. There are some good articles outlining the challenges and security implications of solely relying on the Aurora Store and F-Droid.

Sideloading APKs is perhaps the least secure method for installing an application. However, it may be required in instances where Google has banned an application from their store (e.g., NewPipe). Securely sideloading applications, to include validating their integrity, is beyond the scope of this article.

Essential Applications

There are the applications I personally view as essential for a mobile driver. You'll notice that this list is devoid of many types of applications (e.g., Travel, Hotel, Banking). In those instances, use the web client.

Secure Communication: Signal. Signal is the golden standard of secure (not private) communications. As I don't have a typical phone number, I use a dedicated VOIP number with Registration Lock enabled, and a very strong PIN.

Secure Communication: Element. Element is a cross-platform client for the Matrix network. Matrix has significant cross-connectivity with other network services (e.g., IRC, Telegram, etc.) and can support end-to-end encrypted messaging in rooms.

Secure Collaboration: ProtonMail / ProtonCalendar. ProtonMail/ProtonCalendar are good-enough from a privacy/security perspective to rely on them for daily driver accounts. If Google is in your threat model, enforcing FIDO2-only access via Advanced Protection Program is about the highest security bar you can get. You can also do the same with an Office365 subscription and conditional access policies.

Secure Virtual Private Network: Mullvad. VPNs are hit-or-miss depending on your threat model. Mullvad is reasonably affordable, supports Wireguard natively, and has enough credibility to be trusted for general web browsing. Only recommended if you want to evade your local ISP / network path.

Password Manager: KeepassDX. KeepassDX is open-source, doesn't require network connectivity, supports hardware tokens (e.g., YubiKeys), and works seamlessly with your Keepass vault. Revoke network permissions in GrapheneOS, and synchronize your vault using a dedicated tool.

Two Factor Authentication App: Aegis. Aegis Authentication is open-source, feature rich, has native backup/restore features, and doesn't need network access. Revoke network permissions in GrapheneOS.

File Synchronization: Resilio Sync or SyncThing. Resilio Sync isn't open-source, but it's a fantastic synchronization product. It quickly and trivially synchronizes sensitive files like photos, keepass vaults, etc. SyncThing is an open-source alternative that is very well-respected.

File Encryption: Cryptomator. Cryptomator is an open-source project that allows you to create encrypted vaults for file storage. This works in tandem with your file synchronization application (e.g., Resilio Sync, SyncThing) for moving around sensitive files.

Note-Taking: Obsidian. In my opinion, Obsidian is the quintiessential note-taking application. It free, feature-rich, uses plaintext Markdown (MD) files under the hood, and can be synced locally. Combine with a file synchronization application (e.g., Resilio Sync, SyncThing) for managing your Obsidian vaults.

Private Browsing: Tor Browser / Orbot. A VPN will help prevent your local network or internet service provider (ISP) from observing details about your network traffic, but it is a far cry away from private or anonymous. Tor Browser allows you to browse the web using a series of relays in a secure, anoymous, and censorship-resistant manner. Orbot allows you to selectively route application traffic through the Tor network.  

Apple Tag Tracking: AirGuard. AirGuard periodically uses bluetooth to scan for nearby Apple devices and AirTags. If an AirTag is observed following you (e.g., someone dropped it in your bag), AirGuard will notify you and allow you to find it.

Camera: GrapheneOS comes native with a hardened Camera application. One of the benefits is that it natively removes almost all EXIF metadata on the photos it captures.

PDF Reader: GrapheneOS comes native with a PDF reader designed to be as secure as possible. It has a strict content security policy, uses a hardened Chromium rendering stack, and the rendering code is memory-safe with dynamic code evaluation disabled.

Controlling Application Permissions

The security and privacy of installed applications can be further enhanced through these optional features.

Network permissions: A Network permission toggle allows you to block an application from making direct or indirect access to any available networks. This allows you to ensure a given application cannot make network requests, even to localhost, without your permission.

Device sensors: A Sensors permission toggle allows you to block an application from accessing any device sensors (e.g., accelerometer, gyroscope, compass, barometer, thermometer, etc.) Revoking sensor access from installed applications can prevent against entire classes of privacy inference attacks (e.g., keylogging, location tracking, etc.)

Storage Scopes: GrapheneOS provides Storage Scopes as a fully compatible alternative to the standard Android storage permissions. Instead of granting storage permissions, users can enable Storage Scopes to grant the requested permissions in a highly restricted mode where the app can create files/directories in the user's home directory but can only access the files it has created itself. Users can then optionally add files and directories as storage scopes to permit the app to access files created by other apps.

Parting Thoughts

I have been fortunate enough to run GrapheneOS as my daily driver for the last couple years. Over this period of time, the quality, stability, and functionality of the project have grown significantly.

GrapheneOS initially provided substantive hardening behind-the-scenes with projects like hardened_malloc. It now offers extremely compelling features like Sandboxed Google Play services, hardened Camera and PDF readers, an App Store, and privacy-centric network proxies for OS-level beacons (e.g., captive portal detection).

For my purposes, GrapheneOS meets all of my requirements with little to no downsides. I exclusively communicate via Signal, have no ties to the Google ecosystem, and do not use applications which might conflict with the OS. As such, I wholeheartedly recommend it, and believe it represents the most private and secure mobile operating system you can run.

Further Reading and Acknowledgements

• GrapheneOS Documentation
• Android Security Documentation
• Privsec.dev
• PrivacyGuides.org
• Google Blog - Pixel 6
• 2021 - A Titan M Odyssey [PDF]