A METHOD, A SYSTEM AND A BIOMETRIC SERVER FOR CONTROLLING ACCESS OF USERS TO DESKTOPS IN AN ORGANIZATION

Abstract

A method for controlling access of users to desktops, comprising: 1. a user enters a login; 2. an organization server verifies if the user is authorized to access the desktop, and returns a pseudo of the user; 3. the user scans a pattern of fingerveins of one finger with a biometric scanner comprising cameras at different angles; 4. a file corresponding to said images is encrypted by said biometric scanner (B) with a public key of a biometric server and signed with a private key of said biometric scanner, and sent to the desktop; 5. the desktop forwards said file to said biometric server; 6. the biometric server decrypts the file, verifies the signature of the biometric scanner, and matches the received images with reference images associated with said pseudo; 7. the biometric server decides if the recognition succeeded, failed, or if an additional scan is needed.

Claims

1. A method for controlling access of users to desktops in an organization, comprising the steps of: 1. a user requests access to a desktop; 2. an organization server verifies if the user is authorized to access the desktop, and returns a pseudo of the user; 3. the user scans a pattern of fingerveins of one finger with a biometric scanner comprising a plurality of cameras at different angle around the finger, resulting in a plurality of images of said pattern; 4. a file corresponding to said images is encrypted by said biometric scanner with a public key of a biometric server, and signed with a private key of said biometric scanner, and sent to the desktop; 5. the desktop forwards said encrypted and signed file to said biometric server; 6. the biometric server decrypts the received file with its private key, verifies the signature of the biometric scanner, and matches the received images with reference images associated with said pseudo; 7. the biometric server decides based on the result of this match if the recognition succeeded, failed, or if an additional scan of the user's finger is needed.

2. The method of claim 1, wherein the biometric templates are only accessible to the biometric scanner and to the biometric server.

3. The method of claim 1, wherein the claimed identity of the user is only accessible to the desktop and to the organization server.

4. The method of claim 1, wherein the biometric server compares images of the same finger from different angles with reference images of the same finger corresponding to the claimed pseudo, and delivers several matching scores which are aggregated before a decision to grant or refuse access is taken.

5. The method of one claim 1, wherein the steps 3-7 are iteratively repeated until a predefined false acceptance rate and/or false rejection rate is achieved.

6. The method of claim 5, wherein the number of iterations that is needed is approximated based on a method of sequential distinguishers.

7. A control access system for controlling access of users to desktops in an organization, comprising: 1. a plurality of desktops in which a user can request an access; 2. an organization server arranged for verifying if the user is authorized to access the desktop, and for returning a pseudo of the user; 3. a biometric scanner arranged for letting the user scan a pattern of fingerveins of one finger, said biometric scanner comprising a plurality of cameras at different angle around the finger, resulting in a plurality of images of said pattern, said biometric scanner further comprising a processing system arranged for encrypting a file corresponding to said images with a public key of a biometric server, for scanning said file with a private key of said biometric scanner, and for sending the encrypted and signed file to one said desktop; 4. a biometric server distinct from said organization server; 5. said desktop being further arranged for forwarding said encrypted and signed file to said biometric server; 6. said biometric server being further arranged for decrypting the received file with its private key, for verifying the signature of the biometric scanner, and for matching the received images in said file with reference images associated with said pseudo; 7. the biometric server being further arranged for deciding based on the result of this match if the recognition succeeded, failed, or if an additional scan is needed.

8. The system of claim 7, wherein the biometric templates are only accessible to the biometric scanner and to the biometric server.

9. The system of claim 7, wherein the claimed identity of the user is only accessible to the desktop and to the organization server.

10. The system of claim 7, wherein the biometric server is arranged for comparing images of the same finger from different angles with reference images from the same angles of a finger associated with the same pseudo, and for delivering several matching scores which are aggregated before a decision to grant or refuse access is taken.

11. The system of claim 7, wherein the biometric server is further arranged for iteratively repeating a scan of said fingervein until a predefined false acceptance rate and/or false rejection rate is achieved.

12. A biometric server arranged for receiving a file, for decrypting the received file with a private key, for verifying the signature of the file, and for matching received images in said file with reference images of a user identified by a pseudo; the biometric server being further arranged for deciding based on the result of this match if the recognition succeeded, failed, or if an additional scan of the user's finger is needed.

13. The biometric server of claim 12, wherein the biometric server is further arranged for comparing images of the same finger from different angles with reference images from the same angles of a finger associated with the same pseudo, and for delivering several matching scores which are aggregated before a decision to grant or refuse access is taken.

14. The biometric server of claim 13, further arranged for iteratively repeating a scan of said fingervein until a predefined false acceptance rate and/or false rejection rate is achieved.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The invention will be better understood with the aid of the description of an embodiment given by way of example and illustrated by the figures, in which:

[0037] FIG. 1 shows a view of an access control system according to the invention;

[0038] FIG. 2 is a side view of a biometric scanner for capturing a fingervein of a user;

[0039] FIG. 3 is a front view of a biometric scanner for capturing a fingervein of a user;

DETAILED DESCRIPTION OF POSSIBLE EMBODIMENTS OF THE INVENTION

Notations

[0040] We use following notations and abbreviations in the text: [0041] ⊥ denotes an error message or a dummy value (e.g. a null pointer, an empty string, or an empty list). [0042] PKC Public-key cryptosystem. Given a cryptographic key pair (pk, sk), PKC encrypts a plaintext pt into a ciphertext ct using pk and decrypts it back using sk [0043] DSS Digital signature scheme. Given a key pair (vk, sk), DSS signs data data using sk and verify the signature using vk [0044] AEAD Authenticated encryption with associated data. Given a key K∈AEAD.K, AEAD encrypts a plaintext pt with associated data ad and a nonce N∈AEAD.N and decrypts it back with the same K. [0045] H Hash function. Given a bitstring x, H computes a digest with H(x). [0046] Dec Deterministic function.

[0047] Typically, PKC provides INDCCA security, DSS is EFCMA-secure, AEAD is secure as a MAC and as an encryption against chosen plaintext/ciphertext attacks, and we consider a collision-resistant hash function H. These primitives work with the following notations: [0048] PKC.Gen.fwdarw.(pk,sk) PKC.Enc.sub.pk(pt).fwdarw.ct PKC.Dec.sub.sk(ct).fwdarw.pt [0049] DSS.Gen.fwdarw.(vk,sk) DSS.Sign.sub.sk(data).fwdarw.σ DSS.Verify.sub.vk(data,σ).fwdarw. 0/1 [0050] AEAD.Enc.sub.K(N,ad,pt).fwdarw.ct AEAD.Dec.sub.K(N,ad,ct).fwdarw.pt

Example of Embodiment

[0051] In this description, we focus on an organization which has its own network and file system. Many organizations offer a system to authenticate its users with passwords, such as Active Directory implemented with LDAP-like protocol for example.

[0052] More specifically, the following embodiment is related to users aiming to log in desktops/laptops D under a network in such an organization using a biometric scanner B. In such an organization, an organization server L is used for verifying if a user requesting access is authorized to access his machine and/or the network. In one example, the organization server authenticates the user with a login and password entered by the user. The organization server may also identify the user and verifies if he belongs to a group of authorized users. The organization server L may include a directory, such as for example a LDAP directory, to authenticate or identify the users through passwords. In the present invention, to add an extra layer of secure authentication, a biometric server S which is responsible for the biometric recognition is introduced.

[0053] A high-level overview of the system is given in FIG. 1. Solid rectangles are the machines whereas dashed rectangles are the databases on the corresponding machines. Dashed arrow indicates the inputs from the user to the specified machines. Solid arrows indicate the exchanges between the machines over the network.

[0054] The method is based on a system with different entities, including machines, databases, and human users:

[0055] User: U: a person who wants to access a desktop and a network, and which can be authenticated and authorized for example with a login, password pwd, and fingervein. The fingervein is unique for each user and corresponds to a set of images of the 3D pattern or blood vessels in one finger of the user, or to features extracted from such images.

[0056] Biometric scanner: B. Biometric scanners capture biometric information of users and do necessary computations by following the protocol honestly. The biometric scanner takes several, for example threes images of a user's finger from different angles, which we call 3D fingervein or simply fingervein. Each biometric scanner has a unique identifier serial.sub.B, a private cryptographic key sk.sub.B and knows the public cryptographic key pk.sub.S of the associated biometric server S.

[0057] Organization server: L. This server may belong to the organization and contains a database with a directory of its users, their names (login) and passwords (pwd). In one embodiment, the organization server may be based on Microsoft Active Directory. The organization server assigns a pseudo to some users, for privacy reasons. The pseudo is not required to be remembered (or even known) by the user. The organization server L has a unique identifier serial.sub.L. A user name login is assumed to be unique to each L, meaning that the (serial.sub.L, login) pair is unique.

[0058] Desktops: D. The desktop computers can connect to the information network of the organization. In this document, the expression “desktop” should not be limited to computers with a desktop form factor, but also includes laptop computers, all-in-one computers, tablets, smartphones, and any similar user equipment that can access the network of the organization once authenticated and authorized by the organization server.

[0059] In order to control access of users to desktops, each desktop is set up with the address of its organization server L and the address addr.sub.B of a close-by biometric scanner B. Each desktop knows the public cryptographic key pk.sub.S of the associated biometric server S.

[0060] Enrollment station: E. (Not shown on FIG. 1) It consists of a computer, tablet or similar equipment used to enroll users with their biometric templates scanned through a biometric scanner B. The enrolment station E communicates with the biometric scanner B to capture biometric templates, i.e., and communicates with the biometric server S to add, remove, or modify entries in the database on the server.

[0061] Biometric server: S. In one embodiment, there is only one biometric server. It contains or can access two databases DB.sub.0 and DB.sub.1: DB.sub.0 other stores identifiers of the enrollment stations and biometric scanners and DB.sub.1 stores the reference biometric templates (ref temp) of users along with their associated pseudo (pseudo). The biometric server is used for matching the reference templates to the claimed users. The database DB.sub.0 is used during the authentication of data coming through a legitimate enrollment station E and a legitimate biometric scanner B. The biometric server S can be outside of the organization's network. One biometric server can be shared by different organizations.

Setup

[0062] A list of parameters that each element of the system holds is indicated in Table 1.

TABLE-US-00001 TABLE 1 D B L E S pk.sub.S pk.sub.S pk.sub.S (pk.sub.S, sk.sub.S) serial.sub.L (vk.sub.B, sk.sub.B ) (vk.sub.E, sk.sub.E ) K.sub.S addr.sub.B serial.sub.B serial.sub.L serial.sub.E DB = {(login, DB.sub.0 = {(serial, vk)} pwd, pseudo)} DB.sub.1 = (pseudo, finger, ref-temp, policy)}

[0063] More specifically, the biometric server S generates or stores its PKC key pair (pk.sub.S, sk.sub.S) and a symmetric key K.sub.S∈AEAD.K. Each biometric scanner B is configured with its own DSS key pair (vk.sub.B, sk.sub.B) and a unique serial number serial.sub.B. It keeps a copy of pk.sub.S, as well.

[0064] Each enrollment station E is configured with its own DSS key pair (vk.sub.E, sk.sub.E) and a unique serial number serial.sub.E. It stores pk.sub.S, as well. The biometric server S maintains a directory DB.sub.0 of the public keys vk (vk.sub.B or vk.sub.E) of each B and E by their serial numbers (serial.sub.B or serial.sub.E). The biometric server S holds one database DB.sub.1 of (pseudo, finger, ref-temp, policy) and (pseudo, policy) entries which is populated by the enrollment station.

[0065] Each desktop D may hold the public key pk.sub.S of the biometric server S. The organization server L holds a database of (login, pwd, pseudo) entries for first layer authentication with passwords.

[0066] One organization may consist of many departments. We identify each department with “domain” which is referred by a unique string domain. The organization server L is unique for each domain, that is L stores users data for this specific domain. We assume that each pseudo is unique. The biometric server S is unique (cross-domain). We assume a secure communication between D and L. We further assume that the password-based protocol between D and L is secure by default.

[0067] As depicted in FIG. 1, D serves as an intermediate machine between the biometric scanner B and the biometric server S to make them communicate. The method of the invention uses this “intermediary” in a secure way by encrypting the exchange of messages sent by the biometric scanner B to the biometric server S, using the public key pk.sub.S, and by mutually authenticating these two entities when they communicate.

[0068] An aim of the invention is to add strong access control to an existing password-based access control system deployed between D and L.

[0069] An aim is to add no software on the directory server L and to make as little changes as possible on the desktops D.

[0070] For privacy reasons, nobody but the biometric scanners B and the biometric server S need to see biometric templates (biometric test and reference images).

[0071] Nobody but the organization server L and the desktops D see the identity of the user. Hence, we only allow the biometric server S to associate biometric data to a pseudo.

[0072] Nobody but L, D, and S see the pseudo of the user. Therefore, unless there is any collusion, the method offers strong privacy by design, and no one can associate biometric templates with a user.

[0073] We make sure that the server S will only treat information coming from a legitimate biometric scanner. The desktops D only forwards messages and does one encryption for S. Hence, the overhead on the desktop D is minimal. This makes the protocol feasible to deploy on already existing systems.

[0074] In this specific embodiment, the user authentication is based on fingervein biometry. To defeat spoofing attacks, it uses what we call 3D fingervein by capturing fingervein through several angles.

[0075] An example of biometric scanner B for capturing fingervein is shown in FIGS. 2 and 3. It comprises a light source, such as LEDs, on one side of a finger of the user U, and three cameras 20L, 20C, 20R for capturing images of the blood vessels 10 in the finger, from three different angles.

[0076] The scanning of the finger may use infrared lights and several, in this example three, cameras 20L, 20C, 20R placed with different angles for capturing images of the blood vessels 10 in the finger, from several different angles. The scanning happens when the user U inserts her finger in a hole where the top is filled with a rack of infrared LEDs 21 and the bottom has the cameras 20. The scanner may interact with its user through color LEDs and/or a small display. The infrared LEDs illuminate a finger and three cameras take images, such as QVGA images, of the finger from three different angles.

[0077] When prompted to scan a finger, the biometric scanner B waits until a presence sensor detects a finger. As each LED corresponds to a region of the picture, we dynamically adjust by software the power of each LED so that the histogram of the corresponding region is optimal. Then, the cameras take a picture. Images may be in gray-scale of size 320×240. They are stored in png format with a file size of one image being around 70 KB in total.

[0078] The biometric scanner B (FIG. 2) comprises a processing system, such as a microprocessor, a microcontroller, or an embedded computer, such as a Raspberry Pi, for controlling the illumination and capture, processing the images captured by the several cameras, extracting features from each image, and sending the features (what we call the fingervein) of each image to the desktop D. The fingervein sent to the desktop D is encrypted with the public key pk.sub.S of the biometric server S and signed with the private key sk.sub.B of the biometric scanner B.

[0079] The communication with the biometric scanner B may happen through Ethernet, USB or WiFi for example.

[0080] The biometric scanner B further comprises a processing system, such as a microprocessor or microcontroller or embedded computer, for controlling the illumination and capture, processing the images captured by the three cameras, extracting features from each image, and sending the features (what we call the fingervein) of each image to the desktop D. The fingervein sent to the desktop D is encrypted with the public key pk.sub.S of the biometric server S and signed with the private key sk.sub.B of the biometric scanner B.

[0081] The desktop D forwards the encrypted fingervein to the biometric server S, which decrypts it with its private key and verifies the signature of the biometric scanner.

[0082] The biometric server S then runs a matching algorithm with the features extracted from the several images of the finger from different angles, and compares those features with reference features of the claimed user obtained during enrolment. Since several pairs of images are compared, the process delivers several matching scores, for example three.

[0083] According to one aspect, those different matching scores are aggregated before a decision to grant or refuse access is taken.

[0084] The aggregation of matching scores has been developed in order to reach a desired FAR and FRR. FAR is the false acceptance rate, i.e. the probability that a wrong finger is accepted, FRR is the false rejection rate, i.e. the probability that the right finger is rejected.

[0085] To do this, the invention uses the method of sequential distinguishers. At every capture, the algorithm decides if the recognition succeeded, failed, or requires more biometric samples to conclude. Hence, a user may be required to be scanned several times, although in most cases, one capture is enough.

Access Control Protocols

[0086] For this section, we start defining a (straightforward) prior Access Control AC with login credentials and then continue with an example of extended AC method according to the invention.

[0087] More precisely, the prior access control method AC works as follows. [0088] 1. The user types his identifier login and his password pwd on a desktop D. [0089] 2. The desktop D queries the organization server L with queryL=(login, pwd) and gets the response respL. Then, the organization server L computes the response by respL=pseudo, where (login, pwd, pseudo) is a valid record in the database. Otherwise, respL=⊥. [0090] 3. If the response by L is ⊥, access is denied and the protocol ends. Otherwise, the desktop D proceeds with the step of extended access control.

[0091] The extended access control AC of the invention depends on the biometric matching. That is, upon inviting the user U to the biometric scanner B to provide a fingervein (test biometric features extracted from the images captured with the scanner), the fingervein will be matched with the reference fingervein of the claimed user, as stored in the database DB.sub.1 during enrollment.

[0092] The matching algorithm returns a score which may be insufficient to decide to accept or reject. The decision can be to ask for another scan. The final decision is based on all collected scan. Therefore, the extended AC works in a succession of iterations which are defined by a capture step. The capture step can include a prompt for the capture of the fingervein of one specific finger. Some special steps are used to terminate the iteration cycle: a step which accepts and a step which rejects the authentication attempt.

TABLE-US-00002 TABLE 2 finger.sub.l,n Represents a set l of fingers to be scanned n times. The access is granted conditioned that the user's corresponding finger matches with the reference template stored in the database. The step may include a display of a message on the scanner. “always” The desktop D always grants access. “never” The desktop D always denies access. “sms” A verification code is sent by short message, for example SMS, to the user who types it on D. “security” An alert is sent to the security officer who may call the user.

[0093] In Table 2, we give a list of steps for the extended authentication control along with their descriptions. We define both the step of the first iteration and then the algorithm to decide on the next step based on the collected results (i.e. aggregated scores). These two elements form the policy: policy.initmethod and policy.method. More precisely, the initial step to be used is policy.initmethod and after having collected a list hist of scores, the next step is policy.method(hist). If hist is enough, we have policy.method(hist)=“always” (access granted) or policy.method(hist)=“never” (access denied). The step could repeatedly be finger{i},1 (meaning to scan finger i once), change fingers, or try other modalities. We specify the policy for each user at enrollment, as one record of DB.sub.1.

[0094] We will now describe three stages of the extended authentication control of the invention.

[0095] The first iteration of the extended access control AC starts with a protocol called “Stage 1” with the biometric server S who sets the initial step (line 4-6 on the right in the diagram for stage 1). Then, it goes through a protocol called “Stage 2” using step (line 2-8 on the left and line 7 on the left in the diagram of stage 2).

TABLE-US-00003 Desktop D (Stage 1) input: pseudo, addr.sub.B, serial stored: pk.sub.s 1: K.sub.1 ←$ AEAD.  2: query.sub.s ← PKC.Enc.sub.pk.sub.s (‘‘Request’’, K.sub.1, pseudo, serial.sub.B) _ 3: send query.sub.s to S |.fwdarw. 4: get resp.sub.s | | 5: parse resp.sub.s = [N.sub.12, ct.sub.1] | | 6: (token.sub.s, K) ← AEAD.Dec.sub.K.sub.1, (N.sub.12, ⊥, ct.sub.1) | | 7: erase K.sub.1 | | 8: continue to Stage 2 | | Biometric server S (“Request”, query) | | stored: sk.sub.s, K.sub.s | .fwdarw. 1: receive query.sub.s | 2: if anything fails below then return resp.sub.s = ⊥ | 3: PKC.Dec.sub.sk.sub.s (query.sub.s) .fwdarw. (‘‘Request’’, K.sub.1, pseudo, serial.sub.B) | 4: retrieve policy with pseudo from DB.sub.1 | 5: hist ← ⊥ | 6: method ← policy.method (hist) | 7: set T as current time | 8: ad ← method | 9: K    AEAD.  | 10: pt ← (T, pseudo, hist, serial.sub.B, K) | 11: N11, N12 ← $AEAD.  | 12: token.sub.s ← [N.sub.11, ad, AEAD, Enc.sub.K.sub.s (N.sub.11, ad, pt)] | 13: resp.sub.S ← [N.sub.12, AEAD, Enc.sub.K.sub.1, (N.sub.12, ⊥, token.sub.s, K)] | _ 14: return resp.sub.S indicates data missing or illegible when filed

Access Control Stage 1 (Between D and 5)

[0096]

TABLE-US-00004 Desktop D (Stage 2) 1: parse token.sub.s = [N.sub.11, ad, ct.sub.2] 2: parse ad = method 3: if method ∈ {‘‘sms’’, ‘‘securitas’’} then 4:  method ← treat method, hist, serial.sub.B, login, host) 5: end if 6: if method = ‘‘always’’ then grant access 7: if method = ‘‘never’’ then deny access 8: if method is not biometric then abort 9: display ‘‘scan finger in scanner serial.sub.B’’ 10: query.sub.B ← (serial.sub.B, token.sub.s) _ 11: send query.sub.B to B at addr.sub.B |.fwdarw. 12: get resp.sub.B | | 13: continue to Stage 3 | | Biometric scanner B | | stored: Sk.sub.B, pk.sub.s, serial.sub.B | .fwdarw. 1: receive query.sub.B | 2: if anything fails below then return resp.sub.B = ⊥ | 3: parse query.sub.B = (serial.sub.B, token) | 4: cheek that serial.sub.B is correct | 5: parse token = [N, ad, ct] | 6: parse ad = method | 7: parse method = (finger.sub.1,n, message) | 8: display message | 9: extract I, n from finger.sub.I,n | 10: for i ∈ I, j = 1, . . . n do | 11:  invite finger | 12:  capture temp.sub.i,j | 13: end for | 14: temp ← list of all (finger.sub.i, temp.sub.i,j) | 15: data.sub.0 ← (query.sub.B, temp) | 16: sign.sub.0 ← DSS.Sign.sub.sk.sub.B (data.sub.0) | 17: resp.sub.B ← PKC.Enc.sub.pk.sub.s (data.sub.0, sign.sub.0) | _ 18: return resp.sub.B

Access Control Stage 2 (Between D and B)

[0097] In Stage 2, the desktop D may decide to end (by granting access or denying access) or interact with the biometric scanner B.

[0098] After that, it goes through a protocol with the biometric server S called “Stage 3”. In this stage, we determine the next step to use (line 24 in the following diagram).

TABLE-US-00005 Desktop D (Stage 3) 1: K.sub.2 ←   AEAD.  2: query.sub.s ← PKC.Enc.sub.pk.sub.s (‘‘Match’’, K.sub.2, K) _ 3: send query.sub.s and resp.sub.B to S |.fwdarw. 4: get resp.sub.s | | 5: parse resp.sub.s ← (N.sub.12, ct.sub.2) | | 6: (token.sub.s, K) ← AEAD.Dec.sub.K.sub.2 (N, H (query.sub.B), ct.sub.2) | | 7: erase K.sub.2 | | 8: continue to Stage 2 | | Biometric server S (‘‘Match’’ query) | | stored: 5k.sub.s, K.sub.s | .fwdarw. 1: receive query.sub.s and resp.sub.B | 2: if anything fails below then return resp.sub.s = ⊥ | 3: parse (‘‘Match’’, K.sub.2, K) = PKC.Dec   (query.sub.s) | 4: (data, sign) ← PKC.Dec  , (resp.sub.B) | 5: parse data as (query.sub.B, temp) | 6: parse query.sub.B as (serial.sub.B, token.sub.s) | 7: retrieve vk.sub.B form DB.sub.0 with serial.sub.B | 8: DSS.Verify   (data, sign) | 9: parse token.sub.s as |N, ad, ct) | 10: pt ← AEAD.Dec.sub.K.sub.s (N, ad. ct) | 11: parse ad = finger.sub.I,n | 12: parse pt = (T, pseudo, hist, serial.sub.B, K) | 13: check K = K | 14: check serial.sub.B is correct | 15: verify T not too early/late | 16: x ← ⊥ | 17: for all (finger  , temp   ) ∈ temp do |  18: retrieve ref-temp, from DB.sub.1 with (pseudo, finger  ) |  19: compute score with the matching algorithm |  20: x ← (x, (i, score)) | 21: end for | 22: hist′ ← (hist, x) | 23: retrieve policy from DB.sub.1 with pseudo | 24: determine method = policy.method (hist′) | 25: set T′ as current time | 26: ad ← method | 27: K′    AEAD.  | 28: pt ← (T′, pseudo, hist′, serial  , K′) | 29: N.sub.11 , N.sub.12 ←    AEAD.  | 30: token′.sub.s ← [N11, ad, AEAD.Enc.sub.K   (N.sub.11, ad, pt)] | 31: resp   ← (N.sub.12, AEAD.Enc.sub.K.sub.2 (N.sub.12, H(query.sub.B), token′.sub.s, K′)) | _ 32: return resp.sub.s indicates data missing or illegible when filed

Access Control Stage 3 (Between D and 5)

[0099] Then, the method goes back to Stage 2. Note that whenever there is a failure in verification in a protocol, the protocol aborts immediately. Otherwise, the protocol continues.

[0100] The biometric scanner B is a stateless device. When it receives a request, it takes pictures, sends its response, then sleeps back.

[0101] As the biometric server S is stateless as well, the state information is carried inside a token that the biometric server S encrypts for himself. The token works like a cookie in a browser: the biometric S gives token in the response to the desktop D and D must provide it in the next query to the biometric server S. The token also contains the step to be performed in clear and which can be parsed by the desktop D and by the biometric server B.

Enrollment Protocol

[0102] The enrollment protocol is given in the following table:

TABLE-US-00006 Enrollment station on device E input: pseudo, policy, addr.sub.B, serial.sub.B stored: sk  , pk.sub.s, serial  Stage 1: 1: set T as current time 2: K   ←    AEAD.  . N   AEAD.  3: finger   ← policy, initmethod 4: ad ← finger  5: pt ← (T, pseudo, policy) 6: token   ← [N, ad, AEAD.Enc   (N, ad, pt)] 7: query  ← (serial  , token  ) [00001] Stage 2: 10: data  , ← (‘‘Enroll’’, K  , serial  , H(query.sub.B), resp.sub.B) 11: sign.sub.1 ← DSS.Sign   (data  ) 12: query   ← PKC.Enc   (data  ), sign  ) _ 13: send query.sub.s to S |- .fwdarw. 14: get resp.sub.s | | 15: parse resp.sub.s = N′ , ct′) | | 16: check ‘‘ok’’ = AEAD.Dec   (N′, ⊥, ct′) | | 17: erase K.sub.0 | | Biometric server S (‘‘Enroll’’ query) | | stored: sk.sub.s | | .fwdarw. 18: receive query  | 19: If anything fails below then return resp.sub.s = ⊥ | 20: (data  , sign  ) ← PKCDec   (query  ) | 21: parse data.sub.1 = (‘‘Enroll’’, K.sub.0, serial  , h, resp  ) | 22: retrieve  from DB   with serial  | 23: DSS.Verify   (data  , sign  ) | 24: (data  , sign.sub.0) ← PKCDec   (resp.sub.B) | 25: parse data   = query.sub.B, temp) | 26: check h = H (query.sub.B) | 27: parse query.sub.B = (serial.sub.B, token  ) | 28: retrieve vk.sub.B from DB   with serial  | 29: parse token   = (N, ad, ct) | 30: pt ← AEAD.Dec   (N, ad, ct) | 31: parse ad = finger  | 32: parse pt = (T, pseudo, policy) | 33: verify T not too early/late | 34: DSS.Verify   (data.sub.0, sign.sub.0) | 35: store (pseudo, policy) in DB: | 36: parse temp = (finger   temp  )  | 37: for each i ∈ l do | 38:  decide which    defines ref-temp   = temp  | 39:  store (pseudo, finger, ref-temp  ) in DB.sub.1 | 40: end for | 41: pick N′ ∈ AEAD.  | 42: resp.sub.s ← [N′, AEAD.Enc.sub.K.sub.0 (N′, ⊥, ‘‘ok’’)] | _ _ 43: return resp.sub.s indicates data missing or illegible when filed
Enrolment Protocol. The Dashed Square Represents the Steps Run by the Biometric Scanner B as in Access Control Stage 2.

[0103] The input to the enrollment protocol (on E) is a string pseudo associated to a user to register, and the address addrB of the scanner B. The enrollment could be done remotely: E and B need not be close to each other if the identity of the scanned user can be trusted. Specifically, E goes through two stages: Stage 1 with B and Stage 2 with S. In Stage 2, S receives a query of type “Enroll”. Both stages are defined in FIG. 7. In communication with B, only serial.sub.B, N, and ad=step are in clear. All the rest is end-to-end encrypted.

[0104] Both the biometric server S and the biometric scanner B are stateless (both in enrollment and access control phase). The enrolment station E (and later the desktop D) acts as a master in the communication with the biometric server S and with the biometric scanner B. The biometric scanner B answers to queries in a unique way, so there in no difference between access control and enrollment for the biometric scanner B.

Biometric Algorithms

[0105] The raw image from the scanner is first cleaned up in the biometric scanner B using an image pre-processing algorithm; this pre-processing may comprise illumination and contrast correction, noise reduction, background elimination, cropping, adjustment of the orientation, etc. Finally, the biometric features are extracted. The final feature extraction delivers a black-and-white image which is stored in the database DB.sub.1 or matched with a record in this database. Each record stores several images, for example three.

[0106] Matching algorithm. The biometric matching algorithm compares the test image delivered during access control with one or a plurality of reference images (Templates) stored during enrolment.

[0107] Given two images, the biometric matching algorithm returns a score, for example a score between 0 and 0.5.

[0108] Score algorithms with aggregation. Since the fingervein biometric sensor delivers several images, we obtain several scores that need to be aggregated.

[0109] According to one aspect, the following method steps are preferably used for this aggregation.

[0110] After m iterations (m scan of the finger of one user U), we have a list hist=(score.sub.1, . . . , score.sub.m) where each score.sub.i is a triplet of numbers in the example with three images. Hence, hist=(s.sub.1, . . . , s.sub.n) with n=3 m. We model the s.sub.i by independent random variables. If the test images and the reference images all correspond to the same finger, we assume that every s.sub.i follows one distribution same.sub.c, depending on the used camera c (left, center, or right in the example with three cameras) to scan the templates. If they correspond to different fingers, we assume that every s.sub.i follows one distribution diff.sub.c.

[0111] We design a sequential distinguisher such that given hist, the output is either “same”, or “diff”, or ⊥, meaning that no decision is reached, hence more samples are needed. We define the false acceptance rate FAR=Pr.sub.diff [output=same], and the false rejection rate FRR=Pr.sub.same[output=diff]. An aim is to make a distinguisher reaching a target FAR.sub.target and FRR.sub.target, and requiring as few samples as possible.

[0112] To solve this problem, we use the theory of sequential distinguishers previously used in block cipher cryptanalysis. A complete description of this theory can be found in Pascal Junod, “On the optimality of linear, differential, and sequential distinguishers”, In Eli Biham, editor, Advances in Cryptology, EUROCRYPT 2003, International Conference on the Theory and Applications of Cryptographic Techniques, Warsaw, Poland, May 4-8, 2003, Proceedings, volume 2656 of Lecture Notes in Computer Science, pages 17-32. Springer, 2003.

[0113] Given a tuple of m scores (score.sub.1, . . . , score.sub.m), we compute the likelihood ratio

[00001]$\mathrm{Ir}=\frac{{\mathrm{Pr}}_{\mathrm{same}}\left[{\mathrm{score}}_1,.Math.,{\mathrm{score}}_m\right]}{\left[{\mathrm{score}}_1,.Math.,{\mathrm{score}}_m\right]}{\mathrm{Pr}}_{\mathrm{diff}}$

[0114] The best sequential distinguisher accepts the hypothesis that the scores comes from same if Ir≥τ.sub.+, for some parameter τ.sub.+. It accepts the hypothesis that the score comes from diff if Ir≤τ.sub.−, for some parameter τ.sub.−. In between, the distinguisher waits for more samples. Using the Wald approximation, if we want to obtain FAR.sub.target and FRR.sub.target, we should use τ.sub.+≈1/FARtarget and τ.sub.−≈FRR.sub.target.

[0115] We make the approximation that the scores are normally distributed, which is well supported by experiment. We let ci be the camera used to compute s.sub.i. Hence, In Ir can be computed by summing all

[00002]$\ln \frac{{\mathrm{Pr}}_{\mathrm{same}}\left[s_i\right]}{{\mathrm{Pr}}_{\mathrm{diff}}\left[s_i\right]}=\Delta {\mathrm{lpdf}}_{c_i}\left(s_i\right)$

[0116] Using the probability density function of the normal distribution, we obtain

[00003]$\Delta {\mathrm{lpdf}}_c\left(s\right)=\frac{{\left(s-{\mu }_c^{\mathrm{diff}}\right)}^2}{2{\left({\sigma }_c^{\mathrm{diff}}\right)}^2}-\frac{{\left(s-{\mu }_c^{\mathrm{same}}\right)}^2}{2{\left({\sigma }_c^{\mathrm{same}}\right)}^2}+\ln \frac{{\sigma }_c^{\mathrm{diff}}}{{\sigma }_c^{\mathrm{same}}}$

[0117] The expected value of In Ir with same distribution is

[00004]$E_{\mathrm{same}}\left(\ln \mathrm{lr}\right)=\underset{i}{.Math.}\left(\frac{{\left({\sigma }_{c_i}^{\mathrm{same}}\right)}^2}{2{\left({\sigma }_{c_i}^{\mathrm{diff}}\right)}^2}+\frac{{\left({\mu }_{c_i}^{\mathrm{same}}-{\mu }_{c_i}^{\mathrm{diff}}\right)}^2}{2{\left({\sigma }_{c_i}^{\mathrm{diff}}\right)}^2}-\frac{1}{2}+\ln \frac{{\sigma }_{c_i}^{\mathrm{diff}}}{{\sigma }_{c_i}^{\mathrm{same}}}\right)+\ln$

[0118] Given that we have m iterations for each camera c, we deduce that the complexity to reach a good decision with same is approximately

[00005]$m_{\mathrm{same}}\approx \frac{\ln {\tau }_{+}}{{.Math.}_c\left(\frac{{\left({\sigma }_c^{\mathrm{same}}\right)}^2}{2{\left({\sigma }_c^{\mathrm{diff}}\right)}^2}+\frac{{\left({\mu }_c^{\mathrm{same}}-{\mu }_c^{\mathrm{diff}}\right)}^2}{2{\left({\sigma }_c^{\mathrm{diff}}\right)}^2}-\frac{1}{2}+\ln \frac{{\sigma }_c^{\mathrm{diff}}}{{\sigma }_c^{\mathrm{same}}}\right)}$

[0119] If we have scores coming from three cameras, we have the following experimental parameters

TABLE-US-00007 same left center right μ 0.141 0.148 0.151 σ 0.037 0.032 0.043

TABLE-US-00008 diff left center right μ 0.112 0.111 0.129 σ 0.020 0.014 0.026

[0120] This method has one limitation though: it assumes a bad distribution coming from taking the biometric features of two random different persons. If an adversary tries another distribution of pictures (like a totally white picture), he may have better chances than what our analysis shows. It is typically a problem when the score is very low. For very low scores, the same distribution becomes more likely than the diff one. We let μ.sub.τ be the lower crossing point on the two probability density functions. We decide to skip score.sub.i whenever (score.sub.i).sub.center<μ.sub.τ. It does not deny access. It only declares this capture unusable. Hence, its effect is to divide m.sub.same by Pr.sub.same[μ>μ.sub.τ]. In our case, μ.sub.t=0.0739 and this increases m.sub.same by only 1.04%.

Security Analysis

[0121] The security model assumes that the adversary has full control on the network and can make participants launch protocols with adversarially chosen inputs. Desktops D, scanner B, the server S, and enrollment desktop E are supposed to be honest. The D < > L link is assumed to be secure and out of the scope of this security analysis. That is, in our security games, the adversary plays with every D, E, B, S with chosen input and sits in the middle of communication between them. He can also require a chosen user to have his finger scanned on a chosen B.

[0122] We assume that PKC is INDCCA-secure, DSS is EFCMA-secure, AEAD is indistinguishable from an ideal primitive against chosen plaintext and ciphertext attacks, and H is collision-resistant. It can be proven that: [0123] (enrollment) if E says that pseudo was successfully enrolled with B, it must be the case that S did so, and if S enrolls pseudo from B, it must be because E asked for it and B followed (however, E may fail before announcing a success); [0124] (AC) if D granted access to pseudo from B, it is certainly the case that its policy in DB.sub.1 validated a sequence of captures from B; [0125] (privacy of templates) the adversary cannot extract information about the biometric templates taken from B, even if E is malicious; [0126] (privacy of pseudo) a semi-passive adversary cannot distinguish the pseudo of a user from a random one (however, an active adversary could simulate D and test a pseudo for a user).

Possible Implementation

[0127] The proposed method can rely on any user authentication framework in a network.

[0128] For PKC, we may use 2048-bits RSA-OAEP and AES-GCM depending on the message length. AES-GCM is implemented with 128-bit key size, 128-bit Mac/Tag size, and 128-bit IV/Nonce. The additional data is either empty, 6 bytes or a hash. For hash, we may use SHA256. For DSS, we may use 2048-bits RSA-PSS.

[0129] Depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (for example, not all described acts or events are necessary for the practice of the methods). Moreover, in certain embodiments, acts or events can be performed concurrently, for instance, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines or computing systems that can function together.

[0130] The various illustrative logical blocks, modules, and algorithm steps described herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.

[0131] The various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, a microprocessor, a state machine, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A hardware processor can include electrical circuitry or digital logic circuitry configured to process computer-executable instructions. In another embodiment, a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

[0132] “Servers”, such as the organization server or the biometric server, can be implemented or performed by a physical machine, a virtual server, a general-purpose computer, multiple servers, cloud based computational resources, or other programmable components or modules providing the services and methods described.

[0133] Unless described otherwise, the links and connections between servers, machines, devices or modules can be provided by any protocol, including USB, Ethernet, Bluetooth, etc.

[0134] The steps of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module stored in one or more memory devices and executed by one or more processors, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable storage medium, media, or physical computer storage. An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The storage medium can be volatile or nonvolatile.

[0135] Conditional language used herein, such as, among others, “can,” “might,” “may,” “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements or states. Thus, such conditional language is not generally intended to imply that features, elements or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements or states are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Further, the term “each,” as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term “each” is applied.