Clueless I wondered about that: I have play services installed and am logged in to my Google account. Will it be FRP locked to make it worthless for the thief? Or is that function removed in GOS? I suspect the latter since it would Google services to be deeply integrated into the system, right?
https://grapheneos.org/faq#anti-theft has the information you need. :)
matchboxbananasynergy Hello, I don't understand why i need to set a duress PIN and a duress password? Why not just PIN?
User11 it could be for users that use a passwords instead of a pin when unlocking their phone. I think the wording might be a bit confusing :)
@matchboxbananasynergy @GrapheneOS I just updated a Pixel 7a to 053100 release on the beta channel. I tested setting a Duress Pin and Password in the Owner profile and entering it in a new secondary profile. The lock-screen gave me the little incorrect pin shake then the device immediately shutdown. On turning the device back on it didn't boot into the normal GrapheneOS boot mode, but instead to a GrapheneOS Recovery mode where it said user data was corrupted then offered to try to boot the OS again or Factory Reset the device. After factory resetting it gave me the New Install setup screen. Is the Recovery mode message intended? This seems to clearly indicate the user wiped the device with the Duress feature (rather than the device is new/unused) and makes it unattractive to use in jurisdictions that criminalize deleting data i.e. USA.
Is it a matter of once the device is in a new state the adversary could just check for the remnants of an encrypted filesystem on the storage media and use that as evidence of the device being wiped (even if decryption is no longer possible due to destruction of key material)? It seems to me the feature has the most utility for users that calculate that the punishment the adversary enacts is more desirable than getting access to the data. For example a political dissident that believes their torture, imprisonment, or execution to be preferable to that of their network exposed via their devices contents. Or when one knows the prison term for obstructing an investigation/deleting data is less than the term for incriminating evidence on the device.
I like that GrapheneOS gives users the option to protect the confidentiality of their data in this urgent and final manner. Kudos to all the devs that designed and implemented this feature.
Edit: Addtionally a Duress Pin/Password can be set even when there is no pin or password lock set.
I tried duress pin and it worked as intended .
Thank you for all your hard work in developing the duress feature!
Even though my threat model does not really require this feature in the classic sense, I find the suggestion to use it against phone snatchers quite helpful: I personally don't want to give Google or other apps the invasive permissions a rempote wipe feature would require, but if I can use the duress feature and such a feint to increase the probability that a potential thief triggers the wipe himself, I think that's great (if he wipes the device anyway to sell it, even better - I personally am more interested in my personal data than in getting my phone back).
I also found xxx hint that a short duress password/PIN triggers the wipe in the event of a brute-force or dictionary attack to be a very handy side effect.
Agility8200 This seems to clearly indicate the user wiped the device with the Duress feature
Does it? The message does not say that the device is wiped, only that data is corrupt. Of course, one shouldn't be fooled into thinking that an adversary who is well aware of the duress password feature and how it will display once triggered, will think that the device somehow became corrupted for some inexplicable reason. But it could fool a simple thief or an abusive partner who are not aware of the feature. Most people have never heard of GrapheneOS, and to them it's going to look like the device is failing inexplicably.
The feature isn't theater to try and fool people. It doesn't explicitly say a wipe occurred, but it's not trying to hide it either. Anyone who thinks about it can likely realize what happened. The goal is making so the data can no longer be accessed. It's meant to help in situations where danger to someone can be reduced if there's no longer data to provide. People should of course be responsible and threat model accordingly.
That said, a journalist with sensitive data/sources that they don't remember wiping their device to make that data no longer available might be in a better spot than someone just refusing to provide the password to unlock it. If you're removing the incentive of the attacker to harm you, they might stop. Again, and I cannot stress this enough, everybody should very carefully assess the situation. GrapheneOS is providing a reliable and thorough way to trigger a wipe of your phone's data. How people use the feature (some ideas have already been floated in this thread) is up to them.
The DURESS function works perfectly.
Many thanks.
On the other hand, if you could one day add a wipe after X false attempts, based on the same code, that would be wonderful.
I've seen that you're working on a 2FA system with PIN + BIOMETRIC. Personally, I use a DICEWARE PASSWORD for the owner profile + a user profile with PIN.
Will the 2FA system be for secondary profiles in BFU or is it just for AFU?
The 2FA with biometrics is very interesting if we can completely remove the possibility of adding or modifying a fingerprint. Because even if the password has been communicated, an attacker won't be able to change it and will still need the user to look at the phone.
xxx Brute force attacks are always prevented by the secure element's throttling if you have at least a random 6 digit PIN. The throttling is explained here:
https://grapheneos.org/faq#future-devices
This throttling is implemented by the secure element and therefore cannot be bypassed by restoring OS data on the SSD or exploiting the OS, unlike an OS-based counter for unlock attempts. Bypassing this requires a secure element exploit, which is astoundingly more difficult than an OS exploit to the point that Cellebrite has not figured it out for the Titan M2 (Pixel 6 and later) yet even with an older version. They did figure it out for the Pixel 2 NXP secure element and Titan M1 (Pixel 3 through Pixel 5a). They bypassed it on Samsung phones and Apple's comparable feature up until the iPhone 12 too. They'll likely bypass it on newer Pixels and iPhones eventually. If you want to prevent brute force even if an attacker exploits the secure element, you need a strong passphrase, which we'll be making more usable without resorting to fingerprint-only secondary unlock via 2-factor fingerprint unlock support where you can add a PIN to it.
Duress PIN/password is an OS feature without secure element support. An attacker successfully exploiting the OS can try the duress PIN/password without risking a wipe since they can control the OS. In theory, the secure element could implement duress PIN/password support by having a 2nd authentication token for each Weaver slot which wipes the Weaver token instead of providing it. There's no way for GrapheneOS to implement this without having our own hardware where we can add secure element features. We can explicitly document this in the future usage guide section.
Thank you. So secure element's throttling does the job. I thought
a 2 digits DPin would trigger the deleting long before throttling?
Or am I wrong?
Does this work in safe mode?
Also wondering, is there a possibility in the future to allow disabling entering fastboot mode? For someone who is super paranoid, doesn’t care if their device may one day brick and become unrecoverable, is it possible to make a toggle that disables fastboot mode completely and locks that option with a pin or something?
