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

Privacy
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
7

Edit: Daniel Micay reading my warning about the dangers of marketing to criminals and thinking that privacy and security is only for criminals says way more about him than me! #PrivacyForAll :smiley: (context)

It always concerns me when privacy/security projects like GrapheneOS pivot their marketing to explicitly say law enforcement can’t touch you. I feel like it usually doesn’t end well for them, but it’s neat information to have nonetheless.

I’m kind of surprised at how well the iPhone 12 and later allegedly fares too.

5 Likes
8

I didn’t leave the post with that impression. Certainly that is implied since LE would comprise almost all of celebrite end users, but may I ask why you had that as a take away? Perhaps I skimmed a bit too aggressively.

2 Likes
9

Because Cellebrite sells to law enforcement exclusively?

10

Sure, but the exploits used by Cellibrite are not specific to just Cellebrite and thus LE. Difficult to have a secure OS if another product is floating out there that can break into it. Regardless of who end users of that device are.

It doesn’t seem these devices are solely being used by LE either, but I’m speaking out of my element a bit. I wonder how often they are in the hands of non-LE.

11

Nah, they have multiple product lines and some are quite commonly used in phone stores and repair shops big and small.

2 Likes
12

This is basically what I’m saying though. To me it seems like one thing to say “hey we patched all these exploits,” and another thing to say “hey we can thwart this specific tool that’s only sold to LE based on their confidential slides we found.”

I suppose they already have the attention of LE though, so drawing more attention to themselves probably doesn’t actually matter :laughing:

13

I wouldn’t understand this if that is what they did. I’m not very technical so this is helpful for me to understand real world applications and how they are mitigating risk.

@SkewedZeppelin It’s interesting to hear they might be in use at repair shops. Part of my privacy journey began with the annoyance of having to provide my phone password to get a simple screen replaced years ago.

14

Basically, if your phone is in the BFU (Before First Unlock) state, then your data is safely encrypted if you use a strong enough passphrase. But if your phone is in the AFU (After First Unlock) state, then your data is decrypted and can be extracted with an exploit.

GrapheneOS has an auto-reboot feature to put the phone in BFU state after a set amount of time, and they also made it a lot harder to exploit the device in AFU state with things like the ability to disable the USB-C port on a hardware level.

The main goal is to put your device in BFU state ASAP and protect your device as much as possible until it reboots with the auto-reboot feature.

5 Likes
15

That’s not how I interpret it. Taken to abstract all it means is a vulnerability was discovered and exploited by someone and the GrapheneOS project investigated and implemented mitigations. Should they not mitigate 0-day vulnerabilities either in their project or dependencies? (AOSP, Pixel hardware, etc)

I’m not up to date on the policies of Cellebrite however

a) Capabilities that Cellebrite has today may be rediscovered by less scrupulous actors tomorrow.
b) Some Cellebrite devices have ended up in the hands of malicious actors.
c) At least in the past Cellerbrite did sell forensic equipment to governments that many would consider “challenged” in terms of human rights.

3 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
18

if law enforcement can’t break the project integrity they just shut it down :brain:

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