It is a newly released feature and updates aren't pushed to Stable where most of the users are immediately. We just put the docs for the feature and all the past changes we missed like USB controls on the website now.
Now it's in Stable there should be. I will try source some footage.
Is there any video of GrapheneOS's duress PIN in action? I'm naturally curious but I'm not willing ro wipe my only phone. cc nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm
I'll try source some for you, may take some time.
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:
https://grapheneos.org/features#duress
It near instantly wipes and shuts down.
We've also finally added documentation on our USB-C port control to our features page:
https://grapheneos.org/features#usb-c-port-control
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.
Users are free to trigger their Duress password on a spare device in many different ways for feedback. ☺️
It isn't planned currently as a technical threat would be able to figure that out, or would be able to tell if it is a decoy through other means. It's a big reason we don't have a hidden profile feature at all (e.g. FFS would leave signs). The feature would only work best against someone with no knowledge on what GrapheneOS is. Cellebrite and XRY and other industry actors mentioning us in their internal documents or product material would suggest they study our work and read our posts.
Another example is Owner is still required to be authenticated first and there's tons of ways to see if an authenticated profile os the Owner or not.
We believe features involved in tricking someone could lead to someone trusting that feature and underestimating how skilled the person they're trying to trick, which could endanger them or bring even more trouble. While you could also trick someone with our Duress PIN that's not the objective, the device owner should trigger it when the time is right.
FYI: GrapheneOS does remain installed after a trigger right now so you can go into a recovery.
FYI: Obviously Pixel 8a doesn't have this or other new features due to being in prerelease, since it is currently based on Android 14 QPR2 and not QPR3. Once it is available then all currently supported devices are together.
Obviously we can't speak on what potential bad guys (criminals or abusive states) would do. Laws are different elsewhere, but some would likely choose whatever would happen to them over what would happen if they surrendered. If a threat threatens to kill you, how can you be sure they won't just kill you if you complied anyway?
Sadly a duress PIN isn't designed to make you unaccountable. An erased device will always look obvious, and how they treat it really depends on who is trying to take it away.
You can best describe it as a trigger for erasing data to prevent an unauthorized party (in your proximity) from having potential access. It's great for protecting data you do not want anybody but yourself knowing. A whistleblower preparing to leak something confidential could come to mind.
It's more about protecting your data than yourself.
Yes of course. Wouldn't make sense to do something that causes permanent damage. Can reinstall GrapheneOS or another OS without problems.
Since release is in Alpha there will be people in Alpha testing channels reinstalling GrapheneOS often for further QA.
Once backups are improved and not using Seedvault, that new backup system should be designed to work well for recovering after a duress trigger. Although there are bigger priorities right now.
#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
#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.
I was requested to make a glossary for the terms so here they are:
AFU: After First Unlock
Cellebrite refers to devices AFU as a device where it is in AFU state where they do not know the user's credential. If it is known or brute forced, they use the term 'Unlocked' instead.
AFU support without Brute Force could imply a unique exploit to unlock, like IPR or a lockscreen bypass.
BF: Brute Force
BFU: Before First Unlock
A 'BFU Extraction' on the table is a type of extraction for a very small amount of BFU state accessible data only. It doesn't mean they can extract the entire device. Using a brute force to unlock the device would turn it into Unlocked.
FBE: Filesystem-Based Encryption (Encryption Android and iOS uses)
FDE: Full Disk Encryption (Android FBE is really a form of FDE, but they use FDE to refer to the non-filesystem-based dm-crypt encryption from older Android versions.)
FFS: Full File System extraction (OS data, data of current user, app data, files and more).
SPL: Security Patch Level ('Up to {date} SPL' means it works on versions BEFORE that date)
Supersonic BF: Supersonic Brute Force
IPR: Instant Password Retrieval (iPhone specific exploit)
There isn't. We're just posting a review on these leaked details to help dispel false claims about GrapheneOS being compromised by Cellebrite and also advise the general public what these companies are up to.
The documents tell a bigger picture that we are one of the only platforms actually protecting against attacks on devices by users that don't provide the passphrase, as what the images tell.
#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.
Personal note:
Companies selling exploits for smartphones talking about #GrapheneOS in their internal documents and their limitation and failure in targeting the OS is only further evidence of the success of our recent mobile security and privacy work.
A multi-million dollar industry of companies exist just to discover and sell exploits for devices. Cellebrite is only one of many. Attacks by actors of such capabilities is what GrapheneOS aims to protect against, like we had done earlier this year, where we discovered vulnerabilities these companies took advantage of and disrupted their fun with improving and adding new security features. There is more to come.
We may not be as large as they are, but think about why they have to say our name and why they separated us from Android and iOS. What we do is significant and impactful. We don't ignore the competition or be deliberately vague or misleading about capabilities like these companies have been about us.
Digital forensics is such a valuable (and in my opinion, undervalued) cyber security skill but it is a shame these titans of the industry are all secretive and protective about their work. Some go as far as to mislead the public. Transparency and co-operation is the most valuable trait in the realm of digital security and companies like these shouldn't get a waiver.
I could have so much more to say including about how these companies' software are often designed too deliberately simple or complicated to make you depend on them and give them more money. Tools like Cellebrite are so easy to navigate and use that it feels like it's designed that way to not create forensics experts that can end up doing work themselves, and that other tools are deliberately complicated to faciliate to customer to buy their training.
If you want to hit companies like these where it hurts, then try learning DFIR, learn mobile forensics, and do it without selling out to them. Reduce what they can sell to you and break the gatekeeping the sector has.
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.
More information on how it would be phrased can be seen here: https://grapheneos.org/faq#trademark
nostr:npub1c9d95evcdeatgy6dacats5j5mfw96jcyu79579kg9qm3jtf42xzs07sqfm what would be needed to make this a reality?
Someone could build their own OS which can be based on GrapheneOS. It's permissible as long as people don't present it as the genuine GrapheneOS.
The end result still wouldn't be GrapheneOS though, and the security GrapheneOS has cannot be guaranteed on these builds. Some features are also entirely dependent on the hardware like MTE for newer Pixels or the Tensor Pixels USB-C port controls.
There has been the base for it for a while now, bit we expect Desktop Mode to be finalized and functional first.
We are keeping eyes on the improvements. Current reporting is say Android 15 is when this will be ready.
https://9to5google.com/2024/04/04/android-desktop-mode-window-management/
When there is a fully working desktop mode upstream, it will come to GrapheneOS.
If your threat model doesn't account being forced by someone to unlock with your biometric then it is a good choice. It also prevents someone seeing your PIN which prevents certain types of shoulder surfing.
We do not support face unlock on supported Pixels as we do not think they are secure enough. The older generations had dedicated face unlock hardware the current Pixels don't have.
Our second factor unlock will do a combination of fingerprint + PIN. That way they are two separate types of authentication (something you are and something you know).
The secondary factor unlock is especially close to being done though and has been worked on by a community member who we plan to hire.
Not yet. Both this and duress password are being worked on and most are close to being done but there is also other priorities like Pixel 8a too. Hopefully it is soon.