Sean McNamara
2006-12-01 20:16:09 UTC
Hello to all of the 3 people that are subscribed to this list ;)
I have been considering the fingerprint reader support as a whole,
trying to come up with what I think are a few good TODO items. Not all
of these have to do with libthinkfinger; quite a few of them are related
to better integrating this technology into userland.
Keep in mind my background as I come up with these: I am not a security
expert; I am a University student with limited knowledge of the
internals of PAM/libusb/desktop managers, a good command of C,
familiarity with the GNU C library, and a keen interest for the
usability (read: convenience) aspect of devices such as this fingerprint
reader. As such my TODOs may omit certain things that other users might
want: group policy, fingerprint file lockdowns/encryption, SELinux
integration, or a kernel-mode driver are all beyond my knowledge or
desire to enable. I believe in using reasonable POSIX security and the
pre-existing frameworks (PAM, for example,) along with a focus on
modularity as well as strong user feedback.
Also, I am basing these TODOs off of Michael Crusoe's "biometrically
enhanced local user authentication" (BELUA) stack, diagrammed at the
bottom of this page: http://www.qrivy.net/~michael/blua/
If you think of something to change about his stack, you might take it
up with him - for now, I'd just like to help any way I can to complete
the circle that he has sketched.
According to his diagram, we clearly need an interface between the
"vendor Biometric Service Provider (BSP)" (libthinkfinger), and the
bioAPI framework. As it is, libthinkfinger just provides userland
exported functions so that we can use this hardware for just about
*anything*, including using it as a joystick, interactive
finger-painting over Jabber, random number generation, realistic game
character generation, biology, or just plain old authentication and
security (how boring!)
Michael Crusoe has already done proper integration between the BioAPI
and the PAM Gateway. This is a nontrivial amount of work that is
completed for us if we do, in fact, bind libthinkfinger to the BioAPI.
In addition, PAM->kdm/gdm/xdm/etc. integration is handled with
configuration files, which we can follow examples of from the
proprietary UPEK driver where folks set it up for PAM integration.
However, the amount of BioAPI support we can provide is limited by our
current knowledge and developed APIs to return information from the
device. Suggested below are a few improvements that could be added to
libthinkfinger by making use of some more of the values returned by
libusb during/after a swipe. Note: the hardware may actually support
providing more information about a given swipe than their BSP lets on.
I'm not experienced enough with the device to uncover additional
features, but we should be able to bring our BSP up to match the level
of support in theirs.
I am currently studying the BioAPI and reading the "TouchChip TFM/ESS
Fingerprint BSP for Linux Specification" provided by UPEK. Obviously, we
will not be using their BSP at all (we are replacing it with an open
source equivalent that hopefully also provides more features), but if
you look at the specs on Page 12, there is a list of constants
indicating a message to be directed at the user. I don't imagine their
software BSP is doing any interpretation on the device's results to
determine these values; the device probably returns this information
somewhere in the results for each swipe. If this can be probed by
libthinkfinger, I can bridge it to develop a BioAPI GUI callback such as
this:
typedef BioAPI_RETURN (BioAPI *BioAPI_GUI_STATE_CALLBACK)
(void *GuiStateCallbackCtx,
BioAPI_GUI_STATE GuiState,
BioAPI_GUI_RESPONSE Response,
BioAPI_GUI_MESSAGE Message,
BioAPI_GUI_PROGRESS Progress,
BioAPI_GUI_BITMAP_PTR SampleBuffer);
Their BSP only supports a user message callback, which is still useful.
We can integrate this with an onscreen display and export this out of
libthinkfinger, so that regardless of the client, they may request our
implementation of a GUI (complete with images and user-friendly textual
feedback) responding after each swipe.
My inspiration for this work is actually in the Windows ThinkVantage
suite provided by IBM for fingerprint authentication: if you swipe your
finger too fast when logging in, it actually says on the screen, "Too
Fast" and provides an image of a finger swiping too fast...! How the
heck does it know? The hardware, I assume. I don't imagine a small
userland .so (the UPEK BSP) is sophisticated enough to do anything more
than marshal the hardware's response up the stack. That's what I would
like to help develop - the BioAPI integration layer.
Hopefully Pavel and Timo are signed up to this list.... though I'd like
feedback from everyone if possible. I'm willing to devote substantial
effort to this, mostly on the weekends, until this semester is over.
After the semester is over in mid-December, I will have more time on my
hands than usual until February, so I'll be able to work on it even more
then.
I enjoy real-time collaboration, so maybe we should set up an IRC
channel somewhere, or exchange IM contact info. Also, let me know if one
of you has already made significant headway on BioAPI integration - and
whether or not you'd like some help. It seems that we don't currently
link against BioAPI, much less operate with it, using the latest svn
checkout of libthinkfinger.
If you find my ideas helpful, and would like me to work more on the
project, please email me directly and I will provide my Sourceforge user
name. This is the first F/OSS project I've considered being seriously
involved in, apart from testing/scripts/workarounds/micro-contributions
- so please be nice! :)
Regards,
Sean
I have been considering the fingerprint reader support as a whole,
trying to come up with what I think are a few good TODO items. Not all
of these have to do with libthinkfinger; quite a few of them are related
to better integrating this technology into userland.
Keep in mind my background as I come up with these: I am not a security
expert; I am a University student with limited knowledge of the
internals of PAM/libusb/desktop managers, a good command of C,
familiarity with the GNU C library, and a keen interest for the
usability (read: convenience) aspect of devices such as this fingerprint
reader. As such my TODOs may omit certain things that other users might
want: group policy, fingerprint file lockdowns/encryption, SELinux
integration, or a kernel-mode driver are all beyond my knowledge or
desire to enable. I believe in using reasonable POSIX security and the
pre-existing frameworks (PAM, for example,) along with a focus on
modularity as well as strong user feedback.
Also, I am basing these TODOs off of Michael Crusoe's "biometrically
enhanced local user authentication" (BELUA) stack, diagrammed at the
bottom of this page: http://www.qrivy.net/~michael/blua/
If you think of something to change about his stack, you might take it
up with him - for now, I'd just like to help any way I can to complete
the circle that he has sketched.
According to his diagram, we clearly need an interface between the
"vendor Biometric Service Provider (BSP)" (libthinkfinger), and the
bioAPI framework. As it is, libthinkfinger just provides userland
exported functions so that we can use this hardware for just about
*anything*, including using it as a joystick, interactive
finger-painting over Jabber, random number generation, realistic game
character generation, biology, or just plain old authentication and
security (how boring!)
Michael Crusoe has already done proper integration between the BioAPI
and the PAM Gateway. This is a nontrivial amount of work that is
completed for us if we do, in fact, bind libthinkfinger to the BioAPI.
In addition, PAM->kdm/gdm/xdm/etc. integration is handled with
configuration files, which we can follow examples of from the
proprietary UPEK driver where folks set it up for PAM integration.
However, the amount of BioAPI support we can provide is limited by our
current knowledge and developed APIs to return information from the
device. Suggested below are a few improvements that could be added to
libthinkfinger by making use of some more of the values returned by
libusb during/after a swipe. Note: the hardware may actually support
providing more information about a given swipe than their BSP lets on.
I'm not experienced enough with the device to uncover additional
features, but we should be able to bring our BSP up to match the level
of support in theirs.
I am currently studying the BioAPI and reading the "TouchChip TFM/ESS
Fingerprint BSP for Linux Specification" provided by UPEK. Obviously, we
will not be using their BSP at all (we are replacing it with an open
source equivalent that hopefully also provides more features), but if
you look at the specs on Page 12, there is a list of constants
indicating a message to be directed at the user. I don't imagine their
software BSP is doing any interpretation on the device's results to
determine these values; the device probably returns this information
somewhere in the results for each swipe. If this can be probed by
libthinkfinger, I can bridge it to develop a BioAPI GUI callback such as
this:
typedef BioAPI_RETURN (BioAPI *BioAPI_GUI_STATE_CALLBACK)
(void *GuiStateCallbackCtx,
BioAPI_GUI_STATE GuiState,
BioAPI_GUI_RESPONSE Response,
BioAPI_GUI_MESSAGE Message,
BioAPI_GUI_PROGRESS Progress,
BioAPI_GUI_BITMAP_PTR SampleBuffer);
Their BSP only supports a user message callback, which is still useful.
We can integrate this with an onscreen display and export this out of
libthinkfinger, so that regardless of the client, they may request our
implementation of a GUI (complete with images and user-friendly textual
feedback) responding after each swipe.
My inspiration for this work is actually in the Windows ThinkVantage
suite provided by IBM for fingerprint authentication: if you swipe your
finger too fast when logging in, it actually says on the screen, "Too
Fast" and provides an image of a finger swiping too fast...! How the
heck does it know? The hardware, I assume. I don't imagine a small
userland .so (the UPEK BSP) is sophisticated enough to do anything more
than marshal the hardware's response up the stack. That's what I would
like to help develop - the BioAPI integration layer.
Hopefully Pavel and Timo are signed up to this list.... though I'd like
feedback from everyone if possible. I'm willing to devote substantial
effort to this, mostly on the weekends, until this semester is over.
After the semester is over in mid-December, I will have more time on my
hands than usual until February, so I'll be able to work on it even more
then.
I enjoy real-time collaboration, so maybe we should set up an IRC
channel somewhere, or exchange IM contact info. Also, let me know if one
of you has already made significant headway on BioAPI integration - and
whether or not you'd like some help. It seems that we don't currently
link against BioAPI, much less operate with it, using the latest svn
checkout of libthinkfinger.
If you find my ideas helpful, and would like me to work more on the
project, please email me directly and I will provide my Sourceforge user
name. This is the first F/OSS project I've considered being seriously
involved in, apart from testing/scripts/workarounds/micro-contributions
- so please be nice! :)
Regards,
Sean