Pixel 6 and later use the open source Trusty OS for the Trusted Execution Environment (TrustZone) and secure core firmware.
Starting with this month's quarterly release (Android 14 QPR3), Trusty sources and baseline applets are part of the Android Open Source Project in trusty/.
Not everything is published, particularly Tensor specific portions. It'd be helpful to publish the rest to make it easier to audit and propose improvements.
They still need to publish the Titan M2 fork of OpenTitan too, which they committed to eventually doing several years ago.
The secure element in the Pixel 2 was an off-the-shelf NXP part running open source applets published in AOSP. In the Pixel 3, they moved to a custom secure element based on a standard ARM secure core and committed to open sourcing the firmware but it was blocked by the ARM NDA.
OpenTitan was created to replace their secure elements based on ARM secure cores with a custom RISC-V design across their servers, Chromebooks and Pixel phones/tablets. Pixel 6 and later have a RISC-V secure element (Titan M2), but they still need to publish Pixel specific code.
Upstream OpenTitan project is currently focused on implementing the TPM specification for desktop/server use. TPM is a horrible secure element API. It isn't what's used on Pixels where they got to design APIs for usage by the Android Open Source Project based on what it needs.
This is closely related to publishing the rest of the Trusty code used for Pixels, since they implement communication using authenticated encryption between the SoC secure core and the standalone secure element. Non-Pixel Android ecosystem could benefit a lot from all this code.
We are requesting feedback on Bluetooth compatibility regressions with Android 14 QPR3. Read more on the forums:
I put it back to the current, btw
Thank you for 1000 followers Nostr crew. Grateful to see so many fans of GrapheneOS here again. In the mean time, my profile picture was changed back to my old one. 🤔
We've found a serious bug in Android 14 QPR3 which can lead to devices getting stuck in a crash loop on boot after adding a device association such as a WearOS pairing. This impacts both stock Pixel OS and AOSP. Google is aware and reverted the broken change in Android 15 Beta 2.
Today, we plan to do a release fixing this serious issue and the AOSP Bluetooth module regression breaking pairing with the Galaxy Watch6 device we purchased for testing due to previous Bluetooth regressions in Android 14 QPR2 breaking it. Today's release should reach Stable.
If you don't depend on Bluetooth, you might as well update to the current OS release in the Beta channel and then switch back to Stable. Only reason it's not in the Stable channel yet is these 2 issues. There's another minor upstream Settings UI style issue which doesn't matter. #GrapheneOS
#GrapheneOS version 2024061300 released.
I also missed the post about 2024061200 so I will go through both in brief. GrapheneOS moved to Android 14 QPR3 on the previous version.
We've found at least one new issue with the Android Open Source Project 14 QPR3 Bluetooth module and are already working on resolving it. We'll have a quick follow-up release fixing the Bluetooth regression and other issues discovered during public Alpha testing.
Pixel 8a is now supported as part of the standard Android releases instead of having a device branch based on Android 14 QPR1. We've had stable releases for it available since May 15th (1 day after launch) based on our last QPR1-based release (2024030300). Pixel 8a users will be getting the GrapheneOS improvements from March, April, May and June along with the Android 14 QPR2 and QPR3 improvements so it's a much larger release for the Pixel 8a.
Changes since the 2024061200 release:
- fix upstream Android 14 QPR3 regression which breaks updating certain apps with our app repository client
- fix boot-time optimizing apps progress UI with Android 14 QPR3 and enable it again
- fix regression in our Android 14 QPR3 port resulting in PIN scrambling in secondary users being determined by the Owner user setting
- revert upstream Android 14 QPR3 Internet quick tile overhaul since it broke the functionality in secondary users
- temporarily add back disabling memory tagging and hardened_malloc for surfaceflinger since Android 14 QPR3 didn't fix it as expected
- disable temporary unconditional system crash notifications since we've gotten the initial feedback we needed via the previous release
- add additional null check for eSIM wiping done as part of the duress PIN/password wipe implementation to avoid harmless exception
- Settings: remove blank illustration from "Screen resolution" screen
- Vanadium: update to version 126.0.6478.50.1
- make duress PIN/password tests faster and more reliable
Changes since the 2024060500 release:
- full 2024-06-05 security patch level
rebased onto AP2A.240605.024 Android Open Source Project release, which is the 3rd quarterly maintenance/feature release for Android 14 (QPR3)
- temporarily disable boot-time optimizing apps progress UI due to upstream Android 14 QPR3 regression (our own post-boot background optimizing apps progress notification works fine)
- temporarily enable system crash notifications unconditionally for the initial QPR3-based release
- change default USB-C port mode to "Charging-only when locked" from "Charging-only when locked, except before first unlock"
- Settings: fix regression permitting disabling apps when it shouldn't be allowed due to device manager policy
- Vanadium: update to version 126.0.6478.50.0
- GmsCompatConfig: update to version 117
I can't TLDR this as we reported this, but it is good news. We discovered this and took action in January.
If you mean the first vulnerability in the article (CVE-2024-32896) then we reported that vulnerability ourselves. Its the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:
https://grapheneos.social/@GrapheneOS/112204428984003954
Despite the nomenclature of this type of vulnerability, this is not actually Pixel specific. The two CVEs refer to a same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.
CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3 where the device can now be wiped without a reboot. It's not specific to Pixels at all. CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader although it doesn't entirely address the problem.
These vulnerabilities were discovered by us as a forensics company (MSAB) were selling Brute Force capabilities for Pixels on the Stock OS and leaked how they were doing it in an instruction video about bypassing insecure duress apps like Wasted using the device admin API to factory reset (CVE-2024-29748). We understood that they would boot into fastboot mode to interrupt factory resets helped by the device not wiping without reboot (CVE-2024-32896), which led them to RAM dump (CVE-2024-29745) and brute force the device from the credential hashes left in memory to unlock the device.
MSAB openly admitted they weren't able to do this with GrapheneOS. Since they could only do this on an AFU device then our automatic reboot feature stopped them there too. Hardened_malloc (hardened memory allocator used in GrapheneOS) zeroes memory when free which could also have played a factor.
MSAB discussed having consent support (which involves user giving away their PIN/password consensually) for their forensic extraction software for GrapheneOS but that's not relevant to us. The targets were strictly stock OS users, but that doesn't mean adding these fixes didn't help GrapheneOS too, and we would never say never to something similar happening for GrapheneOS devices even with that confirmation.
We took additional action and added features like USB-C port controls, duress password. and hardening against proximity attacks. We added firmware-based reset attack mitigations as part of GrapheneOS device requirements afterwards. Other OEMs have this issue and they need to fix it themselves.
The other CVEs mentioned were fixed back on April for stock OS users. Although the reason this came up again this week is the full solution to this is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP released a few days ago. GrapheneOS upgraded to Android 14 QPR3 as it came out, but we backported the wipe-without-reboot on 2024052100 for our unique duress password feature.
You can see the official thread mirrored here. Android 14 QPR3 just released and GrapheneOS is working hard since our first release with it so I have been quite busy:
When other hardware can meet these requirements, we will support them:
https://grapheneos.org/faq#future-devices
It is disappointing only Pixels do this currently. Samsung is a close contender if they didn't intentionally sabotage users installing other OSes by disabling cameras, security features and 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.
#GrapheneOS receives fourth Android Security Acknowledgement of the year. This time we are credited for moving wipe-without-reboot to the stock OS.
CVE-2024-32896 which is marked as being actively exploited in the wild in the June 2024 Pixel Update Bulletin is the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:
None of this is actually Pixel specific.
Bulletin:
https://source.android.com/docs/security/overview/acknowledgements
Attribution to us:
https://source.android.com/docs/securi
CVE-2024-32896 and CVE-2024-29748 refer to the same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.
CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3. It's not at all Pixel specific.
This is being widely incorrectly reported in tech news coverage. Pixel Update Bulletins are almost entirely patches for vulnerabilities which apply to other devices too. Android Security Bulletins are the list of what other OEMs are required to fix, not the full list of patches.
We explained this in our previous thread:
https://grapheneos.social/@GrapheneOS/112204437363495338
CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader. Full solution is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP.
Our 2024052100 release backported the upstream wipe-without-reboot feature being shipped in the June 2024 release of Android (Android 14 QPR3): https://grapheneos.org/releases#2024052100.
We extended it to make it more robust via extra redundancy in our 2024060400 release:
https://grapheneos.org/releases#2024060400.
There were 2 main issues:
1) memory not wiped when booting firmware-based fastboot mode, allowing exploiting it to get previous OS memory
2) AOSP device admin API depends on reboot-to-recovery to wipe before Android 14 QPR3
Neither of these issue is being fixed outside Pixels yet.
Each month, Android has a new version released. These are the monthly, quarterly (QPR) and yearly releases. The baseline monthly security patches are NOT the monthly releases of Android. They're backports of a SUBSET of the patches with High/Critical severity, not all patches.
Most devices only ship the backported patches to older Android releases (12, 13 and 14). Pixels ship the monthly, quarterly and yearly releases. Other devices will mostly get the 2nd vulnerability fix when they update to Android 15. They'll have to fix the 1st issue on their own.
We have a thread about forensic company capabilities at:
based on leaked Cellebrite documentation. Shows GrapheneOS does a much better job than iOS/Android blocking exploits and only Pixel 6 and later or iPhone 12 and later successfully stop brute forcing.
Interesting to understand if nostr:npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5 was affected as well
I can't TLDR this as we reported this, but it is good news. We discovered this and took action in January.
If you mean the first vulnerability in the article (CVE-2024-32896) then we reported that vulnerability ourselves. Its the 2nd part of the fix for CVE-2024-29748 vulnerability we described here:
https://grapheneos.social/@GrapheneOS/112204428984003954
Despite the nomenclature of this type of vulnerability, this is not actually Pixel specific. The two CVEs refer to a same vulnerability of interrupting reboot for wipes via the device admin API, which applies to all devices.
CVE-2024-32896 is a full fix in AOSP as part of Android 14 QPR3 where the device can now be wiped without a reboot. It's not specific to Pixels at all. CVE-2024-29748 was a mitigation for the issue implemented in the Pixel bootloader although it doesn't entirely address the problem.
These vulnerabilities were discovered by us as a forensics company (MSAB) were selling Brute Force capabilities for Pixels on the Stock OS and leaked how they were doing it in an instruction video about bypassing insecure duress apps like Wasted using the device admin API to factory reset (CVE-2024-29748). We understood that they would boot into fastboot mode to interrupt factory resets helped by the device not wiping without reboot (CVE-2024-32896), which led them to RAM dump (CVE-2024-29745) and brute force the device from the credential hashes left in memory to unlock the device.
MSAB openly admitted they weren't able to do this with GrapheneOS. Since they could only do this on an AFU device then our automatic reboot feature stopped them there too. Hardened_malloc (hardened memory allocator used in GrapheneOS) zeroes memory when free which could also have played a factor.
MSAB discussed having consent support (which involves user giving away their PIN/password consensually) for their forensic extraction software for GrapheneOS but that's not relevant to us. The targets were strictly stock OS users, but that doesn't mean adding these fixes didn't help GrapheneOS too, and we would never say never to something similar happening for GrapheneOS devices even with that confirmation.
We took additional action and added features like USB-C port controls, duress password. and hardening against proximity attacks. We added firmware-based reset attack mitigations as part of GrapheneOS device requirements afterwards. Other OEMs have this issue and they need to fix it themselves.
The other CVEs mentioned were fixed back on April for stock OS users. Although the reason this came up again this week is the full solution to this is implementing wipe-without-reboot, which is now a standard feature in Android 14 QPR3 released as part of AOSP released a few days ago. GrapheneOS upgraded to Android 14 QPR3 as it came out, but we backported the wipe-without-reboot on 2024052100 for our unique duress password feature.
You can. You can toggle WiFi on afterwards if thats what you mean.
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm
If I remove the SIM and turn off the mobile, does the pixel phone still communicate with towers? Thinking of going wifi-only.
You would need to use Airplane Mode as well to get what you want, which turns the cellular radios off. It can still interact with the network without a SIM, hence why you can call 911 without one.
#GrapheneOS version 2024060600 released.
- Sandboxed Google Play compatibility layer: adjust to DynamiteLoader changes being deployed with a new feature flag in Play services 24.22
- stop treating pressing the spacebar on a physical keyboard as submitting the lockscreen password since it prevents entering passphrases with spaces (upstream Android bug which has existed for around 8.5 years)
- Vanadium: update to version 125.0.6422.165.0
- GmsCompatConfig: update to version 116
#GrapheneOS version 2024060400 released.
This is an early June security update release based on the May 2024 security patch backports since this month's release of the Android Open Source Project and stock Pixel OS with Android 14 QPR3 isn't available yet. There are also improvements to wiping which is used by the duress password.
- full 2024-06-01 security patch level
- extend the standard wipe-without-reboot implementation beyond wiping the hardware keystores (which prevents recovering any OS data by preventing deriving the key encryption keys) by also wiping the secdiscardable data needed to derive key encryption keys, the encrypted storage keys and the Weaver slots in the secure element through a secure element erase
- kernel (5.10): update to latest GKI LTS branch revision
- kernel (5.15): update to latest GKI LTS branch revision
- kernel (6.1): update to latest GKI LTS branch revision
After the wipe it will boot to recovery as it can't access any data and then reset OS. After that it boots into the GrapheneOS setup wizard.
To flash to another OS or stock OS, make sure to enable OEM unlocking on the fresh GrapheneOS install after the duress happens.
BTW we never recommended those apps that used device admin APIs for resetting the device since you could deactivate them and interrupt the erasure. XRY had tutorial videos explaining how to bypass Duress and others by holding the buttons that would boot into Fastboot mode. Law Enforcement knew for long time. We also had criminal sellers using our work unlawfully and bundling those apps trying to lie, sell it and say whatever they sold was better than GrapheneOS at extortionate prices.
Duress feature took as long as it did because we needed a unique way to wipe the device without reboot, that couldn't be interrupted and was also as fast as possible. We had our own wipe-without-reboot then Google designed one for future Android after our reports so GrapheneOS backported that as part of the infrastructure for the Duress feature.
Hopefully those apps are redundant for GrapheneOS users now.
#GrapheneOS duress password in action. This is on a sacrificial Pixel 6a. I did it a few times, and let me tell you, DO NOT screw around with this. You get no second chance. It's gone. Instantly. And it's beautiful.
https://v.nostr.build/Gel7e.mp4
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl
Here is footage of the brand new #GrapheneOS duress password in action from a user, here on Nostr.
#GrapheneOS duress password in action. This is on a sacrificial Pixel 6a. I did it a few times, and let me tell you, DO NOT screw around with this. You get no second chance. It's gone. Instantly. And it's beautiful.
https://v.nostr.build/Gel7e.mp4
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm nostr:npub16r0tl8a39hhcrapa03559xahsjqj4s0y6t2n5gpdk64v06jtgekqdkz5pl
Thank you for posting this footage here on Nostr!
Tuxsudo has done a video here!