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.
Accrescent is alpha software (in terms of features) and likely wouldn't be appropriate to distribute it wider without further improvement. It is the maintainer's choice. It would be better for the future.
For outside GrapheneOS there's https://accrescent.app
You will need to be on the latest GrapheneOS App Store, it may not have reached everyone yet. If you don't have it then try select Beta and update. You are free to set it back to Stable after updating.
fyi I am aware of other projects using Hardened Malloc as well, for example this hardened Void Linux build has hardened malloc and other hardening:
https://0xacab.org/optout/plagueos
https://0xacab.org/optout/plagueos/-/wikis/Security-Considerations
https://0xacab.org/optout/plagueos/-/wikis/FAQ
It sounds very interesting butI (and I think anyone I know) have never used it though. Can't make a recommendation. Using smaller projects is at your own risk.
The Chromium itself is still patched to disable data collection and opt-in metrics according to the developer and since it uses Vanadium patches I could attest to that. Always better to use the Chromium as a base and build with own patches rather than centipeding someone's fork like ungoogled-chromium. Since if they delay, then you delay.
These forks also aren't security hardened like Vanadium is, forks will just amateurly take out anything that mentions Google which leads to some regressions.
Secureblue is not endorsed but both have a similar user share and the maintainers are frequent GrapheneOS community members. It's listed as an example of other OSes using hardened_malloc on our site.
It's usable, but hardened_malloc will break certain apps the same way they do on GrapheneOS for security. Electron apps are an example. I don't daily-driver secureblue though and the barrier for entry is higher than it is to get started with GrapheneOS.
Brave is a top choice when it comes to content filtering and state partitioning. A big issue with Brave is how much, in my opinion, random nonsense they want you to use with it. Fortunately it never bugs you again once you disable it, but there could be better.
Secureblue (security-hardened Fedora Atomic images) uses a hardened Chromium with Vanadium patches, but it's part of Secureblue for the most part. It also uses our Hardened Malloc.
It's mostly used explicitly by GrapheneOS users. It's maintained by a supporting community member. Some strict security-focused users have been using it for a few years. I don't expect this to be the first choice app store for people due to how limited the app catalog is, but it is worth us mirroring on our App Store so users can get it quickly, and because it is the what we consider choice for security and privacy.
Future progress and adoption will hopefully change things
While the app catalog is currently limited, it is the most private and secure option to get the apps that it has if you need them. Other apps we recommend like Molly (hardened Signal fork) also officially appear on Accrescent. Some popular apps you may recognise are AppVerifier, Aves Gallery, IVPN and ExifEraser (we do not make official ecommendations or endorsements for these apps or services, use at your own preference or risk).
We may add our own builds of certain third party apps but we aren't ready to do that yet. Would be a lot of work.
Accrescent by nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm seems aligned with nostr:nprofile1qqs83nn04fezvsu89p8xg7axjwye2u67errat3dx2um725fs7qnrqlgzqtdq0
values and goals, when a marriage?
Accrescent is by their own team, I don't work on it. We have now chosen to add the option to install on our Apps app. They are maintained by long-time GrapheneOS community members and it's been designed for GrapheneOS users. We have been aware of the app for a few years.
https://github.com/accrescent/accrescent
It was always in our interests to have a more secure app store option as we didn't want F-Droid. Users are still free to install another app store of choice as Accrescent isn't and won't be bundled into GrapheneOS itself.
The #Accrescent security and privacy focused Android app store is now available in the #GrapheneOS app store.
Accrescent is a mobile security and privacy project that closely ties to our values. We hope the Accrescent project can benefit from having more users.
Accrescent features:
- App signing key pinning: first-time app installs are verified so you don't have to TOFU.
- Signed repository metadata: repository contents are protected against malicious tampering.
-Automatic, unattended, unprivileged updates (Android 12+): updates are handled seamlessly without relying on privileged OS integration.
- Designed for split APKs: downloaded APKs are optimized for your device to save bandwidth.
- No remote APK signing: developers are in full control of their app signing keys.
- No account required: users don't need an account to install apps, improving privacy.
GrapheneOS turns 10 this year, quality work takes time and all of this definitely didn't pop out of nowhere suspiciously. IMO this has been the best past 12 months for GrapheneOS so far. Several vuln disclosures, duress password, Vanadium content filtering and more in a small span of time. We definitely appreciate people coming to support GrapheneOS in droves the past 12 months.
It wouldn't make sense for us to be malicious for many reasons, not every GrapheneOS team member is working in private (e.g. the founder) and we have a Foundation registered in Canada with multiple directors. We participate with the broader cybersecurity community with vulnerability disclosures and such. There's nothing wrong with concealing your identity but in our case, we have reputation and our professional lives on the line not to be evil. How we work is very different and open in comparison to real sting operations ran by governments or scam products owned by criminals.
We dont deny certain people want to break us. We will never say we are impenetrable, but we are aware our work is targeted by threats aligned with governments such as in the leaked Cellebrite documentation where they discuss their failures with GrapheneOS. These people deceit the public with vague and misleading information to discredit us. Our effort the past year is down to fighting back on this attack and our fight is completely in the public eye for people to watch, we already survived a hostile takeover attempt, so we we're very sure we're here to stay.
I admit I'm curious to know what can be too good to be true about it? I know it's partially a compliment but still curious.
There is still a large amount of enhancements we would love to add and changes we want to make (see the roadmap on our site) so it surprises me people consider GrapheneOS at the current state to be too good.
#GrapheneOS uncovers leaked documentation for smartphone exploits by Cellebrite.
XRY and Cellebrite say they can do consent-based full filesystem extraction with iOS, Android and #GrapheneOS. It means they can extract data from the device once the user provides the lock method, which should always be expected. They unlock, enable developer options and use ADB.
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.
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.
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 fastbootd 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 https://x.com/GrapheneOS/status/1775305179581018286 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.
Cellebrite documentation and has stated they'll upload future versions of it if you want to look at the rest of it:
We have info on XRY, Graykey and others but not the same level of reliable details as this.
Here is the initial post and screenshots from me where you can see that GrapheneOS is trouble for them if you missed it:
Journalist Joseph Cox of 404 Media has made commentary on the leaked Cellebrite documentation we discussed, and additionally verified the authenticity (we know it's genuine, but it's good to see from others). The #GrapheneOS team has provided commentary.
https://www.404media.co/leaked-docs-show-what-phones-cellebrite-can-and-cant-unlock/
We continue to monitor what threats are up to and prioritize GrapheneOS development when threats arise. We have a proven track record of discovering, reporting and fixing vulnerabilities exploited in the wild. This work will continue.
New pictures of upcoming Pixel 9 Pro Fold if anyone is interested: https://www.androidauthority.com/google-pixel-9-pro-fold-ncc-3461263/
nostr:nprofile1qqsvzkj6vkvxu745zdx7uw4c2f2d5hzafvzw0z60zmyzsdce9564rpgpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp03dnmwv On another note. When Vanadium for Linux? Is that still on the table? Given the mounting lack of trust with stock FF, it would be a gamechanger.
For other platforms it was never planned. It was considered for Android OSes as a whole but it's not worth it because non-GrapheneOS users would see major benefits. Vanadium's security advantage depends a lot on the hardware supported and OS security modelling, browser MTE support being the most significant.
Try allow JavaScript JIT permission on site. Vanadium disables by default.
OS will erase specific data to make the device unable to decrypt the OS, the device will fail to boot, then boot into recovery mode and the OS will reset like you installed GrapheneOS for the first time afterwards.
Nothing of the sort would come in GrapheneOS. It's an opt-in by using stock apps for some features, but more invasive ones that are privileged like circle to search don't exist at all.
A lot of the AI use is quite limited in practice and are instead just features of stock OS apps being marketed as AI. You can get the photo editing features they market as AI like Magic Eraser by installing Google Photos on GrapheneOS with Play services. A lot of generic Google app AI features aren't even on-device but done over the cloud.
There's nothing for us to fix because we can't disable what doesn't exist here. The only functionality that's included in GrapheneOS is hardware acceleration for image processing, neural nets, etc. which we make use of. We provide HDR+ and Night mode the Camera app with it. We had to make new Camera app a long time ago just to get them, because the AOSP camera didn't have it.
That Pixel Screenshots feature appears to just be a feature to search text within and metadata of screenshots, iPhone had that for a while but didn't give it the AI push like Google did. That wouldn't be in GrapheneOS because our apps do not have any feature like that. If it has privileged/invasive access then it would probably never even be considered even if we could.