You're misunderstanding the post 😅
The documentation is saying modern Pixels (especially with GrapheneOS) cannot be brute forced and they only work if users give their passwords away. Cellebrite are having substantial trouble against us, they can't break into any device we support, nor GrapheneOS.
GrapheneOS is mentioned in the documents (see pictures) and is the only OS mentioned separately to Android as their standard choices don't work.
If someone wanted to brute force a device that is BFU, they need to exploit that secure element in addition, rather than just the phone. Very old Pixels we do not support anymore have secure element exploits as per the Cellebrite documentation.
The secure element is the core piece that protects against brute force attacks and physical attacks. It is what enforces brute force throttling and also makes tampering far more difficult. We also use it for other features like in Auditor.
It is a hardware requirement of GrapheneOS to have one and for the device to support an alternative OS using it. That is one of several reasons we use Pixels and this note is an example of the benefit.
We agree it's not an attack, we even said that capability is an expectation at the start.
Unfortunately, some malicious actors, namely people selling proprietary scam phone products have been misinterpreting such claims by Cellebrite, XRY and others about GrapheneOS being supported as GrapheneOS being under attack.
This is our response. This post is meant to highlight how we have got these companies' attention and how they have trouble dealing with us. Earlier this year we found the exploit XRY was using to brute force modern Pixels which lead to us patching it (and got a pretty good bounty from Google for it too). This is more of a post talking about our recent successes and future plans.
We are showing GrapheneOS is not like the other devices with stock or other OSes with exception to some modern iPhones in this post. Consent is the ONLY way for supported GrapheneOS devices at this time. We also wanted to reveal this Cellebrite documentation for clarity as we had discussed it in the past on our forum.
Consent based extraction means that the owner of the device provided consent to extract the device by providing their password to unlock the phone. No OS can't protect against someone willing to do that obviously, so it's out of our scope.
To piss off the right people accordingly:
- Use the most recent phone you possibly can
- Upgrade your phone to the newest possible generation as soon as possible after release
- Use the latest version of GrapheneOS ASAP
- Use a strong high entropy passphrase (makes bruteforce impossible if secure element is exploited)
- Set auto reboot time accordingly so encrypted data goes back at rest when the phone reboots.
- Turn phone off when in a risky situation.
- Disable radios when not using them (turn off Wi-Fi, use airplane mode, disable NFC, UWB etc.)
- Set an appropriate USB port control
- Use user profiles (data stored encrypted with separate credentials)
- Enable duress password when it comes out
- Enable second factor authentication unlock when it comes out
It means they can only extract the device if the owner of the device is giving the person with Cellebrite the password to their device.
Your pixel would not be able to be brute forced. The secure element helps in stock OS and GrapheneOS.
Cellebrite, XRY and others know about GrapheneOS and they don't like us. They talk about GrapheneOS in their advertising media and claim to support it but they only support extractions where the person gives away the device credential.
We have copies of Cellebrite's updated government and law enforcement brute force / data extraction exploit documentation.
Fully supported GrapheneOS devices (Pixel 6 and above) cannot be brute forced by them. GrapheneOS with a Pixel is the ONLY mainstream device they can't beyond up to date, modern iPhones (subject to change).
GrapheneOS has additional features beyond the defaults to make this even harder which aren't mentioned in the docs. We plan to add more.
#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.
An experimental prerelease of #GrapheneOS for the Pixel 8a is now available, including web installer support.
Pixel 8a currently uses Android 14 QPR1 instead of Android 14 QPR2, meaning it's missing many improvements from the 2nd quarterly release including important privacy and security enhancements. It's likely Android 14 QPR3 will be released in June which should resolve this problem.
Android 14 QPR2 is the largest ever quarterly release of Android, because it's the first trunk-based development release. It brought a lot of what Android 15 is going to ship, largely under the hood with new user-facing features largely disabled but present in the code.
Android 14 QPR2 was released on March 4th but had a delay in publishing to AOSP due to issues with pushing the code which was finished by March 5th. GrapheneOS had a release based on it within a day of that, but it took a couple days to reach staging due to regressions we found.
One of those regressions was the High severity Bluetooth vulnerability we found which was introduced in Android 14 QPR2. This issue slipped into our Stable channel release due to only coming up with rare configurations but we got it fixed on March 9th.
Since the Pixel 8a is still using Android 14 QPR1, our initial release is based on porting our changes from our 2024030300 release which was the last one based on QPR1 (https://grapheneos.org/releases#2024030300). It has a current May security patch level, but this doesn't meet our usual standards.
It's missing improvements to GrapheneOS from March, April and May in addition to Android 14 QPR2 changes. We backported our change enabling PAC/BTI for userspace and are using a current GrapheneOS 5.15 LTS common kernel source tree. SHOULD be fixed with June update, QPR3 or not.
Pixel 8a switched to Samsung GNSS (GPS, etc.) from Broadcom so we need to add Samsung PSDS support to our network services for PSDS to work.
We are very disappointed with this route they took. When the 8a has the same upstream OS version then it won't need to rely on a reduced feature pre-release like now.
nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c In 2022 Graphene OS went as far as to announce their collaboration with a hardware vendor to have their own devices produced but in the end it fell through. As far as I understand the idea of a GrapheneOS phone is still on the table if they find the right manufacturer and agreement.
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm am I correct in this understanding? Is the idea of a GrapheneOS phone still something GOS is considering?
Always has been. It's just it never goes well so far because the OEMs always want gimmicks, implement security features improperly or don't want to at all to cut the cost. Having less security than the baseline in our documentation is unacceptable to us.
If we supported devices that are less or improperly secured then it ends up with us being the blamed party for these devices rather than the OEM who slacked off. People would then say it's the fault of GrapheneOS as a whole when the secure devices don't get affected by such problems.
Supporting existing devices is also on the cards but OEMs don't play fair, like Samsung crippling security features and even cameras permanently. I am personally not the type to have the law step in on things like this, but I totally think there should be some litigation about this.
We're working on making an experimental pre-release build of GrapheneOS for the Pixel 8a. It will have the 2024-05-05 security patch level but it will initially be missing the Android 14 QPR2 improvements and also the many GrapheneOS improvements since our March 3rd release.
There's a high chance Android 14 QPR3 will be released in June, and they likely decided it didn't make sense to go through all the work of getting QPR2 ready for release. Launching a brand new Pixel with backports to a previous quarterly release is still quite a strange choice.
Pixel 8a with the latest May 2024 update is running Android 14 QPR1 with backported security patches instead of Android 14 QPR2.
Android 14 QPR2 was released in March 2024 and is by far the largest quarterly release so far due to being the first trunk-based quarterly release.
We're definitely not going to backport all the changes we've made since March to Android 14 QPR1. That means we can't simply make the usual device support branch to support it. It's going to need to start out being treated as if it's an end-of-life device in extended support.
The Pixel 8a doesn't currently meet our expectations. We haven't decided if we want to move development resources from working on new features to providing experimental support for a device with a botched launch. It would be a lot more efficient to wait for it to be fixed first.
It might get fixed in the June release. We could put in a bunch of effort to get experimental support for it in the next 24 hours but that will come at a big cost and it won't be anywhere close to something we can consider a production release due to what they released, not us.
Our #Vanadium browser (https://grapheneos.org/features#vanadium) is based on the stable releases of Chromium. We port to the new releases when they're still in Beta/Dev/Canary but we wait until it's Stable to upgrade, particularly since Stable is the only branch with proper security support.
Within release channels, Chromium uses staged rollouts where initially only a random subset of users get the new release. Recently, the initial Stable channel release started being done 1 week early and only rolled out to a tiny number of users:
https://developer.chrome.com/blog/early-stable
Current release status for Android is at https://chromiumdash.appspot.com/releases?platform=Android. There are 2 variants of a regular Stable release and 2 of an early one, since they enjoy A/B testing changes so much.
We've been following the early Stable, but this month they failed to support it properly...
After the pair of early Stable releases based on v125 for Android, there were 2 pairs of releases based on v124 with 2 rounds of security patches for issues being exploited in the wild. They failed to update the early Stable release as they have before, so we had to deal with it.
Strangely, it appears that the early Stable channel release was only rolled out for Android and the Safari-based iOS app. The 0.2% of Android users receiving the early Stable release aren't getting patches for those 2 vulnerabilities being exploited in the wild. That's not great.
These are the 2 patches missing for Android users who get updated to 125.0.6422.34 or 125.0.6422.35:
https://chromereleases.googleblog.com/2024/05/stable-channel-update-for-desktop_9.html
https://chromereleases.googleblog.com/2024/05/stable-channel-update-for-desktop_13.html
Both are marked as having an exploit in the wild. They should really simply make 1 tag and stop making things overly complex.
#GrapheneOS
Auditor has been updated to support the Pixel 8a on the stock OS and preparations have been made for GrapheneOS support.
https://github.com/GrapheneOS/Auditor/releases/tag/80
When upstream source is available on the device release date, a GrapheneOS build will be produced.
We've received the Pixel 8a for our device testing farm already even though it officially ships May 14th.
Both Android Open Source Project source code tags and stock OS factory images / updates will likely be published on May 14th. We'll need those to add GrapheneOS support.
They typically ship pre-ordered devices a few days early to provide most people with an estimated delivery date on the launch day. It's a bit odd they don't publish everything on the day they ship instead of the planned arrival day since many do arrive early. It's fine with us.
Today, we're going to be adding support for the Pixel 8a in Auditor along with generating and backing up official GrapheneOS signing keys which are separate for each device for security reasons. We can't do much else before the official launch day when the code is published.
#GrapheneOS
Take a look at: https://discuss.grapheneos.org/d/10937-cant-update-vanadium/2
Latest Vanadium release contains a backport early patch for CVE-2024-4671. Update if yours has not been already. #GrapheneOS
In light of a recent high severity vulnerability involving pdf.js, the #GrapheneOS' PDF viewer is not affected.
We use a strict Content-Security-Policy allowlisting the app's static CSS and JavaScript without permitting unsafe-eval or unsafe-inline. It's blocked from using eval or including dynamic JS.
Even if we didn't set a Content Security Policy, the whole point of the app is that it renders a PDF in a sandboxed WebView instance without network, file or content access. It exposes a fairly small subset of the attack surface exposed by a web browser to any web site you visit.
The only data in the sandboxed WebView instance is the PDF which is written into it by the app without giving it access to the file/content. Even if an attacker somehow got JavaScript code execution despite our strict CSP, they couldn't do anything beyond attacking the browser.
The reason we use pdf.js is because it's designed to run efficiently in the browser sandbox. However, unlike opening a website in the browser, we use a restricted environment: no network/file/other access, no dynamic JS or CSS, many features disabled via Permissions Policy, etc.
JavaScript is memory safe but normally has pervasive dynamic code execution via inline JavaScript, dynamically included files and eval. It runs inside a restricted browser sandbox. The browser renderer implementing that sandbox runs inside of the browser's OS level sandbox.
GrapheneOS uses a hardened WebView provided by Vanadium. On Google certified Android OSes, it's provided by Chrome. Either way, our approach is far safer than a C++ PDF library in an OS sandbox (isolatedProcess). It provides 2 extra layers of strong security against most attacks.
Exploiting a vulnerability in the PDF library doesn't really work against our PDF Viewer app since there's an allowlist for the code. In practice, an attacker would need to exploit Chromium's rendering indirectly through pdf.js such as targeting browser font/image rendering.
Android uses isolatedProcess for the official PDF rendering library, which lacks our additional layers of protection and is far easier to exploit. Nearly all Android PDF apps bundle their own C or C++ PDF rendering library and don't bother even using an isolatedProcess sandbox.
Likewise, an update for the PDF viewer had been pushed as soon as the new version was released to have the patched pdf.js version.
Information about the vulnerability: https://github.com/advisories/GHSA-wgrm-67xf-hhpq