Anyone know if there's a way on Grapheneos to have phone wipe after x failed pin or password attempts ?
Discussion
#grapheneos
@Majere may know.
I don't think so. In theory the secure element should rate limit attempts to mitigate a brute force attack.
I've heard there are plans for a duress pin that will wipe the device instead of unlocking it.
There's also Ripple, which is a panic button that will notify other apps to take some action such as locking, logging out, deleting all their data, and I think even uninstalling themselves.
Finally, there's the automatic reboot, which will remove the decryption keys from memory to mitigate attacks such as "steal someone's phone, make sure it can't grey updates and then wait for a vulnerability to be announced so you can exploit it to gain access."
None of these are specifically what you are asking for, but they might be something that you can use to address your concerns some other way.
Replying here so I can do two in one:
GrapheneOS does not have such a feature yet but a PN/password that erases the device is being worked on. Oftentimes people use an app like Wasted, Duress or similar which allows a trigger to erase the device via device admin. We never recommended these because all these duress features that people sell or make apps for in this method can be easily bypassed by holding the Volume Down button when the trigger happens to boot to Fastboot and cancel it. We have a video by a forensics company (MSAB) instructing how to perform this bypass, it has been common knowledge for ages.
This is why this work has took longer than people think, because the way GrapheneOS does it should not be cancelled or bypassed. It has to be new.
The automatic reboot covers a threat actor seeking to attack a device by taking advantage of it being in an AFU state. This is not the only protection we have on offer. The very new USB port controls are another. The hardware-backed rate limiting via the Titan M2 is a part of the benefits of the hardware we support. The longer passwords also means having ones so long you cannot brute force (providing the entropy is great!)
Regardless of autoreboot, your phone won't get any updates if seized. They could wait and see if they can exploit in the future... but if a phone is in BFU their work becomes harder. They'd need to find a way to exploit the tamper-resistant secure element to even think about getting through brute force protections most likely.
Thank you Dr. Hax and final. So I've garnered that the device with a sufficiently secure password will protect itself by the secure element with autoreboot and rate-limiting features. Feels better understanding with more clarity how that works, and that I can be more at ease with the secure element to protect against possible shenanigans.