xcancel.com/niemerg/status/2081832… This proposal wouldn't hide that a wipe occurred and would help adversaries exploit and recover data from the device. It isn't a new idea and people have proposed variations of this hundreds of time for years. These proposals wouldn't hold up against widely available forensic software. Giving an attacker access to a decoy profile would make it far easier for them to exploit the device. Without a shut down or reboot, a device was previously in After First Unlock state would be very vulnerable to having data extracted. GrapheneOS has strong protection against data extraction without depending on a duress PIN/password. The default enabled protections combined with a strong passphrase and 2nd factor fingerprint PIN would have provided fantastic protection for the data on the device. Reducing the device auto-reboot timer would be even better. The secure element would have protected the data with only a random 6 digit PIN instead of a passphrase in practice too. All of our features are designed to work against adversaries aware of GrapheneOS. Our duress PIN/password is no different. Adversaries aware of GrapheneOS face a dilemma about whether a PIN/password provided by the user is going to unlock the device or wipe it. It wasn't designed around being a secret resulting in an unpleasant surprise for an adversary. We also plan to provide it as part of secure element rate limiting on future devices built to run GrapheneOS to prevent bypassing it with an OS exploit. Triggering our duress PIN/password feature wipes both hardware keystores, the secure element as a whole and disk encryption metadata. Each of these 3 steps is enough on their own to reliably wipe material needed to obtain the key encryption keys for disk encryption. It happens nearly instantly and it wouldn't be secure if it took a bunch of time or depended on actually erasing any of the encrypted data. Shutting down the device triggers clearing sensitive data from RAM and registers to complete the process. It's necessary to clear a lot of sensitive data from memory and registers including decrypted encryption keys in TEE memory. Giving an adversary access to a profile on the device instead of shutting down or rebooting would be very problematic. It would give them an immense amount of attack surface for exploiting the device to recover sensitive user data. If the Owner user is in After First Unlock state, the adversary has given massive attack surface for exploiting the device to obtain all of the data from the main user. It would be the extreme opposite of the attack surface reduction and exploit protections provided by GrapheneOS. GrapheneOS and apps running on it could continue to function indefinitely after the key derivation material is wiped. It already has disk encryption keys loaded into Trusted Execution Environment memory and is using those for inline disk encryption via wrapped keys. Only functionality depending on hardware keys would be broken. If there were profiles in After First Unlock state those would still be available. An attacker exploiting the device would recover the same data as before wiping the key encryption keys. Forensic data extraction companies have access to GrapheneOS and we don't have access to their software. We cannot rely on security through obscurity or knowing how their software works including which vulnerabilities they exploit. Fooling widely available forensic software into believing a decoy profile is the Owner user isn't feasible. It would need to provide a fully functional Android Debug Bridge (ADB) environment which is completely impractical. People should consider the fact that they likely haven't thought about this nearly as much as us. There are good reasons for why we designed this feature the way we did and it's working as intended in the real world. The feature becoming widely known about is a requirement for it to work as intended by creating a dilemma for adversaries. The main thing we need now is secure element support for it which we can get implemented for future devices as part of our Motorola Mobility partnership and future OEM partnerships.
“duress” password is incorrectly designed—it shouldn’t be apparent to the attacker that it was triggered and should instead open to an innocuous and data free home screen while nuking everything in the background
Jul 28, 2026 · 5:17 PM UTC
76 231 2,896 160,509
We've seen years of proposals for hiding or stealthily wiping data for years. None of the proposals would work against an adversary with access to widely available forensic software since it's aware of GrapheneOS. It also wouldn't work against an adversary aware of it themselves.
3 1 321 10,332
GrapheneOS doesn't depend on a duress PIN/password to protect against data extraction via exploits. It needs it to protect against coercion. The news coverage will help it provide the intended deterrence. See discuss.grapheneos.org/d/407… for a broader overview of our overall approach.
3 3 237 8,859