GrapheneOS

Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024.

404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.

Jul 21, 2024 at 7:12pmWeb
Show threadGrapheneOSJul 21, 2024
Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.
Show threadGrapheneOSJul 21, 2024
GrapheneOS is defending against these tools with generic exploit protections rather than by patching specific vulnerabilities. Until recently, it's likely that it was our generic memory corruption exploit mitigations including hardened_malloc which was successfully stopping this.
Show threadGrapheneOSJul 21, 2024
In February 2024, we added a new feature for disabling the USB-C port at a hardware level. In March 2024, we set the default mode to "Charging-only when locked, except before first unlock". In June 2024, we increased the default security level to "Charging-only when locked".
Show threadGrapheneOSJul 21, 2024
Later in June 2024, we extended our software-level USB protection, merged it into the newer hardware-level protection feature and extended the hardware-level protection to pogo pins on the Pixel Tablet. There's extremely strong protection against these USB-based attacks now.
Show threadGrapheneOSJul 21, 2024
Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for overall Android devices. Other than the Titan M2 on the Pixel 6 and later not being successfully yet to bypass brute force protection, it's largely just based on what they've had time to support.
Show threadIlias 🤓Jul 21, 2024

@GrapheneOS

So if im correct:

Modern iPhone with latest IOS:
- After first unlock extraction is possible.
- Before first unlock extraction (partially) possible.
- Brute force NOT possible.

Modern Pixel with latest GrapheneOS:
- After first unlock extraction is NOT possible.
- Before first unlock extraction is NOT possible.
- Brute force NOT possible.

Modern Pixel with latest Android:
- After first unlock extraction is possible.
- Before first unlock extraction (partially) possible.
- Brute force NOT possible.

Show threadGrapheneOSJul 21, 2024

@ilias

Yes, but they can develop new exploits, so there is more to consider.

GrapheneOS users have auto-reboot enabled by default which gets the device to BFU from AFU automatically, so GrapheneOS users don't have to worry about future AFU exploits for a device obtained by an adversary in the past.

A strong passphrase avoids relying on the iPhone/Pixel brute force protection. It's holding up against Cellebrite right now, but not necessarily against the US government using hardware tampering.

Show threadGrapheneOSJul 21, 2024

@ilias

Our upcoming 2-factor fingerprint unlock feature will help our users avoid relying on the secure element. GrapheneOS users will be able to use a strong passphrase for primary unlock and fingerprint+PIN for secondary unlock to avoid the usual drawbacks of biometric unlock. For this purpose, a 4 digit PIN will be fine since there are only 5 overall attempts. We hope it's usable enough that a large portion of our users end up moving to it. This will combine very well with auto-reboot.

Show threadIlias 🤓Jul 21, 2024

@GrapheneOS
Thank you.
I'm now interested to know what happened after the 2022 SPL update.

And do we know which data is (partially) extractable after first unlock on stock Pixel Android and IOS?

Show threadGrapheneOSJul 21, 2024
@ilias It's known for Pixels because it's easy to check what's stored in device encrypted data. We could provide a toggle for making the Owner password into a boot password protecting more of the data but it would be fairly hard to implement and quite invasive so we haven't done it yet. This wasn't one of our focuses until recently. We were focused much more on defending against remote attacks and security/privacy from apps. Since January, we've been working on defending against this a lot too.
Show threadGrapheneOSJul 21, 2024
@ilias The 2022 issue is likely the SIM PIN lockscreen bypass. It didn't give much access for Before First Unlock state but it did open up a lot more attack surface and they could have used another exploit. We patched this before the stock OS, but we could have patched it much earlier than we did. We didn't want to risk releasing a partial fix for an issue an in doing so exposing people to it being exploited. We could have fixed it a few months before we did, but we can't change that now.
Show threadGrapheneOSJul 21, 2024
@ilias We thought they were going to take it seriously and get it fixed within 2-3 months with their much greater resources. We eventually ended up fixing it early because it was taking them so long. We were very disappointed in them taking around 10 months to fix this since the initial report. They've gotten better at dealing with stuff like this since then, but they need to improve more. It should be possible for them to fix this kind of thing in days or at least weeks, not months.
Show threadGrapheneOSJul 21, 2024
@ilias We have no idea if Cellebrite was exploiting it before it was publicly disclosed as part of Google patching it. They may have developed an exploit based on it after it was publicly disclosed. We don't have the historical documentation. At least 3 people found it independently before disclosure: a Google engineer, one of our developers and another security researcher. Indicates that it was not particularly hard to find. Not clear why they didn't prioritize and fix it faster.
Show threadIlias 🤓Jul 21, 2024
@GrapheneOS Thank you for the explanation and information. And thank you for your work!
Show threadJan TurowskiOct 17, 2024

@ilias @GrapheneOS

Sorry if this is a noob question: Does it make a difference if you manage to wipe the device (remotely) before forensics gets to copy the data or are there tools to retrieve the data anyway?

Show threadIlias 🤓Oct 17, 2024
@trochi @GrapheneOS
GrapheneOS does not have an option to wipe the device remotely. But in theory if you wipe a device remotely it's connected to the internet so it is in AFU (after first unlock) state.
Show threadJan TurowskiOct 17, 2024
@ilias @GrapheneOS
I see! So what about locally right before you lose posession over your device: How unlikely that may be, would that make a difference?
Show threadGrapheneOSOct 17, 2024

@trochi @ilias On GrapheneOS, if the device is wiped, all data from storage is immediately not recoverable right after the factory reset starts due to wipe-without-reboot support which was also implemented upstream in Android 14 QPR3 onwards and then later backported as an Android Security Bulletin patch.

GrapheneOS has the standard device admin wipe API and this uses the standard wiping with wipe-without-reboot support.

We also have extra improvements to wipe-without-reboot in GrapheneOS.

Show threadGrapheneOSOct 17, 2024

@ilias @trochi GrapheneOS has the standard device admin API for wiping the device which can be used to wipe the device remotely. However, it's standard operating procedure to put a phone in a faraday bag.

The device does not have to be in AFU mode to wipe it remotely, a device admin app can support running in BFU via direct boot support. However, why would the device be allowed to be on and connected to the internet for the proposed threat model?

Show threadGrapheneOSOct 17, 2024
@trochi @ilias None of the data can be recovered after wiping, with multiple things guaranteeing it. We improved this with wipe-without-reboot support which we got them to implement upstream which gets the device irreversibly wiped before a factory reset reboots it to recovery to wipe/format. You can also use our duress PIN/password feature which you can see in the unlock settings on GrapheneOS. You can use a device admin app if you want more wipe triggers.
Show threadGrapheneOSJul 21, 2024
In January 2024, we reported several vulnerabilities being exploited by the XRY tool from MSAB to get data from Android devices including stock OS Pixels. In April 2024, Pixels shipped a reset attack mitigation we proposed preventing the whole attack vector. We plan to expand it.
Show threadGrapheneOSJul 21, 2024
Currently, non-Pixel devices are still vulnerable to these reset attacks. In June 2024, Android 14 QPR3 included another feature we proposed providing wipe-without-reboot support for the device admin wipe API. We shipped this early and use it in our duress PIN/password feature.
Show threadGrapheneOSJul 21, 2024
We also began triggering a full compacting garbage collection cycle in system_server and SystemUI when the device is locked based on info about these attacks. This releases memory for no longer allocated objects to the OS, where our generic zero-on-free feature clears all of it.
Show threadGrapheneOSJul 21, 2024
In the near future, we plan to ship support for adding a PIN as a 2nd factor to fingerprint unlock to enable users to use a strong passphrase combined with PIN+fingerprint secondary unlock for convenience. We have an initial implementation, but it needs more work before shipping.
Show threadGrapheneOSJul 21, 2024
We're going to continue advancing the state of the art for protection against exploitation. Hardware vendors are welcome to collaborate with us if they want to protect users. We're regularly filing vulnerability reports and making suggestions to improve the security of Pixels.
Show threadGrapheneOSJul 23, 2024

Glossary:

BFU: Before First Unlock exploitation of OS
BF: Brute Force password after BFU exploitation, which requires bypassing secure element brute force protection if implemented
AFU: After First Unlock exploitation of OS
FFS: Full Filesystem Extraction from an unlocked device

Show threadGrapheneOSJul 23, 2024
BF capability does not bypass hardware-bound key derivation, so a brute force is still rate limited but no longer has an extremely small number of attempts. Cellebrite Advanced Services may be able to bypass this through extracting data from hardware, but it would be difficult.
Show threadGrapheneOSJul 23, 2024
BF implies ability to bypass random 6 digit PINs. It does not imply ability to bypass a decent passphrase where hardware-bound key derivation slows them down too much. A truly strong passphrase is safe even if they bypass hardware-bound key derivation and use a huge server farm.
Show threadalihan_bananAug 25, 2024
@GrapheneOS i love using my pixel with graphene os 😍
Show threadaaJul 21, 2024
@GrapheneOS mind clarifying all of these acronyms? from what I can tell AFU is unlocked file based encryption and BFU is locked file based encryption but I can't tell what BF is
Show threadGrapheneOSJul 21, 2024

@aa

After First Unlock
Before First Unlock
Full Filesystem Extraction
Brute Force

Cellebrite appears to be able to get the iOS lock method as part of their AFU exploit and uses that to obtain the small subset of data meant to be kept at rest while locked After First Unlock so they're not differentiating between those iOS data classes because they've defeated the whole purpose of those data classes. Hopefully, Android's upcoming implementation actually works properly. We'll see.

Show threadOrca 🌻 | 🎀 | 🪁 | 🏴🏳️‍⚧️Jul 21, 2024
@GrapheneOS @aa Does "Full Filesystem Extraction" require unlocked phones?
Show threadGrapheneOSJul 21, 2024

@Orca @aa

It requires an unlocked device, but their BFU or AFU exploits provide an unlocked device.

BFU exploit requires BF (Brute Force) to provide a fully unlocked device which they lack on Pixel 6 or later / iPhone 12 or later at the moment. A strong passphrase prevents it.

Show threadParaplegic RacehorseJul 22, 2024

@GrapheneOS

What happens if GraphenOS leads a coalition of AOSP projects in a lawsuit against #Cellebrite (and others) on DMCA 1201 anti-circumvention grounds?

Show threadGrapheneOSJul 22, 2024

@paraplegic_racehorse

Cellebrite isn't the only company building these kinds of exploits and governments around the world want these capabilities so they're going to get them built. We work on securing against it through technical measures rather than trying to stop it with legal or political action. It's simply not what we do. We'll defend ourselves as an organization and our team members as individuals when they're attacked but this is something we need to address with technical measures.

Show threadHannahJul 22, 2024

@GrapheneOS I love how they phrase it as "YES, with a caveat" instead of the more accurate "NO, except for very old versions".

Thanks for the great work. Having learned how cheap Cellebrite is, it is probably a real threat to anyone who is at risk of being hassled by law enforcement.

Show threadKevin Karhan Jul 27, 2024

@GrapheneOS Still I'd not trust on this staying the same forever.

Also #Cellebrite as a #Govware vendor needs to be criminalozed for their #malware alone!

Show threadGrapheneOSJul 27, 2024
@kkarhan We've made huge improvements to the security of GrapheneOS against these atttacks in 2024. They should be forced to use a different attack vector than USB for locked GrapheneOS devices now such as Wi-Fi, Bluetooth or cellular. It's entirely possible they'll figure out a way to exploit it, but they might not ship it in the Cellebrite Premium tool if it can't be done via USB. We certainly don't think that they can't exploit GrapheneOS, but it'll be a lot harder for them to do it now.
Show threadGrapheneOSJul 27, 2024
@kkarhan We plan to dedicate significant effort to hardening against lockscreen bypasses within the UI. We'll likely disable lockscreen camera access by default at least for fresh installations as part of this, among other things. We could also consider enabling a Wi-Fi and Bluetooth timeout by default, although auto-reboot is a more complete way of dealing with the whole thing.
Show threadKevin Karhan Jul 27, 2024

@GrapheneOS consider a "suicide code" that literally if enabled, configured ans entered as lockscreen pin/password will allow users to destroy their device and it's storage content by wiping the headers needed to decrypt the data if not short the battery.

  • Same with i.e. fingerprints being used to unlock triggering said "device suicide", makibg it way more practical for users to deny access and enforve their #HumanRight to remian silent if shooting the flash chip into pieces isn't an option!

If it didn't require basically engineering an entire new mainboard, I'd suggest to go full asshole on those #Govware machines and literally run a #USBkiller against that #Cellebrite garbage.

Show threadGrapheneOSJul 27, 2024

@kkarhan We already have a duress PIN/password feature which wipes the device nearly instantly without requiring a reboot to recovery. It does it when you enter the PIN/passphrase in any place the OS requests it, not just the lockscreen.

It's too easy to enter a fingerprint by accident. We have a 2-factor fingerprint feature in development and you'll be able to enter the duress PIN as the special PIN requested after the fingerprint is accepted before the device is unlocked.

Show threadKevin Karhan Jul 27, 2024

@GrapheneOS good.

Now I just need to find a device that you support that isn't a gued-shut & unrepairable mess with real #DualSIM, #MicroSD & #HeadphoneJack...

I really wished you'd support #shift and #Fairphone|s...

Show threadGrapheneOSJul 27, 2024

@kkarhan Those are insecure devices which are missing many of our security requirements. They're missing what we need to provide protection against exploits Cellebrite and similar companies.

https://grapheneos.org/faq#future-devices

The devices we support do have real dual SIM. eSIM is increasingly the norm and they support either physical SIM + eSIM or dual eSIM. GrapheneOS has perfectly usable eSIM support included.

The devices we support have USB-C digital audio output along with DisplayPort alternate mode.

GrapheneOS Frequently Asked Questions

Answers to frequently asked questions about GrapheneOS.

GrapheneOS
Show threadGrapheneOSJul 27, 2024

@kkarhan There's no point in waiting for us to support devices not meeting even basic security requirements. It's never going to happen. If there was a device missing only a couple minor features we could consider removing them as hard requirements, but we're certainly not going to remove any of the important features.

Both of those phone brands are missing even proper security patches for firmware/drivers which would impact GrapheneOS too. A large portion of that list is missing for them...

Show threadGrapheneOSJul 27, 2024
@kkarhan You'll need to talk to Fairphone rather than us if you want them to make secure devices. We don't think that's going to happen and it would be a waste of effort. It's more likely that a vendor like Samsung will work with us and make major improvements to security than a tiny vendor without the resources to implement what we require and which clearly doesn't prioritize security meeting our standards.
Show threadKevin Karhan Jul 27, 2024

@GrapheneOS I mean if you have an actual laundry list of points to do then I'm shure they could do it...

  • Whether #Fairphone or #shift or anyone else does follow through on those is a different story, but I'd rather not rely on #Google as sole source of supported devices cuz nothing obligates them to enable yozmu if not allowing then to actively prevent #GrapheneOS being flashed if not brick existing installations (like #Sony did with he #OptherOS aka. #YellowDogLinux on the #PS3)...
Kevin Karhan :verified: (@kkarhan@infosec.space)

@GrapheneOS@grapheneos.social then please provide a list of said requirements so that manufacturers could actually comply to them... Thanks.

Infosec.Space
Show threadGrapheneOSJul 27, 2024

@kkarhan There's already a list available at https://grapheneos.org/faq#future-devices which we've linked to you above. Neither company you've brought up appears to prioritize security and it's not a matter of us providing them with a list of requirements. These are nearly all quite standard security features and any company wanting to compete with iPhone and Pixel security would need to implement it.

Pixels are the AOSP reference devices and officially support installing another OS. It doesn't void warranty.

GrapheneOS Frequently Asked Questions

Answers to frequently asked questions about GrapheneOS.

GrapheneOS
Show threadGrapheneOSJul 27, 2024
@kkarhan If you're going to bring up trustworthiness of these companies, why are you proposing devices made by a company working with scammers involved in attacks on the GrapheneOS project? Fairphone has also never acknowledged multiple security issues reported to them because they didn't get media coverage...
Show threadKevin Karhan Jul 27, 2024

@GrapheneOS then please provide a list of said requirements so that manufacturers could actually comply to them...

Thanks.

Show threadGrapheneOSJul 27, 2024
@kkarhan We already linked you to our official list of requirements at https://grapheneos.org/faq#future-devices. This is not absolutely everything that's required and it focuses on what's missing on a lot of devices. It doesn't state lots of very obvious things provided by most devices.
GrapheneOS Frequently Asked Questions

Answers to frequently asked questions about GrapheneOS.

GrapheneOS
Show threadKevin Karhan Jul 27, 2024

@GrapheneOS It's just that I hate #eSIM as I'm used to swap SIMs.

If I want eSIM I can get a reprogrammable eSIM card.

Personally I'd just wosh the folks at #shift and #fairphobe would work with you to get those security issues fixed.

And no, I can't stand #USBc dongles as a matter of principle, because there is no good reason for a phone to not have a #HeadphoneJavk when #Sony even made Smartphones that were #watertight that had them!

Show threadGrapheneOSAug 1, 2024

@kkarhan

> It's just that I hate #eSIM as I'm used to swap SIMs.

You can have a physical SIM and 2 eSIM, with two used at the same time. eSIM is nearly entirely superior and uses a higher quality secure element included in the phone... It is superior from a user perspective and only inferior from a carrier control perspective. Not clear why you don't like it.

> Personally I'd just wosh the folks at #shift and #fairphobe would work with you to get those security issues fixed.

They won't.

Show threadGrapheneOSAug 1, 2024
@kkarhan Fairphone and Shift have made it quite clear over the years that security is not a priority for them and that they have no plans to even provide the basics let alone meeting the requirements for GrapheneOS. You're suggesting starting from devices where the vendors don't even provide the basics of security by shipping all the updates properly and providing the standard Android hardware-based security features. They do not need a partnership with us to know they should ship these things.
Show threadExerra Aug 1, 2024

@GrapheneOS @kkarhan

It is superior from a user perspective and only inferior from a carrier control perspectiveI suppose it is a lot better if you use just one eSIM and don't switch phones a lot, however if you do I imagine it introduces a larger risk while transferring data between devices and certainly limits what devices you can use (e.g. can't use older devices that don't support it, or maybe even modern flip phone styled devices).

Also, how does eSIM reduce carrier control?

Show threadGrapheneOSAug 1, 2024

@exerra @kkarhan

It runs in a secure element provided specifically for this purpose instead of putting a secure element from the carrier into your device. The carrier is forced to trust a secure element they don't control. Not all of them are fans of this.

Easy eSIM transfer does exist but isn't universally supported yet. You can always just have a new one issued.

Show threadExerra Aug 1, 2024
@GrapheneOS @kkarhan What does that mean in practice? In layman's terms, what kind of control do carriers actually lose?

From what I understand the only real drawbacks for a carrier is that it is easier to switch away from them, however that is also a big plus for cheaper carriers. Also, if they wanted to reissue a SIM, all they then will have to do is just show a QR code on their dashboard.

Another big upside is reduced operational costs as they don't need to order physical SIM cards for their local branches.

If a carrier wanted to refuse service to you, they don't need to do anything to your SIM, all they have to do is just refuse connections on their end.
Show threadGrapheneOSAug 1, 2024

@exerra @kkarhan

Mainly that they don't control the SIM hardware but rather the secure element in the device has to be trusted by them. A physical SIM and eSIM are both well isolated but in theory they could do something shady with a SIM since it's their hardware.

The attack surface for the OS, etc. is similar either way. However, if they have a piece of hardware you're inserted into your device and carry with you that's placing a somewhat higher level of trust in them regardless.

Show threadJohnAug 10, 2024
@GrapheneOS The German police tried to read my Pixel 6 device in BFU mode with the help of Cellebrite. They actually didn't succeed. I got my device back after 4 months. Thank you GrapheneOS developers for your work.
Show threadApicultor 🐝Aug 28, 2024

@GrapheneOS Does this mean an A12-powered iPhone with 17.5 in BFU will yield only what is listed here?

https://cellebrite.com/en/what-can-be-recovered-from-bfu-data-collection/

Do you have info covering 17.6.1?

Show threadGrapheneOSAug 28, 2024
@apicultor With Cellebrite Premium, yes. They potentially have better exploits for the secure element as part of Cellebrite Advanced Services, that's not clear.