On 7/3/06, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> 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 ? -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
