We published the Cellebrite Premium documentation from April 2024 in May 2024.
Our thread properly explained the info in the tables including their inability to exploit Pixel 6 or later secure element and only partially bypass it on iPhone 12 or later at that current period of time.
Cellebrite was a few months behind on supporting the latest iOS versions. It's common for them to fall a few months behind for the latest iOS and quarterly/yearly Android releases. They've had April, May, June and July to advance further. It's wrong to assume capabilities didn't change for the later iPhones.
404media published an article about the leaked documentation this week but it doesn't go into depth analyzing the leaked information as we did, but it didn't make any major errors. Many news publications are now writing highly inaccurate articles about it following that coverage.
The detailed Android table showing the same info as iPhones for Pixels wasn't included in the article. Other news publications appear to be ignoring the leaked docs and our thread linked by 404media with more detail. They're only paraphrasing that article and making assumptions.
The person who shared it with 404media is one of our community members. We regularly get sent this kind of information. In the case of XRY from MSAB, we were able to report several Android vulnerabilities based on their docs which are now fixed on Pixels but not elsewhere yet.
We received Cellebrite's April 2024 Android and iOS support documents in April and from another source in May before publishing it. Someone else shared those and more documents on our forum. It didn't help us improve GrapheneOS, but it's good to know what we're doing is currently working.
It would be a lot more helpful if people leaked the current code for Cellebrite, Graykey and XRY to us. We'll report all of the Android vulnerabilities they use whether or not they can be used against GrapheneOS. We can also make suggestions on how to fix vulnerability classes.
In April, Pixels added a reset attack mitigation feature based on our proposal ruling out the class of vulnerability being used by XRY.
In June, Pixels added support for wipe-without-reboot based on our proposal to prevent device admin app wiping bypass being used by XRY.
In Cellebrite's docs, they show they can extract the iOS lock method from memory on an After First Unlock device after exploiting it, so the opt-in data classes for keeping data at rest when locked don't really work. XRY used a similar issue in their now blocked Android exploit.
#GrapheneOS zero-on-free features appear to stop that data from being kept around after unlock. However, it would be nice to know what's being kept around. It's not the password since they have to brute force so it must be the initial scrypt-derived key or one of the hashes of it.
These details should tell you that if you consider these types of groups (sophisticated adversaries with limitless physical access) as a part of your threat model, then you should:
- Use the most recent phone you possibly can
- Upgrade your phone to the newest possible generation as soon as possible after release if you can help it.
- Use the latest version of GrapheneOS ASAP. Do not delay.
- Use a strong, high entropy passphrase to make bruteforcing the device credential impossible if secure element is ever exploited.
- Set GrapheneOS auto reboot time accordingly so encrypted data goes back at rest when the phone reboots, which makes AFU exploitation impossible. The lower the better.
- Enable duress password. Set it to something easy to trigger but not easy to misfire.
- Turn your phone off in a high risk situation, and trigger duress when in a duress situation.
- Disable your radios when not using them (turn off Wi-Fi, use airplane mode, disable NFC, UWB etc.) for attack surface reduction.
- Set an appropriate USB port control or disable the USB port so they aren't able to connect a device to it.
- Use user profiles (application data and user files within profiles are stored encrypted with separate credentials).
- Enable upcoming GrapheneOS security features like second factor authentication unlock when they come out.
- Communicate only over secure messaging. Some apps like Molly (Signal fork) have features to encrypt the app storage with a passphrase, which access to that app's data impossible even when a profile is compromised providing the passphrase is secure enough.
- Become disassociated to data. Learn to only keep files or other data as long as it is necessary. If you have no use for them for a long time, then back it up elsewhere, encrypted. Delete anything you don't have a use for in the present. Your data is not your memories.
- Remember that you are only as secure as the people you trust. If they do not meet your safety or security requirements, don't enable them to do things that could cause trouble.
nostr:nevent1qqs8uxurjncnpj8uyzqy5gd3lyevzd8u92xhk2xe9fdln5y03hgwrwgpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsgwaf3p
UPDATE: Someone has shared a newer version of the iOS table indicating Cellebrite caught up to iOS 17.5.1 or higher along with the iPhone 15 for the OS exploits.
It's common for them to fall behind by a few months for new iOS and Android versions. Android and iOS have no secure way to automatically get devices back into Before First Unlock from After First Unlock as GrapheneOS does so attackers can simply wait until they have an exploit.
We're currently waiting for one of our several sources to provide us with the new Android and iOS documentation. We aren't going to post the leaked iOS table in this thread because we can't confirm that it's authentic yet. We should have the new documentation quite soon though.
It's unfortunate that there was a whole bunch of secondary news coverage where it was misreported that Cellebrite was unable to exploit current iOS based on documentation from April 2024. It's July 2024 now, and they've had months to restore the capabilities broken by an update.
nostr:nevent1qqs8uxurjncnpj8uyzqy5gd3lyevzd8u92xhk2xe9fdln5y03hgwrwgpz4mhxue69uhhyetvv9ujumn0wd68ytnzvuhsygxptfdxtxrw026pxn0w82u9y4x6t3w5kp883d83djpgxuvj6d23s5psgqqqqqqsgwaf3p
Oddbean new post about login | logout