GrapheneOS / os-issue-tracker

Issue tracker for GrapheneOS Android Open Source Project hardening work. Standalone projects like Auditor, AttestationServer and hardened_malloc have their own dedicated trackers.
https://grapheneos.org/
360 stars 21 forks source link

add support for setting a PIN as a 2nd factor for fingerprint unlock #28

Open thestinger opened 5 years ago

thestinger commented 5 years ago

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.

jengo9332 commented 5 years ago

@thestinger has the old split boot/lockscreen password been migrated to GrapheneOS?

thestinger commented 5 years ago

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:

https://developer.android.com/reference/android/security/keystore/KeyProtection.Builder.html#setUnlockedDeviceRequired(boolean)

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.

throwException commented 1 year ago

Might I (and hopefully others) put out a bounty to motivate some developer to implement this?

(I have no experience with such bounties yet)

lepras commented 1 year ago

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.

u-fred commented 8 months ago

Will start on this soon.

Foxtrek64 commented 8 months ago

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.

matchboxbananasynergy commented 8 months ago

It will be a PIN.

thestinger commented 8 months ago

@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.

throwException commented 8 months ago

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.

thestinger commented 8 months ago

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.

Foxtrek64 commented 8 months ago

Thanks for the info! I look forward to seeing a PR on this.

schrauger commented 4 months ago

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!

thestinger commented 4 months ago

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.

nyaasi commented 3 months ago

Just to make sure, but the duress pin is still functional with the intended 2nd factor and will wipe the device, right?

thestinger commented 3 months ago

It will be, yes.

ZLima12 commented 2 months ago

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:

  1. Device running GrapheneOS is set up using a weak pin as the main unlock method.
  2. An attacker learns the pin.
  3. The device's unlock method is changed to a strong passphrase.
  4. The attacker gains access to the device.

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.

thestinger commented 2 months ago

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.

MichaelDevon commented 1 month ago

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.

richardebeling commented 1 month ago

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.

thestinger commented 1 month ago

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.

secretmango commented 2 weeks ago

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.