GrapheneOS

GrapheneOS, 1 day ago

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.

Capability table described by the tweet. We can't properly format the tabular data as alt text but we can share it elsewhere.

GrapheneOS, 1 day ago

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.

Capability table described by the tweet. We can't properly format the tabular data as alt text but we can share it elsewhere.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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, 1 day ago (edited 1 day ago)

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

@sleepybisexual A random 6+ digit PIN or weak passphrase is only secure on devices with a secure element throttling attempts. See https://grapheneos.org/faq#encryption for an explanation of how it works on Pixels. If an attacker developers a secure element exploit, they can bypass a random 6+ digit PIN or weak passphrase.

Random passphrase with around 7-8 diceware words prevents any kinds of exploits combined with massive server farms from being able to obtain the data.

Bear in mind encryption is per-user.

GrapheneOS, 1 day ago

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.

GrapheneOS, 1 day ago

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, 1 day ago

One of our community members has uploaded the Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it:

https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares/4

We have info on XRY, Graykey and others but not the same level of reliable details as this.

GrapheneOS, 1 day ago

@Orca It means high speed brute force beyond the intended rate of unlock attempts. For the Android side of things, they just call it brute force.

They could keep trying new passcodes for a Pixel 6 or later after a BFU exploit but they say brute force isn't possible as in they can only go at the incredibly slow rate the secure element allows which is 1 attempt per day after 140 failed attempts. Pixels do this part better than iOS. They've got a fantastic secure element since the Pixel 6.

GrapheneOS, 1 day ago

@Orca Cellebrite and others seem to have an easier time exploiting the stock Pixel OS than iOS but they could make a few small changes such as adding our USB-C port control feature and enabling the MTE support they worked so hard on providing to do better. Adding auto-reboot timer after locking could make a huge difference even if it's a huge timer like 1 week or 2 weeks. We started with 72 hours but have dropped it down to 18 hours based on user feedback, since few people even notice that.

GrapheneOS, 1 day ago

@Orca If someone uses their phone at least once in the morning and once at night, they won't ever run into the 18 hour auto-reboot. We don't expect them to be that aggressive, but what would be the downside in auto-reboot 1 week after the device was locked, with users able to change the time or opt-out completely? It has no significant usability impact that way, and some tiny minority who dislike it can turn it off, such as someone using a phone as some kind of appliance.

GrapheneOS, 3 days ago

@RyuKurisu @tailscale Turning off an always-on VPN with leak blocking enabled is supposed to continue blocking network traffic. You need to disable the leak blocking for the traffic to go through with it turned off.

Which GrapheneOS release are you on? You can check via Settings > About device > Build number (at the bottom). If you're using Beta or Alpha, update to the latest OS release.

GrapheneOS, 3 days ago

@RyuKurisu @tailscale It doesn't require a bug report. The default is blocking leaks on GrapheneOS but it works the same way other than a different default.