[Fingerforce-devel] Re: Fingerprint authentication

[Miguel Gea Milvaques]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Timo Hoenig wrote:
> Hi Miguel,

Hi Timo!

> 
> While reading my IRC backlog I saw your about your progress on getting
> the AuthenTec reader supported.  Can you please elaborate a little bit?

The actual state is still in design stage, but there are some problems
solved.

The main was the fingerprint comparation. Fvs software with little
modifications works. The AuthenTec reader seems not to do the
fingerprint authentication itself, so It need fvs. (I know UPEK don't
need it).

This will help to enable *any* device that could be able to scan a
fingerprint only. Of course this will be optional.

> 
> As I was very busy with other things lately I did not work a lot on
> ThinkFinger but I was thinking about fingerprint reader support in
> general.  Let me share my thoughts about that.

This is my main thinkings too. The AuthenTec scanner is my test
hardware, but I allways thinks in any scanner.

> 
> No matter which device we are supporting it will definitely have common
> operations as others (acquiring, comparing and such).  This should make
> us think about abstraction.  We just do not want to add a different PAM
> module for each new device hitting the market.  We should aim for a
> project which serves them all.

This days I've began writing a pam module that could be scanner
independent, but I've found some design problems. I'll try to explain
you now how I thought the complete system and where is my problem.

I've been looking for all scanners software that I could find and all
them has a common feature. All them has an scan software that gives a
image as result. Using the tools I have, I thought in a system like this:

pam_module  --> scan fingerprint *executing* the software -->

- -> returns bir (if image, process with fvs to obtain it) ->

- -> compare with database birs (with fvs or hardware if available,
executing the software)


Why executing? Because my idea is *not* rewrite all drivers that could
found. This is a good idea, but on other hand it's a very bad idea exec
from pam module. This is the problem I have at this moment. As it seemed
really easy to write to me, I've begin writing this ugly pam module as test.

> 
> I am no keen on introducing yet another system daemon, but with regard
> to fingerprint reading support it is probably not avoidable.

This is a very good idea that could solve my problem :)

> 
> Assuming we have a daemon we could define an abstract API.  That API in
> turn can be utilized by any application or service (e.g. PAM).  The
> daemon itself is abstracting any communication with the fingerprint
> reader devices.
> 
> This leads us to the following:
> 
>       * one PAM module for all devices

I agree.

>       * solve the 'PAM is not being run in context of root' issue

I agree too.

>       * avoid concurrent access on the fingerprint reader device

I didn't thought about this :(

> 
> On top of that (depending on the implementation details):
> 
>       * enable applications programmed in high level languages make use
>         of fingerprint readers without the need of library wrappers
>         (Precondition: using D-Bus)
>       * enable non-root users to utilize the fingerprint reader devices
>         (Precondition: "at_console" policy, e.g. using
>         ConsoleKit/PolicyKit)
> 
> And some other advantages which are on my mind but I have not yet
> thoroughly thought about.
>

I agree with you in the necessity of write only one pam module for all
devices, and connect it with the daemon.

A important part we must work on is in how to get to do *not*
rewrite/modify all existing drivers/software. If we must rewrite them,
we maybe must think in bioapi, although I really prefer don't do it.

> So much for now.  With your experience of the AuthenTec device I can
> hopefully get a picture which is more clear than my above rumblings.  It
> looks like the UPEK and AuthenTec device are quite the opposite to each
> other with regard to their implementation.  That is exactly what we need
> to find a proper design for the API.


The thinkfinger is internally quite nice, it returns errors and states
of the fingerprint. This *not* happen on Authentec (and I supose others)
. This will do the API more difficult to design. But we could try to
design it and, if we like it, implement it.


Thanks.

Miguel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGQ664NTNQylgICMQRAhhTAJ9CFJVgil6gBmzKXjPaUSXZDvQDRQCbBZB6
8kv0dJzakxCscVx4zokYNGo=
=JhpW
-----END PGP SIGNATURE-----