Self Destruction After 10 Incorrect Attempts Erases and Encrypts Everything

283827262627

I’m unsure why it hasn’t been implemented on GOS, as one of the first initial security mechanisms

Software throttling / limits can be bypassed. We don't do security theater. The hardware-based throttling provided by the secure element is what provides this properly already

And if you add an alphabetical-number password, your phone is safe

A random 6 digit PIN is secure unless the secure element is compromised. A strong random passphrase is useful to avoid depending on the secure element. A low hard limit on number of attempts by the secure element would make a random 4 digit PIN quite secure but that's not what the hardware does and it's no good to do this via software. There's already a standard Android software mechanism that's not actually useful which is why it's only exposed to device managers.

283827262627 It's not a secure approach and therefore Android doesn't expose it in the standard interface. GrapheneOS isn't going to change that because it's the right approach. Android implements it for use by device managers because of demand for it. We strongly recommend against using a device manager to configure this because it as we explained above, a software implementation can be easily bypassed in the relevant thread model and doesn't truly work.

There's already always-enabled, aggressive hardware-based throttling which quickly throttles up to 1 day between each attempt after 140 failed attempts. This is what makes a random 6 digit PIN secure. It's always enabled and doesn't pose any risk of data loss as long as you don't forget your PIN/passphrase. The secure element COULD implement a configurable fixed number of attempts, but it doesn't currently do that. Either way, bypassing a random 6 digit PIN or better involves compromising the secure element, just like bypassing a fixed limit on the number of attempts. Your assumption that the approach used by the Pixel secure element is easier to bypass isn't correct. It is true that if the secure element supported setting a fixed limit, it would allow using a random 4 digit PIN with decent security, but it's not supported and software cannot implement what needs to be a hardware-based feature.

If you want to protect against brute force, you need at least a random 6 digit PIN to provide a high level of security based on the secure element throttling. If you want to entirely avoid dependence on hardware-based security, then you need a strong random passphrase such as around 7 random diceware words. That's very impractical for anything but a secondary user for particularly sensitive data unless you're using biometric secondary unlock.

For everything in between a random 6 digit PIN and a truly strong random passphrase not depending on hardware security to outright prevent brute forcing, it's more complex. There are multiple software and hardware-based features designed to stretch the benefits of a weaker passphrase: scrypt-based key derivation in the OS, the secure element throttling (Weaver) and finally hardware accelerated, hardware-bound key derivation by the TEE using the outputs from the OS and secure element. The secure element throttling is very aggressive so it works with a random 6 digit PIN. The scrypt usage by the OS and the TEE hardware accelerated, hardware-bound key derivation are only really useful with a passphrase. Even if the secure element does get compromised by an attacker, they still have to brute force, and the TEE feature prevents them brute forcing faster than the rate supported by the TEE unless they can bypass that feature by extracting the key from hardware if it's implemented as intended (physical extraction or some kind of side channel flaw are required if it's done as intended where the key derivation is keyed based on a key in hardware that's not available to TEE firmware). If they can bypass that feature too, then they're limited only by their available server farm infrastructure, and therefore if you want to entirely avoid reliance on hardware security features, you need a strong random passphrase that's secure simply based on having enough entropy. Around 90 bit is still secure, and there's scrypt + TEE key derivation making that better than simply a 90 bit key. You don't actually need to go overboard with an 128-bit entropy random passphrase but you could.

A hard limit on the number of attempts enforced by a secure element vs. time-based throttling are both bypassed via exploiting the secure element. It's wrong to assume that a hard limit would be more secure. A hard limit requires storing and protecting a persistent counter in the secure element as opposed to requiring a coarse monotonic timer. One of these is not necessarily more secure from tampering than the other. Both are secure element features depending on physical anti-tampering.

An OS can implement a hard limit or time-based throttling, but that's not at all secure against this threat model and is bypassed through compromising the OS or tampering with hardware not hardened against exploitation. For example, an attacker can image the SSD and restore it. Storing a counter on the SSD would be entirely insecure without involving the TEE or secure element to make it rollback protected, and at that point it should just be done properly without trusting the OS...

Android's software-based limit on number of attempts for device managers is not really useful and you if you think you want to use it then you must be misunderstanding something. They made that to satisfy enterprise demands for this feature despite the fact that they approached it in a secure always-on way instead of an opt-in feature with risk of data loss. The approach used by Pixels and other phones implementing Weaver works fine. It's just not a great idea to use a random 4 digit PIN since allowing 1 attempt per day after throttling up doesn't give a high enough margin of protection. The secure element implementing an optional configurable hard limit would let you use a random 4 digit PIN if you configured a low attempt limit, but it doesn't do implement that and you should just use a random 6 digit PIN. GrapheneOS cannot implement an additional secure element feature like this without not only having our own device but also being the ones making the secure element firmware.

GrapheneOS Thanks for the information. How do I change to a six digit pin? I've looked and can't find that. I currently have the standard four digit pin because that was all i was offered.

This is a feature that can I enable/disable or is a system mandatory setting or what?

What about introducing 'under duress' combination that wipes all user data and restores factory settings?

Logically and mathematically Pixel/GOS is fine on this. Emotionally I think people like how iOS does it. Either way, if the guv really wants in and really wants to spend the money, they will get in over a few weeks or months at worse by paying big bucks to someone who can crack it. You or me, no worries.