On 23rd June 2023, I made a reply on SN to @siggy47 about how I would post my experiences and advices with GrapheneOS. Obviously, I have been very late on that and I am sorry. A lot of things happened overall that slowed down my progress on personal endeavours. But, I always had this in my books and I hope you can find some of the rambling in here insightful. As a power user with a professional understanding of GrapheneOS who authors a lot of resources for the project, I hope this article can help you see things differently.
In this post I am going to provide a simplified rundown on the vast GrapheneOS documentation. I will assume users are briefly familiar with GrapheneOS due to the audience of this website and likely wherever this article is spread to, but don't feel alienated if you aren't because I'll still give some background. Outside of that, I will provide some technical details on what certain features exist and do, the justification and purpose for GrapheneOS, and a bit about myself and how I do things. I'll also try and explain some of the GrapheneOS philosophy.
In the start of the year, I joined GrapheneOS as a non-developing contributor. I am very grateful to be on the side of an extremely talented team and a software project that I consider systematically important in today's landscape and the security community as a whole. I owe a lot thanks to their work from when I was a user and originally it all started as a way of giving back to software projects I supported.
I especially want to thank a lot of SN and Nostr users for their enduring support of GrapheneOS. For exceptional reasons I purged my old Nostr nsec and I am not on Nostr much for the time being. It will likely be less to do about GrapheneOS since there are Mastodon bridges and other moderators there now, so more Final, less GrapheneOS.
Anyways, here's your article:
Background
Smartphones established their place in society as an irreplaceable tool for communication and access to the online world from anywhere and anytime. As global adoption increased, they became the largest containers of people's private and sensitive information. Additionally, the more a person uses their smartphone, the greater the amount of information that device then contains about it's owner. The typical mobile mobile devices manages data such as communications (like texts or emails), contacts, locations, documents, photos, videos and online activity - with people additionally using their device to manage their finances or their identity.
This scope of information handled by a smartphone is diverse and comprehensive. Such information wouldn't just be able to identify a unique person, but also track them and view their life in a chronological timeline. Thanks to all of this data being in one place, there can be grave consequences if someone were to compromise or abuse your privacy rights of your device. This, along with their widespread use, are some of the many reasons why a smartphone is one of the most highly desired platforms for malicious actors to target.
Mobile security is important, arguably, the most important priority in a list of fundamental digital security actions. The first thing you should think about protecting is the things you use the most and keep closest to you, like your accounts and everyday devices. Digital security isn't just about protecting yourself, but the people you communicate with or have information about. Security incidents, breaches and targeted attacks affect others professionally and personally.
Mobile operating systems are well-designed. Many security mechanisms like disk encryption, application sandboxing, adminless users, exploit mitigations and adoption of hardware-based security features like secure elements aren't default, mandatory or adopted in a majority of desktop operating systems (mainly Windows and Linux). Despite the success here, there is significant room for improvement.
When mobile operating system developers and hardware manufacturers want to improve their product, they try to stay on a summit where there is great usability, personalization, and user experience. This can be a conflict against users who need extraordinary security requirements, since high security will often come at a cost of a restricted environment, and wanting more privacy will come with a sacrifice of a less personalized user experience. The more work you put into security, the more restrictive your workflow will be. The more privacy you uphold, the less intuitive your user experience, as bespoke personalization for the user can only be accomplished by the user providing more information about themselves.
This is a problem for users who have higher security requirements. Users who care about such features or have bespoke security needs may be missing out when using the mainstream offerings since they don't provide further security and privacy features because of a percieved notion that adding such features makes it too complex and disruptive for users. Users should have the choice to go further beyond and have individual options to do so. For example, Apple's Lockdown Mode functionality only disables a group of features without the option to toggle to activate some of them individually, which risks the mode being too disruptive and discouraging users to add protection. With mobile devices being a high target, this is very important problem I hope the project I am discussing helps to solve.
Introduction
In this post I will discuss GrapheneOS, a privacy and security-hardened mobile operating system built on providing improved security and privacy while maintaining the app compatibility and overall usability of Android. In simple terms, hardening is the process of increasing the security of a system above the defaults that the system provides. In our example, GrapheneOS uses the Android platform's security model as a foundation, and provides changes, user features and new technologies designed to improve the security of the platform and the user's privacy above the Android foundation.
In relation to the security-usability problem, many of the GrapheneOS security features are set up with minimal user impact or intervention. Users of GrapheneOS have far greater security than they would on Android with little setbacks beyond features and applications exclusive or only designed to work on stock Android distributions. GrapheneOS is not just a moderately secure OS, it is a very usable OS as well - it is very advanced security work in a simple environment. GrapheneOS also provides features to help with usability and app compatibility while still benefitting with security, such as the sandboxed Google Play compatibility layer.
GrapheneOS is a result of previous projects dating back from 2014. The original developments of the project included porting OpenBSD's memory allocator to Android and the PaX Linux kernel patches. After a failed hostile takeover attempt GrapheneOS became a fully independent free and open source project in 2018, and development is funded through donations sent towards a non-profit GrapheneOS Foundation who supports the developer team.
Why GrapheneOS must exist
Outside of the subject of this post, there are little to no offerings in the space for a useable mobile operating system where privacy and security are the designated focus. Many people will say they have a product that is, but it is inaccurate, problematic, or even malicious. The market of security and privacy is a space ripe with scammers and criminals, because privacy and security are extremely easy concepts to sell to people. They can meet many characteristics of a scam, such as marketing with a sense of urgency, an appeal to authority, a play of the reader's emotions such as their paranoia, an offering of scarcity by designating everything else as less secure, and referencing current events to make their product more relevant.
I say this with little remorse: the mobile security industry is plagued with unethical and criminal-backed rot that sells proprietary, unsafe, or misleading scam products ran by equally sketchy people. These companies' primary market is to sell insecure devices to anti-intellectual criminal filth who believe they are untouchable, or to trick people who don't know any better into buying some brick product or being a reseller marketing extortionate sponsorship, affiliate deals or government "support". They are such a trend that law enforcement routinely compromise their business operations, and create fake products for sting operations. Many of these companies also sell their products to fund their own likely illegal business dealings.
Many companies like this are still alive today... Crypto Cloud, Omerta Digital, Renati/ChatMail (Myntex), Freedom Phone, Unplugged Phone and many others are currently ongoing. While none will explicitly market for criminals, they all fall under the same characteristics of selling you a false promise and providing lulling whispers of extreme, unrealistic claims to anyone mistaken enough to fall for them.
I have no interest in killers or drug dealers, but the effect that these scams like these have had on ordinary people wanting to protect themselves is catastrophic. While it is great to see the evil in society face justice thanks to these law enforcement operations, the truth remains that hundreds of thousands of people fall victim to fake marketing from criminal enterprises like EncroChat, SkyECC, and Phantom Secure or even the FBI's own ANOM. These cases don't just highlight that hundreds of thousands put their trust in fake security, but how easy it is to make a scam product with the same characteristics, marketing, and bogus claims time after time and still have people fall for it. It begs the question, how many ordinary people have also put their trust in false security?
Outside of criminal enterprises, GrapheneOS is different to other open source projects, it is not just the same, redone custom Android distribution with some Google apps removed or some random apps bundled into it. GrapheneOS is about OS security innovation and is full of security features not available elsewhere, and we're about doing it properly and faithful to the upstream OS security model unlike other projects as well.
A security-focused operating system can't just be an ordinary operating system with some components removed, as described above it must be hardened and above the standards users are willing to expect. GrapheneOS provides that, and is a free and open source project for people. It isn't a sketchy product for criminal scumbags to make money from, unlike these bogus products. We are one of the largest mobile security projects out there and GrapheneOS exists to protect others... we have evidently done so.
The right to privacy is one of the foundational building bricks of a modern state. People can, or better, should rightfully care that their personal details must remain confidential. Who you are, where you live, who your friends and family are, how they live, and how you all run your lives are private matters. Security is the essential baseline that upholds your privacy online and in the real world. Security measures like encryption, access controls, exploit mitigations, and being up to date against modern threats are some of the many ways your privacy is upheld. Without security you cannot have privacy, because you do not have measures to protect what you wish to withhold against your adversary.
GrapheneOS defence strategy
GrapheneOS's defence strategy is to harden the system from the bottom to the top (from firmware, kernel, app runtime and app sandbox all the way up to the user-facing apps and settings) to reduce the amount of vulnerabilities and increase the difficulty in exploiting them. A vulnerability is a flaw in software that can be abused by a malicious actor for an attack. GrapheneOS hardens the system above Android in a huge variety of different ways, however you can consider these strategies to fall under any of these three core principles:
- Attack Surface Reduction: Preventing attacks by removing, disabling or configuring OS components to reduce their capability as an exploitable attack vector.
- Exploit Protection, Detection and Mitigation: Preventing attacks by adopting security technologies designed to make exploits difficult, more detectable, or easier to remediate.
- Containment and Sandboxing: Preventing attacks by designing the system that runs applications and user-installed code to be an unprivileged, contained environment that restricts them from malicious activity.
Almost all of the GrapheneOS changes, features and technologies adopted can be mapped on these principles as well:
(this picture doesn't contain every feature, and a feature doesn't have to be *exclusive* to the principles they are contained within either, but it maps the primary purpose of that feature)No system is definitively unhackable, but some systems can certainly be more difficult to hack than others. Offensive and defensive security engineers move in an arms race to outdo eachother (typically for the benefit of the security community - but not always), and they follow each other in what trends they are interested in. Some features are on our radar for several years before they ever get adopted, and the same goes for our adversaries because they know it will be challenging for them.
Security innovation is important for GrapheneOS, it's a long try to be the platform to get game-changing security features first (like MTE) or have the most secure implementation of them (like Duress Password). Security innovation makes big moves that changes the priorities of adversarial groups wishing to target us. For a real world example: Cellebrite, an Israeli mobile forensics firm using exploits to target iPhones and stock android OS devices for forensic extractions recently opened up a job application for researchers who have an expertise in PAC and MTE, hardware-based exploit mitigations GrapheneOS notably takes advantage of:
(Does this mean Cellebrite is interested in exclusive targeting for GrapheneOS in particular? No, other platforms could use MTE as well - but it's only widely used, and in production, in GrapheneOS. We are also referenced in their internal documentation published by us. We are virtually certain we are group of interest.)The defence strategy is designed to target vulnerability or attack groups rather than focus on individual attacks or proof-of-concepts. Doing the latter only helps dealing with what's known or already patched and is an attitude that provides little awareness or consideration of unknown vulnerabilities or in-the-wild attack campaigns. Well-designed security features or design choices can make overall exploitation of certain vulnerability groups harder or impossible. How they are prioritized is based on the most dangerous and most common types of exploitation in the threat landscape right now.
GrapheneOS threat modelling brief
Threat modelling is the evaluation of risks and the countermeasures or remedies of the risks. Risk means potential uncertainty that compromises the security of our system, there doesn't necessarily have to be a vulnerability for a risk to exist either. Risks are based on known security trends, and what is considered a risk to act against is based on evaluating what we develop, what could go wrong, and what we know in the threat landscape that could influence our judgement.
The most dangerous threats would be:
- Remote (from distance, i.e. the Internet) exploitation
- Categories of vulnerabilities that contribute to most critical vulnerabilities (like memory corruption)
- Physical access / proximity attacks
- Compromise by third party
Let's review the market behind remote exploitation:
The Threat Market
Going back to what we said about the popularity of targeting mobiles, how do we know that mobile platforms are the most desired platform for malicious actors? The price tags for targeting the platform increase as the devices become more secure, smarter, and complex. Targeted exploitation for smartphones is a massive business and there is a huge industrial complex of companies trying to discover exploits to sell them off as commodities. This is a multi-million dollar industry with very high-paying customers in governments or the elite class. Companies in these industries may hack for different reasons, they can be cyber-arms dealers who sell malware as espionage tools like NSO Group, or forensics companies leveraging exploits to sell data extraction capabilities to 'law enforcement' like Cellebrite and MSAB.
This exploit market has always been high-demand. Alongside companies who sell tools leveraging exploits, there are companies who act as a broker, offering money to people who will give the exploits to them instead of the affected party so they can sell that exploit to their partners. Zerodium, OpZero and Crowdfense are some examples of popular exploit brokers. The best exploits that could meet any objective are worth payouts of millions of dollars, typically above the highest bounty that would be paid out by the affected software's developers.
If we take a look at some scopes of bounties from exploit broker companies, we can see just how much the price of the capability total compromise of mobile devices can cost. For an Android Zero-click full chain compromise, Crowdfense offers up to five million dollars, with Zerodium and Operation Zero offering two and a half million:
In these attack descriptions "Persistence" means the compromise continues even after a device is rebooted, "Full chain" (FC) can have different details per provider, but all universally agree that it is a complete, total compromise of the target and access to any device functionality. "Zero-Click" means an attack that requires no interaction from the user, for example tricking them to click a link. As pictured, Google provides Android bounties as well, which goes toward improving the security of Android rather than using attacks as commodities.
These high prices may seem surprising but are generally very cheap compared to the profits made from exploits that end up being commercialised. NSO Group are alleged to have sold their zero-click exploits for a $500,000 installation fee per client to manage the software with an additional $650,000 per 10 iPhone targets. Just one business client would be enough to get returns more than what Google ever offered for giving up.
What you will find is most of these vulnerabilities all have something in common...
Memory vulnerabilities
Before going into the threat model, let's give a very brief and simple example on how GrapheneOS threat models for a single security feature:
- Firstly, we know the most dangerous threat the Android platform faces is remote exploitation of an unknown vulnerability, for example in targeted spyware campaigns. "Remote" means it can be attacked from a distance (i.e. from the Internet).
- Secondly, we know the majority of formerly unknown, exploited in-the-wild vulnerabilities on the Android platform happen via memory corruption. These vulnerabilities are about a weakness in software that allows it's memory assignments to be altered due to a software flaw. This flaw could then be abused maliciously because they can break out of security restraints due to the nature of allowing arbitrary code to be run.
- Finally, we know that memory corruption also makes up a majority of vulnerabilities in Android assigned CRITICAL and overwhelmingly make up the most dangerous in capability.
- Therefore, GrapheneOS should prioritize to deal with memory corruption flaws.
- So, GrapheneOS provides a hardened memory allocator, memory tagging, and additional hardening to remove attack surface involving memory unsafe code.
So now, let's go through this with more context:
Google's Security Blog reported that "Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language" and that in 2022, the year Android 13 released, was the first year where memory safety vulnerabilities did not represent a majority of vulnerabilities in Android. However, this does not paint the full picture on the severity of these bugs.
To understand what this means, memory means a type of storage on a computer for fast, volatile, temporary data for software to use, store (allocate), access and erase (free). Think of it quite literally like memories in your head you can immediately recall. In this case, operating systems and software store certain time-sensitive data about itself when in use to perform instructions faster. Programs are designed to allocate memory, which stores it in RAM to allow it to be used, and then free it, which erases it when it is not needed or programmed to be freed.
Memory safety is a term to describe protection against software flaws and security vulnerabilities relating to memory management. If code is not memory safe, it means it is vulnerable to certain types of security errors, here are two noteworthy examples:
- Buffer overflow: Memory being written beyond it's designed boundary which writes itself over other memory objects adjacent to it.
- Use-after free: Attempting to use memory that was previously allocated that is currently freed.
These two security bugs can be used to exploit software vulnerable to them if malicious code is written within memory or by taking advantage of unexpected behavior or bugs caused by corruption. Enforced memory safety stops programmers from introducing memory bugs that could lead to memory corruption vulnerabilities. Some programming languages (like Rust, Kotlin, Java) check for memory errors and are deemed memory-safe, while other languages like C do not, which makes them memory-unsafe.
In 2022, Google's Security Blog also reported that memory safety vulnerabilities represent a disproportionate amount of critical severity vulnerabilities. Depsite only representing 36% of all total vulnerabilities that year they represented 86% of critical vulnerabilities, 89% of remotely exploitable vulnerabilities and additionally made up around 78% of confirmed exploited in-the-wild exploits on Android devices since 2014 as per their zero-days "in the wild" spreadsheet. While this figure is subject to change, at the time of this video being produced, Memory corruption has been the cause for almost every in-the-wild Zero Day on not just Android but WebKit and Chrome.
https://security.googleblog.com/2021/01/data-driven-security-hardening-in.html
https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
Remotely exploitable vulnerabilities, such as code execution, allow attackers to have terrifying influence over their target's device, and memory corruption makes up a majority of exploits of this degree. They can allow breaking out of enforced security measures like the app sandbox, and because of the nature of the vulnerability allowing arbitrary code to be run, the attacker can design a payload to allow their target device to do whatever they need to meet their objectives. For most threat actors, surveillance is the objective for their attacks, and being able to do this remotely is sought after in the threat market because anyone who can get that capability is able to watch over anyone from any part of the globe as long as they have a network connection.
Physical attacks
Over the past year, GrapheneOS has looked at features and security enhancements for resistance against attacks from threats with hands-on proximity of the device. Forensics companies like Cellebrite, MSAB and Magnet are particularly interested in capabilities involving this scenario because their products are for clients who seize devices for the purpose of extracting data from them, like law enforcement agencies and governments.
Let's simplify the threat model approach again:
- Firstly, we were long aware of these companies selling capabilities of stock Pixel devices in the public. However, their attacks didn't work on GrapheneOS and Cellebrite and MSAB confirmed this back then, and today.
- Secondly, at the start of the year we discovered more details on how MSAB's capability for the stock operating system worked. We were able to infer they performed a reset attack thanks to a boot firmware wiping memory on unsafe reboots and factory reset bypasses. A reset attack is an attack involving dumping memory to get sensitive information like password information to crack the device. (Vulns assigned: CVE-2024-32896, CVE-2024-29745, CVE-2024-29748)
- Finally, after reporting the vulnerabilities upstream to Google and adding additional protections early to reduce window of opportunity of MSAB.
- Therefore, GrapheneOS should look at features protecting against attacks with proximity.
- So, GrapheneOS adds a duress password functionality and adds a USB-C port control feature to disable the USB-C port or it's data lines entirely when the device is powered on.
Third party threat / supply chain attacks
- Firstly, we were previously victim of an attempted hostile takeover attempt and escaped it, GrapheneOS is designed for this to not happen again.
- Secondly, we are aware of supply chain attacks allowing sophisticated and typical threats to push malicious updates of popular software to users to attack them.
- Finally, we are aware of the Pixel platform's features with protecting this.
- So, GrapheneOS uses them. Updates cannot be installed without being signed by GrapheneOS, even if the server is compromised, a bad update cant be installed.
- GrapheneOS provides no additional trusted parties by default beyond the OEM and GrapheneOS by having only connections to GrapheneOS and no bundled apps.
GrapheneOS is designed with minimal trust to prevent influence from third parties with regards to network services like update servers. It also takes advantage of the Pixel platform's "insider attack protection" in the Titan M2 secure element which prevents malicious upgrades of it's firmware from being uploaded without the device being unlocked first. This prevents seizing a device, maliciously upgrading it and trying to get a way in from exploiting the secure element.
GrapheneOS allows auditing the device from the Auditor app and also verifying the verified boot key hash on start-up in that appears in the install page.
Security of the GrapheneOS platform
GrapheneOS holds hardware security requirements for devices it supports. This is because GrapheneOS directly depends on the hardware for many major features like MTE, USB port controls, and throttling of device unlocks by a secure element. If GrapheneOS supported less secure devices and was compromised on those devices, there would be a preconcieved notion that it is a fault of GrapheneOS as a whole which doesn't help with reputation.
Contrary to popular belief, Pixels aren't the only supported device because they're the only device that has a relockable bootloader... there is a lot more to it. Here are some requirements most devices don't typically meet:
- Support for using alternate operating systems including full hardware security functionality
- Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they're released)
- Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
- Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that's completed
- Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
- Hardware memory tagging (ARM MTE or equivalent)
As of writing this only Google ever steps up to provide these features for users. And these requirements are important because functionality like this is what makes GrapheneOS a special offering.
Firmware security
I was asked about this on Nostr, so I will explain the answer for them, based on my GrapheneOS Forum post here.
Risks of malicious firmware are often overhyped and misunderstood. Even so, hardware components on GrapheneOS devices have to be isolated by an IOMMU. Hardware devices interface with the software through drivers, which is where the majority of the attack surface for most hardware components comes from. Therefore, drivers need to be designed securely and have it be treated by the OS untrusted. Drivers being so privileged in desktop OSes like Windows is what makes certain firmware attacks so dangerous in those platforms. The OS relies upon the hardware and firmware to be able to contain components, but ends up responsible for managing that because it has control over the configuration of shared memory and the attack surface from the complexity of the interface and the OS side implementation.
If a component has DMA access, that needs to be isolated and the driver must be designed to treat the shared memory as untrusted, as it would do with other data. OS security relates to hardware components like radios and the vast majority of the attack surface is in software, not hardware.
Many theories on malicious insiders and foul play are often unrealistic and too disconnected from the reality of real cases to the point it is completely made up. Attacks from firmware of hardware for commercial devices aren't widespread and provide questionable benefit for attackers beyond a persistence mechanism. They completely go against the utility of such a targeted attack by being widespread, as the success in such attacks in the past has came from how little people were attacked by it. The lesser the targets, the lesser the likelihood detection. Performing an attack this way is contradictory to the purpose of an attack.
Malicious firmware embedded or upgraded in hardware need an interface within the running software of the device to send information back to the threat is performing the surveillance, it doesn't provide much of a stealth benefit. Many cases of malicious firmware have a stage that involves using injecting malware in the operating system, and making connections to a server to perform the command and control stage of a cyber attack. This connection would be needed so the C2 could recieve instructions, or for the target device to send information about itself. It must add presence into the operating system to access data from it, which makes it detectable.
These connections or other indicators of compromise can and do be monitored and cybersecurity threat intelligence organisations use traditional forensics techniques to discover malicious firmware, the issue isn't down to how the target is performed, rather how small of an amount of people are attacked with it.
Take an example of CosmicStrand, MoonBounce, and MosaicRegressor - three examples of malicious UEFI firmware rootkits (also known as bootkits), these bootkits all share the same characteristics:
- The bootkit injects malicious software or exploits into the operating system on bootup,
- This malware makes a constant connection to a Command and Control server over the Internet, and
- The only purpose of the firmware in the attack chain is to enforce persistence (a consistent compromise of the target) during the attack.
The firmware have no direct idea on what operating system the device they are connected to is running, they have no ability to check the instructions that they are performing are actually working. What if you just ran an OS where this is just unable to run properly? What if you block the executables it generates? What if you block the C2 servers they connect to? They need an internet connection, and certain firmware alone can't do that. They depend on the software and the network it's connected with to allow it, which means there are many ways to prevent such abilities if they came up anyways.
Malicious firmware from the side of a malicious insider can still be very ineffective, how can you update and improve your operating system in a way that keeps the supposed backdoor functional for a long period of time, without breaking it when removing legacy code that may have unnecessary security vulnerabilities that get caught by the countless of groups? It would become a mess for the firmware developers and operating system developers to maintain.
An attack through this vector is also inefficient in comparison to just paying for a zero-click, remote full chain compromise attack for a few million dollars which gets you the same amount of information and requires less hassle and preparation to do.
These types of attacks are mainly limited to intelligence agencies and for what they may have in their arsenal in comparison, they are a extremely high-risk, but high-reward capability and requires taking extreme measures such as interdiction of a package with the target's device, performing a covert operation where they may need to sneak into their property undetected to get physical device access, or among other things.
We wouldn't trust a device we are confident had malicious firmware.
GrapheneOS and Me
Before I go into the post about GrapheneOS usage... every big post on here about GrapheneOS seems to make a small background about themselves, so I will put my situation here too.
I am a technical person but also an introvert. I am interested in certain defence roles like forensics but uncomfortable with how that area of the industry works. I'd never, ever want to be a cop. I am a person who chooses his own or makes his own if what I can pick from is not acceptable enough for me. I am heavily interested in digital security and privacy, however, I also frequently use software that would probably get me lynched on certain parts of the internet (including this one) but I don't care because you aren't me. I only use what satisfies me and my personal or security requirements.
I am not overkill in security or privacy practices unlike what some would believe. A lot of my actions are mainly a hobby or a research purpose instead, and I think a lot of what some people do is LARP-y and suggests a hidden incompetence. I only had to recently bump up my security requirements. Overall, I am uninteresting, and I don't believe I am worth the budget or time for my/a rogue nation. If I got hit with a stealthy cyberattack I am considering it a compliment. However, I do think I have higher requirements than most because of the assets I hold and
I don't need to make sacrifices on deleting something popular because I likely don't use it and also that I don't really keep my eggs in one basket. For example, YouTube is the most I've ever used Google for in the past 8 years. I don't use the other invasives that much either and most of my usage of certain platforms is just down to GrapheneOS chat content moderation.
When this post you're reading was published, I have been a GrapheneOS user for 5 or 6 years. I have observed the work for longer than that, but never had the chance to use it until I had a first device to run it a year later. Since then, I have been using GrapheneOS as a daily driver on three different generations of Pixels and I have had no regrets with it.
Why do I (or others) use GrapheneOS?
Because I like it, and that's all the reason you need. I could probably meet my same requirements with an iPhone and Signal, but security isn't limited to people who believe that they are targeted or that they need to have some big, extraordinary reason to use software. People use GrapheneOS as a tool for personal freedom or for some other reasons indifferent to mine or anyone else in the team.
"Degoogling" isn't really something we're focused on, even though we are likely more "degoogled" than other operating systems. We avoid that term in our project because we aren't removing Google apps and services for some ideological reason, they aren't bundled because we don't bundle any additional software like that and it is down to the user's choice to install them. I personally believe it can unintentionally write-off what GrapheneOS is about, since that being the first word they hear of could think GrapheneOS is just an Android OS free of Google rather than a mobile OS designed for security and privacy.
Other users may use GrapheneOS for other reasons, they may have been a victim of a targeted cyberattack, they may hold valuable information, they may have cryptocurrencies they want to protect. GrapheneOS helps with all of those things.
How does final use GrapheneOS?
I try and use GrapheneOS as a mostly ordinary person, I do use a SIM as I travel a lot. Although here are some standout behaviors:
- I use the Alpha channel for everything. This is not recommended for all users, but it gets me updates the fastest. You can individually choose to have some apps be updated through Alpha and not the OS.
- I mostly run apps closely built for GrapheneOS users in mind.
- I don't use the owner profile at all except for a VPN, everything is running in other profiles with unique credentials.
- I have duress password enabled thanks to an incident, my auto-reboot is set to 30 minutes and I have all exploit mitigations and security settings enabled by default, for things like DCL access or memory tagging, they are disabled for individual apps on edge cases.
- I use the Markup app installed in the App Store app, way better screenshot editor, try it!!!!
- I predominantly get my apps from Accrescent. Almost every app I use except for some edge cases which I update through other sources.
- I don't use the Play Services, I keep edge cases for my old profile.
What apps does final use?
The most important app for me is Molly, a hardened Signal fork I use to talk to the people around my person. It comes with improved battery optimisation when no Play Services are installed but also provides a database encryption feature to encrypt the message database. I also use other messengers like SimpleX when the phone number requirement is a non-negotiable.
Organic Maps is another important app, it's a perfect FOSS maps app that works offline. I also use it quite often and this app and Molly are both available on the Accrescent app store. For media I use InnerTune for music and Libretube to watch YouTube.
For LN I use Phoenix, no particular special preference. I just care about self-custody, it's quite maintained and just works for me! I use Amethyst as my Nostr client as that's what I used for a long time.
For security, I use Aegis as my 2FA manager and KeePassDX to manage passwords, I also use App Verifier to check legitimate apps as well.
I use Gboard with internet permissions disabled as a keyboard, since apps across profiles update globally, I have the Google profile responsible for updating it.
How would a high-risk individual use GrapheneOS?
These details should tell you that if you consider very well funded groups, like sophisticated adversaries with limitless physical access as a part of your threat model, then you should:
-
Use the most recent phone you possibly can
-
Upgrade your phone to the newest possible generation as soon as possible after release if you can help it.
-
Use the latest version of GrapheneOS ASAP. Do not delay.
-
Use a strong, high entropy passphrase to make bruteforcing the device credential impossible if secure element is ever exploited.
-
Set GrapheneOS auto reboot time accordingly so encrypted data goes back at rest when the phone reboots, which makes AFU exploitation impossible. The lower the better.
-
Enable duress password. Set it to something easy to trigger but not easy to misfire.
-
Turn your phone off in a high risk situation, and trigger duress when in a duress situation.
-
Disable your radios when not using them (turn off Wi-Fi, use airplane mode, disable NFC, UWB etc.) for attack surface reduction.
-
Set an appropriate USB port control or disable the USB port so they aren't able to connect a device to it.
-
Use user profiles (application data and user files within profiles are stored encrypted with separate credentials).
-
Enable upcoming GrapheneOS security features like second factor authentication unlock when they come out.
-
Communicate only over secure messaging. Some apps like Molly (Signal fork) have features to encrypt the app storage with a passphrase, which access to that app's data impossible even when a profile is compromised providing the passphrase is secure enough.
-
Become disassociated to data. Learn to only keep files or other data as long as it is necessary. If you have no use for them for a long time, then back it up elsewhere, encrypted. Delete anything you don't have a use for in the present. Your data is not your memories.
-
Remember that you are only as secure as the people you trust. If they do not meet your safety or security requirements, don't enable them to do things that could cause trouble.
Abrupt conclusion
So, I guess this is it... it's a super long post and I'd be surprised if anyone read these notes in one sitting, but, I am grateful to all of the GrapheneOS supporters and fans on SN and Nostr. I was one of you as well and I hope I can make content like this but for other subjects (and preferably, less rambling), but the quality of posting is you improve over time. I imagine the quality suddenly dropped halfway as this is a super long draft I slowly am losing my patience to read from top-to-bottom, hahaha.
After burning my keys, I am slowly coming to Nostr again on a new npub, check out my profile for that.
If you are wishing to read more about technical details of GrapheneOS I didn't provide, feel free to read my other posts:
Overview of new advanced hardening on GrapheneOS version 2024083100 and later:
#670170
REVEALED: Here's the Cellebrite Premium Device Support Matrix for July 2024: #616858
