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

matchboxbananasynergy

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.

spiral

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?

ev6x

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?

popsicleman

matchboxbananasynergy 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.

While I believe in transparency, if refraining from publishing original information protects sources and allows further improvements to GrapheneOS based on real-world exploits I think that is an acceptable tradeoff.

Question if it is ok to ask: I see in the "Android OS Access Support Matrix" that GrapheneOS is supported for BFU and AFU "up to late 2022 SPL". Is it known exactly what vulnerability was patched around that time?

I'm guessing that for AFU they're trying to exploit the running OS to gain code execution and/or read memory. However what are the implications of exploiting a device in BFU state? Because if my understanding is correct there is a limited amount of metadata or other information available in BFU up for grabs and the rest is protected by FBE which requires deriving the hardware backed encryption keys in conjunction with the users unlock password.

pizofreude

matchboxbananasynergy Kudos for the great summary. ☕

N1b

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

Hathaway_Noa

I uploaded all the necessary PDF files detailing their capabilities / release notes + how to use on the following link:

https://easyupload.io/m/t94ht1

With every new Cellebrite Premium / Inseyets updateI will upload the PDF files :)

stereo3441

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?

popsicleman

Hathaway_Noa Thank you for your service.

That site was rather difficult to download from. Is it ok with you if I mirror it somewhere that is hopefully less annoying and we can crosscheck the hashes of the files?

[deleted]

Matthai

Matthai Cellebrite specifically claims they have been able to extract plaintext iPhone passcode (Instant Passcode Retrieval) from AFU iPhone since A11

yes, source https://postimg.cc/gxNXN4MK

Matthai they are able to dump Secure Enclave RAM since A11

Hathaway_Noa I uploaded all the necessary PDF files detailing their capabilities / release notes + how to use on the following link:

https://easyupload.io/m/t94ht1

With every new Cellebrite Premium / Inseyets updateI will upload the PDF files :)

Because they're able to BF in BFU mode, it necessarily implies that they can bypass secure enclave's timing delay. This strongly implies that they have code execution on secure enclave because "the Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities"

Jostdis

Hathaway_Noa The link is dead.

Titan_M2

What happened with the late 2022 patch level?

GrapheneOS

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.

GrapheneOS

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.

fid02

An interesting and useful read. Sending you massive thanks for your hard work. 😊

GrapheneOS a new contributor we plan to hire.

Congratulations, fredu!

stereo3441

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.

VAULT

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

final

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

[deleted]

Is the google pixel tablet safe too?

matchboxbananasynergy

[deleted] The Pixel Tablet is essentially a 7th generation Pixel device. What applies to other 7th gen products like 7, 7 Pro, 7a and Pixel Fold should more or less apply to the tablet as well.

[deleted]

matchboxbananasynergy thank you! So should be good to go then

FiscalPixel

matchboxbananasynergy
Says pixel 6 and later, does this include 6a as it's not as powerful as the pixel 6?

Thanks

de0u

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.

GrapheneOS

ev6x They can extract more data than you're meant to be able to extract via ADB by escalating privileges there, but having the lock method already gives them nearly all the data directly by design unless there's no backup service included to get app data. They can access everything you can access once they have your lock method which at least indirectly gives them nearly all the data even without a backup service. Regardless, once they have the lock method, the attack surface is enormous and it's not very realistic to stop them at that point. They can install whatever apps they want, grant any permissions they want including special access permissions, accessibility services, etc. and a few development permissions only available via ADB. It isn't at all realistic to prevent an exploit by someone with that control over the device already. Secondary users that are at rest have their data safe from them based on the security of the lock method similarly to Owner when the device is at rest since their encryption keys are separate.

Panda-na

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 😄

GrapheneOS

Panda-na Other alternate operating systems aren't hardened and largely roll back security rather than improving it. DivestOS applies a portion of our privacy/security patches, but on top of LineageOS which rolls back security and DivestOS is focused on insecure devices. Cellebrite may still need to do some work in order to support them but it would generally be much easier for them compared to exploiting a stock OS device, not harder.

neel

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.