Overview

Purpose

It covers the basic functions of Enrollment, Verification, and Identification, and includes a database interface to allow a biometric service provider (BSP) to manage the identification population for optimum performance.

It also provides primitives which allow the application to manage the capture of samples on a client, and the Enrollment, Verification, and Identification, on a server.

The HRS is designed for use by both application developers and biometric technology developers. To make the integration of the technology as straight-forward and simple as possible (thus enhancing its commercial viability), the approach taken is to hide or encapsulate to the extent possible the complexities of the biometric technology. This approach also serves to extend the generality of the interface to address a larger set of potential biometric technologies and applications.

This specification is designed to support multiple authentication methods, both singularly and when used in a combined or "layered" manner.

Biometric Technology

Thereafter, whenever the user needs to be authenticated, samples are captured from the device, processed into a usable form, and matched against the template that was enrolled earlier. This form of biometric authentication is called Verification, since it verifies that a user is who they say they are (that is, verifies a particular asserted identity).

Biometric Technology, however, allows a new form of authentication called Identification. In this form, a user does not have to assert an identity. Instead, the biometric service provider compares the processed samples of the user against a specified population of templates, and decides which ones match most closely. Depending on the match probabilities, the user's identity could be concluded to be that corresponding to the template with the closest match.

Possible Implementation Strategies shows some possible implementation strategies. The various steps in the verification and identification operations are shown in the box labeled Biometric Service Provider. The stages identified above the box refer to the primitive functions of the H-level interface.

• Capture

• Process

• Match

BIRs and Templates

The term biometric identification record (BIR) refers to any biometric data that is returned to the application, including raw data, intermediate data, processed sample(s) ready for verification or identification, as well as enrollment data. Typically, the only data stored persistently by the application is the BIR generated for enrollment (that is, the template). The structure of a BIR is shown in Biometric Identification Record (BIR).

Values of Format Owner are assigned and registered by the International Biometric Industry Association (IBIA), which ensures uniqueness of these values. Registered format owners then create one or more FormatIDs (either published or proprietary), corresponding to a defined format for the subsequent opaque biometric data, which may optionally also be registered with the IBIA. Organizations wishing to register as a biometric data format owner can do so for a nominal fee by contacting the IBIA:

The Signature is optional. For standardized BIR formats, the signature will take a standard form (to be determined when the format is standardized). For proprietary BIR formats (all that exists at the present time), the signature can take any form that suits the BSP. For this reason, there is no C-program structure definition of the signature.

The BIR Data Type indicates whether the BIR is signed and/or encrypted.

When a service provider creates a new BIR, it returns a handle to it. Most local operations can be performed without moving the BIR out of the service provider. [BIRs can be quite large, so this is a performance advantage.] However, if the application needs to manage the BIR (either store it in an application database, or send it to a server for verification/identification), it can acquire the BIR using the handle.

Whenever an application needs to provide a BIR as input, it can be done in one of three ways:

• By reference to its handle

• By reference to its key value in an open database managed by the BSP

• By supplying the BIR itself

API Model

• Enroll
  Samples are captured from a device, processed into a usable form from which a template is constructed, and returned to the application.

• Verify
  One or more samples are captured, processed into a usable form, and then matched against an input template. The results of the comparison are returned.

• Identify
  One or more samples are captured, processed into a usable form, and matched against a set of templates. A list is returned showing how close the samples compare against the top candidates in the set.

However, as Possible Implementation Strategies shows, the processing of the biometric data from the capture of raw samples to the matching against a template may be accomplished in many stages, with much CPU-intensive processing. The API has been defined to allow the biometric developer the maximum freedom in the placement of the processing involved, and allows the processing to be shared between the client machine (which has the biometric device attached), and a server machine. It also allows for self-contained devices, in which all the biometric processing can be done. Client/server support by BSPs is optional.

There are several good reasons why processing and matching may take place on a server, including:

• The algorithms will execute in a more secure environment.

• The Client PC may not have sufficient power to run the algorithms well.

• The user database (and the resources that it is protecting) may be on a server.

• Identification over large populations can only reasonably be done on a server.

Two methods are provided to support client/server processing.

1. Using Primitive Functions

   There are four primitive functions in the API which, when used in sequence on client and server, can accomplish the same as the high-level abstractions:

   Capture
   Capture is always execute on the client machine; attempting to execute Capture on a machine without a biometric device will return function not supported. One or more samples are acquired (either for Enrollment, Verification or Identification). The Capture function is allowed to do as much processing on the sample(s) as it sees fit, and may, in fact, for verification or identification complete the construction of the BIR. If processing is incomplete, Capture returns an "intermediate" BIR; indicating that the Process function needs to be called. If processing is complete, Capture returns a "processed" BIR; indicating that the Process function does not need to be called. The application specifies the purpose for which the samples are intended, giving the BSP the opportunity to do special processing. This purpose is recorded in the constructed BIR.

   Process
   The "processing algorithms" must be available on the server, but may also be available on the client. The Process function is intended to provide the processing of samples necessary for the purpose of verification or identification (not enrollment). It always takes an "intermediate" BIR as input, and may complete the processing of the biometric data into "final" form suitable for its intended purpose. On the client, if it completes the processing, it returns a "processed" BIR; otherwise it returns an "intermediate" BIR; indicating that Process needs to be called on the server. On the server, it will always complete processing, and always return a "processed" BIR. The application can always choose to defer processing to the server machine, but may try to save bandwidth (and server horsepower) by calling Process on the client.¹

   Match
   Performs the actual comparison between the "processed" BIR and one template (VerifyMatch), or between the "processed" BIR and a set of templates (IdentifyMatch). The support for IdentifyMatch is optional, but the supported Match functions are always available on the server, and may be available on the client.

   CreateTemplate
   CreateTemplate is provided to perform the processing of samples for the construction of an enrollment template. CreateTemplate always takes an "intermediate" BIR as input, and constructs a template (that is, a "processed" BIR with the recorded purpose of either enroll_verify and/or enroll_identify). Optionally, CreateTemplate can take an old template and create a new template which is the adaptation of the old template using the new biometric samples in the "intermediate" BIR. The BSP may optionally allow the application to provide a "payload" to wrap inside the new template - see Payloads.

   Figure: Client/Server Processing using Primitive Functions

2. Using a Streaming Callback

   The application (on both the client and the server) is responsible for providing a streaming interface for the BSP to use to communicate the samples and return the results. In this case, the application does not need to use the Capture, Process and Match primitives. The Verify, Identify, and Enroll, functions use the streaming interface to split the BSP function between client and server. These functions may be driven from either the client or the server. In either the case, if there are Graphical User Interface (GUI) callbacks set, the client BSP will call them at the appropriate times to allow the client application to control the look and feel of the user interface.

   • The client/server application decides whether the authentication should be driven by the client or the server component. The driving component first sets a Streaming Callbackinterface for the BSP. This not only tells the BSP that it is going to operate in client/server mode, but also provides the interface that it will use to initiate communication with its partner BSP.

   • The application calls the appropriate high-level function, and the BSP calls the Streaming Callback to initiate the BSP-to-BSP protocol. (The protocol is the concern of the BSP implementer, but it will likely start with mutual authentication and key agreement).

   • The Streaming Callback is only used by the driving BSP. Whenever it is in control, and has a message to deliver to its partner BSP, it calls the Streaming Callback interface to send the message, and it receives an answer on return from the callback.

   • The StreamInputOutput function is used by the partner application to deliver messages to the partner BSP, and to obtain a return message to send to the driving BSP. The driving application delivers the return message by returning from the Streaming Callback.

   Note:

   A client BSP that is servicing a self-contained device may ignore the Streaming Callback interface, and perform the requested function locally. A server BSP that is servicing a self-contained device will use the Streaming Callback to request that the client BSP proceeds to perform the requested function.

   Figure: Client/Server Operations Driven from Server
   Figure: Client/Server Operations Driven from Client

FAR and FRR

There are two possible measures for the results of a match:

• False Accept Rate (FAR)

• False Reject Rate (FRR)

FAR is the probability that samples falsely match the presented template, whereas FRR is the probability that the samples are falsely rejected (that is, should match, but do not). Depending on the circumstances, the application may be more interested in one than the other.

The HRS functions allow the application to request a maximum FAR value (that is, a limit on the probability of a false match,) and an optional maximum FRR value. If both are provided, the application must tell the BSP which one should take precedence.

The principal result returned is the actual FAR value achieved by the match. A BSP may optionally return the actual FRR value achieved. For Identify and IdentifyMatch, these results are contained in the Candidate array.

The returning of scores to an application can be a security weakness if appropriate steps are not taken.. This is because a "rogue" application can mount a "hillclimbing" attack by sequentially randomly modifying a sample and retaining only the changes that produce an increase in the returned score. In this way a synthetic image can be created to fool the biometric system. However, allowing only discrete increments of score (FAR) to be returned to the application eliminates this method of attack. The level of quantization required to neutralize this attack is dependent on the type of biometric and the algorithms used.

Payloads

In the Enroll, Process, and Update functions, the application may present a "payload" to be carried in the opaque data of the BIR that is being constructed. This payload is essentially wrapped inside the biometric data by the BSP. It is released to the application on successful verification of the template. The BSP may have a policy of only releasing the "payload" if the Actual FAR achieved is below a certain threshold (this threshold being recorded in the BSP's registry entry).

The "payload" can be any data that is useful to the application; it does not have to be cryptographic; and even in a cryptographic application it could be either a key label or a wrapped key.

BIR Databases

The HRS allows a BSP to manage a database of BIRs for two reasons:

• To optimize the performance of the Identification operation over large populations

• To provide access to the BIRs that may be stored on a self-contained sensing device

It is the responsibility of the application to make any necessary association between the BSP's database(s) and the user database(s). To assist in this, each entry in a BSP database has a GUID associated with it. For security reasons, entries in a BSP database cannot be modified; only created and deleted. New entries get new GUIDs.

Not all service providers support identification, and not all those need to support a database interface. If the identification population is sufficiently small, it can be handled by passing an array of BIRs across the interface.

Databases can be created by name, and a service provider may have a default database. If a service provider supports a device that can store BIRs, then that device should be the default database. The default database is always open when the BSP is attached, and the handle to the open default database is always -1.

User Interface Considerations

Most biometric service providers come with a built-in user interface, and this may often be sufficient for most purposes. The API, however, allows the application to control the "look-and-feel" of this user interface, by allowing the application to provide callbacks for the service provider to use to present and gather samples.

One of the callbacks is used to present and gather samples and to indicate state changes to the application. All service providers must support this callback, though the state machines may vary considerably. The other GUI callback is used to present streaming data to the user, in the form of a series of bitmaps. This callback is optional, and the service provider indicates in its registry entry whether one is required. This entry also indicates whether the user must validate samples, and whether samples are verified.

The service provider is in control of the user interface state machine, and calls the state callback whenever there is a state change event. These state changes may be the completion of a sample, progress on a sample, or the need to present the user with a message. On return, the application can present the service provider with a response from the user; cancel, continue, valid sample, invalid sample, etc.

If the service provider needs to present a sample stream to the user, it calls the streaming callback in parallel to the state change events. This callback will require multi-threading in both the service provider and the application.

Footnotes

1.

"Processed" BIRs are always smaller than "intermediate" BIRs; by how much is technology dependent, and also dependent on how much processing has already been done by Capture.