Hi GrapheneOS I've been on GOS for near two years, and by next week will have flashed my 200th Pixel with GOS for clients. And I am just so greatful for GOS, but also for how you guys share information such as above. Just wanted to say thank you to the team for all you do for we the people. "Privacy is Dead! Long Live Privacy!"
VAULT
vmpas Pixel 9 has some security improvements but not a large improvement over the Pixel 8. Pixel 8 and later is a massive improvement over the prior devices when using GrapheneOS due to hardware memory tagging. Pointer authentication codes (PAC) and branch target identification (BTI) are nice minor features. PAC could be much more heavily integrated but currently isn't and MTE is far more valuable. MTE is a far better long term approach if they increased the tag sizes. PAC is a short term approach and requires a lot of case-by-case integration to get much value out of it.
There are still a few things unclear to me.
If FFS = Full Filesystem Extraction from an unlocked device, then what does BF: NO, FFS: YES suggest. They can extract filessystem without unlocking it or not?
Assuming BF: YES in AFU still has rate limits as you state it does, can you assume that a 6 digit pin would take long enough to crack that it would go over the GrapheneOS default 18 hours to reset to BFU / iOS 18.2 default 72 hours?
Why do they even list FFS in unlocked devices? Can't you do whatever you want to an unlocked device or am I missing something?
On iPhone 12-14 with iOS 17.5-17.5.1 does AFU mean that if it's in AFU mode they can unlock the phone?
FFS refers to extracting data when they have the PIN/password to unlock it already. Having an unlocked device doesn't mean you can extract all of the data from it. Their tool requires unlocking, enabling developer options (requires authentication), enabling ADB, authorizing ADB access from their tool and then uses unintended functionality in ADB to extract all of the data. FFS is their baseline capability which generally works everywhere as long as the user doesn't have a device admin app disabling ADB. They could far more easily exploit the OS after unlocking it but those aren't the kinds of exploits done by the Cellebrite Premium tool and would require something else.
BF refers to brute force attacks after they've exploited the devices, which implies also exploiting the secure element on devices providing throttling with one.
stopthefeds AFU means they can exploit the device in AFU and obtain nearly all the data from it even without the BF capability. They have a capability not listed in this table called IPR which was listed for previous versions of the table which enables them to obtain the PIN/password for iOS when they have the AFU capability. It's possible they support this on each version with AFU support now so they stopped listing it. The details of IPR are unclear and it seems it only works when the memory hasn't been reused for something else. It's definitely not supposed to be possible but iOS was or still is making a mistake enabling it. It may be fixed by now.
GrapheneOS Does closing a user profile put that profile back into BFU? Or it stays unencrypted?
stopthefeds Does closing a user profile put that profile back into BFU? Or it stays unencrypted?
Closing a secondary user profile unloads the encryption key, making all its data inaccessible, so is in some sense equivalent to BFU. But traces from the activity in that user profile may still exist, such as in system wide log files. Rebooting the device is the only way to be sure. Rebooting is also the only way to unload the encryption key for the owner profile or private space.
BFU (before first unlock) refers to a device that is powered off, or that has been powered on without any valid credentials yet provided at all. Rebooting or powering off the device is the only way to return it to BFU state.
stopthefeds Does closing a user profile
Using End session from the power button menu or the lock screen of a secondary user flushes the encryption keys from memory
https://grapheneos.org/features#end-session
stopthefeds It's back at rest in terms of the disk encryption. However, data can persist in memory in parts of the kernel, SystemUI, system_server and other system-wide software such as driver services. Our zero-on-free implementation in the kernel and userspace helps clear data as soon as possible but it won't clear something that's not released. @ryrona mentioned the in-memory log buffer which is one example. No sensitive data is supposed to be logged there but not all apps will respect that and the interpretation of what that means varies throughout the OS and apps. It's not the only example, just one of them. If you want to get back to a clean BFU state, you inherently need to reboot.
GrapheneOS If you were to recommend a phone that can resist electronic forensics, would you recommend an iPhone or a Graphene OS device? Does Graphene OS have any advantages over iOS in resisting electronic forensics?
I would recommend GrapheneOS - it is much more private (see: https://arstechnica.com/tech-policy/2025/01/apple-agrees-to-pay-95m-delete-private-conversations-siri-recorded/), autoreboot feature is much more customizable (and has it way before iPhone), and has also some other anti-forensic features.
On the other hand - Apple has more aggresive and more deceptive marketing, which seems pretty important for some people... :)
Zw10704 GrapheneOS is clearly doing better than iOS for this as shown by the data above and other information. Why would we recommend an OS being consistently successfully exploited over GrapheneOS which is consistently resisting it? Look at the information in the thread.
GrapheneOS Thank you for your answer. I have another question, why Samsung's Knox cannot resist Cellebrite forensics?
Zw10704 because it's marketing blabber that has successfully fooled government entities. For some points, see my and @other8026's reply here https://discuss.grapheneos.org/d/16901-what-is-your-opinion-on-samsung-xcover-7-5g-security-with-7-years-of-updates/15
Zw10704 Knox isn't a specific technical thing but rather Samsung's branding for a bunch of standard security features and a small number of low impact Samsung-specific features. Pixels have much better overall hardware, firmware and software security than Samsung devices along with supporting using GrapheneOS for a massive upgrade to privacy and security. Despite us not making the hardware, GrapheneOS uses hardware-based security features not used by either Galaxy or Pixel devices in addition to all the standard hardware-based security features used by the stock Pixel OS. Examples are hardware memory tagging in hardened_malloc and Vanadium for detecting memory corruption in production instead of only for development, pointer authentication codes in userspace rather than only the kernel, branch target identification throughout the kernel and userspace to cover what type-based CFI doesn't, hardware-based USB-C port control, etc. These examples show how GrapheneOS is not only a software-based security project but is also leveraging hardware security much more. Recommend reading through https://grapheneos.org/features, just bear in mind some recent features like 2-factor fingerprint unlock aren't included there yet and the amount of coverage on the page is not directly connected to the importance/impact.
In the early 2010's it was my understanding, through employee conversations, that both Cellebrite and XRY were assisted by handset manufacturers. This may have been merely port drivers, proprietary specs, or a plethora of other possibilities.
During this same time AT&T stores used Cellebrite devices for transferring data between a customer's old and new devices (typically in a back office).
Relevant today? Likely not, but still interesting.
Hi I am just curious to see where we are at with the security of iOS 18.2.1
Hello, I'm interested in this question, does it turn out that pixel 7 is no longer as safe as pixel 8 and newer before forensic tools?
