Wipe device after failed 10 password attempts

7sec

I understand GrapheneOS uses the Weaver, why it cannot implement an option to allow the user to set a limit of maximum failed passwords. After lets say 10 password failed attempts the device will be wiped.

flawedworld

There is no hardware support for this.

Hathaway_Noa

flawedworld It can be done with an app on Fdroid called 'locker'. You can pick the amount of failed attempts that you would like and it will wipe your device automatically.

flawedworld

That doesn't imply hardware support. It's a poor means of implementing it.

Friedemann

flawedworld

It's a poor means of implementing it.

May I ask what you mean by that?
Like an update from app or GrapheneOS can break the entire setup of locker and fail to reset device after x failed attempts. I hate to be in blissful ignorance to think something is working when its not.

Not using locker atm.

schklom

flawedworld Sorry for necropost, but FYI it can be done to work even BFU using Device-Owner privileges, using e.g. https://github.com/BinTianqi/OwnDroid

Making an app a DO comes with some annoying restrictions, like no Work-Profiles anywhere, and no Private Space on Owner. And Private Spaces on secondary users can get randomly deleted due to some incompatibility.

Novalissoide

schklom This doesn't increase security.

schklom

Novalissoide If it doesn't increase security, I guess you should tell Apple, they're allowing the same thing: https://support.apple.com/en-au/guide/iphone/iph14a867ae/ios while advertising it as security.

Novalissoide

schklom Apple don't let user do this via third party app. Imbedded in the OS, fine, probably well tested for conflicts.

Novalissoide

schklom or do they? Didn't look it up. .

Watermelon

schklom Apple implemented it in the hardware (source). The assumption is that software-based limits are bypassable. The software itself would have to be (and is) verified by verified boot, with the encrypted data tied to the verified OS (and the secure hardware), which requires the hardware to be able to verify the OS securely, so hardware support for encryption is needed anyway.

schklom

Novalissoide The third party app only enables the feature of the OS (and I think ties its state to the app), that's why it works BFU.

It's an AOSP feature that requires a device-owner to enable it, not a 3rd-party feature.

Novalissoide

schklom The third party app only enables the feature of the OS

You said it best yourself;

"Making an app a DO comes with some annoying restrictions, like no Work-Profiles anywhere, and no Private Space on Owner. And Private Spaces on secondary users can get randomly deleted due to some incompatibility".

So it don't only enables the feature of the OS.

schklom

Novalissoide In many ways, it does. It's just that AOSP is written in such a way to only allow certain APIs to apps that are registered as DO.

It's similar to Work Profiles. They're an AOSP feature, but AOSP requires a 3rd-party app like Shelter to manage them. Shelter simply calls AOSP APIs.

In the same way, DO is a standard AOSP feature, and AOSP mandates that Private Spaces are forbidden on Owner when a DO is active, and get prevented (and deleted if any) on reboot (I figured it out, it's not random, just happens on first login) on secondary profiles. And by default, AOSP prevents Work Profiles (it seems AOSP has a way to allow them but it's not trivial so DO FOSS apps aren't prioritising it).

schklom

Watermelon I'm unsure as to how this is different in any way, it's just done by AOSP instead of iOS. The Secure Element isn't in charge of the login screen, it just wipes encryption keys when the OS asks it to, and AOSP decided that this should only be done by a DO and also decided that enabling a DO disables other features.

Watermelon

schklom The Secure Element isn't in charge of the login screen, it just wipes encryption keys when the OS asks it to

False. The Secure Enclave is in charge of necessary material for decryption, it keeps track of the PIN/password attempts it receives from the OS. Have you checked the link? Once again, Apple implemented it in hardware, not in software. What you describe is software.

schklom

Watermelon Ok my bad i guess. I still count that as a security feature though. Not being done in hardware doesn't make this useless, just a little less secure than on ios. It's an OS feature after all, not an app feature.

Novalissoide

schklom

schklom an OS feature after all, not an app feature

Ok, it may in some sense be described as it being an OS feature since an OS feature gets engaged, but adding any complexity to lockscreen, especially via third party user app in Device Owner mode, I think is a big enough stability/predictability tradeoff to still turn out not increasing security.

Consider the work that got into making GrapheneOS duress feature as rugged and foolproof as it is, to the level where we with confindence can assume that a user complaining after unintended duress wiping, that user almost axiomatically caused this by malpractice. If the feature in question gains that level of ruggedness then maybe it'll make more sense.

Watermelon

schklom I still count that as a security feature though. Not being done in hardware doesn't make this useless

The encryption is already tied to the OS running on your hardware (to prevent imaging your encrypted data and bruteforcing it elsewhere, and this would also be needed to store the unlock attempts counter to persist across reboots), and GrapheneOS already by default blocks data communication in the USB-C port when locked, among all the other security improvements. The encryption depends on the strength of your credential and the secure element only in BFU state; in AFU state, it depends only on GrapheneOS's security improvements, to block access to the decrypted data. Recent and recurrent leaks from Cellebrite have shown that GrapheneOS's auto-reboot feature isn't strictly needed yet, because GrapheneOS successfully holds up even in AFU state. So it might be worth considering.

Watermelon

Novalissoide foolproof

I don't think it's good to call a feature that depends on something occurring in future, which in turn depends on the functioning of the device, foolproof. Consider the auto-reboot feature: Power lost? The data would disappear from the RAM over a short time, and immediately erased by GrapheneOS on boot. Init process crashed? Reboot. Kernel crashed? Reboot. Now consider the duress PIN: Power lost before the OS registered the PIN attempt? Not erased. Kernel crashed before the OS registered the PIN attempt? Not erased. Etc.

Although I agree that that user was a troll.