To involve the psarc members to see the discussion, the previous mails are attached and psarc-ext is cc-ed.
> Detailed responses below: > > > 1) Is it necessary to import libfpr before BioAPI? [Yes] Is libfpr a > > duplicate of BioAPI? [No] > > It's quite unclear to me that BioAPI and libfpr play well together in > the future. BioAPI 2.0 has a separation between matching, sensing, > and archiving that doesn't appear as clearly in libfpr. It seems to > me that the two are quite distinct. > > > As what I said, BioAPI can be regarded as a driver framework for common > > biometric devices. Usually if we want to use a biometric device, a SPI > > module for this device is required(many vendors provide their device's > > module to BioAPI in linux). Thus we can call BioAPI to access that > > So, if this is what they do on Linux, why would we expect them to do > something different (modifying libfpr) on Solaris? No, there's no difference. Just please think of libfpr as a driver collection of fingerprint readers. To support a reader in BioAPI, a BSP(biometric service provider) that implements the SPI is required. For instance, I have a reader. If I want to make it work on linux, I should write the driver and the BSP. So does in Solaris. But if the reader has been supported by libfpr(there's already a loadable module for libfpr), we don't have to write the driver. Further, we just need a BSP based on libfpr since libfpr has cover many fingerprint readers. For the readers not supported by libfpr, you can write the driver and the BSP just like in linux. Or you may just write a loadable module for libfpr and share the BSP. I think the latter one is easy and fast. It just gives another choice without any negative effect. > > > login/bioadm // services level > > | > > pam_bio // PAM level > > | > > ------------------------------------------------------ > > ------| ** BioAPI ** // Common driver level | > > future| | \ | > > ------| SPI_fpr SPI_iris... // SPI module | > > ------------------------------------------------------ > > | \ > > libfpr libiris... // Class drivers level > > | | > > devices devices... > > In that future case, there is no other consumer of libfpr, so the > separation of SIP_fpr and libfpr becomes a strange artifact. At best, > all that SPI_fpr does is adapt between the BioAPI SPI interface and > the libfpr user interface. > > Instead, I would have expected SPI_fpr to connect directly to > underlying devices. I think it's acceptable to consider the libfpr as the driver collections of fingerprint readers. SPI_fpr also needs a driver to access the device, libfpr is the role. > > > 2) Is it necessary to import virtual Biometric Device in X level(or even > > in console level)? [No] > > > > It's too ideal to regards biometric devices as the keyboard/mouse. If > > biometric devices is virtualized, we not only update the X > > applications(such as gdm, dtlogin, etc), but also updates the console > > applications(such as login, su, etc). I didn't ask for X team, but I > > don't think we have so many resources to update all PAM authentication > > services. Further more, a problem may be difficult to be resolved for > > I suggest asking. You may be right, and the answer may be "never" as > you indicate, but I don't think that guessing at another team's > resources or priorities is a good way to proceed. I've mailed Alan.Coopersmith for this, just please wait for the response. > > > architecture design. Many biometric devices integrate the verification > > function in the firmware. If biometric device is virtualized in X, > > pam_bio can't access the device, how can we implement the verification? > > let gdm call bio_verify() directly? It's too weired. Similar to > > What do we do with keyboards and displays today? The PAM function > talks to the verifier, and the framework itself handles the I/O to the > user. > > That same model seems to apply here. For the biometric devices that just capture images(just as keyboards get username/password), the PAM module gets the image and verify it by comparing with data records. They have the same model. However, for the biometric devices that integrate the verification module in the firmware, the devices directly return the verification/identification result(the data records are preloaded into the firmware). If the biometric devices are virtualized in X and only accessed by the application, how does the PAM module implement the authentication? So I'd like to keep the biometric devices accessed by PAM modules, just like smartcard and javacard cases. Finally I'd like to post another issue that may be argued in the commitment review. It's about the multi-thread design for PAM module and the export of PAM_CONV_INTERRUPT. For the current multi-thread design, Gary had ever queried it and GDM community also needs confirmation. http://bugzilla.gnome.org/show_bug.cgi?id=464637 For the multi-thread design, many mutex locks are used to keep the PAM resources and the device resources thread-safe. I've implemented and tested it. No problems are found so far. Viewed from the architecture, if it's ugly or has potential issues, there will be the following solutions. 1) Single thread mode. It's the easiest way. Thus the biometric authentication can not be bypassed. Fingerprint, username, password should be verified one by one. 2) Prompt mode. The PAM module sends an PAM_ECHO_ON message "Login with Fingerprint?(Y/N)" and gets the user's choice, then enters the selected branch. It's single thread and needs the user's input before authentication. 3) Application mode. Similar to the prompt mode, a deamon is created in application level to monitor the user's choice. If the multi-thread design is not accepted, I think solution 2) is a substitute. -- Best Regards, GaoPeng Chen Call: +86-10-62673005 Ext: x82005 Sun Microsystem Inc. China -------------- next part -------------- >From - Subject: Answers to the Issues of Fingerprint authentication (PSARC 2007/286) From: Gaopeng Chen - Sun China <[email protected]> Reply-To: Gaopeng.Chen at sun.com To: James Carlson <James.D.Carlson at Sun.COM> Content-Type: multipart/mixed; boundary="=-/GqKDirRUm0Sqcpdpf1k" Organization: SUN Message-Id: <1186644461.9515.137.camel at highroc> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.335 Date: Thu, 09 Aug 2007 15:27:41 +0800 X-Evolution-Transport: sendmail: X-Evolution-Account: SunMail X-Evolution-Fcc: imap://gc161489 at mail-apac.sun.com/Sent X-Evolution-Format: text/plain X-Evolution-Source: imap://gc161489 at mail-apac.sun.com/ --=-/GqKDirRUm0Sqcpdpf1k Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi James, Would you please give your comments for my answers to your issues? In the inception review meeting, some of your issues are not resolved. I'd like to know your opinions after they are updated. Thanks. -- Best Regards, GaoPeng Chen Call: +86-10-62673005 Ext: x82005 Sun Microsystem Inc. China --=-/GqKDirRUm0Sqcpdpf1k Content-Disposition: attachment; filename=update-notes Content-Type: text/plain; name=update-notes; charset=gb2312 Content-Transfer-Encoding: 7bit ## After inception review, some major points will be updated for the project. 1) /etc/fpr.conf -> /usr/lib/fpr/fpr.conf Put this conf file together with the loadable modules. 2) /etc/fpr/$(USER)/$(ID) -> /var/bio/$(BIO_TYPE) The datum are stored in /var/bio and managed by ndbm(3C). 3) fpr_open(uint16_t, uint16_t) -> fpr_open(uint16_t, uint16_t, const char *) Add a unique string to open the specified device. 4) remove the claims about the algorithms strenth The algorithm component will be delivers as reference components. Users are encourged to develop their own algorithms. 5) pam_fpr -> pam_bio This module will cover the biometric authentication. Currently it has only the branch $(BIO_TYPE) = "fingerprint". 6) add arguments(bus=..,dev=..,ser=..) for pam_bio Add a unique string to associate the specified device with the pam module if there are two same devices in a system. 7) introduce a private module biodb This module implements the biometric datum for different repositories (currently just files). It's shared by pam_bio and bioadm. 8) fprmgmt -> bioadm Add a new option "-l" to list user's biometric records. 9) introduce two packages SUNWfpr and SUNWbio These two modules respectively present the fingerprint drivers and biometric module/applicatoin. --=-/GqKDirRUm0Sqcpdpf1k Content-Disposition: attachment; filename=issues-QA Content-Type: text/plain; name=issues-QA; charset=gb2312 Content-Transfer-Encoding: 7bit PSARC 2007/286: Fingerprint Authentication Submitter: Gaopeng Chen Owner: Kais Belgaied Intern: Darren Reed ISSUES ====== * In the materials submitted, there is no apparent mechanism provided to prevent the insertion of something masquerading as a fingerprint device via a different USB port than than the one through which the "real" device is connected. Through discussion on this topic, the requirement that it be possible to specify the hub port associated with a fingerprint reader emerged. > After consideration, I think if the attacker can produce a copied fingerprint reader, hack the hardware and plug it to the box, he must have the ability to switch the hub port. As the answer to ajh-1, if the system can be physically attacked, it's security is not insured. The possible problem here is if two same devices are connected to a system, how do we distinguish them and assign them respectively for two different authentication services? See jdc-4. * In the management of the fingerprint devices, it is currently left up to the administrator to use an editor to manually associate a library shared object file with a given USB vendor/product ID. This needs to be improved and a better administration interface delivered for commitment review. > The config file fpr.conf is used to associate a device with a loadable module in libfpr. It's function is similar to the /etc/driver_aliases. It's just valid when libfpr is invoked to open a fingerprint reader. I think a simple config file is reasonable. The file will be put with the loadable modules in /usr/lib/fpr. See djr-1. * The current specification delivers the database files into /etc/fpr. This directory is considered to be inappropriate and the database should be located in /var/fpr. > Yes, the data base is moved to /var/bio/$(BIO_TYPE). See djr-2 and gw-2. * A question was raised over the naming of the PAM module "pam_fpr" and its implementation specific management tool "fprmgmt" - why do we need a specific module and tool for each and every biometric device? The project team accepted this criticism and mentioned that they would redesign these interfaces to cover all biometrics. > The "pam_fpr" will be renamed as "pam_bio", and "fprmgmt" will be renamed as "bioadm". They will have the capacity to hold the other biometric functions. See jdc-2. * Some Sun hardware can support multiple keyboards, mice and screens as the console, and more specifically, with SunRay servers there are a large number of these connected and present. More details are required for the administrative interface so that it is clear how to associate specific fingerprint readers with specific keyboards and mice on systems with a large number of each connected to it. > See jdc-4. * The materials presented made various claims about the strength of their algorithms for protecting the fingerprint data and whether or not certain aspects could be reverse engineered. The team was advised to remove the comments relating to reverse engineering. They did however point out that there is no current industry standard in this area and that they will go into more detail in their documentation for committment. The ARC also asked them to mention what the permissions on related files would be. > The claims of algorithms strength will be removed. See gw-16. The database is protected and has the same privilege with shadow(4). General discussion finished with jdc-12 being wrapped up. In closing we ran out of time to discuss all of the issues on file for this project's PSARC inception review and we ran through the reamaining questions very briefly, explaining what they were about. Comments as follows. * describe in the design document how interfacing libusb with PAM will be done as libusb says it is MT-unsafe but PAM is MT-safe. * understand what the implications of the MT safeness of both PAM and libusb are and document what implications there are for relevant applications. > See gw-4(a). * the project team needs to research DBUS, HAL and interactions with Tamarack's USB notifications. > See gw-6a. Opinion fodder from the meeting: * The documentation provided with the shipped materials needs to be explicitly clear about the security risks involved with using fingerprints because it has been demonstrated that these devices can be very easy to fool. > We'll claim the security risk in the public document. See jdc-3. Advice to the PAC: The USB library interface currently supported by Solaris does not expose any mechanisms for registering vendor/product id's in a manner similar to what we use for PCI. Solaris needs an addition to the libusb(3) interface to support shared libraries being dynamically added and registered with specific USB vendor and product identifiers. Answers to the Issues of Inception (06/20/2007): ajh-1 Maybe I just watch too many James Bond movies, but given that the fingerprint reader is a usb device, what is to stop a would be attacker simply plugging in a piece of specially crafted hardware that identifies as a fingerprint reader and sends a recorded fingerprint at the appropriate interrogation time? A: In this project, the fingerprint device is connected to box by USB interfaces. But it doesn't mean it must be hot-pluggable. USB is just the data bus. Generally for a security system the fingerprint device is integrated in the box or monitor, like the smartcard reader in SunRay. If the attacker can physically intrude the box or device, the system's security can't be guaranteed. ajh-2 Related to my #1, I am concerned at the recommendation of accepting either fingerprint or password. Especially in the light of how easy such things are to defeat. See http://kwc.org/mythbusters/2006/08/episode_59_crimes_and_mythdeme.html While I accept that we can't "not" provide the functionality, I WOULD SUGGEST THAT IT SHOULD BE ACCOMPANIED BY DOCUMENTATION On the pitfalls and recommendations on good and bad use. I can think of any number of scenarios where the recommendation of accepting either password or fingerprint could cause problems. While outside the scope of the case, for my money a finger print is an identifier, not an authenticator. A: Yes, the recommendation and risk to use the fingerprint authentication will be claimed in the user's manual. djr-1 /etc/fpr/fpr.conf - consider using SMF to hold this information so that updates to this "database" can happen as a series of executed commands that interact with SMF rather than trying to safely update a plain text file. A: This configuration file is used by libfpr to associate a device with a loadable module. It's just valid when an application calls libfpr to open a device. It's updated offline, similar to the function of driver_aliases. So SMF is not necessary. This file will be put to /usr/lib/fpr together with the loadable modules. djr-2 Consider using /var/fpr instead of /etc/fpr as the directory within which to store the database. Most importantly, this moves the database to a filesystem that isn't quite often the same as root (/). Note to PSARC: should /var/db/fpr be considered? A: It's accepted to move the data to /var/bio and the data will be stored by database (see gw-2). jdc-1 Are there any existing API standards or open source references for such a thing (BioAPI)? Does Sun get value from being different in this area? Will applications actually support a Sun-proprietary design? Are the functions designed to be usable by BioAPI or will they need to be revisited? A: BioAPI is the standard interfaces and popularly used. The libfpr is just a USB userland driver framework for fingerprint readers. They are in different levels and have no conflicts. libfpr can be easily wrapped by BioAPI. Usually the authentication applications (login, bioadm, etc) work upon pam_bio. So wraping libfpr with BioAPI just needs a minor update in pam_bio. The applications is not necessary to be changed. Now BioAPI is being transitted from 1.1 to 2.0. We'll not port it to support common biometrics until the version 2.0 is finalized. jdc-2 Why is the PAM module named "pam_fpr" (fingerprint recognition?) and the command line tool fprmgmt? Would we need to design a completely different module if someone ships a handprint or iris scanner? A: The "pam_fpr" will be renamed as "pam_bio", and "fprmgmt" will be renamed as "bioadm". Now pam_bio works upon libfpr. After BioAPI is imported, it works upon BioAPI and libfpr is just a provider of BioAPI. The tool bioadm is buit on the PAM module pam_bio, so it's a general tool to mange all the biometric data. jdc-3 What do we tell users about the relative security of fingerprint-based identification? We provide a way to do either-or authentication with common UNIX authentication, but what risks does that expose? A: We'll claim in the public document, the fingerprint is just aided security authentication. The password authentication is also required after fingerprint authentication. The security is not insured if only fingerprint authentication is used in a system. jdc-4 How do we know which fingerprint reading device is associated with which keyboard/display combination, if any? Is there some way for the user to specify this, or does it work only if there's exactly one reader on the system console? A: For a local system, if two or more readers are connected, only the device selected by pam_bio module argument can be used. The best way to distinguish the USB devices is libusb bus, device instance and the serial string. Two same devices should have different libusb device instances and serial strings. They are better than hub port number which may be physically hacked. So that two same readers can be configured for two separate service in pam.conf, # gdm is authenticated by one reader gdm auth required pam_bio_authtok.so.1 \ bus=/dev/usb dev=483.2016/0 ser=123456789 # myapp is authenticated by the other reader myapp auth required pam_bio_authtok.so.1 \ bus=/dev/usb dev=483.2016/1 ser=987654321 For SunRay system, the clients and server see different usb buses. The clients can only see the devices plugged in itself. So the keyboard/disply can be easily distinguished for the clients. To support fingerprint authentication in SunRay systems needs the server-client verification mode. It will be considered with the nis/ldap support in the second step. Server SunRay SunRay usb_bus -> bus1 -> bus2 -> bus3 | | | dev dev dev jdc-5 "Impossible to be reverse engineered" seems like quite a bold claim. What protection on the data is required? (It seems that it's probably mode 0600 and owned by root.) A: This claim will be removed. The database is owned by root with permission 0600, similar to shadow(4). jdc-6 Please explain the SHA2 usage in greater detail. If there's no secret key, how does it actually prevent modification? Can't someone just modify the record and update the hash to match? A: For files repository, SHA2 is used to produce the digest of the fingerprint data to prevent the data from being corrupted. And it's reserved for NIS, LDAP usage. The digest will be encrypted to create a signature to sync between client and server. The detailed design will be given in the second phase of this project. jdc-7 The need for ID numbers in /etc/fpr/fpr.conf seems to point to an architectural problem in libusb. (Not an issue for this project, but shouldn't a registry like this be centralized, as it is for other device IDs?) jdc-8 Is the file format endianness specified somewhere, or are the files architecture-specific? (I assume that this is set by "NISTIR 6529," but that document isn't included with the case materials.) A: The file will be put to the case directory, or got from http://www.oasis-open.org/committees/xcbf/docs/NISTR6529-CBEFF.pdf jdc-9 Using "Consolidation Private" for /etc/fpr/fpr.conf and /usr/sbin/fprmgmt means that users can't really use this new feature. Is that intended? A: In the first phase of this project, We'd like to keep them private. After the project is completely fulfilled in the second phase, they can be changed to a stable level. jdc-10 Opinion note: case is dependent on a future case to add logindevperm exclusions. A: The logindevperm case was approved. jdc-11 nit: prefer 'adm' to 'mgmt'. A: Accepted. See jdc-2. jdc-12 nit: you can't deliver both root (/etc) and usr (/usr/lib) bits in the same package. A: fpr.conf will be put in /usr/lib/fpr with the loadable modules. Two packages will be presented in this project. SUNWfpr - fingerprint reader userland-driver framework { /lib/libfpr.so /usr/lib/fpr/{fpr_msur.so, fpr_silex.so, fpr_upek.so} /usr/lib/fpr/fpr.conf /usr/include/fpr/fpr.h /usr/include/fpr/fpr_mod.h } SUNWbio - biometric authentication { /usr/lib/biodb.so /usr/lib/security/pam_bio_authtok.so /usr/sbin/bioadm } gw-1 What's the difference between dual-mode and multi-factor authentication? Why can't pam.conf be configured correctly without the need for a "dual-mode" option? A: They mean in different domains. Dual-mode means users can be authenticated by either fingerprint or user-passwd, just like the smartcard login in SunRay. Multi-factor means the factors other than password(such as fignerprint, iris, etc) are used to authentication. In this project, pam.conf can be configured correctly if the services don't support dual mode. For instance, if gdm doesn't support PAM_CONV_INTERRUPT, it can only work in single mode. I.e. fingerprint, user-passwd are authenticated in sequence. gdm auth required pam_bio_authtok.so.1 single gdm auth ... If gdm is updated to support PAM_CONV_INTERRUPT, the pam.conf can be configured as dual. Then users can login by either fingerprint (plus password) or the conventional user-password. gdm auth required pam_bio_authtok.so.1 dual gdm auth ... Since PAM_CONV_INTERRUPT is private and not supported by the services, single is the default. Gdm will be updated to support this message to demonstrate the dual mode. gw-2 Why is the file system being used as a database mechanism? Why shouldn't the locally enrolled user's data be included in some lightweight database in a single file? ndbm(3C) or other tier 1 db. A: It's accepted the biometric records will be stored in a file named /var/bio/$(BIO_TYPE) and managed by ndbm. gw-3 /usr/etc/fpr.conf? /etc/fpr.conf -- How is this managed? Who updates it. If managed, why isn't in a set of sfm properties? If unmanaged, it seems like drv.conf material. Where are the usb drv.conf (equivalent) files stored? A: See djr-1. gw-4 libusb says it's MT-Level is Unsafe. PAM is MT-safe per pam handle. gw-4a How will a multi-threaded pam_fpr be thread safe per PAM handle? A: The next paragraph is copied from PSARC/2003/721 (libusb: user level usb library). Libusb cannot be made MT-safe because of the exposure of the usb_busses global pointer, among other things. If the app follows some rules, then it can be used safely in threads. Specifically, if the app doesn't rescan the bus while accessing usb_busses (and the list of devices), then it can be MT-safe. In this project, a pam handle is corresponding to a fingeprint device instance. And fpr_init() is not allowed to be called twice, i.e. usb_busses are not rescanned. So it can be MT-safe. Two separate threads are created in a pam handle for fingerprint and user-passwd auth. The critial resources (pam handle, return value and fingerprint device) are protected for writing operation. It can keep thread-safe within a pam handle. gw-5 20q4: "PAM interfaces will be updated. The guys in security team has agreed..." I believe you've read way too much into an offline discussion email. The contracted private conversation message types are scheduled to be removed. All the consumers have been notified and have agreed to the contract termination. The single exporter pam_smartcard is EOFed. It hasn't yet been removed because of staffing priorities. The technology owner/manager has privately stated no new contracts will be signed. This seems to imply to me the stability isn't intended to be raised. The original use of the contracted private was rushed in for a SunRay deliverable 10 years ago. SunRay has abandoned their use for many reasons, including they don't work correctly for the environment. No new code uses them. PSARC/2004/184 Java Card System PAM module 1.0 (pam_jcdi) didn't require their use. Adding new message types requires modifying PAM consumers. This is almost always a bad idea and should not be taken lightly. A: In the discussion mails, most of the guys agreed that the message PAM_CONV_INTERRUPT is useful and necessary if we want to make users able to select either fingerprint or user-passwd for login. I'm sorry to reference the informal conclusion. Though pam_smartcard is EOFed, I'd like to re-propose this message. pam_jcdi doesn't use it because dual-mode login is not required by it. In this project, both single and dual modes are supported. To keep the compatibility, single mode is the default for the PAM services. See gw-1. gw-6 OCF is dead; SCF is dead; MUSCLE - PS/SC (Lite) is the intended way forward in Solaris. The MUSCLE website says it has "Biometric abstraction support". How does this project fit with MUSCLE's Biometric support? Why is another "framework" desirable? A: MUSCLE(Movement for the Use of Smart Cards in a Linux Environment) is mostly for smartcard. Biometrics is mentioned in the MUSCLE's website. But I didn't find the real design or implementation. http://web.inf.tu-dresden.de/~ko189283/MuscleCard/MuscleCardArticle.html#ArchitectureOverview So I guess the meaning is for some specific smartcards integrated with fingerprint sensor and info, like the site reference. http://www2.linuxjournal.com/article/3013 The industry standard is BioAPI. Now it's in the transition period from version 1.1 to 2.0. Our design is complient with bioapi. We will not import it until the version 2.0 is completely finalized. gw-6a How does this project relate to Tamarack and it's USB notification? A: The fingerprint devices is managed by libfpr based on libusb and ugen mechanism. In this project the pluggable notification is not necessary for the applications and users since fingerprint devices are impossible to be hot-plugged by users. A related RFE(CR 6575969) is proposed to support ugen devices' notification in HAL. gw-7 20q#8 "When a failure ... logged to the system console. ..." What is being proposed here? How does this compare to all the other PAM operations? A: When a failure happens in libfpr, an error message can be got. The error message will be logged by "syslog(LOG_ERR,...)" just as the other PAM modules do. gw-8 20q#8 "The authentication failure will be given 3 times retry ..." What is being proposed here? How does it compare with all the other login mechanisms where retry is the applications responsibility? What exactly is the proposed PAM service module doing? A: Retry in the pam_bio is eliminated, and it will be done by the applications. gw-9 ADT_fingerprint_auth, where is this generated and why? Why is it being proposed that ADT_passwd be recorded? A: ADT_fingerprint_auth is removed. gw-10 Why is access to the fingerprint reader device sensitive? Why should normal users be granted access after they've logged in? A: If the fingerprint reader is used for authentication, we should prevent the normal users from directly accessing it. If a normal user can control the reader after login, he may open and lock the devices. So the fingerprint authentication can't be used by other services. gw-11 What's the relationship of this project with SunRay DTUs? A: SunRay has the same libusb interfaces with normal systems. So libfpr should work in SunRay for it's based on libusb. See jdc-4. gw-12 "The network is the computer." Solaris is a multi-user multi-OS instance operating system. Why is this project complete without name service support? A: Just step by step. Firstly, we'll deliver a local system solution. In the second step, we'll support network client-server mode. gw-13 Considering name service support, I'd expect user authentication policies to follow nsswith.conf:passwd. N.B. pam_dial_auth is serial line rather than user authentication. A: Yes. We'll consider it in the second phase. gw-14 What is the login GUI scenario? Fingerprint support on other systems presents feedback of the image being captured. Same question for enrollment. A: It's not planned to display the captured image in the GUI. The applications are based upon PAM, and PAM didn't export the image message type. So only image quality is reported to applications by PAM message. We may record some classic fingerprint images according to the image quality and display it in GUI, just like some applications do in Windows. Besides, not everybody accepts that their fingerprint is displayed on the screen. gw-15 What is the administrative model for fprmgmt? It appears to be proposed in the User Management Rights Profile, yet it also seems to be implied that any user can run it to update their enrollment. A: The tool fprmgmt has the same secure model with passmgmt(1M). It requires the profile "User Security". I've tested that only root or the role with the above profile can run it. Normal users don't have the priviledge. gw-16 Are all the formats and algorithms used for the fingerprint data/enrollment/verification industry standard? A: This question has been discussed in the mails and Colin helped me answer it for I was not in the office. I'd like to make a summary. The fingerprint data is formatted by CBEFF (Common Biometric Exchange File Format, NISTIR 6529), which includes 3 parts, SBH (Standard Biometric Header), BSMB (Biometric Specific Memory Block) and SB (Signature Block). This is the industry standard and BioAPI also complies with it. The BSMB is a block to store the fingerprint templates, which are computed by the fignerprint alogrithms. There's no standard algorithm for enrollment/verification now. The libfpr is a container, a framework to load the modules for specific devices. In the market, there are two types of devices. One of them can capture and enroll/match the fingerprint by the hardware, the other type can only capture images. For the former one, the loadable module is totally a driver module. For the latter one, the loadable module needs to capture the image and implement the enrollment/verification by software. Generally we recommend the manufacturer or developers to develop their own module including match algorithm. Since there's not software implementation in solaris for the fingerprint readers that can only capture images, we'll provide a basic match algorithm component in libfpr if the loadable module didn't implement it. We'll decide to put this component to solaris or just opensolaris as reference code, after the complete algorithm evaluation. wes-1 recording alternate fingers? I have access to a colocation facility where I need a RFID badge plus one of my index fingers to get in; both fingers are enrolled. How would this be handled? A: Now in pam_bio, all enrolled fingerprints are equal. A user can enroll at most 10 finerprint records with the ID from 1 to 10. For login authentication, any fingerprint that matchs one of them can pass the authentication. wes-2 (commentary/uplevel of ajh-1) See mythbusters episode 59; commercially available readers are very subject to spoofing without specially-crafted readers. decent summary at http://kwc.org/mythbusters/2006/08/episode_59_crimes_and_mythdeme.html notably: 1) they found that covertly collecting a fingerprint from a coworker was trivial even when the target knew people were out to get a copy of his fingerprint. (Should not be surprising given that they've been used since 2) it was necessary to enhance the collected print, but the technique they developed was straightforward: enlarge the image, trace over it with a black marker pen, then reduce it back to original size. 3) Common printed circuit board etching techniques were used to construct a mold for several substances including latex and ballistics gel. 4) "liveness sensors" in the locks they tried were easily defeated (they found that licking the "finger" would fool the sensors they tested; for one reader, licking a paper copy of the print caused it to pass). this is not a substitute for actually watching this episode. --- Question: What claims of security do we make about this mechanism, and how do we back them up? A: See jdc-3. wes-3 proper distribution of functionality in a network using fingerprint readers - wouldn't publication of sample fingerprints in the name service (to be validated locally to the fingerprint reader) make it easier to find sample fingerprints to copy? A: For network support, the data transferred on the network is the fingerprint templates instead of the raw image. And the signature verification between client and server is required to protect the data. The detailed design of how to protect the data will be given in the second phase of this project to support NIS, NIS+ and LDAP. djr-3 JDS is in a different consolidation to fprmgmt, so for it to use fprmgmt (which is ON) will require a contract as fprmgmt is only being promoted as consolidation private. A: Accepted. --=-/GqKDirRUm0Sqcpdpf1k-- -------------- next part -------------- An embedded message was scrubbed... From: James Carlson <[email protected]> Subject: Re: Answers to the Issues of Fingerprint authentication (PSARC 2007/286) Date: Thu, 09 Aug 2007 12:11:33 -0400 Size: 9381 URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070814/e2f28c6a/attachment.nws> -------------- next part -------------- An embedded message was scrubbed... From: Gaopeng Chen - Sun China <[email protected]> Subject: Re: Answers to the Issues of Fingerprint authentication (PSARC 2007/286) Date: Fri, 10 Aug 2007 18:07:16 +0800 Size: 10889 URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070814/e2f28c6a/attachment-0001.nws> -------------- next part -------------- An embedded message was scrubbed... From: James Carlson <[email protected]> Subject: Re: Answers to the Issues of Fingerprint authentication (PSARC 2007/286) Date: Fri, 10 Aug 2007 07:57:28 -0400 Size: 10786 URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070814/e2f28c6a/attachment-0002.nws> -------------- next part -------------- An embedded message was scrubbed... From: Gaopeng Chen - Sun China <[email protected]> Subject: Re: Answers to the Issues of Fingerprint authentication (PSARC 2007/286) Date: Sun, 12 Aug 2007 15:11:50 +0800 Size: 4835 URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070814/e2f28c6a/attachment-0003.nws> -------------- next part -------------- An embedded message was scrubbed... From: James Carlson <[email protected]> Subject: Re: Answers to the Issues of Fingerprint authentication (PSARC 2007/286) Date: Sun, 12 Aug 2007 14:13:50 -0400 Size: 7246 URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070814/e2f28c6a/attachment-0004.nws>
