final [GrapheneOS] ๐Ÿ“ฑ๐Ÿ‘๏ธโ€๐Ÿ—จ๏ธ's avatar
final [GrapheneOS] ๐Ÿ“ฑ๐Ÿ‘๏ธโ€๐Ÿ—จ๏ธ
npub1c9d9...sqfm
Keeping the fight. Community Moderator for #GrapheneOS https://discuss.grapheneos.org/u/final This is a personal account. I do not speak on behalf of GrapheneOS developers as a whole (nor am I) and suggestions shall not be endorsements.
#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
Latest release of #GrapheneOS finally shipped the long awaited duress PIN/password implementation. If you have a spare device, we recommend trying it out. We've added initial documentation to the features page: It near instantly wipes and shuts down. We've also finally added documentation on our USB-C port control to our features page: Most users can set this to "Charging-only when locked" without a loss of functionality or even "Charging-only" if you don't use USB accessories, DisplayPort or MTP. Default is "Charging-only when locked, except before first unlock" to avoid locking users out of devices with a broken touchscreen. The main threat model for this is defending the device until the auto-reboot timer started when the screen is locked gets user data back at rest.
#GrapheneOS version 2024053100 released. Duress Password is finally here. - add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down - disable unused adoptable storage support since it would complicate duress password support (support can be added if we ever support a device able to use it) - increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature - disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access - kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153 - kernel (6.1): update to latest GKI LTS branch revision - Vanadium: update to version 125.0.6422.147.0 - GmsCompatConfig: update to version 115 -make SystemUI tests compatible with GrapheneOS changes
The most recent release of #GrapheneOS (2024052100) adds the first piece of our ongoing work on duress/panic features. It makes standard factory resets including by device admin APIs wipe the device near instantly before it reboots to recovery to wipe and format it. We made our own wipe-without-reboot but we're backporting the Android 15 implementation instead of using ours. They made it in response to our vulnerability report about this (CVE-2024-29748, reported by GrapheneOS). The April release added 2 Pixel specific protections against the 2 vulnerabilities we reported, but both vulnerabilities essentially impact all Android devices and were only addressed for Pixels. The factory reset interruption also isn't fully addressed until they ship this part. A wipe without reboot is important as cutting device power during a restart can interrupt the wipe process. GrapheneOS now wipes without a reboot.
#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 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 ( 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.
โ†‘