Non-Factory

Standard API pushes biometric applications into the mainstream

Standard application programming interface is expected to ensure biometric application use across various platforms and operating systems.
March 1, 2000
10 min read

Standard application programming interface is expected to ensure biometric application use across various platforms and operating systems.

By Andrew Wilson, Editor at Large

Biometrics technologies use the physiological or behavioral characteristics of an individual for identification or verification. Such technologies include iris scan, retina scan, finger scan, hand geometry, face recognition, and dynamic signature verification. These technologies are currently in use in many different applications including automatic teller machines, PC network security, worker time and attendance recording, customer verification, and data- and security-system access, among others.

"Currently, the biometrics market and, more specifically, the fingerprint identification market consist of a number of vendors of incompatible hardware and software," says Aaron Watson, a software engineer at I/O Software (Riverside, CA). "But, for the biometrics market to grow and reach its true potential, it is necessary to have compatibility among applications and hardware from different vendors."

However, it is neither cost-effective nor efficient for application developers to write new drivers and redesign new software-developer kits for each biometric device they want to support. Conversely, hardware vendors do not want to develop different device drivers for interfacing with different biometric applications running on different operating systems and processors.

Consortium approach

To overcome these compatibility problems, a consortium led by companies such as Unisys (Blue Bell, PA), Intel Corp. (Santa Clara, CA), and Compaq Computer (Houston, TX) was formed in 1998 to develop an application programming interface (API) for various biometric technologies (the BioAPI). By the end of that year, the consortium had developed a multilevel API architecture.

In December 1998, I/O Software joined the consortium, and the company's Biometric API (BAPI) specification was integrated as the lower level of the BioAPI specification. In March 1999, the Information Technology Laboratory of the US National Institute of Standards and Technologies (Gaithersburg, MD) and the US Biometric Consortium (Fort Meade, MD) agreed to merge their Human Authentication Application Programming Interface (HA-API) Working Group with the BioAPI consortium. As part of this agreement, the BioAPI consortium agreed to integrate the HA-API and BAPI API into its BioAPI architecture.

According to BioAPI consortium steering-committee member John Wilson of Intel, implementation of the BioAPI will enable biometric applications to be deployed across a variety of platforms and operating systems. Biometric vendors incorporating BioAPI into their systems will use standard application interfaces; gain modular access to biometric functions, algorithms, and devices; and use standard methods of differentiating biometric data and device types.

Version 1.0 of the BioAPI specification, targeted for release in March 2000, is intended to provide a biometric-authentication model that covers enrollment, verification, and identification. Including a database interface, the specification provides primitives that will allow biometric applications to manage the capture of samples on the client and enrollment, verification, and identification on a server.

Click here to enlarge image

FIGURE 1. Precursors to the BioAPI include both the Human Authentication Application Programming Interface (HA-API; top) and the Biometric API specification (BAPI; bottom). In both methods, compliant applications can call an API subsystem that provides an application programming interface that programmers can use to provide common functionality in their applications. At the lowest level, device management or manager functions provide a standard interface for biometric applications to access device drivers of different biometric devices or modules.

"BioAPI allows different and multiple devices to be plugged into a standard framework to protect the application from differences in biometric technologies," says Wilson. When implemented, individual biometric applications will not have to be rewritten because a "verify" request from the application using the "BioAPI_VerifyMatch" call, for example, will work even when a fingerprint biometrics-service provider from one vendor is replaced by an updated version or one from another vendor.

Building on history

Top-level functions that an application would use to incorporate biometric capabilities are derived from the Biometric Consortium's Version 2.0 of the HA-API standard and I/O Software's BAPI software-developer kit Version 1.1. Both standards define the application programming interface in a modular interface (see Fig. 1). At the top level, the HA-API or BAPI-compliant application is used to call an API subsystem that provides an interface that programmers use to provide common functionality in their applications. At the lowest level, device-management subsystems provide a service-provider interface for biometric applications to access device drivers of different devices (or modules).

In its initial release, BAPI did not provide data (template) compatibility between different biometric devices. This incompatibility meant that a fingerprint, for example, acquired on one BAPI-compliant scanner would not work with hardware or algorithms from another vendor.

Click here to enlarge image

FIGURE 2. Unlike HA-API and BAPI, the BioAPI standard uses the term "template" to refer to the biometric enrollment data for a user. The template must be matched by samples taken from the user to authenticate the user. Knowledge of the template format is handled in the template header. For example, the Format Owner and ID fields might say "Veridicom" and "Version 1.0," respectively, to identify the format type. A biometric identification record (BIR) is then returned to the application that includes raw data, intermediate data, and processed samples ready for verification or identification and enrollment data.With the introduction of the BioAPI, an initial template of a person can be constructed by collecting samples of fingerprints, facial images, and retinal or iris images from biometric sensing devices. Salient features are extracted from the samples, and the results are combined into the template. This initial template then takes the place of a password or pass phrase. Thereafter, whenever the person needs to be authenticated, a biometrics sample is collected and verified against the stored template.

Alternatively, in a process called identification, the collected sample is compared against a number of templates. The templates that best match are identified by the system. According to Wilson, the BioAPI programming model will be abstract enough to cover all forms of authentication.

"For a fingerprint image," explains Lawrence O'Gorman of Veridicom (Santa Clara, CA), "the raw image might be 300 x 300 or 90,000 pixels. But the "salient features" are the relative locations of the ridge minutiae (for example, in a face image, the nose, eyes, mouth, and so forth). In both cases, the features are used for matching, not the raw image, and the feature size is less than 1000 bytes, much less than the raw data."

Templates are derived from feature extraction, which provides the biometric identification record (BIR) used for the verification or identification algorithms. "Although each manufacturer may use different template formats," says O'Gorman, the BioAPI assures that a company-specific template goes to a company-specific matcher: fingerprint template to proper fingerprint matcher and face template to proper face matcher. This knowledge of the template format is handled in the template header (see Fig. 2). "For example," says O'Gorman, "the Format Owner and ID fields might say "Veridicom" and "Version 1.0," respectively, to identify the format type."

Templates and BIRs

At the present time, BIRs are implementation dependent, and neither the intermediate BIRs nor the processed BIRs produced from them are interchangeable among service providers, even of the same type. "It is possible that fingerprint templates can be standardized using some form of minutiae," says Intel's Wilson. BIRs formed from other biometric technologies are not expected to be standardized in the foreseeable future.

Click here to enlarge image

FIGURE 3. The Common Security Services Manager (CSSM) allows applications to access security services through an API or layered security services and tools. Service provider modules include cryptographic service providers that perform operations including encryption and decryption, trust policy library modules that implement authorization policies, certificate library (CL) modules that manipulate digital certificate data, and data storage library (DSL) modules that store objects.

"In lieu of standard templates, BioAPI is still useful," says Veridicom's O'Gorman. "Consider a company updating vendor A's fingerprint matcher to vendor B's. In this case, the BioAPI provides two advantages. Different vendors' products can now interface through a common set of function commands so that the application does not have to be rewritten. And, the application can still use vendor A for its old data and vendor B for its new data—without any changes. This is because BioAPI understands the different data formats and routes vendor A's data to vendor A's matcher and vendor B's data to vendor B's matcher—all without any application code changes," he adds.

Says O'Gorman, "If a customer desires a single biometric modality with a single BIR format, the industry is not there yet. However, fingerprint templates are likely to become the first "universal" formats, enabling the same ubiquitous acceptance for fingerprints as we currently have for band cards in automatic teller machines." Currently, there is an undertaking by organizations such as Veridicom, IBM Corp., US Federal Bureau of Investigation, Sagem-Morpho, and NEC, among others, to produce a standard template for fingerprint minutia under the direction of the American Association of Motor Vehicle Administrators (AAMVA; Arlington, VA).

Security benefits

Data in templates and BIRs are classified as sensitive because they are used to identify people. However, even if a template were to be compromised, there are safeguards in the API that make it difficult to illegally manipulate the data. To protect integrity, the biometrics data must be cryptographically encoded. To do so, biometric algorithms and biometrics data must be cryptographically protected. "Cryptographic protection of the data must include the signing of the data with the biometric service provider's (private) key, and for privacy reasons, it will also include encrypting the data," says Intel's Wilson.

According to Arthur Chang, the AuthenTec (Melbourne, FL) representative to the BioAPI standards committee, the company is committed to the BioAPI as part of its API offering. "Authentec, the developer of the FingerLoc personal identification system, is also a supporter of the Common Data Security Architecture (CDSA) standards, which are a more comprehensive security-oriented biometrics extension module," Chang adds.

Also developed by Intel, the CDSA standard provides an open, cross-platform, software framework consisting of application programming interfaces designed to make computer platforms more secure for applications such as electronic commerce, communications, and digital content (see Fig. 3). By writing to one common API, software developers can add authentication services (such as fingerprint scanners), encryption services, and security process management. Application developers can then focus on a single API for all security services, instead of a potentially conflicting collection of individual API sets from multiple toolkit vendors.

Because of the importance of established standards, the relationship between BioAPI and other identification and authentication standards that incorporate biometrics, such as CDSA, will be considered by the BioAPI consortium. Today, however, the BioAPI may not be ready for immediate use. "We incorporated previous versions (including HA-API), but found it difficult to keep up with the constantly changing specifications and politics of BioAPI," says Ben Dawson, director of vision research at Miros Inc. (Wellesley, MA), the manufacturer of TrueFace face-recognition software. "However, we will use BioAPI when the specification converges," he adds.

Company Information

American Association of Motor Vehicle Administrators
Arlington, VA 22203
(703) 522-4200
Fax: (703) 522-1553
Web: www.aamva.org

AuthenTec
Melbourne, FL 32902
(407) 308-1300
Web: www.authentec.com

Compaq Computer
Houston, TX 77269
(281) 370-0670
Fax: (281) 514-1740Intel Corp.
Santa Clara, CA 95052
Web: www.intel.com

I/O Software
Riverside, CA 92507
(909) 222-7600
Fax: (909) 222-7601
Web: www.iosoftware.com

Miros Inc.
Wellesley, MA 02482
(781) 235-0330
Fax: (781) 235-0720
Web: www.miros.com

NIST
Gaithersburg, MD 20899
(301) 975-6478
Web: www.nist.gov

Unisys
Blue Bell, PA19424
(215) 986-4011
Web: www.unisys.com

US Biometrics Consortium
Fort Meade, MD 20755
E-mail: [email protected]
Web: www.biometrics.org

Veridicom
Santa Clara CA 95051
(408) 588-9400
Fax: (408) 588-9402
Web: www.veridicom.com

Sign up for Vision Systems Design Newsletters

Voice Your Opinion!

To join the conversation, and become an exclusive member of Vision Systems Design, create an account today!