answered
2019-07-29 11:21:54 +0200
Some background info / rationale for how it is ...
Unlocking device happens in context of unlock UI - which has been designed with lock code entry in mind (i.e. it is active only when interaction with user is possible) -> implicitly requires that display is on before unlocking can happen.
Waking up device happens and must happen under mce control, and is governed by various policies involving proximity sensor, call state, alarms, etc.
So the first decision that needed to be made was either to make unlock ui & mce to share a lot of state data - which takes design and development time and adds complexity which then makes mishaps/errors in security critical area more likely, or handle "fingerprint wake up" as something completely separate from "fingerprint unlock" -> the latter was chosen (well, it was also the only option that was feasible development time wise).
Now then, when handling such separate "fingerprint wake up" one must consider things like:
Whether/when it can be activated -> Activation policy is handled in device specific configuration files depending on scanner behavior in suspend, power consumption, (proximity) sensor reliability, etc. (#1)
Whether it should act on any fingerprint or only on registered ones: Allowing anything resembling a finger to wake up the device would both make pocket calls etc more likely and actually be more complex (and possibly more power hungry too) to implement than using only registered fingers ...
Limiting wake up attempts similarly to unlocking has some issues too: Due to separation of wake up vs unlock the counters would need be separate too i.e. we could end up in situation where one is active while the other one has gotten disabled - how would one indicate such situations to the user, especially when no visual clues can be used for wake up part (display is off after all) -> wake up attempts are not limited - at least for now.
Also noteworthy: Unlocking with fingerprint is possible also from "Sneak peek" aka "glance ui" aka "lpm". Which means that in devices that have a fingerprint scanner and which do support lpm -> Taking phone out of pocket / stte will wakeup the display -> Placing the finger on scanner will unlock the phone -> Single press unlock is possible. Unfortunately, due to problems with proximity sensor, lpm is more or less defunct in some devices such as XA2.
note#1: Users can tweak these values with mcetool, execute mcetool fingerprint-wakeup to list relevant options.
It is never a good idea to use the fingerprint to unlock. Where is the problem to enter an unlock code?
4carlos ( 2019-07-21 07:36:39 +0200 )edit@4carlos, that's personal preference. I'm aware of the risks, but I prefer the ease of access. Either way, it has nothing to do with this issue.
Fuzzillogic ( 2019-07-21 11:48:04 +0200 )editI don't understand the problem. You still cannot unlock the phone with your registered finger once the 5 tries has passed. Let me put it differently: What is the difference between using the power button or a registered finger to wake the display? Either way, the phone is still locked. Having false-positive registers when the display is off could happen easily (And thus more than 5 times) with the phone in a pocket for instance.
Nova ( 2019-07-26 10:39:12 +0200 )edit@Nova by that logic there isn't any need for a maximum number of retries at all. However, the fingerprint reader can give false positives, as in, an unregistered print passes a registered print.
Fuzzillogic ( 2019-07-26 18:29:36 +0200 )edit@Fuzzillogic :
What threat model are you thinking about ?
Somebody trying to bruteforce the fingerprints by repeatedly 3D-printing fingerprints until they find a match/false positive, (which won't open the phone anyway because it's going to be way more than 5 attempts) and then they return the phone, hoping that the target won't notice the absence and will unlock the phone with PIN (which will reset the prints counter), at which point the attacker must re-steal the phone and unlock it with the false positive to finally gain access?
(Or am I missing a more obvious less contrived threat?)
Because if you're fearing an attacker that is motivated enough to jump through all these hoops, you're a major target and thus should shouldn't rely on flimsy security like PINs and fingerprints, but should better use encryption and long random passwords (and physical key if possible).
DrYak ( 2019-07-27 11:23:33 +0200 )edit