Feature Request: Secure Erase Phone After x min/hours of not signing in

PrivacyEndGame

Duress password does not go far enough to save you from your device being cloned, confiscated before it can be entered, or a high level threat holding your device in an unpatched state long enough until an inevitable exploit to unlock it is found. Its also critical for those who don't wish to be punished for putting in a duress password instead of the real password who would need the duress password the most out of all of us in the first place.

By allowing the phone to securely erase itself after 10 minuets, 1 hour, 5 hours, or 10 hours or a time of your choosing of not putting in your password/fingerprint to unlock, it makes GrapheneOS truly a more secure and private phone. This is an additional feature to duress pin and the best part is that the underlying secure erase technology is already baked in for future use cases like such. Its also very much a feature in line with auto reboot style of design.

During the normal course or the day when you inevitability will need to keep your device locked for longer than usual, say to go to bed or tend to something important, you can enter in a third password that will pause the secure erase timer until you're ready to renter the password to re-activate the secure erase feature. First password is your normal password, second one is your duress pin/password, third password is to pause and unpause this feature. This would be a game changer for those of us who need the assurance of a phone that can truly protect our privacy and security to the highest level and further showcases the level of commitment GrapheneOS has to being the most secure and private phone on the planet for all levels of protection.

Ammako

PrivacyEndGame or a high level threat holding your device in an unpatched state long enough until an inevitable exploit to unlock it is found

This is only a concern if your encryption is weak.

In BFU, they need to be able to decrypt before they can do anything. An inevitable exploit can't just magically find the decryption key. It would have to be logged somehow, or bruteforced.

It's not going to be logged, because you're not there to enter it. So it would need to be bruteforced. The encryption uses a combination of a hardware-backed key + your unlock method, so even if you had a 1-digit pin, they can't just dump the data from the chip and bruteforce it on a computer. It needs to be done on-device, so the key from secure element is accessible.

If you were using a very short PIN (2-3 digits), that can be bruteforced in a reasonable amount of time with no exploits. A PIN of 6 digits in length is revommended because the throttling means you can't bruteforce 6-digits in a reasonable amount of time.

But there can be vulnerabilities that would allow bypassing the throttling, as you know. So use a long passphrase instead of a PIN. Then it doesn't matter what exploits ever come out, unless the attacker was able to log your passphrase, they're not going to be getting in. A sufficiently long passphrase would take millions of years to bruteforce even if the throttling were to be bypassed.

But a sufficiently long passphrase isn't convenient, that 1) takes a long time every time you need to unlock, and 2) every time the password has to be entered, there is a risk that prying eyes could read as you are entering it (especially in public places, or other private spaces that aren't your own home.) Fortunately, you can set fingerprint unlock to be used as a secondary unlock method. So you would have a strong passphrase keeping storage secure, while being able to easily unlock with one tap.

But then you'd be vulnerable to law enforcement requiring you to unlock, because it's a fingerprint and not a PIN. This is part of the reason why GOS is planning on adding the option for a second factor PIN to go with fingerprint unlock.

So the idea is that you have a strong passphrass to keep your storage securely encrypted, that you only need to enter once while at home after a restart, and every time you need to unlock in AFU, you touch with your fingerprint and then enter a short PIN. Autohreboot nearly guarantees you will be put back into BFU if the device is seized, the storage can't be reliably decrypted even with throttle bypass, you don't lose usability in daily use, and you can't be required to unlock it because of the PIN.

https://github.com/GrapheneOS/os-issue-tracker/issues/28

It's not implemented yet and I don't know how far along progress has come for it, but somebody very recently opened pull requests for it. With any luck, their code meets GrapheneOS quality standards, and it can be available in an update soon.

AlphaElwedritsch

Very bad idea

DeletedUser69

What happens when your device gets seized in "paused" state while you sleep, won't you be back at square 1? Think this through properly mate.

PrivacyEndGame

DeletedUser69 One idea is that you can select if you want the third password to temporarily pause this feature all together until you re-enter the third password or you can have the third password simply add more time to the timer by say 8 hours or a time of your choosing so that the feature is always active, just delayed in worst case scenario but even then its still a better way of secure erasing then not having the feature available to those who need it at all.

fluxcondensator

DeletedUser69 Yeah a "pause" password seems unnecessary.

Dumdum

https://github.com/GrapheneOS/os-issue-tracker/issues/4310

PrivacyEndGame

Dumdum eventually the phone will be reconnected back to its battery in order to be unlocked, once the clock realizes its been that long since when it was last operational, one of its first's actions will be to secure erase instead of asking for password.

PrivacyEndGame

Dumdum more powerfully for most people, it will also take awhile for someone like law enforcement to even consider removing the battery as a necessary option which by then many hours or days have gone by for the phone to have time to secure erase itself if a perfectly designed method to deal with this is problematic. A fingerprint/password to shut down the phone or disconnect cellular from lock screen works well for robbers as well to prevent law enforcement from just turning the phone off in the mean time.

PrivacyEndGame

Ammako thank you for this reply. The long passphrase not being exploited is reassuring to know that this feature won't be necessary to have exploit protection. However that said, the primary reason to want it is still a serious concern of mine. Especially with fingerprint plus pin unlock where it becomes even more difficult to say idk to what the short pin is.

In many countrys they can compel you to hand over pin and password or face jail time. In USA you can even be held in contempt of court if a judge rules you need to hand over the passphrase/pin since supreme court has not ruled on this yet. So even for USA citizens, having the ability for the phone to erase itself after multiple hours is still an extremely important feature to have as you can't compel someone to give a password to something that no longer exists. Duress pin would be clear destruction of evidence. Duress password really only helps as a quicker way of erasing your phone then anything else right now for those who truly need the protection. I hope something can be worked out. Even in USA there have been cases where judges will hold you in contempt in jail without yet having a trial found guilty until you remember the password. A secure erase feature will help tremendously in this regard to the original intent of the duress password feature.

Blastoidea

PrivacyEndGame
We have a saying here.

“All you have to do is prove your innocense, and you can be on your way.”

Ammako

PrivacyEndGame and you think that the phone getting factory reset would save you from jail time, in that scenario?

missing-root

Turn off USB either when locked or entirely
Auto-reboot timer
Strong pin
The "pin+biometrics" feature we are waiting for
User profile, so a second pin needed.

JollyRancher

Ammako
In the US it would. Say your phone will factory reset after 24 hours without the password being entered.

The police seize your phone. Then they need to get a court order from a judge ordering you to unlock your phone. Then they need to serve that court order on you. Then you request to consult with your lawyer on whether or not you need to obey the court order. Your lawyer also files an emergency appeal of the order on any grounds good enough to not risk court sanction.

Even assuming that you have to turn over the password eventually, getting it dragged out long enough to exceed the reset time is more than possible.

Use of a duress pin is spoliation of evidence and the court gets to assume that the destroyed evidence is as bad as possible for your case.

Use of a duress feature set before you have knowledge of the legal proceedings and triggered without any input from you is not destruction of evidence.

You also can't be held in contempt of court for refusing to obey a court order as you are willing to provide the password (doing so is just meaningless now).

Being able to set the duress feature as a deadman switch set to trigger after a period unless reset would actually be a material improvement for several threat models.

PrivacyEndGame

If after x min/hours/days of not signing in is too problematic because of the device being powered off or battery removed, what about resting the phone the next time it powers back on if its been powered off for more than x days or minutes even. Phone keeps track of it being on while on, if when it turns back on there's been a long lapse, it will begin erasing itself since eventually you'll need to turn it back on to get into it.

Alternatively, albeit even stranger, if you pick up the phone the wrong way it resets itself using its gyroscope and motion sensors. Like how in the movies if you touch the computer wrong it explodes. You have to pick up your phone a certain way, which you demo to it while setting it up which acts like another password, and if anyone trys to pick it up any other way it will cause it to reset before they can even get to removing its battery from it.

AlphaElwedritsch

you're serious about all this, right?

Upstate1618

https://github.com/GrapheneOS/os-issue-tracker/issues/4512