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.

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.

@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!

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

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

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

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

@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

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

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

@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: (@[email protected])

@[email protected] then please provide a list of said requirements so that manufacturers could actually comply to them... Thanks.

Infosec.Space

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

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

Thanks.

@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

@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!

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

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

@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?

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

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

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