Skip to content

Add Kensington VeriMark IT (Synaptics Tudor, 047d:8054) support - #276

Open
Rambomst wants to merge 1 commit into
uunicorn:masterfrom
Rambomst:verimark-it-support
Open

Add Kensington VeriMark IT (Synaptics Tudor, 047d:8054) support#276
Rambomst wants to merge 1 commit into
uunicorn:masterfrom
Rambomst:verimark-it-support

Conversation

@Rambomst

@Rambomst Rambomst commented Aug 4, 2026

Copy link
Copy Markdown

The VeriMark IT is a different device family from the Prometheus sensors and needs its own bring-up:

  • it takes ownership with a 0x93 command carrying a host-generated ECDH key (persisted under /var/lib/python-validity so it survives reboots) instead of the flash-based pairing;
  • the TLS record layer is AES-256-GCM with a mixed SHA256/SHA384 handshake (CertVerify signs a SHA256 hash, Finished uses a SHA384 PRF);
  • enroll, on-chip 1:N identify and delete all run on the device, and a match returns only a 16-byte template id, so which user and finger a print belongs to is tracked host-side.

tls.py gains an opt-in AES-GCM path plus the SHA384-PRF and mixed-hash Finished hooks; the existing CBC/HMAC path is unchanged (the new behaviour is guarded so it defaults to the old values). tudor.py is the device driver: pairing + GCM bring-up, on-chip enroll/identify/delete (TudorSensor) and a host-side identity store (TudorDb). init.open() dispatches to it for 047d:8054 and specialises the sensor/db singletons in place, so the fprintd dbus-service is unchanged. usb.py and the udev rule register the device.

Reconstructed from captured Windows-driver traffic and tested end to end via open-fprintd (fprintd-enroll / fprintd-verify / PAM login) on a real reader.

The VeriMark IT is a different device family from the Prometheus sensors and needs its own bring-up:

* it takes ownership with a 0x93 command carrying a host-generated ECDH key (persisted under /var/lib/python-validity so it survives reboots) instead of the flash-based pairing;
* the TLS record layer is AES-256-GCM with a mixed SHA256/SHA384 handshake (CertVerify signs a SHA256 hash, Finished uses a SHA384 PRF);
* enroll, on-chip 1:N identify and delete all run on the device, and a match returns only a 16-byte template id, so which user and finger a print belongs to is tracked host-side.

tls.py gains an opt-in AES-GCM path plus the SHA384-PRF and mixed-hash Finished hooks; the existing CBC/HMAC path is unchanged (the new behaviour is guarded so it defaults to the old values). tudor.py is the device driver: pairing + GCM bring-up, on-chip enroll/identify/delete (TudorSensor) and a host-side identity store (TudorDb). init.open() dispatches to it for 047d:8054 and specialises the sensor/db singletons in place, so the fprintd dbus-service is unchanged. usb.py and the udev rule register the device.

Reconstructed from captured Windows-driver traffic and tested end to end via open-fprintd (fprintd-enroll / fprintd-verify / PAM login) on a real reader.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant