Re: Driver for Microsoft USB Fingerprint Reader

["Daniel Bonekeeper" <thehazard@gmail.com>]

On 7/3/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Llu, 2006-07-03 am 18:11 -0400, ysgrifennodd Daniel Bonekeeper:
> > That's one problem: I don't want to create one more userspace
> > interface for that. I suppose that all the hundreds of fingerprint
> > readers that ships with a SDK have their own way of doing that.. that
>
> The very cheap readers all appear to be fairly crude image scanners, and
> they even lack hardware encryption/perturbation so they are actually of
> very limited value.

Noticed that. Well, which device to use is a decision of the user and
the kernel should be able to handle his needs, independently from
being the most secure or not.

> > looks awfull to me, even though I believe that currently there isn't
> > any uniform way of working with fingerprint readers... shouldn't we
> > have a way to classify devices ? For example, if I want to list all
>
> They vary from "low res bitmap" and the rest in software through "low
> res bitmap mangled by specific device instance unique scheme" (1)
> through to smart card based external tamperproof boxes that authenticate
> the smartcard with the fingerprint and the host typically via PAM in
> user space.
>
> That's a huge range of devices with little in common.

=(
At least they have something in common: all of them deliver an image
as output. Maybe that could be centralized somehow... for example, a
single structure that we use to ask for the capabilities of a fp
reader and the driver fills it telling the maximum resolution of
image, if it supports encryption or not (or if the datastream that
comes from the driver is encrypted or not), etc. What the userspace
does with the image is irrelevant. Let's imagine that: I have a daemon
in userspace that is responsible for reading fingerprints from
/dev/fingerprint[012], and it is supposed to be device-independent. So
this device asks the device for information about its capabilities,
and the device returns the information as a structure (for example
telling the dimension of the image returned, the image format, etc).

How does encryption-based readers works ? I suppose that a software
driver or library in userspace should be responsible for decrypting
the image and processing it, right ? So, in this case, the decryption
could be done at kernel level (to fit the model above, where just
images are returned), or giving the option for the userspace to
receive the raw encrypted stuff.

> Alan
> (1) Think about what happens if you don't have this. Its possible to
> steal a result then reverse engineer a "finger" on your own laptop to
> produce the same result.

At some point, the encrypted image needs to be decrypted for
processing, so it can be stolen anyways, right ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/