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

General
1

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 GrapheneOS: "April release of the Pixel boot chain firmware in…" - GrapheneOS Mastodon 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.

GrapheneOS is your best choice if you really need security, and the consequences are high.

11 Likes
2

And avoid all phones other than the Pixel and iPhone. It’s terrible that other Android phones are so insecure.

10 Likes
3

AOSP is more secure than windows, but way less private because of chinese manfacturers.

4

What does AOSP have to do with Chinese manufacturers? Chinese manufactured phones have their own operating systems, such as MIUI, OxygenOS, HarmonyOS, etc.

2 Likes
5

They are all AOSP based, so security is similar.

6

No, neither the privacy nor the security of these operating systems are similar to AOSP.

2 Likes
16

I am not sure i understand this correctly, but why is the brute force resistance of stock pixel being mentioned if it is vulnerable to BFU extractions even if it’s locked?

Edit: I think they can extract data but it’s encrypted and they still need the phone password to decrypt?

17

@whoami5

A bit on the long side but informative

2 Likes
19

My understanding, and hopefully someone can correct me if I’m wrong, is that for Pixel’s and iPhone’s with Secure Enclave that the decryption key is held within the Secure Enclave hardware on the phone. The phone password authenticates to the Secure Enclave to release the real decryption key to the OS. In a BFU situation the data downloaded would still be encrypted with the long, complex, and random key generated by the Secure Enclave. This means they would be brute forcing a nearly impossible target. It would be like intercepting a Signal message and trying to brute force the 256 AES encryption.

In AFU, the decryption key has been released to the OS and is only protected by the device password. An AFU file extraction therefore merely needs to brute force the phone password/PIN and not the far more complex Secure Enclave. Thus a six digit pin will be cracked in moments. However, a complex alpha numeric password would be far harder to crack so the ultimate protection for your data will be the strength of the password for your device in an AFU file extraction situation.

Again this is my understanding and look forward to correction/further nuance from more knowledgable posters.

3 Likes
20

You data is encrypted in BFU state and decrypted in AFU state.

1 Like
22

Re-More Info

23

But the BFU protections only apply to Pixel 6 or newer and iPhones according to the cellebrite slides ?

24

https://telefoncek.si/2024/05/2024-05-30-grapheneos-and-forensic-extraction-of-data/

GrapheneOS and forensic extraction of data

2 Likes
25

I would presume for Pixel this is due to the use of the Google designed Titan chipset on Pixel 6 where as earlier Pixels used Qualcomm that did not have the Secure Enclave-like functions iPhone’s have had since I believe iPhone 6.

26

The Titan M was present from Pixel 3 up to Pixel 6, where it was replaced by the Titan M2.

1 Like
27

Thank you for the correction!

1 Like
29

Virtual machine escapes don’t cost shit compared to Android RCE Zero Click exploits, but you’re free to keep your head in the sand and believe that desktop OS’s are the most secure.

2 Likes
30

You can just look at cost of exploits for desktop operating systems vs android and ios. It’s not even close. And if I’m being honest, so few people even use Qubes that I don’t think they even bother trying to find exploits for it. Not saying it’s not secure vs a standard desktop linux machine but I don’t think there’s the same level of scrutiny.

2 Likes
31

This is incorrect. The key is not held in secure element but rather key encryption key is derived from the lock method and the secure element is used to throttle the derivation of the key.

That isn’t the case. Rather, the NXP secure element that was used on the Pixel 2 and Titan M1 seem to have been successfully exploited by Cellebrite just like how they exploited the secure elements in iPhones. iPhone 12 and later has an additional protection within the secure element where exploiting the secure element itself isn’t enough to bypass this, that’s why it started holding up. Samsung has secure elements using standard ARM cores too but they are bypassing that. It doesn’t mean Pixel 5a and earlier or very recent Samsung phones lack secure element, it just means they’re exploiting it.

Pixel 2 added a secure element, but a much less secure standard NXP one.
Pixel 3 moved to a custom ARM-based one with a standard ARM secure core (Titan M1).
Pixel 6 moved to a fully custom RISC-V design based on OpenTitan (Titan M2).

The Titan M2 (used since 6th generation Pixels) appears to be blocking the secure element getting exploited by Cellebrite so far. It is not unlikely that it will eventually be exploited as well despite it holding up for a very long time already, which is why if withstanding bruteforcing indefinitely is part of someone’s threat model, they should be using a passphrase with sufficient entropy (such as 7 diceware words) which no longer needs to rely on the secure element’s throttling.

GrapheneOS’ upcoming 2-factor biometric PIN will make using a long passphrase much more usable for people who don’t want to simply use a fingerprint as a fall back. It will enable having a long passphrase as the primary unlock method that can withstand bruteforce attacks even in the event of a secure element exploit, while allowing the user to use a combination of fingerprint + PIN for everyday use in AFU.

It seems that people are also misinterpreting BFU exploit in those tables to mean that a secure element bypass is occurring, which isn’t correct. Them saying that they have BFU capabilities just means they can get limited data from a BFU device that isn’t encrypted, such as some metadata, not that they’re able to bypass the secure element and bruteforce the device to get in. That’s what “BF” is on their table.

Cellebrite’s docs show that brute force protection holds up against them on Pixel 6 and later and iPhone 12 and later, but they are partially bypassing the iPhone hardware defenses on newer devices.

7 Likes
33

Thank you for the thorough explanation and breakdown! There is always another layer of nuance to learn and appreciate you taking the time to explain that for everyone reading this thread.

2 Likes