Commit f488243c authored by Bastien Nocera's avatar Bastien Nocera

Merge branch 'wip/hadess/first-index' into 'master'

New website

See merge request !2
parents 43dacf68 0b1a6556
Pipeline #581 passed with stage
in 3 minutes and 14 seconds
......@@ -20,6 +20,7 @@ pages:
- cd .public/
- for i in *.md ; do discount-mkd2html -css simple.css $i ; done
- rm -f *.md
- cp -r ../images/ .
- cd ..
- mv .public/ public/
# Stable libfprint docs, copied from package, we can't copy from the
......
all: index.html project-history.html security-notes.html us-export-control.html
%.html : %.md
discount-mkd2html -css simple.css $<
# libfprint
![Front](images/Fprint_logo.png)
## API documentation
[libfprint stable](libfprint-stable/)
[libfprint devel](libfprint-dev/)
[fprintd](fprintd-dev/)
# Fingerprint reader support
The fprint project aims to add support for consumer fingerprint reader devices, in Linux, as well as other free Unices.
Previously, Linux support for such devices has been scattered amongst different projects (many incomplete) and inconsistent in that application developers would have to implement support for each type of fingerprint reader separately. For more information on where we came from, see [the project history page](project-history.html).
We're trying to change that by providing a central system to support all the fingerprint readers we can get our hands on. The software is free software and in the long term we're shooting for adoption by distributions, integration into common desktop environments, etc.
Both libfprint and fprintd's source code is available through git, as well as released archives, reachable through their respective GitLab pages.
## Integration
The GNOME desktop [supports fingerprint management](https://help.gnome.org/users/gnome-help/stable/session-fingerprint.html.en) through its **Users** Settings panel. Most Linux distributions support fingerprint login through fprintd.
The OpenBSD operating system also has login integration through [login_fingerprint](http://blade2k.humppa.hu/login_fingerprint-1.2.tar.gz).
## libfprint
libfprint is the centre of our efforts. libfprint is the component which does the dirty work of talking to fingerprint reading devices, and processing fingerprint data.
If you're a user, you probably aren't interested in libfprint, instead you want to find some software which uses libfprint (see Integration section above).
libfprint is of prime interest to developers wishing to add support for specific fingerprinting hardware.
- [GitLab page](https://gitlab.freedesktop.org/libfprint/libfprint)
- [Releases](https://gitlab.freedesktop.org/libfprint/libfprint/tags)
- [stable API documentation](libfprint-stable/)
- [devel API documentation](libfprint-dev/)
## fprintd
fprintd is a daemon that provides fingerprint scanning functionality over D-Bus. This is the software developers will want to integrate with to add fingerprint authentication to OSes, desktop environments and applications. It also includes a PAM module to implement user login, and small command-line utilities if your desktop environment does not integrate support.
- [GitLab page](https://gitlab.freedesktop.org/libfprint/fprintd)
- [Releases](https://gitlab.freedesktop.org/libfprint/fprintd/tags)
- [API documentation](fprintd-dev/)
## Miscalleneous links
- [Mailing list](https://lists.freedesktop.org/mailman/listinfo/fprint)
- [US Export Control](us-export-control.html)
# Project history
## The start: dpfp
In September 2005, Tony Vroon donated Daniel Drake a Microsoft fingerprint reader, with the task of trying to get it running on Linux.
After a slow start, I had an initial incarnation of the driver working and [could see my finger!](http://www.reactivated.net/weblog/archives/2006/01/fingerprinting/).
The Microsoft devices are actually rebranded DigitalPersona devices, but the DigitalPersona drivers do encrypt the image data. It turns out that the firmware controls encryption, and the [Microsoft-supplied firmware disables encryption](http://www.reactivated.net/weblog/archives/2006/01/breaking-encryption-the-easy-way/). So, we could then support the DigitalPersona devices by tweaking the firmware.
This was the [dpfp](http://dpfp.berlios.de/) project in early stages.
Mikko Kiviharju, a Finnish security expert, was researching the devices for a BlackHat Europe paper at the same time. Mikko combined our findings and [generated some press](http://www.itnews.com.au/newsstory.aspx?CIaNID=30692) with the results.
## Parallel work
There weren't many other people thinking about Linux fingerprinting at this time, but there were some projects. UPEK provided binary drivers against BioAPI for their hardware, which Pavel Machek reverse-engineered: it turns out they don't have the imaging problem because UPEK do fingerprint matching in hardware!
A couple of other projects existed which could get images from other devices, but could not do any more.
## Image processing and export control
We can download images from the Microsoft devices, but how do we login with them? We need some kind of image processing, and then comparison of the processed images. Not a small problem.
[I looked into some open source solutions](http://www.reactivated.net/weblog/archives/2006/08/fingerprint-enhancement-and-recognition/) but didn't get too far. In September 2006 I started playing with [NBIS](http://fingerprint.nist.gov/NBIS/index.html) (formerly NFIS2), code from the US government to process and compare fingerprints. It [worked splendidly](http://www.reactivated.net/weblog/archives/2006/10/nfis2-works/), but the project halted due to concerns that we couldn't distribute this from the US without violating the U.S. Export Administration Regulations.
The [Software Freedom Law Center](http://www.softwarefreedom.org/) provided a little advice but this did not really go anywhere or produce any positive findings. NIST themselves were responsive by email but did not like to talk about the legal side, they weren't really sure about the export control restrictions on this software but were playing it safe by limiting distribution to CD only.
## The university project
After some inactivity due to the export concerns, things started happening. I had to choose a 3rd year university project (Computer Science at The University of Manchester), and I proposed a fingerprinting project of broader scale. The university accepted my proposal, agreed it could be an open source project, and the **fprint** idea was born! [Toby Howard](http://www.cs.man.ac.uk/~toby/) accepted the proposal and became the tutor for the project.
Preparing to leaving the US, I sat down and read the US Export Administration Regulations in detail, and discovered that in an open project we are free to redistribute this code after all. I confirmed this in a discussion with the exports office.
I started designing and developing fprint in October 2007. As much as I dislike open source code not being publicly available from the start, as this was an assessed project I felt it necessary to implement the fundamentals myself. The project was then opened up for outside contributions.
THE UNIVERSITY OF MANCHESTER DO NOT ENDORSE THIS THIS SOFTWARE AND ARE IN NO WAY RESPONSIBLE FOR THE CODE CONTAINED WITHIN, OR ANY DAMAGES CAUSED BY IT. Development does not happen on university computers and the project is not hosted at the university either.
After assessment, I [published the report](http://www.reactivated.net/fprint/academic-project/fprint_report.pdf).
## Open source project continuation
After university assessment, the project continues with Bastien Nocera becoming the primary maintainer, Vasily Khoruzhick stepping up to libfprint maintainer in 2016, after years as a developer, and contributions from a wide range of people being included. The project is now hosted by freedesktop.
# Security Notes
Fingerprint-based authentication is a topic which some people are uneasy about.
The fprint project is primarily about getting consumer fingerprint devices operational on Linux, and while security is of interest, it is not a primary objective.
As you'll see from the general discussion below, various aspects of fprint's security depend on the hardware which is driven by the libfprint drivers. Each driver has a page on this site which will have device-specific comments about the security mechanisms in use.
## Disk storage
In order to successfully recognise your fingerprint at some point in time, fprint obviously needs to have prior knowledge of what your fingerprint looks like, and which person/finger that print belongs to. In order to do this, you must _enroll_ your fingerprint for future comparison with new fingerprint scans (this future process is referred to as _verification_).
The enrollment process needs to save information about your fingerprint so that it can refer to it later. It does this by saving data to disk.
In it's current state, fprint is not a very secure system: this data is stored on disk in unencrypted form. This data is not readable by other users, however it is possible that the super-user can access it, and also someone with local access could move the disk to another system in order to gain access to the whole disk.
While the data stored on disk is just information about certain features of your fingerprint (i.e. it is not a complete pictorial representation), it is possible that it could be used by someone to bypass a fingerprint authentication mechanism by appearing as yourself.
The actual data stored on disk is determined by the driver in question. Most libfprint drivers power imaging devices, where the devices simply present an image of your fingerprint to the driver, the driver presents that image to libfprint, and libfprint does image processing and fingerprint matching internally. At enroll time, libfprint stores information about the [minutiae](http://en.wikipedia.org/wiki/Minutiae) points detected on your fingerprint on disk. At verify time, it detects minutiae on the new scan and compares them to the previously-enrolled minutiae set.
Other drivers power devices which do image processing and matching in hardware, so they simply present a "match" or "no match" result to the driver (which is passed up to libfprint and onto the application in question). However, the nature of the system means that these devices still need an enrollment process, and still need the computer to store some fingerprint data on disk. The structure of this data is generally proprietary and unknown, but definitely does encode some kind of information about your fingerprint.
Each libfprint driver has a page on this site, and that page will include some further information about the data that is stored on disk and other security concerns/comments with the devices in question.
I'm not a security expert, but I would hope that there is room for fprint improvement here: we could encrypt the fingerprints on disk and make them substantially harder to 'get at' by unauthorized individuals. If any security experts would like to comment on how we could implement better security for this open source project, it would be much appreciated.
## Latent fingerprints
We leave fingerprints on almost everything that we touch, and these are known as latent fingerprints. It is possible that someone could find a latent fingerprint on an object which you have touched, and identify that the latent fingerprint belongs to yourself. They could fabricate some kind of fake finger and then login to a fingerprint-based system (using fprint or other software) posing as yourself.
On some devices, you may even leave your latent fingerprint on the fingerprint scanner itself. Devices which require you to swipe your finger (rather than just place it on a sensor) generally do not have this problem.
## Fake finger detection
Another point to note is that libfprint does not include any fake finger detection. It may be easier to 'fool' libfprint compared to some commercial systems and drivers which supposedly have a degree of fake finger detection in software.
Some devices probably do a certain amount of fake finger detection in hardware, and libfprint naturally takes advantage of this. Where we know that devices specifically do this, we've noted it on the libfprint driver pages, but this information is not often made public.
## How secure are keyboards anyway?
Has the above made you paranoid? Well, I bet you use a number of computer services which require password-based authorization, which you enter on a keyboard. How secure are keyboards anyway?
* Your password is transmitted 'cleartext' down the keyboard wire
* Or for those with wireless/cordless keyboards (bluetooth/RF), to a substantial area around you.
* It is easy for someone to look over your shoulder and watch the keys as you press them
* It is possible for someone to guess your password
While fingerprinting does have its own security concerns which are outlined above, don't forget the various imperfections with other authorization techniques such as passwords...
## Other fingerprinting approaches
When people think about fingerprint scanning, they often think of standard fingerprint-based authentication, which is primarily what has been discussed above. But what about using fingerprints in contexts which are less critical from a security standpoint? Some ideas are presented below.
* Using a fingerprint to optionally select a username (then requiring password entry as normal)
* Requiring a valid (username,password,fingerprint) triple for authentication purposes
* Using a fingerprint scanner as a quick way of starting applications (e.g. index finger = web browser, middle finger = email client, ...)
* Using a fingerprint as a quick way of loading your user profile for a specific application on a multi-user system
# US Export Control
## Introduction
As detailed in [project history](project-history.html), libfprint originated from an earlier project, which aimed solely to make DigitalPersona fingerprint readers on Linux. These are imaging devices, and after successfully managing to retrieve images from such devices, we ran into a larger problem: how can we process images in order to determine "scan A is the same finger as scan B, login authorised"?
While hunting around for potential solutions, I came across NIST's NFIS2, which is now known as [NBIS](http://fingerprint.nist.gov/NBIS/index.html). You can see on their site that parts of their software are export controlled. At the time, the entire project was export controlled and there was not any description of which parts might potentially be under which export classifications. Now it says:
> It is our understanding that NFSEG and BOZORTH3 fall within ECCN 3D980, which covers software associated with the development, production or use of certain equipment controlled in accordance with U.S concerns about crime control practices in specific countries.
>
> As US export control applies to all exports, such information indicates that _all_ fingerprint processing code (not just NIST's implementation) is subject to these restrictions. Regardless of whether we were to use NFIS2 or not, if NIST's information was anything to go by, our code would fall under special restrictions when being exported from the US. NIST avoided the issue by limiting distribution to CDROM only -- they used your postal address to ensure you are not located in any country designated as terrorist-supportive. Such distribution control is obviously not suitable for an open source project.
I contacted NIST, and Craig Watson was kind enough to provide some useful responses, even though it is clearly not an area of interest for himself. Craig clarified which export classification that NIST thought they might be bound to, and explained that this was only their "understanding" and they were not 100% sure that this classification applies.
James Vasile of the [Software Freedom Law Center](http://www.softwarefreedom.org) kindly spent some time investigating the matter, but no good news emerged.
Some time later, I sat down to really analyse the [Export Administration Regulations](http://www.access.gpo.gov/bis/ear/ear_data.html) to look for solutions. It turns out that distributing NBIS in an open source project is not restricted, for reasons explained below.
## Justification for export safety
We start with section 732.2 of the EAR, which provides a set of steps for determining the scope of the EAR and whether your export falls below it.
### Step 1: Items subject to the exclusive jurisdiction of another Federal agency
I think that this step basically says:
> if your export falls under [ITAR](http://en.wikipedia.org/wiki/International_Traffic_in_Arms_Regulations), then follow ITAR and ignore the EAR
Nevertheless, NBIS does not appear to be subject to any exclusive jurisdiction.
### Step 2: Publicly available technology and software
This step says:
> Determine if your technology or software is publicly available as defined and explained at part 734 of the EAR
So we now fall into part 734...
#### Part 734
Before we reach the real meat, here are some informative quotes from 734.1:
> This part is the first step in determining your obligations under the EAR. If neither your item nor activity is subject to the EAR, then you do not have any obligations under the EAR and you do not need to review other parts of the EAR.
> Conversely, items and activities that are not subject to the EAR are outside the regulatory jurisdiction of the EAR and are not affected by these regulations.
So, we're looking for something that makes us "not subject to the EAR".
Some software-related notes in part 734.2 explain that export of software includes release of EAR-subjected software in a foreign country and release of EAR-subjected source code to a foreign national. Similar logic applies to reexports.
734.2(9) starts talking about software again, but specifically about encryption, which does not concern this code.
Moving onto section 734.3, we see:
> Except for items excluded in paragraph (b) of this section, the following items are subject to the EAR:
Skipping over those items, we reach paragraph (b).
> (b) The following items are not subject to the EAR:
Item 3 of that paragraph says:
> Publicly available technology and software [...] **that are already published or will be published** as described in §734.7 of this part;
Moving down to section 734.7, "PUBLISHED INFORMATION AND SOFTWARE":
> (a) **Information is "published" when it becomes generally accessible to the interested public in any form**, including:
> (1) Publication in periodicals, books, print, **electronic**, or any **other media available for general distribution to any member of the public** or to a community of persons interested in the subject matter, such as those in a scientific or engineering discipline, either **free** or at a price that does not exceed the cost of reproduction and distribution
It is clear that open source software, available as free download to anyone and everyone, would be classified as published information according to the above definition. Going back to 734.3, this indicates that such software is not subject to the EAR. Falling back further to section 734.1, we see that we _do not have any obligations under the EAR and [...] do not need to review other parts of the EAR_.
### Back to 732.2 (step 2)
> (1) If your technology or software is publicly available, and therefore **outside the scope of the EAR**, you may proceed with the export or reexport if you are not a U.S. person subject to General Prohibition Seven.
General Prohibition Seven is briefly described in section 732.3(j) and applies to all U.S. nationals. I am not included in that group, however I am sure that sourceforge (our files host) have mirrors in the US, so I need to consider this anyway.
#### General Prohibition 7
736.2(b)(7) contains the exact text for GP7. This says:
> You may not export certain chemicals (not relevant here)
> You may not provide certain assistance to foreign nationals regarding encryption (not relevant here)
> You may not do anything mentioned in 744.6(a) or 744.6(b)
> * 744.6(a) covers contributions to nuclear explosives, missiles, or biological weapons. It also covers knowingly assisting an illegal export, and helping people build chemical weapons factories. (entirely irrelevant)
> * 744.6(b) says: BIS may decide to impose export license requirements for an export at will, if they feel it may contribute to something in (a) above.
So, it does not seem possible for GP7 to apply to someone regarding the export of libfprint.
We've now completed section 734.2, and have deduced that we are **not subject to the EAR**.
## Further justification
Supplement 1 to part 734 contains an example which is directly relevant to our situation.
> Question A(1): I plan to publish in a foreign journal a scientific paper describing the results of my research, which is **in an area listed in the EAR as requiring a license** to all countries except Canada. Do I need a license to send a copy to my publisher abroad? Answer: No. **This export transaction is not subject to the EAR. The EAR do not cover technology that is already publicly available, as well as technology that is made public by the transaction in question** (§§734.3 and 734.7 of this part). Your research results would be made public by the planned publication. You would not need a license.
Later on in the same supplement, we have 2 more related questions:
>
> Question G(1): Is the export or reexport of software in machine readable code subject to the EAR when the source code for such software is publicly available? Answer: If the source code of a software program is publicly available, then the machine readable code compiled from the source code is software that is publicly available and therefore not subject to the EAR. Question G(2): Is the export or reexport of software sold at a price that does not exceed the cost of reproduction and distribution subject to the EAR? Answer: Software in machine readable code is publicly available if it is available to a community at a price that does not exceed the cost of reproduction and distribution.
## Discussion with U.S. Exports office in Washington
For further clarification, I contacted the U.S. exports office in Washington and explained the situation. They confirmed that such distribution is not subject to the EAR, and also commented that NIST's current distribution method (sent on CDROM to pretty much anyone who asks for it) would likely also qualify the software as publicly available information, even before the first libfprint export occurs.
## Conclusions
As long as libfprint remains open source and freely downloadable, it is exempt from the U.S. Export Administration Regulations. This exemption applies to everyone, so if you're considering redistributing libfprint potentially from the US to another country, _you have nothing to worry about_.
I can also conclude that NIST's own distribution restrictions are unnecessary.
Disclaimers: Although I fully believe the above is true and correct interpretation of the EAR, and after spending several hours trawling through it I am confident I have a good understanding of the system, I am not a lawyer or exports officer. Also, like any other software, export controls may potentially apply on this project in other parts of the world. I have confirmed that the UK has no such restrictions regarding fingerprinting, but have not looked at other area of UK export restrictions, and have not examined export control policies for other countries.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment