Windows using different fingerprint IDs - WINBIO_FINGER_UNSPECIFIED_POS_##

[kageurufu]

trafficstars

% fprintd-list %USER
found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
Fingerprints for user frank on DBus driver (press):
 - #0: WINBIO_ANSI_381_POS_RH_MIDDLE_FINGER
 - #1: WINBIO_ANSI_381_POS_RH_INDEX_FINGER
 - #2: WINBIO_ANSI_381_POS_RH_RING_FINGER
 - #3: WINBIO_ANSI_381_POS_RH_LITTLE_FINGER
 - #4: WINBIO_ANSI_381_POS_RH_THUMB
 - #5: WINBIO_ANSI_381_POS_LH_THUMB
 - #6: WINBIO_ANSI_381_POS_LH_INDEX_FINGER
 - #7: WINBIO_ANSI_381_POS_LH_MIDDLE_FINGER
 - #8: WINBIO_ANSI_381_POS_LH_RING_FINGER
 - #9: WINBIO_ANSI_381_POS_LH_LITTLE_FINGER
 - #10: WINBIO_FINGER_UNSPECIFIED_POS_01
 - #11: WINBIO_FINGER_UNSPECIFIED_POS_02
 - #12: WINBIO_FINGER_UNSPECIFIED_POS_03

I set up by getting my SID from windows, and then setting up my fingerprints under linux. When I rebooted to windows, it recognized I had fingerprints configured but would not accept them. I logged in with my pin, and added fingerprints from within Windows and it created these unspecified positions

I booted back to linux, and got a TLS error:

Sep 25 08:48:45 ScalaAdCaelum python3[1241]: DEBUG:root:>tls> 17: 050200
Sep 25 08:48:45 ScalaAdCaelum python3[1241]: DEBUG:root:>cmd> 170303004066f093c81f41b946e24a1ade763b07bb79161ad093e473c6b883c997378d2216f1f6812919f71c3bca5fe2061f42f73ec0d9fe6647bd0e70062043097891fcff
Sep 25 08:48:45 ScalaAdCaelum python3[1241]: DEBUG:root:<cmd< 0404
Sep 25 08:48:45 ScalaAdCaelum systemd[1]: Stopping python-validity driver dbus service...
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]: Error in atexit._run_exitfuncs:
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]: Traceback (most recent call last):
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:   File "/usr/lib/python3.8/site-packages/validitysensor/init.py", line 21, in close
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:     reboot()
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:   File "/usr/lib/python3.8/site-packages/validitysensor/sensor.py", line 80, in reboot
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:     assert_status(tls.cmd(unhex('050200')))
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:   File "/usr/lib/python3.8/site-packages/validitysensor/tls.py", line 122, in cmd
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:     rsp = self.app(cmd)
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:   File "/usr/lib/python3.8/site-packages/validitysensor/tls.py", line 152, in app
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:     return self.parse_tls_response(self.usb.cmd(self.make_app_data(b)))
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:   File "/usr/lib/python3.8/site-packages/validitysensor/tls.py", line 351, in parse_tls_response
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]:     raise Exception('Unexpected TLS version %d %d' % (mj, mn))
Sep 25 08:48:45 ScalaAdCaelum dbus-service[1241]: Exception: Unexpected TLS version 4 0

I returned to windows, let updates install, and then returned to linux, and now it functions fine again. Windows still will not recognize any but those three unspecified fingers, although linux verifies fine

[uunicorn]

When I rebooted to windows, it recognized I had fingerprints configured but would not accept them

I guess that is intended. SIDs are no secret. Do you really want anyone being able to boot from an Ubuntu live CD and enroll their own fingers to login to your computer? To counter this type of attack Windows is using blobs encrypted with SYSTEM account's key. The blobs are attached to enrolled templates. When a sensor positively matches a template, Windows tries to decrypt associated blobs. It only allows a user to login if a blob exists which was successfully decrypted and contains a matching template hash and a target account SID.

Ideally, Linux should do something similar, because right now it is vulnerable to an attack mentioned above. That would probably require some UI changes though: whenever you try to login with a finger enrolled on another OS, Linux should ask for a different type of authentication (similar to how Windows asks for a PIN) so that it can establish that this template is authorized to login to this computer.

I booted back to linux, and got a TLS error:

This looks like a "normal" restart of a python-validity service after laptop suspend/resume. I think it should be more reliable and less spamy now with the latest combination of open-fprintd and python-validity which I've pushed yesterday.