Open thestinger opened 5 years ago
@thestinger has the old split boot/lockscreen password been migrated to GrapheneOS?
That feature is obsolete and isn't applicable to modern Android. It hasn't existed for years. There's no such thing as a boot password on devices with the modern encryption format introduced with 1st generation Pixels. There are per-profile encryption keys, not a global encryption key and they can become at rest again when profiles are logged out. Fingerprint unlock is an existing implementation of a secondary unlock mechanism available after the initial unlock until a timeout expires. This issue is about extending it with support for a PIN as a far superior successor to the obsolete approach. It's not implemented which is why it's an open issue. This is the replacement for the obsolete feature, and will have strictly better security properties along with significantly better usability.
The primary unlock mechanism (which should be set to a strong passphrase) is used to derive the main encryption key for the profile and is always required for the initial unlock of the profile. The secondary unlock mechanism can then be used until it times out. Both the primary and secondary unlock mechanism are used to protect the keystore. Keys can be set to be usable only when the profile is unlocked in order to keep them at rest when it's locked:
I hope this makes sense. The legacy feature you're talking about cannot exist anymore and this issue is about implementing a superior replacement that fits into the new system.
Might I (and hopefully others) put out a bounty to motivate some developer to implement this?
(I have no experience with such bounties yet)
after some searching I found these:
Can I make Android require Fingerprint + PIN to unlock the screen? | StackExchange
Lockscreen and authentication improvements in Android 11 | GoogleBlog
Better Biometrics in Android P | Google Blog
One Biometric API Over all Android | googleBlog
will dig deeper and find some API's that we can use and come up with a design.
Will start on this soon.
A bit of an implementation question. What second factor options are we looking at allowing here - just pins? Or would we allow passphrases or patterns as well?
Primary security is through the fingerprint, so I imagine the security of the secondary factor would not be as important as the first factor.
It will be a PIN.
@Foxtrek64 The intention is for people to use this by setting a strong passphrase as their primary unlock method and fingerprint + random 6 digit PIN (or similar) for secondary unlock.
Yes, a PIN makes perfect sense, if this quick method is locked out after only a few tries.
The number of tries should be configurable as it heavily depends on the use case as well as the length of the PIN.
The lockout should be lifted as soon as the primary passphrase unlock is entered correctly.
There should be the option to scramble the PIN entry layout.
It already only allows 5 tries, resets after using primary unlock and already has PIN scrambling. This is not an entirely new feature. Fingerprint unlock already exists and PIN unlock for primary unlock already exists. This is simply about adding support for adding a PIN to fingerprint unlock.
Thanks for the info! I look forward to seeing a PR on this.
after some searching I found these:
Can I make Android require Fingerprint + PIN to unlock the screen? | StackExchange
I remember that question! At the time, I came up with a somewhat convoluted and not-exactly-secure solution using Tasker. I'm really looking forward to this upcoming feature in grapheneos. It's one that I have been wanting for nearly a decade!
https://github.com/GrapheneOS-Archive/legacy_bugtracker/issues/451 was the initial issue we filed about it and that was long after we came up with it as a potential feature. We simply didn't used to have the resources to do things like this.
Just to make sure, but the duress pin is still functional with the intended 2nd factor and will wipe the device, right?
It will be, yes.
To clarify, the intended functionality would allow using a passphrase as the sole means of deriving the encryption key, while then requiring both a pin and fingerprint (after first unlock) to avoid entering the full passphrase? Will the implementation also allow for maintaining the existing behavior (fingerprint alone is sufficient unless >=5 failed attempts), while still using a passphrase for the main unlock method?
Additionally, consider the following events:
I am guessing that this is fully handled, but I wanted to confirm that there is no way for the attacker to obtain the encryption key in this scenario.
To clarify, the intended functionality would allow using a passphrase as the sole means of deriving the encryption key, while then requiring both a pin and fingerprint (after first unlock) to avoid entering the full passphrase? Will the implementation also allow for maintaining the existing behavior (fingerprint alone is sufficient unless >=5 failed attempts), while still using a passphrase for the main unlock method?
It doesn't change anything about primary unlock. It only adds the option to add a PIN as a 2nd factor required for fingerprint unlock. There's nothing mandatory about the feature and it doesn't change normal use of fingerprint unlock. We aren't doing anything weird like that.
I am guessing that this is fully handled, but I wanted to confirm that there is no way for the attacker to obtain the encryption key in this scenario.
That is handled perfectly fine. The disk encryption keys are randomly generated and old key encryption keys can't be derived.
I recommend implementing this in a way that it prompts for the PIN before the fingerprint. It would make it easier in duress situations to trigger the wipe, by telling the PIN instead of them having to wait for you to unlock with a finger which would be a 2 step process instead of 1. This would also make the duress feature more reliable in case the user's finger being accidentally rejected by the scanner. Attackers are also more likely to be confused by seeing a password prompt instead of a pin and might suspect the user of planning something.
Note that some users are asking for the PIN as an alternative to the fingerprint, not as an additional factor
These require more degrees of freedom for the user to configure combined authentication methods than just adding a second PIN-factor to fingerprint-AFU-unlocking. It would be nice if this issue could reflect that.
We don't see a very good reason to support a PIN for secondary unlock rather than fingerprint+PIN.
I would also like to have that feature, for situations where fingerprint detection stops working for whatever reason (sweaty/dirty hands, injury, fingerprint sensor broken, ...)
You can always just use the primary unlock method.
You need to understand that each implemented feature is another feature which will not be implemented. Another feature has to be effectively cancelled in order to add something else like what you're proposing.
Yes, fingerprint + pin/password is the best combo
Fingeprint is secure but can be forced
Password cannot just be forced but can be spied on with CCTV cameras etc.
There should be the option to add a second factor to fingerprint unlock. This would allow using a strong main passphrase paired with a weaker PIN usable only via fingerprint unlock when it is applicable (not the first unlock and within a certain time period). Fingerprint unlock is the only convenient way to use a strong encryption passphrase right now, and building upon it would result in a better final result than simply a secondary unlock PIN alone.