Certification of

Aadhaar Authentication Devices

Centre for Development of Advanced Computing

Telephone (Head Quarters, Pune): +91-20-25704100 Fax: +91-20-25694004
Telephone (Mumbai Center): +91-22 26201606, Fax: +91-22-26232195
Website: www.cdac.in, www.cdacmumbai.in

Date: 16th July 2012, v0.9 Page 1 of 27

Table of Contents
1. Executive Summary ............................................................................................................. 3
2. Acronyms and Terms .......................................................................................................... 4
3. Introduction ............................................................................................................................ 5
3.1. SCOPE ................................................................................................................................................................. 5
3.2. PURPOSE ................................................................................................................................................................. 5
3.3. OBJECTIVES ................................................................................................................................................................ 5
4. Biometric Products Solicitation for Certification.................................................... 6
5. Protecting the Privacy of the Volunteer Test Population .................................... 6
6. Field FRR Testing Methodology ..................................................................................... 7
6.1. TEST ENVIRONMENT................................................................................................................................................ 7
6.1.1. Human Test Population............................................................................................................................................. 7
6.1.2. Gatekeeper Client ......................................................................................................................................................... 8
6.1.3. Authentication Station Setup .................................................................................................................................. 9
6.1.4. AUA/ASA Aggregator Network (C-DAC as AUA/ASA)...............................................................................10
6.1.5. UIDAI's Authentication Server .............................................................................................................................10
6.2. FIELD TESTING STEPS............................................................................................................................................ 11
6.3. DATA LOGGING @ AUA/ASA.............................................................................................................................. 12
6.4. EXPECTED DATA ANALYSIS .................................................................................................................................. 13
7. Key Roles and Responsibilities .................................................................................... 14
7.1. STQC ............................................................................................................................................................... 14
7.2. C-DAC ............................................................................................................................................................... 14
7.2.1. Biometrics Team ........................................................................................................................................................14
7.2.2. AUA/ASA Team ...........................................................................................................................................................14
7.3. UIDAI ............................................................................................................................................................... 14
7.4. DEVICE SUPPLIERS ................................................................................................................................................. 15
8. High-level Milestones and Timeline (tentative) ................................................... 15
9. References ............................................................................................................................ 16
10. Annexures ............................................................................................................................. 17
ANNEXURE A. AUTHENTICATION REQUEST AND RESPONSE DATA FORMATS*................................................. 17
ANNEXURE B. HUMAN FACTORS & USABILITY INTERACTION ON FINGERPRINT QUALITY ............................. 19
ANNEXURE C. TWO FINGER AUTHENTICATION PROCESS ..................................................................................... 20
ANNEXURE D. TERMS AND CONDITIONS FOR SUPPLIERS ...................................................................................... 21
ANNEXURE E. FRR CALCULATION: PROCESS FLOW .............................................................................................. 22
ANNEXURE F. GUIDELINES FOR FTA (FAILURE TO ACQUIRE) INDICATORS ...................................................... 24
ANNEXURE G. AADHAAR NUMBERS BY SUPPLIERS FOR TESTING PURPOSE ...................................................... 25
ANNEXURE H. RESIDENT MOVEMENT: PROCESS FLOW ........................................................................................ 26
ANNEXURE I. FRR MOCK REPORT ........................................................................................................................... 27

Date: 16th July 2012, v0.9 Page 2 of 27

1. Executive Summary
Aadhaar authentication is an online, cost effective, secure and portable authentication Table of Content
service. The Aadhaar authentication service delivery agencies should essentially be given
confidence about the biometric authentication products that they are reliable and meet the
technical specifications of UIDAI.

As part of the authentication biometric devices testing and certification procedure, all
devices (sensor-extractor-supplier combination) need to prove acceptable FRR under field
conditions. Such tests are to be carried out under STQC supervision, and in the test setup
created by STQC. The STQC has partnered with C-DAC to carry out this test. This document
details the testing procedure and methodology to be adopted for carrying out this test.

The STQC will take measures to ensure that all interested suppliers will have fair and equal
opportunity to participate in the test. All products will be tested on a live authentication
setup using the same human test population (having Aadhaar numbers) over a period of
two-three weeks. The tests will only include genuine comparisons to determine False Reject
Rates (FRRs) for each native product. Final certification by STQC would be subject to
"sensor-extractor-supplier" meeting the performance objectives stated in the published
STQC's biometric device specification document [STQC, UIDAI Biometric Device
Specifications, 2012].

Date: 16th July 2012, v0.9 Page 3 of 27

2. Acronyms and Terms

Sr.No. Abbreviation Table of Content

1. ASA Authentication Service Agency

2. AUA Authentication User Agency
3. C-DAC Centre for Development of Advanced Computing
4. CIDR Central Identities Data Repository
5. DET Detection Error Tradeoff
6. FAP Fingerprint Acquisition Profile
7. FAR False Accept Rate
8. FRR False Reject Rate
9. GNDC Greater Noida Data Center
10. HMAC Hash-based Message Authentication Code
Mahatma Gandhi National Rural Employment
11. MGNREGA
Guarantee Act
12. OTP One Time Password/PIN
13. PDS Public Distribution System
14. PID Personal Identity Data
Personal Identity Information (or Personally
15. PII
Identifiable Information)
16. PKI Public Key Infrastructure
17. PoC Proof of Concept
18. NFIQ NIST Fingerprint Image Quality
19. ROC Receiver Operating Characteristics
Standardization Testing and Quality Certification
20. STQC
Directorate
21. SSL Secure Socket layer
22. UIDAI Unique Identification Authority of India
23. VPN Virtual Private Network

Date: 16th July 2012, v0.9 Page 4 of 27

3. Introduction
In large scale Biometric application like UIDAI, the choice of the acquisition devices is one of Table of Content
the most critical issues, since many, often conflicting, requirements have to be taken into
account. To determine that a Biometric Device (sensor-extractor-supplier combination) is
capable to meet the goal of UIDAI, in context of its performance in a “given specific
operational environment” requires an understanding of the evaluation methodologies and
statistics used by the biometrics community.

This procedure provides a baseline testing methodology for operational evaluation of

biometric authentication devices to be used for UIDAI applications. This is done through
data collection, data processing, analysis of the matching scores and decisions output by the
system, without detailed knowledge of the system’s algorithms or of the underlying
distribution of biometric characteristics in the population of interest. This document
includes generic test plan, requirements for participating suppliers, integration of hardware
and software into STQC/UIDAI/C-DAC test platform, training and guidance.

3.1. Scope
This document defines Procedure for performance testing of UIDAI biometric system in
terms of false reject rate (FRR) for the purpose of ensuring conformance to UIDAI
requirements, Specifies test method including recording data and results reporting.
The scope covers single finger print authentication device with different
sensor/extractor combination.

3.2. Purpose
The purpose of this test is to find out FRR in operation environment.

3.3. Objectives
The primary objectives of this procedure are to describe test method to:
» standardize the test method incorporating best practices to ensure reliability
and reproduction of test result with subjects of different demographic profile.
» verify compliance with specified performance requirements.
» avoid systematic bias due to incorrect data collection and analysis during
evaluation.
» help test engineer analyst to achieve the best possible estimate of field
performance based on their evaluation.
» understand the limits of applicability of test result and test method.

The secondary objectives of this procedure are to:

» to provide evaluation feedback to participating suppliers/vendors enabling
them to design setup for optimal performance.
» predict performance of different suppliers/vendors.

Date: 16th July 2012, v0.9 Page 5 of 27

4. Biometric Products Solicitation for Certification
Participation in the biometric testing and certification is open to all biometric suppliers. An Table of Content
open solicitation for biometric products compliant with Aadhaar authentication
specifications is announced by STQC to include as many biometric products as possible. The
schedule for the testing will periodically be posted on the STQC’s website.

Through this document, the suppliers interested in participating in the certification are
apprised of the detailed implementation of the test plan in advance of the test. Participating
suppliers should remain ready with their fingerprint capturing devices and software
module(s) for inclusion in the biometric testing. The hardware and software to be used by
the respective suppliers are evaluated as a single combined biometric product for the
purpose of the test.

5. Protecting the Privacy of the Volunteer Test Population

Great lengths are taken to protect the personal information of the volunteer residents, and it
is as per the published UIDAI's Security Policy and Framework.

This test requires residents' biometrics to be captured, packaged and transmitted to UIDAI's
authentication server. It is very important that the data captured at the front end devices
and applications be secured before transmitting over the network. End to end encryption of
personal identity data (PID block) is necessary to ensure that data are not read, stored, or
tampered with for malicious purposes. Following are the security measures for securing the
resident data:
Encryption of resident data (PID block) at the time of capture using 2048 bit PKI.
HMAC (Hmac tag) of PID block to eliminate tampering:
Hash-based Message Authentication Code (HMAC) is a specific construction for
calculating a message authentication code (MAC) involving a cryptographic hash
function in combination with a secret key. As with any MAC, it is useful to
simultaneously verify both the data integrity and the authenticity of a message.
AUA license key to enable/disable specific features.
Digitally signed AUA packet for tamper proofing and authenticity.
No logging/storing of any PID block at device level, PID block is directly encrypted from
the memory. Also, PID block is never logged/stored at AUA/ASA level.
Secure channel is used for transmitting data from device to AUA, AUA to ASA, and then
ASA to UIDAI's GNDC.
Network filter is used (white listed IPs, Certificates).
Audits are maintained for every authentication transaction.
Response is digitally signed for self-verification.
Network protection and "virus/malware checks" schemes are used to ensure no rouge
device or data can disrupt the service.

Date: 16th July 2012, v0.9 Page 6 of 27

6. Field FRR Testing Methodology
This section describes the components of the Aadhaar authentication setup and Table of Content
methodologies for conducting the field FRR testing and certification of the biometric
authentication products: Sensor–Extractor–Supplier Combination.

The high level components are as follows:

1. Authentication Frontend
2. AUA/ASA Network (C-DAC as AUA and ASA)
3. Authentication backend at UIDAI's GNDC

Test will be conducted in a real environment with a limited but actual human test
population.

6.1. Test Environment

The test environment will consist of the following:

Human Test Population
Gatekeeper Client (station set up and managed by UIDAI/CDAC/STQC)
Authentication Station Setup (set up and managed by respective device suppliers)
AUA/ASA Aggregator Network (C-DAC as AUA/ASA)
UIDAI's GNDC Authentication Server

6.1.1. Human Test Population

The field test for certification of authentication devices (sensor-extractor-
supplier combination) would be carried out on volunteer residents using single
fingerprint devices. All products would be tested using the same human test
population over a period of two weeks.

Table below presents an expected age-gender distribution* of test population:

The expected test population size#:

Maximum: 5000
Minimum : 3500

Total
Age Group
(including Male & Female)
5-15 10%
16-45 63%
46-65 24%
66-75 02%
Above 75 01%

# The distribution of test population may vary, but in all situation, all products
would be tested over the common human test population.
* Please refer to Annexure B for reference on a study by NIST.

Date: 16th July 2012, v0.9 Page 7 of 27

 Figure 1: Aadhaar Authentication Setup for Device Certification.

6.1.2. Gatekeeper Client

To identify and reconcile the Aadhaar holders participating in the field test, C-
DAC will deploy a Gatekeeper client. Before a resident is directed to an
authentication station set up (described in section 6.1.3), the resident would be
required to provide his/her details to the Gatekeeper client.

The Gatekeeper client may also help identify fingers that have higher probability
of successful authentication. Although it is recommended that the fingers

Date: 16th July 2012, v0.9 Page 8 of 27

 identified by the Gatekeeper client be used for the authentication purpose by
various device suppliers, the suppliers are free to consider authenticating with
other fingers as deemed fit.

6.1.3. Authentication Station Setup

The Authentication frontend components (in compliance with UIDAI standards
and guidelines) will be designed and implemented by the suppliers. The XML
input data that suppliers have to send to the AUA server should be as per the
specification mentioned in Annexure A of this document. The suppliers would
need to deploy their manpower to execute the field test for their respective
devices.

There will be 8 to 10 authentication stations (desks/halls), where each station

will have multiple terminals. Each terminal may house one or more
authentication devices/sensors. In all cases, each station will have every sensor-
extractor-supplier combination requiring FRR testing for certification purposes.

In order to provide a fair environment to all the participating products, the

device sequence/placement in different halls would be different, so that no
product suffers from unhabituated behavior of the test population.

The authentication station would consist of the following:

Multiple terminals. Each terminal may house the following:
» One or more authentication devices, where each device is a single
fingerprint sensor.
» Fingerprint extractor – the software that extracts fingerprint minutiae
(in compliance to ISO 19794-2:2005) from the captured image. The
extractor software version should be same as what is being submitted
for the certification purpose.
» The application software, in compliance with the UIDAI's policies and
specifications, to communicate and transact the data with AUA/ASA
server. The xml packet being formed by the application software should
be as per the specification mentioned in Annexure A of this document.
» Barcode reader to capture and input resident's Aadhaar number.
» A data card. However, the suppliers are advised to keep with themselves
multiple data cards (of different makes) to ensure the flawless Internet
connectivity. The UIDAI-CDAC-STQC will not be responsible for any
flaw/loss in Internet connectivity.

It is the sole responsibility of the suppliers to bring all the needed hardware,
software and manpower to ensure smooth functioning of devices deployed by
them.

The Aadhaar number and biometric information (such as the fingerprint

minutiae) are all packaged into an Authentication packet [UIDAI, Authentication
API v1.6, 2012] along with the header information and sent to the UIDAI's GNDC
for authentication through the C-DAC's AUA/ASA network. AUA's public URL is:
https://vikrant.cdacbangalore.in/authrequest/process/post

Date: 16th July 2012, v0.9 Page 9 of 27

 6.1.4. AUA/ASA Aggregator Network (C-DAC as AUA/ASA)
C-DAC would be an aggregator and a network partner to STQC for the purpose of
field FRR testing required as part of certification procedure. C-DAC will act as
both AUA and ASA.

The AUA will perform the following validations:

1) XML data validation
2) udc validation: udc validation against the assigned value, as udc attribute
value will be assigned by C-DAC AUA.

The error codes that may be returned by the AUA/ASA server are tabulated
below:

Error Codes
(defined at the C-DAC AUA/ASA for the suppliers)

Sr.No. Error Code Description

1. 1201 CIDR connection timed out

2. 1202 Invalid udc
3. 1203 Invalid Auth. XML

If any errors are encountered at UIDAI’s authentication server in the

authentication request, the error codes would be as defined in the UIDAI’s
API document [UIDAI, Authentication API v1.6, 2012].

6.1.5. UIDAI's Authentication Server

Currently UIDAI is having two data centers (CIDR at Bangalore and GNDC at
Greater Noida) from where authentication infrastructure is running.

C-DAC as AUA/ASA will connect to GNDC authentication infrastructure during

Biometric Testing Campaign and Products Certification.

Date: 16th July 2012, v0.9 Page 10 of 27

 6.2. Field Testing Steps

The field testing will be done in the following steps (refer to Figure 1):

1) Resident approaches the test location. At the test location, he/she is asked to
approach to the gatekeeper client station for the attendance, recommendation of
good fingers and guidance to head towards the respective authentication station.

2) Resident approaches the authentication station. The authentication station

comprises multiple terminals (laptops/workstations), where each terminal may
house one or more participating biometric products (sensor-extractor-supplier
combo).Resident provides Aadhaar Number and biometric details to terminal
devices to get himself/herself authenticated. The resident would need to
authenticate himself/herself on each of the participating product.

Refer to Annexure H for details on Resident Movement Plan.

3) The authentication process follows the "Two Finger Authentication Scheme", as

explained in Annexure_C. The maximum number of attempts per resident per
product is 04. In case of the first attempt (out of four), only one FMR will be
present in the PID block, whereas, in the subsequent attempts (if required), there
will be two FMRs packaged in the same PID block. As per the published
Authentication API Specification 1.6, POSH (Position Hint) is a mandatory attribute
and ten values corresponding to ten fingers are permitted. So, finger labeling
(specifying the finger position) is compulsory at the time of capture.

4) The authentication application software installed in the respective terminals

packages the input parameters, as specified in Annexure A, encrypts, encodes and
sends the packet to the C-DAC AUA server over either a mobile/broadband
network using AUA specific protocol. The connectivity between authentication
device and AUA server has to be ensured by the device supplier.

5) AUA server, after data validation, forms the auth. XML, completes necessary data
logging and then passes the request to the C-DAC ASA server over the secured
network.

6) ASA server, after necessary data logging, passes the request to the UIDAI's GNDC
for resident's authentication over the secured network.

7) The UIDAI authentication server returns a “yes/no” (as part of the response data)
based on the match of the input parameters to the respective terminal (at the test
location) through AUA/ASA server. The response XML data are logged at the
AUA/ASA server.

8) One authentication packet from AUA to GNDC authentication server is normally

about 3-4 KB including single/double fingerprint(s) and AUA digital signature.
Authentication response is about 1 KB.

Date: 16th July 2012, v0.9 Page 11 of 27

 6.3. Data Logging @ AUA/ASA

AUA/ASA will perform the information logging as per the UIDAI policies. The Table of Content
data that would be logged are as follows:

Data Logging Schema for XML Auth, Uses and Meta Tags @ AUA/ASA Server*

Uses
Meta
(Auth) Auth (This element
(Meta) (This element specifies
uid (Root element of the input XML for specifies the auth.
fdc metadata related to the
(Aadhaar authentication service) factors used by the
(fingerprint device and transaction)
number of the request)
device code)
resident)
tid ac sa ver txn lk bio bt udc pip lot lov

Data Logging Schema @ AUA/ASA Server*

uid AUA
fdc Request Request Response Response AUA
(Aadhaar Request
txn (fingerprint Receipt Forward Receipt Forward TAT Response
number of Processing
device code) Time Time Time Time Processing Time
the resident) Time

Where, TAT, AUA Request Processing Time and AUA Response Processing Time will be calculated as follows
» Turn Around Time (TAT): {(Response Receipt Time) – (Request Forward Time)}
» AUA Request Processing Time: {(Request Forward Time) – (Request Receipt Time)}
» AUA Response Processing Time: {(Response Forward Time) – (Response Receipt Time)}

Data Logging Schema for Response XML @ AUA/ASA Server*

AuthRes

txn code ret err ts info

* Please refer to Annexure A for more details on XML data elements. Minor changes are
expected in the logging schemas.

Date: 16th July 2012, v0.9 Page 12 of 27

 6.4. Expected Data Analysis

False Reject Rate (FRR) and average number of attempts for all the products
at a fixed FAR.

Where, a product is defined as a combination of the following:

» Sensor make
» Features extractor SDK, and
» Supplier Profile

Steps for data analysis:

» Design data logging schemas for the data points (to be captured) during the
Testing Campaign.
» C-DAC (AUA/ASA team) to capture and provide data for analysis.
» C-DAC (Biometrics team) to analyze the data, plot required curves, and prepare
report.
» STQC to review the report and give feedback.
» C-DAC to finalize the report and present to STQC for their approval
» Products certification by STQC (based on the approved report).

Please refer to Annexure E, Annexure F, Annexure G and Annexure I for details.

Date: 16th July 2012, v0.9 Page 13 of 27

7. Key Roles and Responsibilities
7.1. STQC Table of Content
Specifying terms and conditions to the participating suppliers.
Allocation of fdc to the participating biometric products (sensor–extractor–
supplier combination).
Supervise the biometric testing methodologies and testing campaign.
Specifying terms and conditions to the participating suppliers.
Review and approval of test data analysis & reports.
Drive testing and certification process to closure
Certification of biometric devices for Aadhaar project.

7.2. C-DAC

7.2.1. Biometrics Team

Coordination and preparation of the document on field testing
methodologies and certification of Aadhaar authentication devices.
Technical services at field level operations, including installation and
functioning of Gatekeeper client application software.
Running the required post-campaign tests for data analysis and FRR
calculation.
Performing a detailed analysis of the results of the tests and graph
generations.
Drawing conclusions, and upon approval by the competent authorities,
creating the final field testing report for certification of the participating
products by STQC.

7.2.2. AUA/ASA Team

Carrying out all the identified back-end AUA/ASA level
development/activities.
Data validation and errors handling.
All sorts of data logging: BFD, Authentication requests and responses.
Provide required data to C-DAC Biometrics team for data analysis
Technical services at field level operations.

7.3. UIDAI
Provide inputs for the field testing Project Plan and DPR.
Provide support for monitoring field testing activities, and develop training
material for the field level manpower.
Receive data analysis and report for information & further action as may be
necessary
Liaise with local administration, provide field level manpower to manage resident
mobilization, and train the field level manpower.
Identify locations where field testing may be conducted.

Date: 16th July 2012, v0.9 Page 14 of 27

 7.4. Device Suppliers
Deploy required number of authentication devices and other supporting hardware
(laptop, barcode reader etc.) at assigned authentication stations (8-10) Table of Content
Ensure end-to-end working of authentication application (including network
connectivity) as per published API 1.6 and other specifications given in testing
methodology document
Deploy necessary manpower to manage the authentication operations for the
respective devices
Take necessary measures to ensure all residents directed to the specific
authentication devices are able to transact
Provide other required support to C-DAC/STQC for carrying out the test

8. High-level Milestones and Timeline (tentative)

Date: 16th July 2012, v0.9 Page 15 of 27

9. References
1) [UIDAI, Authentication API v1.6, 2012]: AADHAAR Authentication API Specification - Table of Content
Version 1.6
http://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_6.pdf

2) [UIDAI, Role of Biometric Technology, 2012]: Role of Biometric Technology in Aadhaar

Authentication (Authentication Accuracy –Report)
http://uidai.gov.in/images/role_of_biometric_technology_in_aadhaar_authentication_02
0412.pdf

3) [UIDAI, Authentication Model, 2012]: AADHAAR Authentication Operating Model

http://www.uidai.gov.in/images/authDoc/d3_1_operating_model_v1.pdf

4) [UIDAI, BFD v1.6, 2012]: AADHAAR BEST FINGER DETECTION API Specification -
Version 1.6
http://uidai.gov.in/images/FrontPageUpdates/aadhaar_bfd_api_1_6.pdf

5) [UIDAI, BDCS, 2012]: UIDAI Biometric Device Specifications (Authentication)

http://stqc.gov.in/sites/upload_files/stqc/files/New%20Revision%20_May_%201%20
STQC%20UIDAI%20BDCS-03-
08%20UIDAI%20Biometric%20Device%20Specifications%20_Authentication_.pdf

6) [UIDAI, Security Policy & Framework, 2011]: Aadhaar Security Policy & Framework for
UIDAI Authentication – Version 1.0
http://uidai.gov.in/images/authDoc/d3_4_security_policy_framework_v1.pdf

7) [NIST, Performance of Biometric devices, 2002]: Best practices in testing and reporting
performance of biometric devices, Version 2.01 By A. J. Mansfield, National Physical
Laboratory and J. L. Wayman, San Jose State University. Middlesex: NPL Report CMSC
14/02.
http://fingerprint.nist.gov/minex04/minex_report.pdf

8) [NIST, MINEX Performance and Interoperability, 2006]: MINEX Performance and

Interoperability of the INCITS 378 Fingerprint Template, Supplement No. 1 Native
Matching, Patrick Grother, Michael McCabe, Craig Watson, Mike Indovina, Wayne
Salamon, Patricia Flanagan, Elham Tabassi, Elaine Newton, Charles Wilson, National
Institute of Standards and Technology March 21, 2006

9) [STQC, UIDAI Biometric Device Specifications, 2012]: UIDAI Biometric Device

Specifications
http://stqc.gov.in/sites/upload_files/stqc/files/New%20Revision%20_May_%201%20
STQC%20UIDAI%20BDCS-03-
08%20UIDAI%20Biometric%20Device%20Specifications%20_Authentication_.pdf

10) [STQC, Certification, 2011]: STQC Biometric Devices Testing and Certification
http://www.stqc.gov.in/content/bio-metric-devices-testing-and-certification

Date: 16th July 2012, v0.9 Page 16 of 27

 10. Annexures
Table of Content
Annexure A. Authentication Request and Response Data Formats*
Back to Context
» Aadhaar authentication during field testing will use only XML as the
data format for input and output.
» The formats mentioned below are meant only for field testing and
certification purposes.
* Primary source: [UIDAI, Authentication API v1.6, 2012]

A1. Authentication Request Data Format: The XML input data elements
are as follows:

<Auth uid=”” tid=”” ac=”” sa=”” ver=”” txn=”” lk=””>

<Uses bio=”y” bt=”FMR”/>
<Meta udc=”” fdc=”” pip=”” lot=”P” lov=””/>
<Skey ci=””>encrypted and encoded session key</Skey>
<Data>encrypted PID block</Data>
<Hmac>SHA-256 Hash of Pid block, encrypted and then
encoded</Hmac>
<Signature>Digital signature of AUA</Signature>
</Auth>

The XML input data marked in blue color are to be sent by the
supplier (from the authentication device) to the C-DAC AUA/ASA
server. Rest of the input data elements will be populated at the AUA's
end by the AUA.

Description of the above mentioned data elements (to be provided

by the Suppliers) are as follows:

Valid Values for Max. Length

Sr.No. Element Attributes Source Description
Field Testing & Format

Aadhaar
Aadhaar number of the resident
1. number of the Numeric string
uid Supplier from human test population
resident being of length 12.
Auth called for field testing.
authenticated
(mandatory)
Alphanumeric vendor code of Alpha-numeric
2. As assigned by
sa Supplier size 6 will be stored in this string of length
C-DAC AUA
attribute. 20
Unique Device Code. This Alpha-numeric
As assigned by attribute value will be assigned string of
udc Supplier
C-DAC AUA by CDAC for all the terminal maximum
devices. length 20
3.
Meta Fingerprint device code. This is
(mandatory) a unique code provided for the Alpha-numeric
As assigned by fingerprint sensor-extractor- string of
fdc Supplier
STQC supplier combination and will maximum
be provided by STQC before length 10
start of the field testing.

Date: 16th July 2012, v0.9 Page 17 of 27

 All devices will be connected to
the Internet and will have a
public IP (if the device has a
Public IP
private IP and is behind a
pip address of the Supplier ---
router/proxy/etc, then public IP
device.
address of the
router/proxy/etc. should be
set).
Value of this
Public key certificate identifier
attribute is the Certificate
using which “skey” was
4. SKey certificate expiration date
ci Supplier encrypted. UIDAI may have
(mandatory) expiration date in the format
multiple public keys in field at
in the format “YYYYMMDD“
the same time.
“YYYYMMDD”
Encrypted &
5. Data The PID block should be in the
--- encoded Pid Supplier ---
(mandatory) XML format.
block
Encrypted & encoded SHA-256
hash of Pid block:
After forming Pid XML,
Encrypted & compute SHA-256 hash of
6. Hmac encoded SHA- Pid XML string.
--- Supplier ---
(mandatory) 256 hash of Pid
Then encrypt using session
block
key (skey).
Then encode using base-64
encoding.

A2. Authentication Response Data Format: The XML response data

elements are as follows:

<AuthRes ret="y|n" code="" txn="" err="" auaerr="" ts="" info="">

</AuthRes>

Signature elements from UIDAI "AuthRes" are removed

"auaerr" attribute is added in "AuthRes" element
"auaerr" will return C-DAC AUA-ASA error code

Date: 16th July 2012, v0.9 Page 18 of 27

 Annexure B. Human Factors & Usability Interaction on Fingerprint Quality
Source URLs: Table of Content
http://zing.ncsl.nist.gov/biousa/docs/WP302_Theofanos.pdf Back to Context

http://zing.ncsl.nist.gov/biousa/docs/theofanos_quality_workshop_3-8-
06.pdf
http://zing.ncsl.nist.gov/biousa/docs/chi_2006_poster2.pdf
A. Human Factors and Usability Interaction on Fingerprint Quality
» Age Factor
Younger subjects submit higher quality prints than older subjects

Figure 2. A quality vs age group.

» Attempts by Age Groups

When feedback was introduced older participants tried more times:

Figure 3. Attempts vs age group.

» Gender Dependency
Women’s fingerprints, on average, are of poorer quality than men’s:

Figure 4. Quality dependency on gender.

Date: 16th July 2012, v0.9 Page 19 of 27

 Annexure C. Two Finger Authentication Process
Table of Content
Back to Context

Figure 2: Two Finger Authentication Process

Date: 16th July 2012, v0.9 Page 20 of 27

 Annexure D. Terms and Conditions for Suppliers
Table of Content
1. The participating suppliers will have to bring their terminals, Back to Context
authentication devices, feature extractor, the application software (in
compliance with the UIDAI's policies and specifications) etc., to
communicate and transact the data with AUA/ASA server.

2. It is the sole responsibility of the suppliers to bring all the needed

hardware, software and manpower to ensure smooth functioning of
devices deployed by them.

3. The suppliers are advised to keep with themselves multiple data

cards (of different makes) to ensure the flawless Internet
connectivity. The UIDAI-CDAC-STQC will not be responsible for any
flaw/loss in Internet connectivity.

4. Data/log sheets (hard copies), as per the template provided by STQC,

will be maintained for each day during the field testing. The sheets
will bear the resident transactions, hardware failure (if any) and
such other related details, which need to be signed by all the
suppliers.

5. It is the responsibility of the suppliers to ensure all the test

participants directed to a particular authentication station transact on
the corresponding device deployed by the respective suppliers.

Date: 16th July 2012, v0.9 Page 21 of 27

 Annexure E. FRR Calculation: Process Flow
Table of Content
Back to Context

Date: 16th July 2012, v0.9 Page 22 of 27

Notes
Note-1. Action Codes 01 or 03: BFD can be repeated for these residents second time.
Attention should be paid to following factors during BFD:
a. Verify that the Aadhaar card indeed belongs to the same resident.
b. Verify the Aadhaar number being entered.
c. Sequence of capturing fingers as per the suggested order.

Note-2. Action Code 04 or 99: In case, if resident obtains action code 99, the resident is asked
to wait aside for 2-5 minutes (time for on-demand fingerprint template loading from
enrollment system into authentication systems) and BFD is repeated. 99 could also be
a result of wrongly entered UID. Action code 04 refers to the action to check whether
the Aadhaar number was entered correctly. If it was entered correctly, the resident's
enrollment needs to be updated.

During BFD, even after second round, the action code returned is 01/03/04/99,
such resident can’t participate in the authentication exercise.

[Refer to the Best Finger Detection API document for exhaustive error codes and
action codes]

Note-3. In case a particular resident authentication is not attempted by the participating

supplier, supplier is required to notify the room supervisor in person. Room
supervisor will categorize the error along the following two categories for that device,
namely –

a. Failure to Acquire (FTA) – When resident fingers are not captured by the device
after the repeated attempts, then the supervisor is required to make a note of the
resident's Aadhaar number and make a note of it under FTA category for that
particular device. Supervisor is also required to note any remarks as potential
reasons for FTA.

b. Network error or other system related errors – When residents are not able to
attempt authentication due to network or other authentication station/device
related issue, the supervisor makes a note of such Aadhaar numbers under
"Network and Other Errors" category for that device. These include response
codes excluding y and 300.

All the FTA cases and network errors or other device related errors have to be
recorded by supervisor. In case, if any supplier fails to intimate these errors to the
supervisor, all the balance cases from total population which were not recorded
in the UIDAI authentication backend logs will be counted as FTA for that
particular device.

Note-4. All suppliers are provided with a grace of 25 failure cases to accommodate errors due
to intermittent network or other authentication device related issues. The suppliers
are requested to plan for multiple network connectivity options to accommodate
variable network connectivity conditions.

Note-5. In case a particular resident leaves the authentication room midway during the device
authentication process, then the resident's Aadhaar number is eliminated for FRR
calculation for all participating suppliers.
Date: 16th July 2012, v0.9 Page 23 of 27
 Annexure F. Guidelines for FTA (Failure to Acquire) Indicators
Table of Content
As deliberated in earlier workshops, FTA is an important component of Back to Context
FRR calculation. The decision mechanism for concluding the FTA is based
on the following indicators:

Indicator 1. Resident is made to spend more than 03 minutes per

device (in case of normal operating conditions: like network
availability, etc.)

Indicator 2. Crowd gets built (or sequence gets blocked) at any

particular device.

Indicator 3. More than 06 multiple attempts:

As observed by the respective STQC supervisor
As informed by the resident

Indicator 4. "Yes" response after more than 04 attempts as

observed during reconciliation process:
Restarting the application in-between (or after
multiple attempts) during the authentication process
of a resident.

Date: 16th July 2012, v0.9 Page 24 of 27

 Annexure G. Aadhaar Numbers by Suppliers for Testing Purpose
Table of Content
Back to Context

Sr. No. Aadhaar Number

1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

I hereby declare that I will use only the above mentioned Aadhaar
numbers for testing the readiness of my applications/devices.

Supplier Name :

Representative Name :

Signature :

Date :

Date: 16th July 2012, v0.9 Page 25 of 27

 Annexure H. Resident Movement: Process Flow
Table of Content
Back to Context

Resident • Resident comes to welcome

ome table
ta
Mobilizer at • Token & consent form given
ven to the resident
welcome table • Resident signs consent form
orm aand carries to BFD station

Runner • Directs resident to a BFD

D station
stati

• Do BFD
BFD Operators • Staple consent form and BFD rreceipt

• Coordinate with runnerss of ea

each floor and write station
Resident no. and serial number forr the sstation in BFD receipt
mobilizer at he resi
• Explain the process to the resident
STQC table quired station no.
• Direct resident to the required

Operators at • Do authentication of the resident

reside in a sequential
manner
Auth. Stations • Sign-off in the respectivee devic
device cell (on BFD receipt)

• Ensure smooth movement nt

STQC
/error
• Track/record exception/errors
Supervisor at
QC table
• Direct resident to the STQC tab after ensuring
Auth. station resident authenticates onn each device of the station

STQC • Collect the BFD receipt and consent

co form from resident,
Personnel at and file in the respectivee BOX ffile
irect the
• Sign-off the token and direct th resident to gift-
STQC table counter

• Collect token from the resident

esiden
Gift Counter • Handover Gift
Table • Thank the resident

Date: 16th July 2012, v0.9 Page 26 of 27

 Annexure I. FRR Mock Report
Mock report and the corresponding graph are based on dummy data, Table of Content
meant only for gaining good understanding and clarity. Slight variation is Back to Context
expected in the approach.

Please refer to the next page for the mock report.

Date: 16th July 2012, v0.9 Page 27 of 27

 FRR Field Testing Mock Report
Symbols and Definitions -
Test Population A: Number of residents with Auth response “Yes” .
Size arrived to the B: Number of residents with Auth response “No”.
5000
location and N: Number of residents who could not be authenticated for network failure or other reasons .
attempted BFD(X) M: Number of residents with FTA (Failure to Acquire).
K: K = 0 { if N <= 25 Failure Cases [refer to Note 04] } or K = N - 25 { if N > 25 Failure Cases }.
Number of
residents who
75 During BFD, even after second round, if the action code returned is 04, such resident can’t participate in the authentication exercise.
failed in BFD
process (Y)
Total Population
Size of the
residents with the
4925 P: Total population which attempted authentication across all devices (P = A + B + M + N).
best fingers
(Action Code 00)
(P = X - Y)

A B N M
Number of residents
fdc (B+ M K K)
Sr. No. could not be Verdict
(dummy)
Auth. Result "y" Auth. Result 300/"n" authenticated for FTA Cases
FRR 100
10
((A + B + M K
K)
network failure or
other reasons.

1 FDC0001001 4822 45 28 30 1.591836735 1.591836735

2 FDC0001002 4898 2 0 25 0.54822335 0.54822335
3 FDC0001003 4876 19 2 28 0.954702417 0.954702417
4 FDC0001004 4870 20 0 35 1.116751269 1.116751269
5 FDC0001005 4871 29 0 25 1.096446701 1.096446701
6 FDC0001006 4840 10 45 30 1.224489796 1.224489796
7 FDC0001007 4859 37 0 29 1.340101523 1.340101523
8 FDC0001008 4725 145 0 55 4.060913706 Device Rejected (FRR > 2%)
9 FDC0001009 4898 5 1 21 0.528025995 0.528025995
10 FDC0001010 4772 100 3 50 3.04754165 Device Rejected (FRR > 2%)
11 FDC0001011 4878 29 0 18 0.954314721 0.954314721
12 FDC0001012 4872 15 4 34 0.995732575 0.995732575
13 FDC0001013 4883 4 0 38 0.852791878 0.852791878
14 FDC0001014 4810 75 0 40 2.335025381 Device Rejected (FRR > 2%)
15 FDC0001015 4894 6 0 25 0.629441624 0.629441624
16 FDC0001016 4869 30 0 26 1.137055838 1.137055838
17 FDC0001017 4785 95 0 45 2.842639594 Device Rejected (FRR > 2%)
18 FDC0001018 4880 12 0 33 0.913705584 0.913705584
19 FDC0001019 4870 18 0 37 1.116751269 1.116751269
20 FDC0001020 4828 35 35 27 1.469387755 1.469387755
21 FDC0001021 4899 4 0 22 0.527918782 0.527918782
22 FDC0001022 4891 10 0 24 0.69035533 0.69035533
23 FDC0001023 4866 22 12 25 0.956645634 0.956645634
24 FDC0001024 4645 195 5 80 5.589430894 Device Rejected (FRR > 2%)
25 FDC0001025 4830 60 0 35 1.92893401 1.92893401
26 FDC0001026 4893 16 0 16 0.649746193 0.649746193
27 FDC0001027 4897 10 0 18 0.568527919 0.568527919
28 FDC0001028 4872 24 4 25 0.995732575 0.995732575
29 FDC0001029 4847 45 0 33 1.583756345 1.583756345
30 FDC0001030 4889 12 0 24 0.730964467 0.730964467
 Mock Report
(FRR Field Testing and Device Certification)
6

FRR %
2

0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
FRR % 1.5918 0.5482 0.9547 1.1168 1.0964 1.2245 1.3401 4.0609 0.528 3.0475 0.9543 0.9957 0.8528 2.335 0.6294 1.1371 2.8426 0.9137 1.1168 1.4694 0.5279 0.6904 0.9566 5.5894 1.9289 0.6497 0.5685 0.9957 1.5838 0.731