Bio Stds Oct07

Biometric Standards
Tutorial
Catherine J. Tilton
VP, Standards & Emerging Technologies, Daon
Chair, BioAPI Consortium
US HOD to ISO/IEC JTC1 SC37
11955 Freedom Drive, Suite 16000
Reston, VA 20190
703-984-4080
(fax) 703-984-4099
cathy.tilton@daon.com
1
Agenda
• Introduction
• Standards activities
• Data/interchange standards
• API standards
• Security standards
• Smartcard standards
• Other standards
• Adoption & Conformance
29 October 2007 Biometric Summit

© Daon 2
IT Standards
• Standards have become strategic business issues.
• Why do we need IT standards?
– For any given technology, industry standards assure the availability in
the marketplace of multiple sources for comparable products
– They foster wide spread utilization of the technology
– They reduce time-to-market
– They facilitate interchange and /or interoperability
– They reduce risk to integrators and end users
– They reduce vendor “lock-in” effect
– They are a sign of industry maturity

© Daon 3
Who benefits?
• Vendors
• Integrators
• End-Users
• The enterprise
• The industry

© Daon 4
Vendors
• Allows vendors to compete based on features,
performance, and quality
• Provides compatibility across a broad range and
quantity of applications
• Opens new markets to the technology (that were
hesitant to adopt due to lock-in problem)
• Respond to customer demands
• Write once - port many
• Your customer today - mine tomorrow

© Daon 5
Integrators
• Broader choice/selection of technologies
• Ease of integration
• Add flexibility in their applications/systems
• Levels of sophistication/control
• Support for test/evaluation
• Multiple applications/multiple technologies (N:M)
• Lowers risk

© Daon 6
End Users/Customers
• Flexibility to configure system to best fit:
– User population
– Application
– Environment
• No lock-in to a point solution or proprietary technology
(algorithm or hardware)
• Allows for ease of technology refresh/system upgrades
• Common data format facilitates interoperability
• Supports biometric plug-and-play

© Daon 7
The Enterprise
• Context: Roll-out of biometrics across a large scale
organization
– Many seats --> cost/seat
– Diverse population --> need flexibility to accommodate
• Poor candidates
• Physical disabilities
• Religious concerns
– Varied environments Æ geographically dispersed
– Future technology upgrade/migration

© Daon 8
The Industry
• Standards are a sign of industry maturity
• Increases competition
• Lowers cost
• Expands applications
• Grows the biometrics market
path to:
on the
Step

© Daon 9
Benefits (Summary)
Vendors Open competition, new markets, reuse
Integrators Selection, ease of integration
End Users Flexibility, interoperability, lower risk
The Enterprise Technology refresh, diverse environments
The Industry Maturity, competition, ubiquity

© Daon 10
Trade-Offs
• Standards sometimes criticized as being the “lowest
common denominator”
– Some validity to this
– Interoperability is not always free
• Cost: possible loss/degradation of performance, low
level control, etc.
Flexibility Optimization
it is almost always possible to build a “hardwired”, highly customized

implementation that is faster & more efficient than a standard, interoperable one

© Daon 11
Example comparison
Standard Proprietary
- Lowers complexity of the - Product optimization
Advantages
application - Better performance

- Re-use - Lower level control
- Future proofing - More sophistication
- Vendor independence - Can be faster to market (due to
- Upgrade path standards development time)
- Simplifies CM
- Simplified integration
Disadvantages
- May incur additional overhead -Custom interfaces for each

- May not be able to take proprietary product to be interfaced
advantage of vendor unique - Increased cost/complexity
capabilities - Added CM
- Interfaces are generic and - Product changes affect
consensus based, so may not be application
optimized for a particular use - Can result in vendor dependence

© Daon 12
Standards Activities
13
Standards acceleration
Pre 9/11 Post 9/11

• Law enforcement standards • Formal biometric standards
– ANSI/NIST ITL1-xxxx committees formed
– EFTS – INCITS M1: late 2001
– WSQ – ISO/IEC JTC1 SC37:
• Small set of commercial June 2002
standards • Biometrics work in other
– BioAPI 1.1 groups
– CBEFF – ISO/IEC JTC1 SC17 & 27
– ANSI X9.84 – ISO TC68
– ITU-T
– OASIS

© Daon 14
The Transformation
NIST Workshop:
• Industry rejects the notion of a standard
fingerprint minutiae template
• CBEFF project initiated to standardize
“package” instead
ISO/IEC 19794-2 Biometric Data Interchange

Format – Part 2: Finger Minutiae Data
published

© Daon 15
By the numbers
Published
18 20
Final draft
5 9
Draft*
13 19
New
projects/proposals 2 2
As of Oct07 *Includes amendments but not revisions

© Daon 16
Standards Organizations
International
National
Informal
BioAPI
Consortium

© Daon 17
Standards Scene
• ISO – International Organization for Standardization
– JTC1/SC17: Cards & Personal ID
– JTC1/SC37: Biometrics
– JTC1/SC27: IT Security
– TC68: Financial Services
• INCITS – International Committee on Information Technology
Standards
– B10: Cards & Personal ID
– M1: Biometrics
– T4: Security Techniques
• Informal Bodies
– BioAPI Consortium
– JCF

© Daon 18
ICAO ITU-T
International ISO IEC
ILO
TC 68
Banking, ISO/IEC JTC 1
Securities and Information Technology OASIS
Other Financial BioAPI
Services Consortium
VoiceXML
SC 17 Forum
SC 27 SC 37
Cards & IT Security
Personal Biometrics Open Group
Identification Techniques
US National ANSI
INCITS M1
represents the
X9 U.S. in JTC 1
NIST/ITL INCITS SC 37
(US TAG ISO TC 68)
(ANSI/NIST ITL-1-
2007)
X9F B10
Identification CS1 M1
Data &
Information Cards & Related Cyber Security Biometrics
Security Devices
© Daon 19
Standards Terminology/Process (ISO)
TC – Technical Committee (industry)
• SC – Subcommittee (segment)
» WG – Working Group (project)
Progression of Work (International)

– New Work Item (NWI) Proposal (NP)
• Results in approved project
– Working Draft (WD)
– Committee Draft (CD)
– Final Committee Draft (FCD)
– Final Draft International Specification (FDIS)
– International Standard (IS)
– Note: Votes are by National Bodies (countries)

© Daon 20
INCITS M1 Organization
Task
http://www.incits.org/tc_home/m1.htm
M1.2 Technical Interfaces
Groups
M1.3 Data Interchange Formats
M1.4 Biometric Profiles
M1.5 Performance Testing & Reporting
M1.6 Cross Jurisdictional & Societal
Ad Hoc
Groups AHGBISGF AHGEMS AHGSQ AHGBEA

© Daon 21
Interfaces Data Formats Profiles Testing
ANSI INCITS 358- ANSI INCITS 377 ANSI INCITS 383* ANSI INCITS 409.1 M1/03-0398 Biometric/
2002: BioAPI Finger Pattern Fmt* Verif. & Identif. of Biom. Perf. Testing & Smartcard Interoperability
ANSI INCITS 378 Transportation Workers Reporting – Principles
ANSI INCITS 398- M1/05-0676 Evaluation
Finger Minutiae Fmt* & Framework
2005: CBEFF* ANSI INCITS 394 of Multimodal Systems
ANSI INCITS 379 Personal Identif. for ANSI INCITS 409.2
1703D BioAPI Conform- Biom. Perf. Testing & M1/07-0185rev Biometrics
ance Test Methodology Iris Recog. Fmt* Border Management
Reporting – Technology in E-Authentication
1538M Amd to BioAPI ANSI INCITS 381 420 Point-of-Sale Testing Methodologies
for Multimodal Fusion Finger Image Fmt* Biometric Identification
ANSI INCITS 409.3
ANSI INCITS 385 ANSI INCITS 421 Scenario Testing Meth.
442 Biometric Identity
Face Recog. Fmt* DoD Implementations
Assurance Services
ANSI INCITS 396 ANSI INCITS 409.4
ANSI INCITS 422 Comm. Operational Testing Meth.
434 Tenprint Capture Hand Geometry Fmt Biom. Phys. Access Ctrl.
Using BioAPI
ANSI INCITS 395 Pt5 – Biom. Device Perf.
CBEFF Conformance Signature/Sign Fmt Eval for Access Control
Test Methodology 1797D Keystroke Pt6 – Perf. & Interop. Test
Dynamics Data of Biom. Data Formats
439 Fusion Data Pt7 – Testing Meth. for
3D Face Amd Specific Environments
1749D Data Format Pt8 – Interpreting Test

Conformance Meth. Results using Stat. Anal.
Approved standards
1672D Sample Quality * Revision in progress
1821D Speaker Fmt

© Daon 22
JTC1 Subcommittee 37 (SC 37) Biometrics
• Established by JTC 1 in June 2002.
• Responsible for “the standardization of generic
biometric technologies pertaining to human beings to
support interoperability & data interchange”.
• An international formal standards forum able to:
– Coalesce a wide range of interests among IT and
biometric industry and users of biometric-based solutions
for multiple Identification and Verification applications.
– Provide the most efficient approach for the utilization of
biometric experts’ time.
– Establish strong liaison with other ISO/IEC TCs (i.e., TC68)
and JTC 1 SCs (i.e., SC17 and SC27).
http://isotc.iso.org/livelink/livelink/fetch/2000/2122/327993/2262372/customview.html?func=ll&objId=2262372
&objAction=browse&sort=name
© Daon 23
SC37 Structure
WG1 Harmonized Biometric Vocabulary and Definitions Canada
WG2 Biometric Technical Interfaces Korea
WG3 Biometric Data Interchange Formats Germany
WG4 Profiles for Biometric Applications USA
WG5 Biometric Testing and Reporting UK
WG6 Cross Jurisdictional and Societal Aspects Italy
Secretariat and Chair: US / ANSI

© Daon 24
SC37 Participation
P-Members O-Members
• Austria • Indonesia
• Australia • Netherlands
• Denmark • Poland
• Canada • New Zealand
• Hungary • Switzerland
• China • Norway
• Czech Rep. • Portugal
• Finland • Russia
• France • Singapore 15 Liaisons
• Germany • South Africa
• Ireland • Spain
• Israel • Sweden
17 25/6
• Italy • Ukraine
• Japan • UK
• Korea, Rep. • US
• Malaysia

© Daon 25
Vocabulary Interfaces Data Formats Profiles Testing Societal
SD2 Harmonized 19784 BioAPI 19794 Biometric Data 24713 Biometric 19795 Biom. Perf. 24714 TR on Cross
Biometric Vocab. Interchange Formats Profiles Testing & Reporting Jurisdictional &
-1: BioAPI Specification
-1: Framework -1: Reference Arch. -1: Princ. & Framework Societal Aspects of
Biometric Vocab. Amd1: BioGUI Implementations of
Corpus -2: Finger Minutiae -2: Phys Access Ctrl -2: Methodologies for Biometric Tech.
Amd2: Frameworkless for Airport Employees Tech. & Scenario Eval
Amd1: Extraction -1: Guide to Accessib.,
Amd3: Security -3: TR on Modality Privacy, Health & Safety
-3: Finger Spectral -3: Biom. Ident. &
Verif. of Seafarers Specific Testing Issues for Commercial
-2: Archive FPI Pattern
-4: Interoperability Applications
-3: BioAPI Lite -4: Finger Image Performance Testing -2: Practical Application
-4: Sensor FPI -5: Face Image -5: Performance of to specific Contexts
19785 CBEFF Phys. Access. Ctrl Sys.
Amd1: Capture Condit. 24799 Pictograms,
24709 BioAPI -6: Test Methodologies
-1: Data Elem. Spec Amd2: 3D Face Icons, & Symbols
Conformance Test. for Operational Eval.
-2: Registration Auth -1: Methods & Proc. -6: Iris Image
-7: Signature/Sign
-3: Patron Formats -2: Assertions for BSPs Time Series Data
29794 Sample Quality -8: Finger Pattern
-4: Security Blk Fmts -3: Assert. for Frameworks
Skeletal Data*
-1: Framework
-4: Assertions for Apps
24722 TR on Multi- -9: Vascular Image
-4: Finger Image
Modal Fusion 24708 BioAPI -10: Hand Geometry Approved standards
Interworking Protocol -5: Face Image Silhouette
24741 TR on a Final Draft International Standard
Biometrics Tutorial -11 Signature/Sign (or equiv.)
Conf. Test Meth. For Proc. Dynamic Data
Data Interchg Records
-12: Face Feature Data
-13: Voice Data Does not show revision projects

-14: DNA Data
© Daon 26
Standards in a Nutshell
OASIS X9.84 Revision X9.84

OASIS X9F4
X9F4 BioAPI
BioAPI
XML
XML
X9.84 Coordination
DL/ID BioAPI
AAMVA
AAMVA B10
B10 X9.84 BC
BC v1.1
CBEFF
JTC1
JTC1 TC68
TC68 X9.84 M1
M1
SC17
SC17 SC2
SC2 Revision
BIAS
US TAG
JTC1
JTC1 Liaison JTC1
JTC1 OASIS
OASIS
SC27
SC27 Agreements SC37
SC37
ITU-T
ITU-T
Source: J. Stapleton, Innove
© Daon 27
Data/Interchange Standards
28
Common Biometric Exchange Formats Framework
(CBEFF)
• CBEFF describes a set of metadata elements necessary

to support exchange of biometric information in a
common way.
• Features
o Facilitates biometric data interchange between different
systems or components
o Promotes interoperability of biometric-based applications
o Provides forward compatibility for technology improvements
o Simplifies the software and hardware integration process

© Daon 29
CBEFF Evolution
Workshop – Feb 1999
Jan 2001
NISTIR 6529
Apr 2004
NISTIR 6529-A
Feb 2005
ANSI INCITS 398-2005
May 2006
ISO/IEC 19785-1

© Daon 30
CBEFF in a Nutshell
Standard
Biometric • Defines Basic Fields used by Biometric Data
– Useful Biometric Processing Info
Header
– Biometric Data
– Security
• Doesn’t constrain the encoding of data
• Registration of biometric data via IBIA
• Allows for new adaptations
• CBEFF compliance can be met by “Patrons and
Clients” model
Security
Block

© Daon 31
Common Biometric Structure/Elements
HEADER BIOMETRIC DATA BLOCK SIGNATURE

BIOMETRIC(BDB)
DATA BLOCK SECURITY
(SBH)
HEADER (SB)*
BLOCK*
*Optional
Required
Header field Identifies the specific, detailed
format of the succeeding
Format Owner biometric data:
Format Type
- May be standard or proprietary
- Published or unpublished
- Raw, intermediate, or processed
- For enrollment, verification, or
Receiving component (application or technology)
identification
reads Format ID and determines:
- One or more samples
- One or more biometric types
- Ability to interpret/process
- Clear/encrypted, signed/unsigned
- Decision as to where to route the data

© Daon 32
Patron/Client Model
Example Patrons:
CBEFF Patron: An organization that has • BioAPI
defined a standard or specification • ISO 7816-11
incorporating biometric data object
(structure) that meets CBEFF • SC37 (19784-3)
requirements.
Example Clients:
CBEFF Client: An entity that defines a • INCITS M1 (e.g. 378)
specific biometric data record (block) • BioScrypt
(e.g., a BDB format owner) that meets
CBEFF requirements. This would • Iridian
include any vendor, standards • Identix
committee, working group, or industry
consortium that has registered itself CBEFF
with IBIA and has defined one or
more BDB format types.

© Daon 33
CBEFF Patrons & Clients
Patrons specify:
CBEFF
• Encoding of the data elements
Derives • Additional (non-common) data
From elements
• Which optional fields are
present
Patron’s
Formats X9.84
BioAPI Future Format
Biometric Definition
BIR
Object
Places
Data Into
Client’s
Data
Company Format Standard Format Future Format
A’s Owner Body B’s Owner Biometric Owner
Biometric & Biometric & Package &
Data (BDB) Format Type Data (BDB) Format Type (BDB) Format Type
BIR: Biometric Information Record

Identified By
BDB: Biometric Data Block

© Daon 34
Registering Format Owner/Types
• Format Owner values are:
– Unique values which combined with Format Type specify format of
opaque biometric data
• Format Owner Registration (e.g. company, organization, etc.)
• Format Type Registration (e.g. product)
– Obtained from the IBIA (registration authority)
– Available now (nominal fee required)
• Web Enabled registration: http://www.ibia.org/cbeff_new/
• Web access to registered Format Owner and Type assignments.
– Used by CBEFF, BioAPI, CDSA HRS, X9.84, ICAO LDS,
AAMVA/B10.8, 7816, JCF, XCBF, ANSI/NIST
• x9-84 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) tc68(133)

country(16) x9(840) x9Standards(9) x9-84(84) format-owner(4) x
– ibia-owner(1)
• formatOwner (xx)
– formatType (yy)}

© Daon 35
Format Owners
• INCITS M1: 0x001B
• ISO/IEC SC37: 0x0101
• NIST: 0x000F
Also supports proprietary (vendor) owners

© Daon 36
M1 Format Types
Format Type Format Standard
0x0201 Minutiae (basic) INCITS 378
0x0202 Minutiae (with extension) INCITS 378
0x0301 Finger pattern (basic) INCITS 377
0x0302 Finger pattern (extended) INCITS 377
0x0401 Finger image INCITS 381
0x0501 Face image INCITS 385
0x0601 Iris (basic) INCITS 379
0x0602 Iris (with extension) INCITS 379
0x0701 - 6 Signature (various) INCITS 395
0x0801 - 2 Hand Geometry (basic/ext) INCITS 396
© Daon 37
Data elements
CBEFF Nested
Structure Standard Bio Header Type=Multi Bio
– Allows for
multiple data Standard Bio Header Type=Finger
types/objects
within a single
data structure Standard Bio Header Data
Standard Bio Header Data
Standard Bio Header Data Type=Iris
Signature

© Daon 38
Element M/O Description Abstract Value
CBEFF_BDB_format_ M ID of the Group or Vendor which defined Integers 0 through 65,535
owner the BDB
CBEFF_BDB_format_ M ID of the BDB Format Type as specified Integers 0 through 65,535
type by the Format Owner
CBEFF_BDB_encrypt M* Indicates whether BDB is encrypted or NO ENCRYPTION: the BDB is
ion_options not not encrypted
ENCRYPTION: the BDB is
encrypted
CBEFF_BIR_integrity M* Indicates whether the integrity of the BDB NO INTEGRITY: integrity is not
_options is protected or not (i.e., signed/MACd) applied to the BIR.
INTEGRITY: integrity is applied
to the BIR.
CBEFF_subheader_c M-C Specifies the number of sub-header Integers 0 through 255
ount O-S blocks in the next level below (complex
BIRs).
CBEFF_BDB_biometr O Indication of Biometric Type (i.e., Table provided.
ic_type fingerprint, face, etc.). Recent
CBEFF_BDB_biometr O Feature or choice within a biometric type Table provided. Changes
ic_subtype (e.g., left index finger).
CBEFF_BDB_challen O Information used to present a challenge Zero, one, or more octets of
ge_response to a user or system. transparent data.

© Daon 39
CBEFF_BDB_creation O Date/time biometric data was 2000-01-01T00:00:00Z through
_date generated. 3000-12-31T23:59:59Z
CBEFF_BDB_index O Identifier of an object that is related to, Patron specified.
but separate from, the BDB with which
it is associated.
CBEFF_BDB_process O Processed state of the biometric RAW, INTERMEDIATE,
ed_level samples/templates stored in the BDB. PROCESSED
CBEFF_BDB_product O Registered biometric organization that integers 1 through 65,535
_owner owns the product (i.e., the Biometric
Service Provider (BSP) / transforming
application) that created the BDB.
CBEFF_BDB_product O Identifies the product that created the integers 1 through 65,535
_type BDB.
CBEFF_BDB_purpose O Intended use of the BDB. VERIFY, IDENTIFY, ENROLL,
ENROLL FOR VERIFICATION
ONLY, ENROLL FOR
IDENTIFICATION ONLY, AUDIT
CBEFF_BDB_quality O Specifies the quality of the biometric Integer 0-100,
data in the BDB NOT SET, NOT SUPPORTED
CBEFF_BDB_validity_ O Time interval (not before through not 2000-01-01 to 3000-12-31 / 2000-
period after) when the BDB is valid. 01-01 to 3000-12-31

© Daon 40
CBEFF_BIR_creation_date O UTC date and time instant that the BIR 2000-01-01T00:00:00Z through
was created 3000-12-31T23:59:59Z
CBEFF_BIR_creator O Organization that is responsible for the Character string.
application that created the CBEFF BIR.
CBEFF_BIR_index O Analogous to CBEFF_BDB_index, except Patron specified.
that the object's relationship is to the
entire BIR rather than a single BDB
CBEFF_BIR_patron_format O Organization that is the CBEFF patron integers 1 through 65,535
_owner responsible for the patron format of an
embedded SBH.
CBEFF_BIR_patron_format O patron format identifier integers 1 through 65,535
_type
CBEFF_BIR_payload O arbitrary data embedded in the BIR A string of transparent octets
CBEFF_BIR_validity_period O Time interval (not before through not after) 2000-01-01 to 3000-12-31/ 2000-
when the BIR is valid. 01-01 to 3000-12-31
CBEFF_patron_header_ver O version number of the patron format Patron specified.
sion specification to which the BIR conforms.
CBEFF_SB_format_owner O organization (owner) responsible for the integers 1 through 65,535
format of the security block
CBEFF_SB_format_type O security block format identifier integers 1 through 65,535
CBEFF_ version O CBEFF version used in the specification of A major value integer 1-15, and
the CBEFF patron format a minor value integer 0-15

© Daon 41
ISO Version Parts
• 19785-1: Elements • Part 3 Patron Formats:
• 19785-2: Registration – Minimum simple bit-
Authority Procedures oriented
• 19785-3: Patron Formats – Min. simple byte-oriented
• 19785-4: Security Block – Fixed field byte-oriented
Formats (new project) – Fixed field bit-oriented
– TLV
– Complex
– XML
• Note: BioAPI patron format

specified in 19784-1.

© Daon 42
OASIS XCBF
• Organization for the Advancement of Structured Information
Standards (OASIS)
– eXtensible Markup Language (XML)
– XML Common Biometric Format Technical Committee (XCBF) WG
• What is XCBF?
– A Security Standard that defines a common XML markup for two US binary
biometrics standards - X9.84:2002 & BioAPI 1.1
– Instantiation of CBEFF
– Simple Signature, MAC, HMAC & Encryption for XML markup relies on the same
proven, efficient processing used for binary formats in IETF SMIME, RSA PKCS
#7, SET, X9.73 CMS, …
• What does XCBF look like?
– An ASN.1 Schema for XML – markup is encoded in a canonical variant of the
ASN.1 XML Encoding Rules (cXER)
– Common Cryptographic Processing for binary & XML markup
• What is the current status? EF
F
– Version 1.1 published Aug 2003 s t CB
ate
– Used within X9.84-2003 w i th l
gn ed
• For more information: t al i
No
http://www.oasis-open.org/committees/xcbf
http://www.oasis-open.org/specs/index.php#xcbfv1.1
© Daon 43
XCBF Representation
• Based on X9.84 Patron Format of CBEFF (specific
representation, ASN.1, with security features)
• Sample extracts of <biometricHeader>
<version> 0 </version>
CXER encodings: <recordType> <id> 6 </id> </recordType>
<dataType> <processed/> </dataType>
<purpose> <audit/> </purpose>
<quality> 100 </quality>
<validityPeriod>
<notBefore> 1980.10.4 </notBefore>
<notAfter> 2015.10.3.23.59.59 </notAfter>
</validityPeriod>
<format>
<formatOwner>
<oid> 2.23.42.9.10.4.2.0 </oid>
</formatOwner>
<formatType>
<BlindedPrimaryAccountNumber>
A23D552FB4490281C1F6683163D9CCB2
</BlindedPrimaryAccountNumber>
</formatType>
</format>
</biometricHeader>
© Daon 44
M1 Data Interchange Formats
Finger Pattern-Based Approved as ANSI/INCITS 377
Finger Minutiae Approved as ANSI/INCITS 378
Face Recognition Approved as ANSI INCITS 385
Finger Image Approved as ANSI INCITS 381
Iris Image Approved as ANSI INCITS 379
Signature/Sign Approved as ANSI INCITS 395
Hand Geometry Approved as ANSI INCITS 396
Keystroke Dynamics Project 1797D – dropped
Speaker Project 1821D – In progress

© Daon 45
Data Interchange Standards
• Motivation
– Exchange of biometric data in nonproprietary format among
multiple vendors/applications
– Compile biometric databases for use in evaluating multiple
algorithms
– Produce enrollment databases that enable re-enrollment using
future algorithms or algorithm enhancements
• Relationship with other standards
– Data compliant with interchange formats are embedded in
CBEFF Biometric Data Block
– Certain of the formats reference ANSI/NIST-ITL 1-2000
Standard Data Format for the Interchange of Fingerprint, Facial,
& Scar mark & Tattoo (SMT) Information
– Compliance assured with BioAPI (ANSI/INCITS 358-2002 &
ISO/IEC 19784-1)

© Daon 46
Finger Pattern Format INCITS 377 / ISO/IEC 19794-3
• Based on Robust Commercial Algorithm

Implementations
• Small Area/Slide Format Sensors θ
• Data Reduction
λ
– Reduction in Resolution δ
– Cellular Representation
• Pattern broken down into “cells”
• Each cell represented by a cosinusoidal waveform
– Cell group quality
• Data Format Definition

© Daon 47
Record Header Finger Pattern Record Header
Format ID 4B ‘FPR’ 0x00 Finger Location 1B 0-11 (Table)
Version # 4B Impression Type 1B 0-5 (Table)
Record Length 4B # Views 1B 0-255
Product ID 4B Per CBEFF Quality 1B 0-100
# patterns in record 1B 1-255
Length of data block 1B 0-11
Size – X (pixels) 1B 1-255
Finger Pattern Data
Size – Y (pixels) 1B 1-255
View # 1B 0-11
X-resol. (ppcm) 2B 1-788
Y-resol. (ppcm) 2B 1-788 FP cell data 1B 0-11
# cells - X 1B 1 - X size Cell quality data 1B 0-11
# cells - Y 1B 1 - Y size Extended data 1B 0-11
# pixels - X 1B 1 - X size Finger Pattern Data – next view
# pixels - Y 1B 1 - Y size .
X-offset 1B 1 - X size .
Y-offset 1B 1 - Y size .
Bit depth - angle 1B 1-8 Finger Pattern Record Header – next finger
Bit depth - wavelength 1B 1-8
.
Bit depth – phase offset 1B 1-8 .
Bit depth – quality 1B 1-8 .
Cell quality granularity 1B 1-8
Reserved 2B

© Daon 48
Comparison
• INCITS 377-2004 • ISO/IEC 19794-3:2006
– Finger Pattern – Finger Pattern Spectral
– Cosinusoidal only – Adds Fourier & Gabor filter
as optional components (+
associated data & selection
fields)
– Adds core & delta block
– Adds TLV card format

© Daon 49
Finger Minutiae Format INCITS 378 / ISO/IEC 19794-2
• Represents a fingerprint in terms of the ridge

endings and splits – these are called “minutiae”
• Standard contains:
Ridge
– Precise definitions of minutiae endings
Bifurcation
• Minutia location, angle and quality
– Data Format Definition
• Allows >1 finger, >1 view/finger
• Optional extended data area for other features
• Agrees in concept with most law enforcement and AFIS fingerprint
technologies
• Backward-compatible with AAMVA fingerprint format
• Placement is defined carefully for compatibility with ANSI/NIST
standard

© Daon 50
Record Header Per Finger View
Format ID 4B ‘FMR’ 0x00 Extended block length 2B
Version # 4B nnn 0x00 Extended Area (Optional)
Type Code 2B
Record Length 2-6B
Ext. Area Length 2B
Product ID 4B Per CBEFF
Ext. Data Area Var
Equip compliance/ID 2B Vendor specified
Extended data content
Size – X (pixels) 2B
Vendor Specific, or
Size – Y (pixels) 2B Ridge Count Data
X-resol. (ppcm) 2B Extraction Method 1B 0-2
Y-resol. (ppcm) 2B Idx#1 1B 1 - #Min
# finger views 1B 0-255 Idx#2 1B 1 - #Min
Reserved 1B 0x00 Idx#n 1B 1 - #Min
Per Finger View Core/Delta Data
Finger Position 1B 0-11 Core Info Type 2b/2b 0-1
View Number 4b 0-15 # Cores 4b 0-15
Impression Type 4b 0-3,8 X-location 2B
Finger Quality 1B 0-100 Y-location 2B
# Minutiae 1B 1-8 Angle 1B 0-179
Per Minutia Delta Type 2b 0-1
X-location/minutia type 2B # Deltas 6b 0-15
Y-location 2B X-location 2B
Angle 2B 0-179 Y-location 2B
Quality 1B 0-100 Angles 3B 0-179

© Daon 51
MINEX04
• Testing by NIST to quantify performance impact of standardized
minutiae format
– Key to use in PIV
• Results:
– The best proprietary templates are superior to the MIN:A (basic) and
MIN:B (extended) templates in accuracy.
• MIN:A and MIN:B performed similarly.
– As with most tests, error rates between matching algorithms vary by an
order of magnitude.
• 2-finger standard ~ 1-finger proprietary
– Leading vendors in template generation are not always the leaders in
matching (and vice-versa).
– Certification of interoperable product groups requires specification of
the required accuracy.
– Performance is sensitive to the quality of the dataset.
© Daon 52
MTIT (EU Minutiae Template Interoperability Test)
• EU testing of ISO/IEC 19794-2 completed March 2007
9.0%
8.0%
7.0%
6.0%
FNMR at 0.1% FMR
5.0%
Proprietary
PR Native
4.0% PR Interop
RR Native
RR Interop
3.0%
2.0%
1.0%
0.0%
ARCS1 ARCS2 Sagem Motorola Cogent
Database

© Daon 53
Finger Image Format INCITS 381 / ISO/IEC 19794-4
• Generic Image standard for applications requiring:

• Exchange of raw or processed fingerprint images
• Not limited by the amount of resources
• Computer identification and verification functions
• Human comparison of fingerprint image details
• Storing, recording, and transmitting information from one or more fingers or
palm image areas
• Defines the content, format, and units of measurement for the image data
• Consists of a variety of mandatory/optional items
• Scanning resolution (125-1000 ppi)
• Grayscale levels ( 2-256)
• Compressed / uncompressed images
• Certification (EFTS/F)

© Daon 54
Record Header Finger Image (each)
Format ID 4B ‘FIR’ 0x00 Finger Block Length 4B
Version # 4B nnn 0x00
Finger/Palm Position 1B 0-15; 20-36
Record Length 6B
View Count 1B 1-256
Product ID 4B Per CBEFF
Capture Device ID 2B View # 1B 1-256
Vendor specified
Image Acquis. Level 2B Table Finger/Palm Quality 1B
# Fingers/Palms 1B >=1 Impression Type 1B Table
Scale units 1B 1-2 (cm/in) Horiz. Line length 2B pixels

Scan resol - X 2B up to 1000ppi
Vert. Line length 2B # horiz lines
Scan resol - Y 2B up to 1000ppi
Reserved 1B 0x00
Image resol - X 2B <= scan res.
Image data Var
Image resol - Y 2B <= scan res.
Pixel depth 1B 2-65536 levels
Compression Algo. 1B Table
Reserved 1B 0x00

© Daon 55
Facial Format INCITS 385 / ISO/IEC 19794-5
• Developed in coordination with SC37 and ICAO NTWG

• Specifies standard interchange format for intermediate facial image (as
opposed to template)
• Goals
– Interoperability at level of a human readable image
– No larger than necessary to preserve information needed for optimal biometric
match performance
• Content:
– Landmarks: Text info. associated with face, plus pose angle
– Image data (“blob”): Supported image formats,
compression types, data conventions.
• Definitions of (a) full (b) canonical and (c) cropped image
types.
– Image acquisition requirements (e.g. pixel aspect ratio,
depth, image/scanner resolution, color profile, etc.)
– Informative Annexes
• Photography best practices
• Digital attributes
• Image compression (for color and grayscale; JPEG vs. JPEG2K)
© Daon 56
Face Formats
• Basic
– Header + image
– No photographic (lighting/pose) or resolution (size/scale) requirements
apply
• Frontal
– Photographic requirements suitable for 2D face recognition or human
examination
• Full-Frontal
– Specifies size, resolution, and depth requirements
• Token Frontal
– Minimum face size/positioning to minimize storage while allowing
recognition
• 4 types of requirements for each:
– Scene composition, photographic properties, digital properties, storage
format
• Inheritance applies
© Daon 57
© Daon 58
3D face amendment
• IS 19794-5:2005 Face Image Data –

Amendment 2
• INCITS project 1565D (Amd to 385)
• The amendment to the base standard specifies a 3D face

image data interchange format.
• Adds geometric representations – range images, 3D point maps,
3D vertex
• Changes ‘features’ to ‘landmarks’ and adds ‘z’ coordinates

© Daon 59
Iris Image Format INCITS 379 / ISO/IEC 19794-6
• Image capture requirements (informative) Pupil

• Data formats Boundary
– Cartesian (rectilinear) image
• Scan type, expected iris diameter,
r=N
rotation angle + r=0
+
– Polar Image Iris
• Occlusions, boundary extraction, Boundary
transformation type 3
• Compliance 2
M θ=0 1
– Conformity to data format
– Multiple image quality levels (per CBEFF)
• Image capture recommendations
– Iris diameter, resolution, image scale, pixel aspect ratio, contrast, etc.
– To assure consistent performance and interoperability
• Data storage options
– Compression, loss, color, image size, quality level, etc.

© Daon 60
Record Header Iris Image Header
Format ID 4B ‘IIR’ 0x00 Image # 2B
Version # 4B nnn 0x00
Quality 1B
Record Length 4B
Rotation Angle 2B
Capture Device ID 2B
Rotation Uncertainty 2B
# Subtypes 1B 1 or 2
Record Hdr Length 2B 45 Image Length 4B
Image Properties 2B bitfield Iris Image
Iris diameter (pixels) 2B rect. only Image #1 Var
Raw image width (pix) 2B Iris Image Header
Raw image height (pix) 2B .
Intensity depth 1B bits per color .
.
Image Transformation 1B polar only, 0/1
Iris Image
Device Unique ID 16B string
.
Iris subtype header
.
Subtype 1B 0,1,2 .
# Images 1B 1-65535

© Daon 61
Signature/Sign Format INCITS 396 / ISO/IEC 19794-7/11
• Standard Data…from many different digitizers with different

resolutions and drivers:
– Off-The-Shelf Digitizers, Tablet PC, POS Signature Capture Devices,
Pocket PC’s, Palms, Phone Enabled PDA’s etc.
• Content
nc oc k
– Feature Data (Mandatory For Most Applications)
n H a
• Digitizer Data (ID, Resolution, etc.)
• Common Feature Sample Data J oh
• Private Feature Sample Data
– Template Data (If Present)
• Means/SD’s
• Common Feature Template Data
• Private Feature Template Data
– Raw Signature/Sign Data (If Present)
• Number of Bytes in Image
• N samples of (X,Y,T,P) Data
• Typically, template data values consist of Means & Standard
Deviations……So……
– The Template Data Format Is Different From The Feature Data Format

© Daon 62
Hand Geometry Format INCITS 395 / ISO/IEC 19794-10
• Goals
– Vendor independence
– Extensibility
– Small dataset size
• Proposed interchange format
– Hand silhouette (not image)
– Compressed x,y data
• Content
– Data conventions
• Bit/byte ordering, compression
– Acquisition requirements
• Orientation, aspect ratio, presentation
– Data format
• Record header, silhouette data, extended data
– Best practices
• Supports full hand or <5 fingers

© Daon 63
Vascular (Vein) Format ISO/IEC 19794-9
• Progressed at ISO only (FDIS)

• Subcutaneously measured vein patterns
– Based on transparency or reflectance
• Covers palm, back of hand, & fingers
– Though new subtypes also add wrist
• 2D bitmapped data/scan
• Storage formats
– Raw, lossy/lossless compression, multichannel

© Daon 64
Speaker recognition data format INCITS Proj. 1821D
• Collaborative effort between INCITS & VoiceXML Forum

• SIV – Speaker Identification and Verification
• Standardizes at raw audio data level
• XML oriented
• Supports text dependent, text independent, & text
prompted
• Supports “dialogues” or turns within single SIV session
• Content
– Dialogue header (info on channel, sampling rate, etc.)
– Turn header (bandwidth, volume, audio type, prompt, etc.)
– Utterance
r e ss
– (Opt) Extended data (generally vendor specific) pro
g
In

© Daon 65
Practical Benefits
Vendor A Vendor B
Before Enroll Enroll

(Proprietary Capture Capture
Formats) Process Process
Match Match
Now Capture
Enroll Process
(Standard
Formats) Match
Capture Match
Process
Capture Process
Match
© Daon 66
Other Fingerprint Standards
• Data Format for the Interchange of Fingerprint, Facial, & Other
Biometric Information (ANSI/NIST-ITL 1-2007)
– Image: 500 dpi, 8-bit grayscale
– Template: minutiae location (X, Y, theta)
• FBI WSQ standard for fingerprint image compression/decompression
(nominal 15:1)
– IAFIS-IC-0010(V3)
• FBI Electronic Fingerprint Transmission Specification (EFTS), Ver 7.1
– IAFIS-DOC-01078-7 0
– http://www.biometrics.org/REPORTS/FBIfp.html 8.
t
BTS raf
– http://www.fbi.gov/hq/cjisd/iafis/efts71/cover.htm E d
I n
• FBI Appendix F & G (of EFTS)
– Fingerprint image quality specification (IQS)
– Originally written for scanning of inked prints on paper
– Specifies linearity, S/N, modulation, etc.
• AAMVA DL/ID 2000
– Drafted as B10.8, but not published
– Includes finger imaging, minutiae record, facial photo, signature, and compression
© Daon 67
NIST ITL1-2007 Record Types
Logical Record ID Logical Record Contents Type of Data
1 Transaction Information ASCII
2 Descriptive Text (user defined) ASCII
3 Fingerprint Image Record (Low Res Grayscale) binary
4 Fingerprint Image Record (High Res Grayscale) binary
5 Fingerprint Image Record (Low Res Binary) binary
6 Fingerprint Image Record (High Res Binary) binary
7 User Defined Image Record binary

8 Signature Image Record binary
9 Minutiae Data Record ASCII
10 Facial & SMT Image Record ASCII/binary
11-12 Reserved for future use -
13 Latent Image Record (variable res) ASCII/binary
14 Fingerprint Image Record (variable res) ASCII/binary
15 Palmprint Image Record (variable res) ASCII/binary

16 User Defined Testing Image Record (variable res) ASCII/binary
17 Iris Image Record ASCII/binary
99 CBEFF Biometric Data Record ASCII/binary
© Daon 68
ANSI NIST ITL 1-2007 Update
• Published April 2007
• Changes from 2000 version:
– Image quality and segmentation data to support the processing of the
"flat" images
– Definition of a new block of minutiae fields to harmonize with the
INCITS M1 minutiae standard
– Best practice application levels for the capture of facial images
– A new record type for the exchange of iris information (Type 17)
– A new record type to contain biometric information not described in this
standard but conformant to other registered biometric data format
standards (Type 99)
– An XML alternative representation for this standard
• XML version in progress
– Expected by end of year / early 2008

© Daon 69
National Information Exchange Model (NIEM)
• XML data model sponsored by DOJ & DHS
• Latest version 2.0 published June 07
– Subsumed GJXDM
• Broad range of data types
– Biometrics added in v2.0 – ansi-nist namespace
• Hierarchial model
• Supports multiple
domains
www.niem.gov

© Daon 70
Biometric data
• 2 (competing?) structures:
– Law enforcement:
• Electronic Fingerprint Transmission Specification
(EFTS), IAFIS-DOC-01078-7
– Uses ANSI NIST ITL1-2000 record types
– Generic/commercial:
• Common Biometric Exchange Formats Framework
(CBEFF)
– ANSI INCITS 398-2005
– ISO/IEC 19785
– OASIS XCBF

© Daon 71
Interrelationships
HEADER BIOMETRIC DATA BLOCK SECURITY

(SBH) (BDB) (SB)*
EFTS
NIST ITL1-2007 Type 1 Type 2 Type 14 Type 99
HEADER BIOMETRIC DATA BLOCK SECURITY

(SBH) (BDB) (SB)*

© Daon 72
Fingerprint Image Quality
• NISTIR 7151
– “Fingerprint Image Quality”, Aug 2004
• NFIQ image quality metric
– NFIQ’s 5 levels of quality are intended to be predictive of
the relative performance of a minutia based fingerprint
matching system

© Daon 73
Emerging Quality Standards
• INCITS Project 1672D & ISO 29794 (multi-part)
• Attempts to define what “quality” means for a given
modality – how it is measured/interpreted/represented
• 3 components – Character, Fidelity, Utility
U = f(C,F)
SCORE ALGO VENDOR ID* ALGO ID* QSND SCORE
(1B) (2B) (2B) (4b)
*Per IBIA
• Score: Per BioAPI/CBEFF definition (0-100)
• QAID: Quality Algorithm ID
– VendorID, ProductCode, Version major/minor
• QSND: Quality Score Normalized Dataset
– Extends BioAPI’s Excellent, Adequate, Marginal, and
Unacceptable to 8 values (low/high for each)
© Daon 74
ICAO
• International Civil Aviation Organization
– Convention of the UN, est. 1944
• TAG/MRTD– Machine Readable Travel Documents
• New Technologies Working Group (NTWG)
– Reports (ICAO doc 9303)
• Part 1 (passports)
• Part 2 (visas)
• Part 3 (other official travel documents)
– 6th Edition – 2006
• Incorporates preceding supplements
– NTWG supported by SC17 WG3

© Daon 75
ICAO Doc 9303
DOC 9303
Part 1 Part 2 Part 3
Section III - Specifications Common to all MRTDs
Section IV Section IV Section V Section IV Section V

Passport Format A Format B TD1 Card TD2 Card /
(ID-3 size) Visa Visa (ID-1 size) Label
(Size to fit in (ID-2 size) (ID-2 size)
ID-3 Passport)

© Daon 76
ICAO Biometric Blueprint – 4 Pillars
ICAO SELECTED
1
Face Image as the global biometric
ENSURE GLOBAL INTEROPERABILITY
OF IDENTITY CONFIRMATION
ICAO SELECTED
2 Contactless ICC, ISO 14443, >=32K
EXPAND DATA STORAGE
CAPACITY BEYOND OCR-B
ICAO DEVELOPED
3
Logical Data Structure (LDS)
ENSURE GLOBAL INTEROPERABILITY
OF DATA INTERPRETATION
ICAO DEVELOPED
4
Scheme based on PKI principles
PROTECT DATA RECORDED
IN ELECTRONIC DATA TECHNOLOGY

© Daon 77
ICAO Technical Reports
• Biometrics Deployment of Machine Readable Travel Documents,
Ver 2.0, May04
– Annexes D-H comprise the ISO SC37 data interchange formats
related to face, finger, & iris
• Development of a Logical Data Structure (LDS) For Optional

Capacity Expansion Technologies, Ver 1.7, May04
– Biometric elements based on CBEFF
• PKI for Machine Readable Travel Documents Offering ICC Read-

Only Access, Ver 1.1, Oct04
– Supercedes previous Digital Signature TR
• Use of Contactless Integrated Circuits in Machine Readable Travel

Documents, Ver 4.0, May04
– Supplement issued with Biometrics TR (Annex I)

© Daon 78
ICAO LDS

© Daon 79
API Standards
80
API Standards
• Application Program Interface
– Defined way for a software application to communicate (request
services and receive responses) with a technology/service module
– Example: Microsoft Crypto API (CAPI)
– Usually composed of a set of function calls with data/control
parameters and defined data structures
– Generally provided with any SDK
• Biometric APIs
– An API standard defines a common method of interfacing to a particular
technology
– A biometric API standard defines a generic way of interfacing to a
broad range of biometric technologies

© Daon 81
API Standards
Biometric Application Biometric Application
API API
BioAPI Framework
SPI SPI SPI
BSP BSP BSP
Device Device
Device Device 1 N
BSP = Biometric Service Provider Module

© Daon 82
Why is a biometric API standard needed?
• Addresses “lock-in” issue • Benefits:
• Key indicator of industry maturity – Rapid application development
• Required to be competitive with – Easy adoption of new technology
other technologies into existing solutions (exploit
• Allows users across the enterprise price/performance improvements)
to select the biometric that works – Increased competition, which tends
best in their environment, while to lower prices
sharing the same software – Allows:
solutions • Substitution of biometric
• Enables employers to comply with technologies
ADA, by affording an alternate • One application to integrate
biometric for someone unable to multiple biometric technologies
use the primary biometric using the same interface
• Leveraging of a single biometric
technology across multiple
applications

© Daon 83
1996 1997 1998 1999 2000 2001 2002
Evolution
ANSI
BioAPI BioAPI ISO/IEC
HA-API INCITS
1.0 1.1 19784-1
358
• The BioAPI Specification defines an open system

standard application program interface (API) that allows
software applications to communicate with a broad range
of biometric technologies in a common way

© Daon 84
BioAPI
• Combined effort towards single industry standard biometric API
• 100+ member BioAPI Consortium
www.bioapi.org
• Intense effort to develop specification
– Ver 1.0 released 30 March 2000
– Reference implementation beta released Sep 2000
– Ver 1.1 of both released in March 2001
– Linux/Unix/WinCE ports
– Conformance test suites
• Took “best of breed” from other APIs
• Extended HA-API to add:
– Identify and database functions
– Client/server and security support
– Support for application controlled GUI
• Approved as ANSI/INCITS 358-2002 in Feb 02
• Over 40 announced products

© Daon 85
BioAPI Functions
Biometric Operations
Database Operations Unit Operations
Component Management Functions
Data Handle Operations
Callback & Event

Utility Functions
Operations

© Daon 86
Biometric Operations
BASIC FUNCTIONS PRIMITIVE FUNCTIONS
• Enroll User • Capture
– Captures biometric data from sensor
– Enroll
• CreateTemplate
• Creates template (stored in user
account DB and/or BSP DB) – Creates enrollment template
– NewTemplate can be an adaptation of
• Verify asserted identity (1:1) a StoredTemplate
– Verify • Process
• Live input matched against one – Converts “intermediate” to
stored template “processed” BIR for matching
• Discover User’s identity (1:N) • Process with Aux BIR
– Identify • VerifyMatch
• Live input matched against set of – Performs 1:1 match
stored templates • IdentifyMatch
– Performs 1:N match against specified
DB
• Import
– Imports non-real-time data for
processing

© Daon 87
BioAPI Features
• Standardizes functions PLUS • Optional capabilities
– Standard biometric data – Return of raw/audit data
record format (CBEFF) – Return of quality
– Normalizes scoring & – Application-controlled GUI
thresholding – GUI streaming callbacks
• Rich feature set supports: – Detection of source presence
– Client/server implementations – Payload carry
– Model adaptation – BIR signing
– Application control of GUI – BIR encryption
– App or BSP/internal database – Return of FRR
options
– Model adaptation
– Data payloads
– Binning
– Configuration flexibility
through basic and primitive – Self-contained device
operations

© Daon 88
Open Systems
• Platform (OS) independent
– Designed for use in any environment
– Supports cross-platform implementations
– Heterogeneous environments
– Can support Windows, Unix, Linux, Java
• Open system standards provide:
– Broader market for biometric technologies
– Lower risk to integrators & end users
– Adds flexibility
– Expands selections
Windows PC Sun Solaris

Web Browser Web App
BioAPI R/T BioAPI R/T
BSP BSP BSP BSP

© Daon 89
Tools, etc. (v1.1) Adoption (v1.1)
• Win32 framework reference • Customers requiring compliance
implementation – DoD, GSA, FAA, TSA, Treasury,
• Linux/Solaris reference DOS, DHS
implementation – Kaiser, Disney
• WinCE reference implementation • BMO contract awarded 8 April 2002 –
requires compliance to BioAPI (also
• JNI wrapper, C# wrapper X9.84 data packaging)
• PAM interface
• Conformance test suites • Also:
• BioAPI Helper – AAMVA DL/ID standard
• Best practices document (draft) – Draft US Biometric Protection
Profile
• Website – DoD Joint Technical
• Developers listserve Architecture/DISR
– US Biometric Application Profiles
(Transportation Worker/Border
Mgmt)
• Received Larry Linden Security

Award in Apr 2002

© Daon 90
Basic Structure
Application …
R
E API - standard programming interface
G
I
S BioAPI Framework
T
R
…
Y
SPI SPI SPI
BSP BSP BSP
Devices

© Daon 91
Component model
• BSP can be “monolithic” (ala 1.1) or componentized
– Can control units directly or indirectly (through a BFP)
• Function Provider Interface (FPI) can support 4 different
types of BFPs:
– Sensor BFP
– Archive BFP
– Processing Alg. BioAPI BSP
– Matching Alg. FPI
Internal BSP Functions BioAPI Function Providers

© Daon 92
Enroll
Purpose = Enroll for Verification and/or
Enroll for Identification
Enroll (h,purpose,template,…)
GUI
Template
c f
Application
BioAPI Database
Bitmap/
Responses
stream
d BSP
Capture CreateTemplate
raw e

© Daon 93
BioAPI_Enroll
BioAPI_RETURN BioAPI BioAPI_Enroll
(BioAPI_HANDLE BSPHandle,
BioAPI_BIR_PURPOSE Purpose,
BioAPI_BIR_SUBTYPE Subtype,
const BioAPI_BIR_BIOMETRIC_DATA_FORMAT *OutputFormat,
const BioAPI_INPUT_BIR *ReferenceTemplate,
BioAPI_BIR_HANDLE *NewTemplate,
const BioAPI_DATA *Payload,
int32_t Timeout
BioAPI_BIR_HANDLE *AuditData,
BioAPI_UUID *TemplateUUID);
This function captures biometric data from the attached device for the purpose of creating a
ProcessedBIR for the purpose of enrollment.

© Daon 94
BioAPI_ Enroll (cont’d)
Parameters:
BSPHandle (input) - The handle of the attached biometric service provider.
Purpose (input) – A value indicating the desired purpose (BioAPI_PURPOSE_ENROLL,
BioAPI_PURPOSE_ENROLL_FOR_VERIFICATION_ONLY, or
BioAPI_PURPOSE_ENROLL_FOR_IDENTIFICATION_ONLY).
Subtype (input/optional) – Specifies which subtype (e.g., left/right eye) to enroll.
OutputFormat (input/optional) – Specifies which BDB format to use for the returned
NewTemplate, if the BSP supports more than one format.
ReferenceTemplate (input/optional) – Optionally, the BIR to be adapted (updated), or its
key in a BIR database, or its handle.
NewTemplate (output) – a handle to a newly created template that is derived from the new
raw samples and (optionally) the ReferenceTemplate.
Payload (input/optional) – a pointer to data that will be wrapped inside the newly created
template.
Timeout (input) – an integer specifying the timeout value (in milliseconds) for the operation.
If this timeout is reached, the function returns an error, and no results.
TemplateUUID (output/optional) – A pointer to a 16-byte memory block where the BSP-
assigned UUID associated with the ReferenceTemplate (as stored within a BSP-controlled
BIR database) will optionally be returned.
© Daon 95
BioAPI_ Enroll (cont’d)
Return Value
A BioAPI_RETURN value indicating success or specifying a particular error condition. The

value BioAPI_OK indicates success. All other values represent an error condition.
Errors
BioAPIERR_USER_CANCELLED
BioAPIERR_UNABLE_TO_CAPTURE
BioAPIERR_INVALID_BIR_HANDLE
BioAPIERR_TOO_MANY_HANDLES
BioAPIERR_UNABLE_TO_STORE_PAYLOAD
BioAPIERR_TIMEOUT_EXPIRED
BioAPIERR_PURPOSE_NOT_SUPPORTED
BioAPIERR_UNSUPPORTED_FORMAT
BioAPIERR_RECORD_NOT_FOUND
BioAPIERR_QUALITY_ERROR
BioAPIERR_UNIT_IN_USE
See also the BioAPI Error Handling (clause 11)

© Daon 96
Verify
Get template c
Template
Verify (h,template,result….)
GUI
Application
d h Database
BioAPI
Bitmap/
Responses “stored”
stream
e BSP
Capture Process Match Compare “live” v “stored”
“live” f g
Result = probability that user matches template

© Daon 97
BioAPI_Verify
BioAPI_RETURN BioAPI BioAPI_Verify
const BioAPI_FMR *MaxFMRRequested,
const BioAPI_INPUT_BIR *ReferenceTemplate,
BioAPI_BIR_HANDLE *AdaptedBIR,
BioAPI_BOOL *Result,
BioAPI_FMR *FMRAchieved,
BioAPI_DATA *Payload,
Int32_t Timeout,
BioAPI_BIR_HANDLE *AuditData);
This function captures biometric data from the attached device (sensor unit), and compares it against the
Reference Template.
The application shall request a maximum FMR value criterion (threshold) for a successful match. The Boolean
Result indicates whether verification was successful or not, and the FMRAchieved is a FMR value (score)
indicating how closely the BIRs actually matched.

© Daon 98
Identify
c
Get templates Template
Identify (h,templates,results….)
GUI
d h Application
Database
BioAPI
Bitmap/ many “stored”
Responses
stream
e BSP
Capture Process Match Compare “live” v all “stored”
“live” f g
Results = most likely candidates with probabilities

© Daon 99
BioAPI_Identify
BioAPI_RETURN BioAPI BioAPI_Identify
BioAPI_FMR *MaxFMRRequested,
const BioAPI_IDENTIFY_POPULATION *Population,
uint_32 TotalNumberofTemplates,
BioAPI_BOOL Binning,
uint32 MaxNumberOfResults,
uint32 *NumberOfResults,
BioAPI_CANDIDATE_ARRAY **Candidates,
int32_t Timeout,
BioAPI_BIR_HANDLE *AuditData);
This function captures biometric data from the attached device (sensor unit), and compares it against a set of
reference BIRs (the Population).
The population that the match takes place against can be presented in one of two ways: a) in a BIR database
identified by an open database handle, or b) input in an array of BIRs.
The application shall request a maximum FMR value criterion for a successful match.

© Daon 100
BIRs
HEADER BIOMETRIC DATA SECURITY

(standard) (opaque) (optional)
FF
• Biometric Identification Record (BIR) CBE ron
– Record containing biometric data Pat at
or m
– Template: BIR used for Enrollment
F
• Header is subject of joint standardization efforts
– BioAPI Consortium, CBEFF, ANSI X9.F4
• Biometric data is “opaque” to application
– Formats are registered with IBIA (www.ibia.org)
• May be standardized or proprietary
– May contain 1 or more samples in various states of processing

© Daon 101
Scores & Thresholds - FAR, FRR
• Verify gives the probability that a template matches the
user
• Identify indicates the template most likely to match the
user
• FMR is the probability of a False Match (low is “good”)
• FRR is the probability of a False Reject (low is “good”)
• Used as inputs and outputs of matching functions
– MaxFMR: Requested criteria for a successful match.
– FMRAchieved: Nearest/better FMR achieved
– Result: If FAR <= MaxFAR, Result = True
Verify (h, MaxFMR, [MaxFRR, Precedence,]… Result, FMR, [FRR,]…)

Identify (h, MaxFMR, [MaxFRR, Precedence,]… Candidates,… )
FMR for each candidate
© Daon 102
C/S using Primitives - Verification
Application h
Template
C/S Protocol
BIR Database
c f g i
e
Capture (h, verify..) Process Process VerifyMatch
Intermediate Intermediate Intermediate Template Result
GUI or Processed
BIR
or Processed
BIR
BIR +
Processed BIR
j
BioAPI BioAPI
Bitmap/ Responses
stream
BSP BSP
Capture Process Process Match
d optional not optional
Process only needs to be called if Intermediate BIR
Client Server
© Daon 103
BIP – BioAPI Interworking Protocol
• The BioAPI Interworking Protocol (ISO/IEC 24708)
specifies BioAPI framework-to-framework
communications
• BIP enables a BioAPI 2.x application running on a PC to
use a BSP running on a different PC to perform:
– Remote capture
– Remote verification
– Remote identification
– Remote enrollment, etc.
• The BIP messaging protocol is defined by using BioAPI
as a foundation – most BIP request/response messages
correspond to specific BioAPI functions
• BIP allows for multiple transport protocol bindings (e.g.,
SOAP over HTTP)
© Daon 104
BIP Model (basic)
client system
master BIP endpoint
application server system
slave BIP endpoint
local BioAPI framework BIP

remote BioAPI framework
local remote
component component
registry registry
local BSP remote BSP
biometric template
sensor database

© Daon 105
Biometric Databases
DbOpen DbStoreBIR Application-controlled database
DbClose DbGetBIR
DbCreate DbGetNextBIR UUID Password Password
DbDelete DbQueryBIR or
Account
DbSetCursor DbDeleteBIR Template Password
Database
DbFreeCursor
Client Server • BSP-managed database

– Performance
BioAPI BioAPI – Large populations
– Binning/indexing
Capture Process Match
Db Process Match
Db – Multiple databases
Mgr Mgr
BSP BSP
– Population = database
• On-device database
Optional Template UUID – Self-contained devices
Template UUID
• For security, records can be
Template BSP-managed
Database created/deleted not modified
Database
On-device database • Every record gets UUID
(to associate with account record)

© Daon 106
(Framework) Reference Implementation
• BioAPI runtime software • Written in C, Win32
– Middleware framework implementation
between BioAPI compliant • Based on proven CDSA HRS
application and BioAPI code base
compliant BSP • Code portable to other
• Major functions: environments
– Module loading/attaching – No OS specific calls
– Module management – Port library / file system
– Module registry access
– Call passthrough/API-SPI • Open source/public domain
translation • Downloadable from web
• Components
– Framework, MDS • Versions (V1.1): Win32, Linux,
– Password BSP (sample) Solaris, WinCE
– Sample app/exerciser
– Installers
© Daon 107
Technology Modules
• Technology modules instantiate the service provider interface, biometric
algorithms, and device interface (currently monolithic)
• Provide biometric services to applications
– Biometric “engine”
– Biometric service provider (BSP)
• Can be distributed between platforms (i.e., client/server configuration)
• Generally responsible for user interface (GUI), as default
• May encompass one or more technologies
• Typically implemented as a “wrapper” around an existing SDK
• May use proprietary or standard data formats (must be registered)
• May support 1:1, 1:N, or both
• May include an internal or BSP controlled database
• May be instantiated in software or a combination of software & hardware
– May be a self-contained device
– May be a “combo” or “hybrid” device
– May use a dedicated or commodity device

© Daon 108
Technology Modules (BSP)
Application
Module
Registry
Technology
“wrapper”
Module
- Function translation - User interface
- Data translation/packaging - Error handling/timeouts
- Score mapping - Data caching/handle mgmt
SDK
- Biometric operations - Algorithms
- Capture - Device interface/control
- Processing - Countermeasures
- Matching
Device driver
Device

© Daon 109
Differences between v1.1 & 2.0
• Same basic architecture
• 2.0 implements a series of “simplifications and
enhancements”
• Biggest changes:
– Component model
– Attach sessions/Units & Devices
– Registry specification
• Other smaller changes
See website for more details: http://www.bioapi.org/Version_2.0_Description.asp

© Daon 110
BioAPI Related Projects
• US version
– Fusion amendment
– Conformance Test Methodology
• ISO version
– Part 2: Achive Function Provider Interface (FPI)
– Part 3: BioAPI LIte
– Part 4: Sensor FPI
– Amd 2: Security
– Amd 3: Frameworkless
– Conformance Test Methodology (4 parts)
– Java version*
– Tenprint capture using BioAPI* *US projects based on v2.0

© Daon 111
Tenprint Capture Using BioAPI
• “Profiles” the use of BioAPI for tenprint capture
– Based on BioAPI 2.0 (International version)
• Uses ANSI/NIST Type records for input/output BIRs
– “Skeletal” records control capture
– “Filled-in” records provide results
• Control codes & queries (unit properties) defined
• No spec changes required for first phase, but a few
offered/accepted for future
– Subtype field to indicate multiple fingers
– BioAPI_Transform function to initiate image processing
functions (i.e., center/crop, quality check, compress,
segment, etc.)
• Recently approved as INCITS 434
© Daon 112
MS BAPI
• Background
– Microsoft original founder of BioAPI
• Withdrew during merger with HA-API
– I/O Software BioAPI promoter, former steering committee chair, and
chair of the Device working group
• Developer of BAPI
• Committed to provide BAPI as BioAPI lower (device) level
interface
– Announcement on 5/2/00 at CTST in Miami
• MS intends to incorporate BAPI into a future version of the
Windows OS
• Status
– Included in XP Home Edition
– Marked as not for security use

© Daon 113
BAPI Architecture
Application
BAPI - Level 3
(High-Level)
BAPI - Level 2
(Mid-Level)
BAPI - Level 1
(Low-Level) BAPI
BAPI Device Manager (BD Manager) HAL
Common
Services
Biometric Device Module (BDM)
VFilters IFilters VEngines IEngines
Port
Driver
Biometric Device

© Daon 114
BAPI Levels*
Level 3 (High – Abstract)
• Allows developers to rapidly develop prototype applications
• Hides the complexities of multiple biometric technologies
• Technology “blind”
Level 2 (Mid – Technology)

• Allows developers to utilize biometric technology
• Technology specific
Level 3 (Low – Device)

• Technology specific
• Allows developers to utilize device specific
features
• Vendor specific
* Dated material: BAPI specification is unpublished

© Daon 115
Advantages
• BioAPI • BAPI
– ANSI standard, – Better device level
progressing at ISO support (particularly for
– Open system support FP readers)
– Coordinated for – Embedded MS support
compatibility with other – “Free”
related biometric – Can pick up enhanced
standards features of BioAPI since
– Supports data format it is in the public domain
standard
– Available/defined today
– Products shipping

© Daon 116
BIAS
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=bias
• Biometric Identity Assurance Services

• Collaborative project of INCITS and OASIS
– INCITS recently approved as 442; OASIS in progress
• Defines a framework for deploying and invoking
biometrics-based identity assurance capabilities that can
be readily accessed using services-based frameworks
(e.g. web services).
– To remotely invoke biometric operations across an SOA
infrastructure.
Services
Bindings
Biometric
Operations
© Daon 117
BIAS System Context
• BIAS services are modular
and independent operations
which can be assembled in
many different ways to
support a variety of business
processes.
• BIAS services may be

implemented with differing
technologies on multiple
platforms.
• BIAS services can be publicly

exposed directly and/or
utilized indirectly in support of
a service-provider’s own
public services.

© Daon 118
BIAS Services
• Subject • Searching/processing
– Create/delete subject – Verify subject
– Add/remove subject from – Identify subject
gallery – Check quality
• Biographics – Classify biometric data
– Set/list biographic data – Perform fusion
– Update/delete biographic – Transform biometric data
data • Aggregate services
– Retrieve biographic data – Enroll
• Biometrics – Identify
– Set/list biometric data – Verify
– Update/delete biometric – Retrieve information
data
• Asynchronous results retrieval
– Retrieve biometric data
• Query Capabilities

© Daon 119
Security Standards
120
Accredited
ANSI Sub-Committee X9F4 Standards
Committee
• X9 - Financial Services
– X9F - Information & Data Security
• X9F4 - Cryptographic Applications
– X9.84 - Biometric Info. Mgmt. & Security (2003)
• X9.84 Scope
– Security of biometric data across its life cycle
– Management of the biometric data across its life cycle
– Usage of biometric technology for verification and identification banking
customers and employees
– Application of biometric technology for physical and logical access controls
– Encapsulation of biometric data
– Techniques for securely transmitting and storing biometric data
– Security of the physical hardware used throughout the biometric life cycle
• Status
– ISO version: ISO 19092-1 (Security Framework)
– Part 2 on hold: CD 19092-2 (Message Syntax & Crypto)
www.x9.org Jeff Stapleton [jeff.stapleton@innove-us.com]]

© Daon 121
X9.84 Topics
• Framework
• Biometric Components
• Biometric Applications
• Verification
• Identification
• Enrollment
• Biometric Issues
Slides provided by Jeff Stapleton -

© Daon 122
Framework †
Signal
Processing
Data Matching
Collection
Transmission
Storage Decision
† ANSI standard X9.84 Biometric Information Management and Security

© Daon 123
Data Collection
Symbol represents the data collection (or capture)
Data
Collection component which includes the biometric reader
hardware device (sensor) and supporting software.
Inputs: physical world (finger, eye, etc.)
Outputs: biometric data / objects
Signal Processing
Symbol represents the signal processing
Signal
Processing
component, also called feature extraction, which
may be hardware, software, or firmware.
Inputs: biometric data / objects
Outputs: biometric data / objects

© Daon 124
Matching
Symbol represents the matching component which

Matching
may be hardware, software, or firmware.
Outputs: score
Decision
Symbol representing the decision component which

Decision
may be a stand alone process or located within the
Matching or Application components.
Inputs: score (see Matching)
Outputs: yes / no

© Daon 125
Storage
Symbol represents the storage component, which

Storage
includes a centralized data base, local storage on a
work station, and removable media, such as a smart
card.
Outputs: biometric data
Transmission
Symbol represents the transmission component which
Transmission may or may not be present in a biometric systems.
Inputs: protected biometric data / objects
Outputs: protected biometric data / objects

© Daon 126
Framework: Application
Symbol representing an application component.
Application
Application
Symbol represents unprocessed “raw” biometric

data .
Data Symbol represents processed biometric data,

inclusive of sample data, and biometric templates .

© Daon 127
X9.84 Approach
Biometric data should be managed more like a public key ...
– integrity is highest security requirement
– unauthorized disclosure of biometric data should not
compromise the system or the individual
• Biometric data may still be encrypted to protect the system for

reasons of individual privacy issues
* Source: X9.84 Biometric Information Management and Security

© Daon 128
X9.84 Requirements
“Mom and Apple Pie”
1. Mechanisms … to maintain the data integrity of biometric data
and verification results between any two components:
• Cryptographic mechanisms such as a MAC or digital signature,
• physical protection where no transmission is involved and all components
reside within the same tamper resistant unit
2. Mechanisms … to authenticate the source of the biometric data
and verification results, between the sender and receiver
component:
• Cryptographic mechanisms such as a MAC or digital signature
• Using physical protection where no transmission is involved and all
components reside within the same tamper resistant unit
3. If desired, mechanisms … to ensure the confidentiality of the
biometric data during transmission

© Daon 129
Application: Enrollment
Initial capture, entity validation via credentials per risk model
• Bind the identity with the biometric - security
• Optionally perform identification to prevent alias
Data Storage
Collection Signal
Processing
Identification Matching

© Daon 130
X9.84 Requirements
Enrollment
• “Mom and Apple Pie” requirements … +
• Individual enroller requirements
– authentication of individual enroller
– authorization of individual enroller
• Individual enrollee requirements
– authentication of individual enrollee
– authorization of individual enrollee
• Mechanism to bind biometric enrollment to enrollee
• Security level of each component must match that of the
application, including physical
• Integrity of the biometric data must be maintained throughout its
life cycle

© Daon 131
Application: Verification
Match against a template (1:1) based on claimed identity
• Template stored in data base, use knowledge factor (user ID)
• Template stored in possession factor (smart card)
Data Matching Storage

Collection Signal
Processing
Score
adaptation
Application
Application Decision
Yes/No

© Daon 132
X9.84 Requirements
Verification
• “Mom and Apple Pie” requirements… +
• Matching must be performed in a FIPS 140-2, level 3 module1
• Accuracy requirements (addressed separately)
• Enrollment error rates (FTE) consistent with customer service
requirements
1 This requirement is changed in 19092. * Source: X9.84 Biometric Information Management and Security

© Daon 133
Accuracy requirements
• Verification
– False Match shall be no less than PIN
• Error < 10-4 ≈ 1 in 10,000 odds1
– At least as good as current ATM technology
– Recommended: error < 10-5
Recommended error <= 10-5 < mandatory error <= 10-4 ~ PIN-based error
– False Non-Match is a consideration due to denial of

service, but no security requirement defined
• Error < 10-2 ≈ 1 in 100 odds
• Consistent with requirements for convenient operations
1 This requirement is changed in 19092.

© Daon 134
Application: Identification
Match against multiple templates (1-many/few)
• Choose best match from one or more matches
• One such usage is surreptitious surveillance

Collection Signal
Processing
Candidate List
Application
Application Decision
Verified
Identity

© Daon 135
X9.84 Requirements
Identification
• “Mom and Apple” Pie requirements…+
• Accuracy requirements
– Same as Verification…
– Recommends higher accuracy (lower error rates) of biometric
information than for Verification or for Multi-factor
• Typically results in larger templates
• May require more sensitive enrollment devices
• 1:N negative searches during enrollment (detection of
duplicates) require sufficient quality of enrollment

© Daon 136
X9.84 Requirements
Transmission
– “Mom and Apple Pie” cryptography requirements…
Storage
– Central or distributed database
• “Mom and Apple Pie” requirements...+
• Proper access controls over biometric data to prevent
unauthorized access
– Tokens (e.g. smart cards)
• Same as data base, with clarification ...

© Daon 137
X9.84 Requirements
Storage: Tokens – depends on transmission
– A is storage only, all other components are external
– B reader and application is external
– C includes all components and application

Collection Signal
Processing
Score A
C Application
Application Decision B
Yes/No adaptation

© Daon 138
X9.84 Biometric Information Management and Security
X9.84-2001
– Abstract Syntax Notation One (ASN.1) objects
– Object Identifiers: 1,3,133,16,840,9,84,nn…
X9.84-2003
– ASN.1 ⇔ XML (Oasis XCBF)
– Add multiple biometric objects
– Update biometric hardware requirements

© Daon 139
X9.84 Biometric Object
Biometric
Biometric Object is a sequence of Header & Data
Object
Object
Biometric
Biometric
Header
Header
NIST/ITL
CBEFF
Version
Record Type
INCITS 358
Data Type
Purpose
BioAPI
Quality
Validity Period
Format
Biometric Data
No protection of Biometric Data –
string of binary octets

© Daon 140
X9.84 Integrity Object
Integrity
Integrity
Integrity Object is a sequence of
Object
Object Biometric Object & Integrity Block
Biometric
Biometric
Biometric Object is a sequence of Header & Data
Object
Object
Integrity:
• Biometric Header
Biometric
Biometric • Biometric Data
Header
Header
Mechanisms:
Biometric Data • Digital Signature
• MAC
Integrity Block is a choice of one of four X9.73 CMS options:
Integrity
Integrity or or
Signed
Signed Authenticated
or Authenticated
= Signature
Signature MAC
MAC
Block
Block Data
Data Data
Data
Integrity Block contains integrity value (e.g., digital signature) of

Biometric Header & Biometric Data

© Daon 141
X9.84 Privacy Object
Privacy
Privacy
Privacy Object is a sequence of
Object
Object Biometric Header & Privacy Block
Biometric
Biometric
OPTIONAL – cleartext Biometric Header
Header
Header
Privacy Block is a choice of one of four X9.73 CMS options:
Privacy
Privacy or or Established
Established
= Fixed
Fixed Key
Key Named
Named Key
Key
Block
Block Key
Key
Key Name Version

Version
Recipient
Recipient Info
Info
Biometric
Biometric Encrypted
Encrypted Data
Data Encrypted
Encrypted Data
Data Encrypted
Encrypted Info
Info
Object
Object
Biometric
Biometric Header
Header
Ciphertext consists of Biometric Header &
Biometric Data
Biometric Data

© Daon 142
X9.84 Integrity & Privacy Object
Integrity
Integrity Integrity & Privacy Object is a sequence of Biometric
Privacy
Privacy Header, Privacy Block & Integrity Block
Object
Object
Biometric
Biometric
OPTIONAL – cleartext Biometric Header
Header
Header
Integrity:
Privacy
Privacy Biometric
Biometric
Block
Block Object
Object
• Biometric Header
• Biometric Data
Integrity
Integrity Mechanisms:
Block
Block Biometric
Biometric Header
Header • Digital Signature
• MAC
Biometric Data

© Daon 143
X9.84 Assessment
Biometric Validation Control Objectives
• General IT Controls (Britsh Standard 7799, ISO 17799)
– 141 control objectives [Items 1 – 141]
• Key Management Life Cycle Controls (ISO 15782)

• Biometric Information Life Cycle Controls (X9.84)


© Daon 144
Annex E – Attacks & Countermeasures
• E1: Registration of individual • E5: False match –vs- false non-match
using false identity – E5.1: Improper threshold settings
• E2: Fraud susceptibility during – E5.2: Improper device calibration
data collection, “Synthetic Attack” – E5.3: Illicit device or system
• E3: Protection of the data during performance
transmission and storage • E6: Scores and thresholds
– E3.1: Injection of false/replayed – E6.1: Hillclimbing attack
biometric data – E6.2: Update and adaptation
– E3.2: Search for a match • E7: Single –vs- multi-factor
between chosen sample and authentication
templates • E8: Testing
– E3.3: Search for a match • E9: Open –vs- closed systems
between pairs of templates
• E10: Compromise/loss of biometric
• E4: Modification of verification data
results • E11: Data compression
• E.12: System circumvention

© Daon 145
Biometric Architecture/Interrelationships
Application
Biometric
Biometric Object
Validation
Control
X9.84 Biometric Security
Objectives
BIR
BioAPI Framework
CBEFF
Cryptographic Biometric
Service Service
Provider Provider

© Daon 146
Other security standards – in progress
• ISO/IEC 24745, “Biometric Template Protection”, Working
Draft, July 7, 2005
• ISO/IEC 24761, “Authentication Context – Biometrics
(ACBio)”, CD2
• ISO/IEC 19792, “Biometric Security Evaluation”
• ITU-T Study Group 17 Question 8, “Telebiometrics
System Mechanism (TSM)”

© Daon 147
Smart Card Standards
148
ISO 7816-11
• ISO/IEC 7816 consists of the following parts, under the general
title Information technology — Identification cards - Integrated
circuit(s) cards with contacts:
Part 1: Physical characteristics,

Part 2: Dimensions and location of contacts,
Part 3: Electronic signals and transmission protocols,
Part 4: Interindustry commands for interchange
Part 5:Numbering system and registration procedure for application identifier
Part 6: Interindustry data elements
Part 7:Interindustry commands for Structured Card Query Language (SCQL)
Part 8: Security related interindustry commands
Part 9: Additional interindustry commands
Part 10: Electronic signals and answer to reset for synchronous cards
Part 11: Personal verification through biometric methods

© Daon 149
ISO 7816-11 Biometrics and Smart Cards
• ISO/IEC JTC1 /SC17; ISO/IEC CD 7816-11
– Information technology – Identification cards – Integrated circuit(s) cards with
contacts – Part 11: Personal verification through biometric methods
– Part of series which specify characteristics of smart cards
• Goal – CBEFF compatibility
• Attempt to coordinate with other ISO biometric efforts
• Content
– Defines biometric commands/data objects (DO’s)
• Uses TLV data structure
– Defines enrollment and verification process for on-card storage and on-card
matching
– Includes secure messaging mechanism
• Status - Approved

© Daon 150
Biometric information objects – on-card matching
Tag L Value Presence
‘7F60’/ var. Biometric Information Template (BIT)

'7F 61´
Tag L Value
‘80’ 1 Algorithm reference for use in the VERIFY / EXT. AUTHENTICATE / Optional (under A1 / A2 )
MANAGE SE command, see note 3
‘83’ 1 Reference data identifier for use in the VERIFY / EXT. AUTH. / Mandatory
MANAGE SE command (under A1/A2 )
‘06’ ... (OID of NIST/BC WG) To be determined Mandatory
‘A1’ var. Biometric Header Template (BHT) Mandatory
Tag L Value
‘80’ 2 Security and Integrity options (composite structure) (See N/A
Note 1)
‘81’ 2 CBEFF header version N/A
’82’ 2 Patron header version number (default ‘xx01’), where xx is a Mandatory, if absent, the default value applies
patron identifier.
‘83’ 1-3 Biometric type Optional
‘84’ 1 Biometric subtype Optional, used only together with biometric type
‘85’ 1 Record data type N/A
‘86’ 1 Record purpose (verification) N/A
‘87’ 1 Record data quality N/A
‘88’ 7 Creation date and time of biometric reference data Optional
(CCYYMMDDhhmmss)
‘89’ 8 Validity period (from CCYYMMDD, to CCYYMMDD) Optional
‘8A’ 2 Identifier of product (PID) that created the biometric Optional
reference data, value assigned by IBIA, see www.ibia.org
‘8B’ 2 Format owner of the biometric reference data, value Mandatory
assigned by IBIA, see www.ibia.org
‘8C’ 2 Format type of biometric reference data, specified by format Mandatory
owner
‘90’ var. Index, unique identifier for the biometric reference data (see Optional
note 6)
‘91’ / var. Biometric matching algorithm parameters (primitive / Optional
’B1’ constructed), see note 5
© Daon 151
Other smartcard standards
• ISO/IEC 7810
– Identification cards – Physical characteristics
• ISO/IEC 14443 A/B
– Identification cards – Contactless integrated circuit(s) cards
– Proximity cards
• ISO/IEC 15693
– Identification cards – Contactless integrated circuit(s) cards
– Vicinity cards
• In progress / being proposed
– SC17 On-Card matching project

© Daon 152
ISO/IEC 24727
• Identification cards -- Integrated circuit card programming
interfaces -- Part 1: Architecture (approved Jan07)
• Set of programming interfaces for interactions between
integrated circuit cards and external applications (to
include generic services for multi-sector use).
• Specifies:
– system architecture and principles of operation
– a capabilities discovery mechanism
– security rationale
• Does not cover the internal implementation within the card
or the outside world.
• It is independent of the physical interface technology
– Applies to cards accessed by one or more of the following
methods:
• contacts, close coupling and radio frequency.
– The organization/operation of the ICC conform to ISO/IEC
7816-4.
• Multipart standard developed by SC17
© Daon 153
JCF Biometry API
• Goal: Facilitate match-on-card
• Use Javacard for:
– Securely enrolling/managing biometric templates
• Templates stored on card
– Making comparison and granting rights
• No sensitive information sent off card
Credit: K. Krishna, Schlumberger

© Daon 154
The “Big Picture”
PC/Workstation
X9.84 Biometric Object
Application ASN.1 (CBEFF Fmt C)
BioAPI BIR
(CBEFF Fmt B) 7816-11
Biometric
BioAPI DO, TLV
(CBEFF
Fmt D)
BSP
PC/SC
driver
7816-11
Bio Applets Bio Mgr Applet

Biometric Card
JC Biometry API
Sensor Card Reader
Device FP Alg. … Voice Alg. Storage
Matching

© Daon 155
GSC-IS
• NISTIR 6887: Government Smart Card Interoperability
Specification, Ver 2.1
• Goals
– Build upon existing base standards (ISO/IEC 7816)
– Provide a standard, high level smart card services interface for
applications
– Card vendor neutral
– Work with any card reader driver level
– Extensible
• GSC-IS Components
– Virtual Card Edge Interface (CEI)
• Card Capabilities Container (CCC)
• Data Model
– Basic Services Interface (BSI)
– Extended Services Interface (XSI)
Source: T. Schwarzhoff, NIST

© Daon 156
GSC Architectural Model
Transition: ISO/IEC JTC1 SC17, Project 24727

© Daon 157
INCITS M1 Ad Hoc Group
• AHG on Biometric Interoperability in Support of the Government
Smart Card Framework
– Study integration of biometrics and smartcards in context of existing
standards/frameworks
• Defined requirements / identified scenarios of interest
• Evaluated architectural approaches
• Gap analysis
• Recommended extensions to existing standards
• Status:
– Report issued 20 August (M1/03-0398, www.incits.org)
– GSC-IS (NISTIR 6887), ver 2.1 at INCITS B.10 submitted to SC17
– BioAPI 2.0 approved by ISO in 2006
– Report results provided to both as inputs – includes recommendations
for extension

© Daon 158
Requirements for Integrating
• Top-Level Functions
– Authentication to Card
– Off-Card Authentication
• Applications
– Smart Card Centric
• e.g., Biometric used for access control to card
– Biometric Centric
• e.g., Smartcard used for portable/secure storage of biometric
• Scenarios
– Store on Card, Match on Host
– Store on Card, Match in Device
– Store on Card, Match on Card

© Daon 159
PIV
• FIPS-201
– Personal Identity Verification (PIV) of Federal Employees
and Contractors
• Implementation of HSPD-12
• Companion documents
– SP 800-73, Interfaces for Personal Identify Verification
– SP 800-76, Biometric Data Specification for Personal
Identity Verification
– SP 800-78, Cryptographic Algorithms and Key Sizes for
Personal Identity Verification
http://csrc.nist.gov/piv-project/index.html

© Daon 160
SP 800-76
• Biometric “profile” for PIV
– Enrollment:
• NIST ITL1-2000 fingerprint images (tenprint, flat/rolled),
EFTS records, App G sensors
– NFIQ quality metrics
– Background checks
• Facial photo (required): INCITS 385, JPEG 2000
compression (<= 15:1)
– On-card biometrics
• CBEFF structure/patron format
• Fingerprints: 2 INCITS 378 minutiae templates
• Facial photo (optional): INCITS 385, JPEG2000
compression (ROI, <= 24:1)
• Digital signature specified
– Finger image archive: INCITS 381
© Daon 161
PIV Fingerprint Image Flow
Re-acquire
Ten-print
INCITS 378 Generator PIV Card
Fingerprint
(Sec. 3.3) Store (800-73)
Acquisition
(Table 1)
Segmentation PIV Card Re-issuance

[FIPS, 5.3.2.1]
Quality Control INCITS 381 Generator Registration

(Table 2) Fail (Sec. 3.4) Retain Authority or Agency
Pass
ANSI-NIST FBI
Fingerprint Type 4 or Type 14
Transmit
Background Check
Images Generator
(Sec. 3.5)
Pre-PIV Practice

© Daon 162
Other Standards
163
Application Profiles
• Many standards contain “options”
– Leads to interoperability problems
• Within a particular application/domain, these options can be
narrowed
– Further constrain the implementation space
– Identify which options shall always/never be used
– Specify valid values/range of values
– When certain options/values should be used
– Common interpretations of ambiguous requirements
– Any domain specific extensions
• Examples:
M1 TG4 SC37 WG4

• Transportation worker ID • Part 1: Reference Architecture
• Border crossing • Part 2: Airport Employee identification
• Retail/Point of Sale • Part 3: Seafarers
• DoD
• Commercial Physical Access
29 October 2007 Biometric Summit Credit: Mike Hogan, NIST
© Daon 164
• Definitions
– Base Standards - define fundamentals and generalized procedures.
They provide an infrastructure that can be used by a variety of
applications, each of which can make its own selection from the
options offered by them.
– Profiles - define conforming subsets or combinations of base
standards used to provide specific functions. Profiles identify the
use of particular options available in the base standards, and provide
a basis for the development of uniform, internationally recognized,
conformance tests.
• Impact
– Profiles are often overlooked in the rush to market and the rush to
buy.
– Biometric profiles are a crucial level of standardization to ensure
biometric interoperability.
– Biometric profiles specify what base standards apply and what
options and ranges of values in those base standards are necessary
and sufficient to ensure biometric interoperability for a particular set
of application functions.
Definition source: ISO/IEC TR 10000-1:1998
© Daon 165
• Parts • Specify the use of:
– Functional environment for the – Mandatory and optional
application - for example - requirements in base biometric
Border Management: standards to support the
• Pre-arrival functional environment and
• Arrival biometric functions of the
• Stay Management
application profile - for example:
• API - INCITS 358-2002, BioAPI
• Departure
Specification, Version 1.1
• Database
• File Format - Common
Reconciliation/Management
Biometric Exchange File
– Biometric functions for an Format (CBEFF) NISTIR 6529
application: – Mandatory and optional
• Enrollment requirements in other base
• Verification standards to support the
• Identification application profile - for example:
• Watchlist Identification • Compression - JPEG, JPEG
– Standards requirements 2000
• Encryption - AES
© Daon 166
Biometric Reference Architecture – 24713-1 (& SD11)

© Daon 167
Performance Testing Standard – SC37 WG5
• Need • Goals
– Inconsistently reported – Provide uniform,
performance measures are repeatable methods for
difficult or impossible to evaluating & reporting
compare performance of biometric
– Disparate evaluation technologies & systems
techniques thwart efforts to – Provide data needed by
engineer systems with customers and system
predictable performance integrators to design
– Performance claims that systems that meet specific
conflict with user performance requirements
experience diminish – Improve user perception of
confidence in biometric biometric technologies
technologies
Credit: Ron Sutton, Lockheed Martin
© Daon 168
US Standard Structure – INCITS 409
• Part 1 – Principals & Framework
– Definitions, common elements
• Part 2 – Technology Testing
– Specific methodologies, data collection & metric reporting requirements
for technology tests
• Part 3 – Scenario Testing
for scenario tests
• Part 4 – Operational Testing
for operational tests
• New parts – in progress
– Part 5 - Biometric Device Performance Evaluation for Access Control
– Part 6 – Performance and Interoperability Testing of Biometric Data
Interchange Formats (dropped)
– Part 7 – Test Methodologies for Specific Environments
– Part 8 – Interpreting Test Results Using Statistical Analyses

© Daon 169
International Standard Structure
• Part 1 – Test Principles
– Defines test metrics
– Outlines the testing process
– Provides recommendations and requirements on analysis and reporting
• Part 2 – Methodologies for Technology and Scenario Testing
– Provides guidance, recommendations and requirements on methods for
obtaining data to analyse.
• Part 3 – Modality Specific Testing (TR)
– Provides guidance, recommendations and requirements on defining test
protocols (using parts 1 and 2) according to test purpose, application and
biometric modality
• Part 4 – Performance and Interoperability of Data Formats
– Provides methodologies for assessing the cross-vendor performance of data
formats
• Part 5 – Performance of Physical Access Control Systems
– Provides test methodologies for this specific application
• Part 6 – Test Methodologies for Operational Evaluation
– Provides specific methodologies, data collection & metric reporting
requirements for operational tests

© Daon 170
Status
• US • International
– Parts 1-4 published – Part 1 & 2
– Part 5: 5th WD • Published
– Part 6: dropped – Part 3
– Part 7: 3rd WD • DTR
– Part 8: New project
– Part 4
• FDIS
– Part 5
• CD2
– Part 6
• WD

© Daon 171
M1 Ad Hoc Groups
• Biometric Interoperability in Support of the Government
Smart Card Interoperability Specification
– Issued study report August 03
• Evaluating Multi-modal Systems
– Issued report October 05
• Generalized Conformance Testing Methodologies
– Generated new project proposal on this topic
• Biometric Sample Quality
– New group looking at this topic
• Habituation
– Effects of User Habituation and Acclimatization in Biometric
Performance Testing – Discussion paper issued Feb 05
• Biometrics in e-Authentication
– Report published March07
– May spawn new profile standard
© Daon 172
Other SC37 Work
• WG1 – Vocabulary
– Standing document on harmonized vocabulary
– Work in progress
• WG2 – Interfaces
– Multimodal Technical Report
• WG3: Data Interchange Formats
– Part 5: 3D face amendment
– Part 9: Fingerprint skeletal data
– Part 12: Facial feature data
– Part 13: Voice/speaker data
– Part 14: DNA data
– Data format conformance
• WG6: Cross Jurisdictional and Societal Aspects
– Multi-part Technical Report on Cross Jurisdictional and Societal Aspects of
Implementation of Biometric Technology
• Part 1: Guide to the Accessibility, Privacy and Health and Safety Issues in
the deployment of Biometric Systems for Commercial Application
• Part 2: Practical application to specific contexts
– Pictograms, Icons, & Symbols
© Daon 173
Other standards and guidelines
• FIPS 190: Guideline for the Use of Advanced Authentication
Technology Alternatives.
– http://csrc.ncsl.nist.gov/fips/fip190.txt
• Common Criteria
– Biometric Protection Profiles
• Information assurance for biometric products
• Drafts in UK and US
– Biometric Evaluation Methodology (BEM)
• Testing
– Performance Testing Best Practices
• UK Biometrics Working Group
BWG website: http://www.cesg.gov.uk/technology/biometrics

© Daon 174
“Layering” suite of standards
Cross-jurisdictional/societal – 24714
Performance testing – 19795
Application profile – 24713
Software interface – 19784 (BioAPI)
Data packaging – 19785 (CBEFF)
Interchangeable data – 19794 (BDB)

Sample quality - 24794

© Daon 175
Hierarchy and Relationships

© Daon 176
Industry (non-technical) Standards
• IBIA member standards:
– Use of biometrics only for legal, ethical, and non-
discriminatory purposes
– Highest standards of system integrity and database
security to deter identity theft, protect personal privacy, and
ensure equal rights
– Professional courtesy among competitors
– Truth in marketing (including accuracy claims)
– Demonstration that products are safe, accurate, and
effective
– Commitment to principles of free trade
– Privacy principles
http://www.ibia.org

© Daon 177
Adoption
What does “adoption” really mean?
• Willingness of vendors to build products to the spec

– BSPs/SDKs, applications, tools, middleware, devices
• Customer demand
– Reflected in procurements
• References in other standards/documents
• Incorporation into larger architectures
• Visibility/awareness

© Daon 178
Who is adopting?
• ICAO / e-Passports
– ICAO 9303, Machine Readable Travel Documents
• Passports, Visas, Other (cards)
– Logical Data Structure (LDS)
• DG2 (Encoded Face)
• DG3 (Enoded Finger(s))
• DG4 (Encoded Eye(s) (irises))
– Biometrics Deployment Report & LDS
• Call out:
– ISO/IEC 19794-X SC37 biometric data formats
– ISO/IEC 7816-11 (Pers. Verif. thru Biometrics)
– CBEFF

© Daon 179
Who is adopting (cont’d)
• ILO – Seafarer’s ID
– 19794-2 Minutiae format
• International programs
– Border management
– National ID
– Travel
• US programs
– US-VISIT
– Transportation Worker Identification Credential (TWIC)
– Registered Traveler (RT)
– HSPD-12 / PIV / FIPS-201

© Daon 180
The ‘conformance’ issue
• How do you know a product actually conforms to a
standard?
– Test and evaluation?
– To what criteria?
• SC37 standards include “Conformance Clause”
– Identifies minimum set of requirements to claim
conformance
• May also need:
– Conformance standard
• Methodology, assertions
– Conformance test suite

© Daon 181
Harmonized conformance testing
• Path 1: IT Product
Developer self IT Product 1
Developers consumers
declaration of conformity
• Path 2: Second Party 2
2 3 4
Testing
User3
• Path 3: Conformance Testing Lab 3 Validated
4 Products
demonstrated by
Accredited Validation/ Lists/
evaluation in accredited Testing Labs Certification Certificates
Laboratory 4 Bodies 4
laboratory
Accreditation
• Path 4: Conformance Bodies
demonstrated by
evaluation and One standard, one test report, accepted everywhere
validation/certification Source: NIST & BAH

© Daon 182
Program Considerations
• Determine which standards apply to which portions of the system,
particularly with respect to interfaces
– Part of systems engineering process (requirements allocation)
• Trade-offs may be required
– e.g., interoperability –vs– performance (speed, accuracy)
• Quantification requires testing
– for new standards, availability of compliant products*
• *Must be willing to push the envelope
– Vendors sometimes unwilling to implement standards until
forced to
• They’d much rather sell you a proprietary solution that you will be
locked into for years to come
• When customers demand, vendors respond
– Jumpstart may be necessary
• Fund initiatives that will accelerate adoption

© Daon 183
Program Considerations (cont’d)
• Conformance testing
– How do you know when a product actually conforms to a
standard?
• Standards should include conformance clause
• Conformance test methodology standards in progress
• Conformance test suites
• Conformance test programs/certification
• Use of profiles
– Bound the implementation possibilities within a set of standards
• Identify standards, options within standard, exclusions
• Legacy systems
– Decisions required:
• Database conversions?
• Translation layer?
• Grandfather?

© Daon 184
Program Considerations (cont’d)
• Avoid setting up for conflicting standards
– e.g., use of ANSI/NIST ITL1-2000 –vs– ANSI INCITS 381
for fingerprint images
• Use of national –vs– international standards
• Influencing standards in progress
• What if a standard “almost” meets your requirements?
– Sponsor amendment/extension?
– Custom extensions
• Example - MINEX04
• Work with standards bodies on:
– Emerging standards
– Copyright issues
© Daon 185
Examples
• Where does BioAPI apply –
– Enrollment stations, Verification stations
– Matching servers
– Wherever you may need to use >1 technology OR upgrade, replace, or
substitute technology in the future
• Where BioAPI may not be a good fit –
– Within a search/match engine
– Within an embedded microcontroller-based door reader unit
• Applies to applications & BSPs
• Where does CBEFF apply –

– Biometric data encapsulation
– Transmission & storage of biometric data
• Where CBEFF may not be a good fit –
– Interpol checks & other places where EFTS files are currently used
– Within search/match engines

© Daon 186
Program/System Incorporation
• Awareness
– What standards exist, are the engineers familiar
• Requirements
– When require which standard and why
• Analysis
– Tailoring, allocation
– Compatibility/integration with system architecture
• Alternatives
– Product availability, trade-offs
• Modifications
– Legacy subsystems
• Schedule
– Phase in, builds/increments
• System documentation

© Daon 187
Trends
• Development of conformance standards
• Amendments and revisions
• Gap filling
– Missing, more subtle needs, newer technologies &
applications
• Broader participation
• Expanded adoption

© Daon 188
What is needed?
• Broader participation in the standards process
– More countries, more experts
– More contributors, less ‘observers’
• Tools
– Reference implementations
– Conformance test suites
• Interoperability demonstrations/testing
– “plug fests”, data interchange demos -> standards updates
– sponsored testing, conformance programs (qualification)
• Customer demand
– If you want it, you have to demand it
• Feedback on standards needs

© Daon 189
A few things to be aware of
• Revision, amendment, errata, defect reports
• National vs International – adoption/withdrawal decisions

© Daon 190
Conclusion
• Standards activity indicators of widespread interest in
biometrics
• Standards needed to grow the biometrics market,
especially the commercial market
• Standards will:
– Provide flexibility
• As technology evolves
• To accommodate a variety of situations
– Drive biometrics to a commodity
– Make biometrics plug-and-play
– Lower implementation risk

© Daon 191
It can no longer be said:
“The problem with biometrics is …

there aren’t any standards!”

© Daon 192
References
• ISO/IEC JTC1 SC37 - Biometrics, www.jtc1.org (select SC37,or 27, 17)
• International Committee on Information Technology Standards (INCITS) TC
M1 - Biometrics, www.incits.org (select TC M1)
– Buy ANSI or ISO standards: http://webstore.ansi.org/ansidocstore/default.asp
• ANS X9.84-2003 Biometric Information Management and Security
www.x9.org
• ICAO: www.icao.int
• NIST fingerprint standards: http://fingerprint.nist.gov/
• PIV: http://csrc.nist.gov/piv-program/index.html
• OASIS: http://www.oasis-open.org/home/index.php
• International Biometric Industry Association (IBIA) www.ibia.org
• BioAPI Consortium: www.bioapi.org
• Biometric Consortium: www.biometrics.org

© Daon 193
Catherine J. Tilton
Chair, BioAPI Consortium
VP, Standards & Emerging Technologies
Daon
11955 Freedom Drive, Suite 16000
Reston, VA 20190
703-984-4080
Fax: 703-984-4099
cathy.tilton@daon.com
www.daon.com

© Daon 194

Bio Stds Oct07

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Bio Stds Oct07

Загружено:

Авторское право:

Доступные форматы

Biometric Standards

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

Vendors Open competition, new markets, reuse

Integrators Selection, ease of integration

End Users Flexibility, interoperability, lower risk

The Enterprise Technology refresh, diverse environments

The Industry Maturity, competition, ubiquity

29 October 2007 Biometric Summit

it is almost always possible to build a “hardwired”, highly customized

29 October 2007 Biometric Summit

application - Better performance

- May incur additional overhead -Custom interfaces for each

29 October 2007 Biometric Summit

Pre 9/11 Post 9/11

29 October 2007 Biometric Summit

ISO/IEC 19794-2 Biometric Data Interchange

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

Progression of Work (International)

– Note: Votes are by National Bodies (countries)

29 October 2007 Biometric Summit

M1.3 Data Interchange Formats

M1.4 Biometric Profiles

M1.5 Performance Testing & Reporting

M1.6 Cross Jurisdictional & Societal

29 October 2007 Biometric Summit

1749D Data Format Pt8 – Interpreting Test

29 October 2007 Biometric Summit

WG1 Harmonized Biometric Vocabulary and Definitions Canada

WG2 Biometric Technical Interfaces Korea

WG3 Biometric Data Interchange Formats Germany

WG4 Profiles for Biometric Applications USA

WG5 Biometric Testing and Reporting UK

WG6 Cross Jurisdictional and Societal Aspects Italy

Secretariat and Chair: US / ANSI

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

-13: Voice Data Does not show revision projects

OASIS X9.84 Revision X9.84

• CBEFF describes a set of metadata elements necessary

29 October 2007 Biometric Summit

Workshop – Feb 1999

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

HEADER BIOMETRIC DATA BLOCK SIGNATURE

29 October 2007 Biometric Summit

29 October 2007 Biometric Summit

BIR: Biometric Information Record

29 October 2007 Biometric Summit

• x9-84 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) tc68(133)

29 October 2007 Biometric Summit

• ISO/IEC SC37: 0x0101

Also supports proprietary (vendor) owners

29 October 2007 Biometric Summit

Standard Bio Header Data