• Announcements
  • Claims made by forensics companies, their capabilities, and how GrapheneOS fares

Twitter / X: https://x.com/GrapheneOS/status/1791833221165965567
Mastodon: https://grapheneos.social/@GrapheneOS/112462756293586146
Bluesky: https://bsky.app/profile/grapheneos.org/post/3ksrjdx6oj62c


XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.

Cellebrite's list of capabilities provided to customers in April 2024 shows they can successfully exploit every non-GrapheneOS Android device brand both BFU and AFU, but not GrapheneOS if patch level is past late 2022. It shows only Pixels stop brute force via the secure element.

[Pictures of Cellebrite capabilities for Android devices below]

https://grapheneos.social/system/media_attachments/files/112/462/757/183/372/025/original/992254912340eeaf.png
https://grapheneos.social/system/media_attachments/files/112/462/757/581/168/086/original/a2c40bcc6a083183.png

Cellebrite has similar capabilities for iOS devices. This is also from April 2024. We can get the same information from newer months. In the future, we'll avoid sharing screenshots and will simply communicate it via text since to prevent easily tracking down the ongoing leaks.

[Pictures of Celebrite capabilities for Apple products below]

https://grapheneos.social/system/media_attachments/files/112/462/760/076/651/069/original/abb6bfdb2d3cbc6a.png
https://grapheneos.social/system/media_attachments/files/112/462/760/480/507/923/original/eaff65050cbc6d1c.png

Pixel 6 and later or the latest iPhones are the only devices where a random 6 digit PIN can't be brute forced in practice due to the secure element. Use a strong passphrase such as 6-8 diceware words for a user profile with data you need secured forever regardless of exploits.

Pixels are doing a bit better on the secure element front and iPhones are doing a bit better against OS exploitation, but not by much.

As always, this shows the importance of our auto-reboot feature which gets the data back at rest after a timer since the device was locked.

Our focus in this area is defending against exploitation long enough for auto-reboot to work. It's set to 18 hours since the device was locked by default, but users can set it as low as 10 minutes. Since around January, we massively improved security against these attacks.

By default, our recently added USB-C port control feature disallows new USB connections in AFU mode after the device is locked and fully disables USB data at a hardware level once there aren't active USB connections. Users can set it to also do this in BFU or even when unlocked.

Users with a high threat model can fully disable USB including USB-PD/charging while the OS is booted to only allow charging while powered off or booted into the fastboot/fastbootd/recovery/charging modes.

GrapheneOS on 8th gen Pixels is ideal due to hardware memory tagging.

Consent-based data extraction (FFS) is not in the scope of what we're trying to defend against beyond shipping our secure duress PIN/password implementation to replace insecure approaches via apps. Data users can backup is inherently obtainable with consent, which is nearly all.

Within the past 24 hours, there has been an attack on GrapheneOS across social media platforms misrepresenting consent-based data extraction as GrapheneOS being compromised/penetrated. The person doing it is pretending to be multiple people and falsely claiming we covered it up.

GrapheneOS is the only OS having success defending against these attacks. We could do more with a successful hardware partnership such as having encrypted memory with a per-boot key instead of relying on our kernel memory zeroing combined with auto-reboot and fastboot zeroing.

New versions of iOS and Pixel OS often invalidate their existing exploits, but devices in AFU are stuck in AFU mode waiting for new exploits.

Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this.

If you wonder why duress PIN/password is taking so long, it's because we aren't doing it for show like existing implementations. It needs to work properly and guarantee data will be unrecoverable with no way to interrupt it. Slowly rebooting to recovery to wipe isn't acceptable.

See https://grapheneos.social/@GrapheneOS/112204428984003954 for our thread covering the firmware improvements we helped get implemented in the April 2024 release for Pixels. It doesn't currently really help the stock Pixel OS because they haven't blocked the OS exploits that are being used yet but it helps us.

Our hope is that our upcoming 2-factor fingerprint unlock feature combined with a UI for random passphrase and PIN generation will encourage most users to use a 6-8 diceware word passphrase for primary unlock and fingerprint + random 6-digit PIN for convenient secondary unlock.

    Thank you for such ongoing summaries. It takes time to get the main points across this well, and it's very much appreciated!!!

    What happened with the late 2022 patch level?

    matchboxbananasynergy Random 6 digit PIN is only secure on a Pixel/iPhone and only due to secure element throttling. Use a strong passphrase to avoid this.

    Is this implying that iPhones have some sort of secure element throttling? If so, which iPhone models?

      spiral They've had it long before Pixels but it's been getting bypassed. These companies are successfully bypassing secure element throttling from Apple for years along with the recent Samsung and more recent Qualcomm implementation.

      Pixel 2 introduced this for Pixels, with an NXP secure element, Pixel 3 moved to a custom ARM secure element. Pixel 6 moved to a custom RISC-V secure element a while after the launch of the OpenTitan project Google is heavily involved in that's developing open source RISC-V secure elements. Moving away from the standard ARM Cortex secure element cores appears to have blocked these companies from successfully exploiting the secure element for several years. That's a huge success since these companies have a lot of resources and are heavily targeting Pixels due to their widespread use among people who want private phones, far beyond this kind of privacy community. iPhones having far more overall users doesn't necessarily mean they care about them more. They'll likely eventually find a way to exploit it, which is why it's a good idea for people to use a strong passphrase.

      Our 2-factor fingerprint unlock feature will allow people to combine a strong passphrase with convenient fingerprint+PIN unlock to get the best of both worlds. We expect that to massively increase the proportion of our users using a strong passphrase, especially when we add our planned UI for generating random passphrases automatically where it can give you a few choices and you pick the one you like.

      They're successfully bypassing the secure element throttling on 2nd through 5th generation Pixels. Titan M2 has held up so well that it appears they didn't have a working exploit for it at any point, so they can't even brute force a random 6 digit PIN on a Pixel 6 with the initial release of the OS shipping with the device. They're likely only trying to attack the latest firmware version, so unless they succeed at some point they won't end up with the capability even for older devices. It would be a waste of their resources to develop exploits which only work against older OS/firmware versions. These companies are likely quite unhappy with the recent improvements we got done upstream for Pixel firmware in the April release but they still haven't added enough OS level hardening to defeat their reliable AFU OS exploits even temporarily. You can see the latest iOS has made changes which require them to make adjustments, which they'll likely get done pretty quickly, but they appear to have an easier time stock Pixel OS.

      GrapheneOS does far more hardening than iOS against these attacks so the results make sense. We also have auto-reboot so even if they do develop a successful exploit, their window of opportunity to use it to get data from user profiles is 18 hours from when it was locked, or significantly less if users lowered the value which can go as low as 10 minutes. Our new USB-C port control feature is also a really big deal for this. We became aware of them specifically targeting GrapheneOS and have been focusing on improving things as much as we can as one of our highest priorities. Duress PIN/password was delayed since we focused on anti-exploitation approaches benefiting everyone first, but it'll ship soon, as will the 2-factor fingerprint unlock feature which surprisingly is close to done due to a new contributor we plan to hire.

        I'm very excited for the prospect of a secure diceware passphrase generation UI for user lock screen. Do you have any information on what wordlists will be used, minimum passphrase size, or a simplified entry screen. Where if GrapheneOS knows it generated a secure passphrase for the user it might search the list as letters are typed and autofill the word or offer suggestions for words that match the entered prefix?
        Endless thanks for all the hard work and careful thought you put into GrapheneOS.

        Best read of the day :] We the users of GOS are so grateful!!

        Hathaway_Noa Thank you for your contributions to the community and the enlightening info you provided. Do you know how supersonic BF differs from regular BF on iOS?

          matchboxbananasynergy XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.

          So this feels like a dumb question. But I fail to see -- probably due to my lack of technical understanding -- how that is supposed to be noteworthy (by XRY and Cellebrite)? It just sounds like the equivalent of "we have the key to the door so we're able to enter and look around". Like no shit Sherlock. Am I missing something vital here or is this just marketing fluff?

            This is very fascinating! Since the graphic shows a list of phones with stock OS, and a table with GrapheneOS specifically, does this mean that GrapheneOS is the only alternative OS that can be a match against XRY and Cellebrite? I know very well that the GrapheneOS team is doing amazing security work, but to see it like this? It seems like XRY/Cellebrite is threatened by the existence of GrapheneOS 😄

              ev6x How that is supposed to be noteworthy (by XRY and Cellebrite)?

              It's one thing for somebody to have a way to extract data from a phone. For the data to be used in court proceedings it is important to claim a chain of custody from the device as obtained by law enforcement to the screen shot (or other evidence) appearing in testimony. If an officer testifies that a generally-accepted tool was used, that helps.

              stereo3441 Cellebrite says Supersonic Brute Force is about 40x faster than the traditional brute force speed.

              This news makes me glad I swapped my SIM back to my Pixel 8 running GrapheneOS.

              OnePlus does a really good job with hardware but OxygenOS is kinda gimmicky and OnePlus phones are too big anyways.