Aadhaar Registered Devices Specification

Transcription

Unique Identification Authority of India (UIDAI)
3rd Floor, Tower II, Jeevan Bharati Building,
Connaught Circus, New Delhi 110001
AADHAAR REGISTERED DEVICES
TECHNICAL SPECIFICATION - VERSION 1.5
JANUARY 2016
Version 1.5
Contents
1
2
Introduction ................................................................................................................................................... 3
1.1
Target Audience and Pre-Requisites............................................................................................ 3
1.2
Aadhaar Authentication at a Glance ............................................................................................. 3
Registered Devices ...................................................................................................................................... 4
2.1
Understanding Public Devices ........................................................................................................ 4
2.2
Understanding Registered Devices............................................................................................... 6
2.3
Device Hardware and Software .................................................................................................. 10
2.3.1
3
Device Software APIs.............................................................................................................. 10
2.4
Device Registration .......................................................................................................................... 11
2.5
Device Reset........................................................................................................................................ 14
UIDAI Backend APIs ................................................................................................................................ 16
3.1
Registration API ................................................................................................................................ 16
3.1.1
Register API Input ................................................................................................................... 16
3.1.2
Register API Response ........................................................................................................... 18
3.2
Device Reset API ............................................................................................................................... 19
3.2.1
Reset API Input ......................................................................................................................... 20
3.2.2
Reset API Response................................................................................................................. 21
©UIDAI, 2016
uidai.gov.in
Page |2
Version 1.5
1 Introduction
The Unique Identification Authority of India (UIDAI) has been created, with the mandate of
providing a Unique Identity (Aadhaar) to all Indian residents. The UIDAI proposes to provide
online authentication using demographic and biometric data.
Aadhaar “authentication” means the process wherein Aadhaar Number, along with other
attributes, including biometrics, are submitted to the Central Identities Data Repository
(CIDR) for its verification on the basis of information or data or documents available with it.
Aadhaar authentication service only responds with a “yes/no” and no personal identity
information is returned as part of the response.
1.1 Target Audience and Pre-Requisites
This is a technical document and is targeted primarily at biometric device manufacturers
who want to build registered devices as per this specification for Aadhaar authentication
ecosystem and get it registered for use. Application developers who are users of registered
devices need to only understand the usage of it.
Before reading this document, readers must read the Aadhaar authentication document
http://uidai.gov.in/images/FrontPageUpdates/aadhaar_authentication_api_1_6.pdf
1.2 Aadhaar Authentication at a Glance
Aadhaar authentication is the process wherein Aadhaar Number, along with other attributes,
including biometrics, are submitted online to the Aadhaar system for its verification on the
basis of information or data or documents available with it. During the authentication
transaction, the resident’s record is first selected using the Aadhaar Number and then the
demographic/biometric inputs are matched against the stored data which was provided by
the resident during enrolment/update process.
For latest documentation on Aadhaar authentication, see http://uidai.gov.in/auth
©UIDAI, 2016
uidai.gov.in
Page |3
Version 1.5
2 Registered Devices
This chapter describes the specification in detail for registered devices for biometric device
manufacturers and also provide details on registration flow before these can be used with
larger host devices.
2.1 Understanding Public Devices
Before understanding registered devices and the need for it, it is important to understand
how public devices work.
Following is the logical diagram of a minimalistic public device:
Host Machine
with AUA App
Sensor
Processor
(as needed)
Public Device
(Hardware Zone)
Device
Driver
USB/BT/
Other
Biometrics
Extractor/
Processor
SDK
(PoS, Micro-ATM,
Mobile Phones,
Tablets, Laptops, etc.)
A
U
A
S
e
r
v
e
r
Following is the sequence of typical operations using the public devices required to conduct
Aadhaar biometric authentication:
1. AUA provided application starts in host machine (any application such as banking
used for providing resident services).
2. Application captures Aadhaar number and other essential business transaction data
(such as amount in the case of payment).
3. When ready for biometric input capture, application prompts the Aadhaar holder for
capturing biometrics (fingerprint or iris).
©UIDAI, 2016
uidai.gov.in
Page |4
Version 1.5
4. Image inputs are continuously captured by “sensor” and an optional video stream is
provided via the “Device Driver” to the application on host for preview.
5. When sensor or device driver detects a good image, it provides the captured good
image back to host application.
6. Application with the help of “Biometric SDK” does additional image quality checks
and FMR/FIR/IIR creation. Notice that in the case of fingerprints, image gets
converted using an extractor algorithm to FMR and in the case of Iris image, it gets
processed into IIR.
7. Using the FMR/FIR/IIR inputs (one or more) application then creates the PID block
(see Aadhaar Authentication API Specification for details) and does rest of the
authentication steps to complete the transaction.
Sequence diagram for public devices is shown below:
©UIDAI, 2016
uidai.gov.in
Page |5
Version 1.5
Several security measures are taken to ensure strong transaction security and end to
end traceability even in public devices. Specific protection against usage of stored
biometrics include deploying signed applications, host and operator authentication by AUA,
usage of multi-factor authentication, resident SMS/Email alerts on authentication, biometric
locking, and so on.
In the case of public devices, although above security measures are in place, there is still a
technical possibility of having the biometric data captured in between capture device and
host machine if the device or host machine of AUA is compromised. Hence stored biometrics
could be used on a compromised device to conduct some transactions although it can be
potential detected and subsequent usage stopped on the server using above security
monitoring and protection scheme already in place.
2.2 Understanding Registered Devices
Registered devices specification described in this document addresses precisely the scenario
of potential use of stored biometrics by ensuring biometrics data between device and host is
encrypted and devices are uniquely identified.
It provides two key additional features compared to public devices:
1. Device identification – every physical sensor device having a unique identifier
allowing device authentication, traceability, analytics, and fraud management.
2. Eliminating use of stored biometrics – every biometric record is processed and
encrypted within the secure zone eliminating transmission of unencrypted
biometrics from sensor to host machine.
There are 4 key steps to getting a registered device ready for authentication use:
1. Manufacturer procures public key from CA, shares public key with UIDAI, and get a
“Manufacturer Key” issued by UDIAI.
2. Certify the model as a compliant registered device and obtain other accuracy related
certifications as necessary.
3. Manufacture devices with manufacturer key.
4. Register every individual physical device unit using the registration API before field
distribution and use.
©UIDAI, 2016
uidai.gov.in
Page |6
Version 1.5
Key design mandate is that registered devices must provide a secure flow from capture
to extract/process of biometric input and provide encrypted templates/images
(FMR, FIR, IIR) back to application which is then used for Aadhaar authentication.
Registered devices MUST ensure:

There is no mechanism to inject stored biometrics during the capture to
extract/process flow.

No external program/probe should be able to read the encryption/signature
keys.
UIDAI does not mandate specific hardware design and manufacturers are expected to
innovate and create appropriate form factors for market use.
Following is the logical diagram of a registered device (for illustration purposes only, Actual
HW design may differ):
Sensor
Host Machine
with AUA App
Processor (s)
(For extraction,
encryption)
USB/BT/
Other
RAM
Device
Driver
Storage
Registered Device
(Secure Hardware Zone)
(PoS, Micro-ATM,
Mobile Phones,
Tablets, Laptops, etc.)
A
U
A
S
e
r
v
e
r
There is no requirement for entire registered device to be physically separate unit. This is to
ensure other than physically enclosed external registered devices, embedded devices,
phones, etc. can also act as registered devices.
©UIDAI, 2016
uidai.gov.in
Page |7
Version 1.5
Sequence diagram for registered devices is shown below:
Following is the sequence of typical operations using the registered devices required to
conduct Aadhaar biometric authentication:
1. AUA provided application starts on host machine.
2. Application captures Aadhaar number and other essential business transaction data
(such as amount in the case of payment).
3. When ready for biometric input capture, application prompts the Aadhaar holder for
capturing biometrics (fingerprint or iris) and calls “startCapture()” function of the
device driver (supplied by registered devices vendor) and provide “PID ts” (see
Aadhaar authentication API for details on authentication input and its format) as
input (used for encryption, see step 6).
4. Device driver may provide continuous video stream to application while capturing
the biometrics for visual preview.
©UIDAI, 2016
uidai.gov.in
Page |8
Version 1.5
5. When the registered device detects a good capture, it does processing within the
secure zone to create encrypted FMR/FIR/IIR. It is mandatory that the
extraction/processing is done within a secure capture-to-extract flow.
6. Registered device uses “PID ts” (passed by calling application during startCapture
function call), a random number RNi, and device key Ki (stored within secure zone)
to create a new encryption key DKi
RNi = HOTP(Ki,Si+C)
where Ki is the latest key,
Si is the latest seed (set during registration and Reset),
and C is the incremental counter
C is a 3 digit integer value between 1 to 999
C needs to be incremented for every request
C needs to be reset to 1 after every Reset API call
The size of the RNi is 10 digits
DKi = encryptAES-256(SHA-256(RNi+ts), Ki)
7. Registered device encrypts the FMR/FIR/IIR using DKi within secure zone and gives
it back to application.
a. Return array = [C, EBR , BR]
where C is the counter,
BR is the unencrypted bio record (FMR/FIR/IIR based on usage),
and EBR being encrypted bio record computed as
EBR = encryptAES-256(BR, DKi)
b. Providing unencrypted bio record helps in display, additional validations such
as local duplicate check (e.g., avoiding same finger being used when using dual
finger authentication), etc. on the host.
8. After returning the encrypted bio record, device MUST erase all captured data from
its memory/storage. This is mandatory to ensure old captures are never used for
subsequent calls.
9. If there are any errors or host application requests additional captures, step 3 through
8 are repeated.
10. Host application creates PID block (as per Aadhaar API specs) using EBR (encrypted
FMR/FIR/IIR) and completes transaction. Base 64 encoded EBR needs to be
prepended with counter C and a delimiter “|”.
©UIDAI, 2016
uidai.gov.in
Page |9
Version 1.5
Data block = C | base-64(EBR)
Host application must call “getTid()” function of the device on every authentication
transaction to obtain “tid” value and use it as part of “tid” parameter of
authentication API.
Notice that steps 3 through 8 are different in the case of registered devices where capture
through template/image processing is done within the secure zone compared to doing
within host application. Most importantly, output template/image (FMR, FIR, IIR) is
encrypted within the device secure zone before returning it to host application and used
within PID block.
2.3 Device Hardware and Software
Registered devices hardware should provide a secure zone within which capture to
biometric template extraction/processing is done and returned to the application using the
keys which are stored within the secure zone.
Registered devices MUST ensure:

There is no mechanism to inject stored biometrics during the capture to
extract/process flow.

No external program/probe should be able to read the encryption/signature
keys.
UIDAI does not mandate specific hardware design and manufacturers are expected to
innovate and create appropriate form factors for market use.
2.3.1 Device Software APIs
Registered devices module should implement the following APIs at a minimum and expose
these functions to host application:
1. getRegisterInput (returns binary input block – a byte array – used for initial
registration, see register API input)
2. setDeviceInfo (sets binary output block – a byte array – returned from the
register/reset API, see ”drd” definition within register/reset API response)
©UIDAI, 2016
uidai.gov.in
P a g e | 10
Version 1.5
3. getResetInput (returns binary input block – a byte array – used for key resetting,
see reset API input)
4. getTid (returns UIDAI server generated tid which is set during registration. Null if
device is not registered)
5. startCapture (initiates the biometric capture operation)
6. getPKeyCi (returns expiry date in the form YYYYMMDD of the UIDAI public key used
for encryption while registration)
7. getDevicePKey (returns X509 Certificate which is the device public key, see
registration section for details)
8. setPKey (this function should take UIDAI public key and expiry and ensure it is set
inside the device. This can be used in case it is expired before registration.
Registration application must validate x.509 and invoke this function as required.)
IMPORTANT SECURITY NOTE: Registered devices MUST NOT expose ANY
mechanism/function/interface that allows an image/template to be given as input
and gives back an encrypted image/template as well as obtain the key.
2.4 Device Registration
Device registration is a one-time activity of registering the device on the UIDAI server and
initializing the device. Once a device is used for authentication, it can never be “re-registered”
as another device. Registration should be done by the manufacturer or their partners.
Manufacturer of the device needs do the following:
1. Manufacturer provides a public key procured from one of the approved Certification
Authority in India by CCA to UIDAI. UIDAI Signs the public key and provides to the
Manufacturer.
a. Let us call this as ”Manufacturer Key”.
b. Note that one manufacturer may have one or more Manufacturer Keys.
2. Get device model certified for usage as registered devices.
3. Manufacture physical devices having manufacturer specific Unique PhysicalIDs.
a. It should generate a unique private-public key pair.
b. The public key should be signed by the Manufacturer Key. Let us call it “Device
Public Key”.
©UIDAI, 2016
uidai.gov.in
P a g e | 11
Version 1.5
NOTE: Manufacturer must keep their private keys secure and ensure they are not
compromised and not available to people.
Registration agency (either manufacturer or their partners) needs to do the following during
registration of the devices:
1. Registration Agency obtains a set of devices for registration.
2. Uses a registration facility to initiate registration of each physical device (this can be
manual or automated process based on device volume). This facility must be
different from the actual field where the device is used.
3. Each device is connected to the registration application that uses the Register API (see
later section for API details).
4. Registration application calls “getRegisterInput()” function of the device to obtain
the input for the Register API.
5. Device generates a new device registration key (DK0) and encrypts it with UIDAI
public key. The DK0 is used to encrypt the physical device ID and modelID. Then it
creates registration input as:
DK0 = SHA-256(RandomNumber)
EB = encryptRSAOAEP(DK0)+encryptAES-256 (physicalID +,+
modelID, DK0)
Input block = EB+signatureSHA-256(EB, PrivateKey)
Encryption – RSA OAEP & AES/CFB/PKCS7Padding with padding/IV
PhysicalID and ModelID must be separated with comma (“,”) before
encrypting with DK0
ModelID must be a valid ID in certified model list
Signature is created by signing the encrypted bytes (EB) using the unique
device private key using SHA-256 hash algorithm
6. Registration application forms the input XML for Aadhaar Device Registration API
(see next section), digitally signs the request, adds the device public key by calling
“getDevicePkey()”, and calls “Register” API of UIDAI.
7. UIDAI registration server does the following:
a. Validates the input
©UIDAI, 2016
uidai.gov.in
P a g e | 12
Version 1.5
b.
c.
d.
e.
f.
Generates initial AES-256 key K0 and initial seed S0
Generates globally unique “tid”
Stores the data within UIDAI server device registry
Encrypts response block with key DK0 that was part of input
Responds with an XML having encoded “drd” attribute (see API details in later
for details)
g. Registration application passes decoded “drd” value to device by calling
“setDeviceInfo()” function
8. Device within its hardware module decrypts “drd” value using DK0, extracts the initial
key K0 , seed S0 and stores it in secure storage along with “tid”.
Device is now ready for field deployment and use!!
Registration sequence diagram is:
©UIDAI, 2016
uidai.gov.in
P a g e | 13
Version 1.5
2.5 Device Reset
Unlike initial registration, device may be reset many times during its life. There are two
situations where reset needs to be initiated:
1. Administrator of the device forcing a reset due to an encryption error.
2. When UIDAI server gives an explicit error code as part of authentication API
indicating that a reset is mandatory due to UDIAI key rotation policy.
Following is the sequence diagram for reset flow.
©UIDAI, 2016
uidai.gov.in
P a g e | 14
Version 1.5
Device reset flow is as below:
1. Either based on admin command or based on specific error code on previous
transaction from UIDAI server, host admin application initiates device reset.
2. Host requests registered device to provide input using “getResetInput()” function
passing “ts” (timestamp) which is used for the reset API transaction.
3. Device generates a new key and creates input block for reset API
DKi = encryptAES-256(SHA-256(ts), Ki)
DKiHash = SHA-256(DKi)
Input block = encryptAES-256(tid, DKiHash)
Encryption –AES/CFB/PKCS7Padding with padding/IV
4. Host forms reset API input XML and calls the API via AUA server to UDIAI server.
5. UDIAI server generates a new Ki+1, next seed, encrypts it with with DKiHash and
sends it back.
6. Host calls “setDeviceInfo()” function and provides “drd” block to device
7. Device decrypts Ki+1 using DKiHash and replaces Ki with Ki+1 and Si with Si+1.
©UIDAI, 2016
uidai.gov.in
P a g e | 15
Version 1.5
3 UIDAI Backend APIs
UIDAI provides APIs for registration of every device as well as key reset during field usage.
Following sections provide details of these APIs.
3.1 Registration API
3.1.1 Register API Input
<Register rac="" ver="" txn="" ts="" lk="" ci="">
<Data>base-64 encoded registration input block</Data>
<DevicePKey>base64 of X509 Certificate </DevicePKey>
<Signature>Digital signature of registration agency</Signature>
</Register>
Element: Register (mandatory)

Root element of the input XML for registration service.
Attributes:

rac – (mandatory) A unique code for the registration agency assigned by UIDAI. This
is an alpha-numeric string having maximum length 10.

ver – (mandatory) version of Register API. Currently only valid value is “1.0”.

txn – (mandatory) Agency specific transaction identifier for auditing and tracking.
Agency can choose to pass this as part of input. This is returned as part of response
as is. This is very useful for linking transactions full round trip across systems. This is
an alpha-numeric string of maximum length 50. Only supported characters are A-Z,
a-z, 0-9, period, comma, hyphen, backward & forward slash, left & right parenthesis,
and colon. No other characters are supported.

ts – Timestamp when the request is initiated. This is of type XSD dateTime.

lk – (mandatory) A valid “License Key” assigned to the agency. Administration portal
of UIDAI will provide a mechanism for registration agency administrator to generate
license keys and use it within the API. This is an alpha-numeric string of length up to
64 characters.
©UIDAI, 2016
uidai.gov.in
P a g e | 16
Version 1.5

ci – (mandatory) UIDAI Public key certificate identifier using which “DKi” was
encrypted. Value of this attribute should be obtaines by calling “getPkeyCi()” which
returns the certificate expiration date in the format “YYYYMMDD”.
Element: Data (mandatory)

This element contains the actual registration input data obtained from the device
hardware.
o This is base-64 encoded version of encrypted input data generated within the
device. It is constructed inside the device hardware
DK0 = SHA-256(RandomNumber)
EB = encryptRSAOAEP(DK0)+encryptAES-256 (physicalID
+,+modelID, DK0)
Input block = EB+signatureSHA-256(EB, PrivateKey)
Encryption – RSA OAEP & AES/CFB/PKCS7Padding with padding/IV
PhysicalID and ModelID must be separated with comma (“,”) befor
encrypting with DK0
ModelID must be a valid ID in ceritifed model list
Signature is created by signing the encrypted bytes (EB) using the unique
device private key using SHA-256 hash algorithm
Element: DevicePKey (mandatory)

The request XML should have the X509 device public key certificate issued using the
Manufacturer Key.

In case of new Manufacturer Key new devices would use this once they receive. UIDAI
will automatically validate with the correct certificate.

This must be obtained via “getDevicePKey()” function call
Element: Signature (mandatory)

The request XML should be digitally signed for message integrity and nonrepudiation purposes by the registration agency.

Registration Agency private key must be used to sign the XML
©UIDAI, 2016
uidai.gov.in
P a g e | 17
Version 1.5
3.1.2 Register API Response
<RegisterRes ret="y|n" code="" txn="" drd="" err="" ts="">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xmlc14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256"
/>
<Reference URI="">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature" />
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>
<DigestValue></DigestValue>
</Reference>
</SignedInfo>
<SignatureValue></SignatureValue>
</Signature>
</RegisterRes>
Element: RegisterRes

Root element of response XML
Attributes:

ret – this is the main authentication response. It is either “y” or “n”.

code – unique alphanumeric “registration response” code having maximum length
40. Agency is expected to store this for audit.

txn – Registration specific transaction identifier. This is exactly the same value that
is sent within the request.

ts – Timestamp when the response is generated. This is of type XSD dateTime.

drd – Device Response Data. This data must be sent back all the way to host
registration application which should de-code and pass it to registered devices for
decrypting and storing the contents. Structure is:
o base-64(encryptAES-256(K0+tid+S0,DK0)where “tid” is a unique id
generated during registration.
“K0” is the 32-byte AES-256 key.
“tid” is a 32-byte alpha-numeric string.
©UIDAI, 2016
uidai.gov.in
P a g e | 18
Version 1.5
And “S0” is the 10-byte initial seed for HOTP generation during biometric
data encryption
o Registered device should decrypt this and store K0, S0, and tid

err – Failure error code. If authentication fails (“ret” attribute value is “n”), this
attribute provides any of the following codes (for latest updates on error codes, see
https://developer.uidai.gov.in/site/api_err):
o “RG-100” – Manufacturer signature not recognized.
o “RG-110” – PhysicalID and/or ModelID could not be extracted
o “RG-120” – Unable to determine the model or model is not certified
o “RG-130” – Device manufacturer signature verification failed
o “RG-500” – Invalid encryption of device input block
o “RG-510” – Invalid Register XML format
o “RG-520” – Invalid UIDAI public key
o “RG-530” – Invalid registration agency code
o “RG-540” – Invalid Register XML version
o “RG-550” – Request expired (“Register-->ts” value is older than 1 hour)
o “RG-560” – Timestamp value is future time (value “Register-->ts” is ahead of
server time beyond acceptable threshold)
o “RG-565” – Duplicate request
o “RG-570” – Device already registered and used. Cannot register again.
o “RG-580” – Agency license key has expired
o “RG-590” – Invalid non-decryptable license key
o “RG-569” – Registration agency digital signature verification failed
o “RG-570” – Invalid key info in digital signature
o “RG-999” – Unknown error
3.2 Device Reset API
NOTE: This API must be implemented on all field applications using Aadhaar
biometric authentication to ensure key reset and rotation support is built-in. Without
this API, when keys have expired (due to mandatory rotation policy) or go out of sync,
registered devices stops working and will require a reset.
After Reset API call, device internal counter (counter C used for HOTP generation)
should be reset to 1.
©UIDAI, 2016
uidai.gov.in
P a g e | 19
Version 1.5
3.2.1 Reset API Input
<Reset tid="" ac="" sa="" ver="" ts="" txn="" lk="">
<Data>encoded encrypted reset input block</Data>
<Signature>Digital signature of registration agency</Signature>
</Reset>
Element: Reset (mandatory)

Root element of the input XML for reset service.
Attributes:

tid – (mandatory) returned by “getTid()” function

ac – (mandatory) A unique code for the AUA which is assigned by UIDAI during AUA
registration process. This is an alpha-numeric string having maximum length 10.

sa – (mandatory) A unique “Sub-AUA” code. AUAs are expected to manage these
codes within their system and ensure uniqueness within their system. This allows
auditing and business intelligence to be provided at SA level. If AUA and SA are same
agency, use value of “ac” for this attribute. This is an alpha-numeric string having
maximum length 10.

ver – (mandatory) version of reset API. Currently only valid value is “1.0”.

ts – Timestamp in ISO format (YYYY-MM-DDThh:mm:ss) generated by host for this
transaction

txn – (mandatory) AUA specific transaction identifier for auditing and tracking.
Agency can choose to pass this as part of input. This is an alpha-numeric string of
maximum length 50. Only supported characters are A-Z, a-z, 0-9, period, comma,
hyphen, backward & forward slash, left & right parenthesis, and colon. No other
characters are supported.

lk – (mandatory) A valid “License Key” assigned to the AUA. Administration portal of
UIDAI will provide a mechanism for AUA administrator to generate license keys and
use it within the authentication. This is an alpha-numeric string of length up to 64
characters.
Element: Data (mandatory)

This element contains the actual reset input data obtained from the device hardware.
o This is base-64 encoded version of encrypted input block. o It is constructed
inside the device hardware module as:
©UIDAI, 2016
uidai.gov.in
P a g e | 20
Version 1.5
DKi = encryptAES-256(SHA-256(ts), Ki)
DKiHash = SHA-256(DKi)
Input block = encryptAES-256(tid, DKiHash)
Encryption –AES/CFB/PKCS7Padding with padding/IV
Element: Signature (mandatory)

The request XML should be digitally signed for message integrity and nonrepudiation purposes by AUA.
3.2.2 Reset API Response
<ResetRes ret="y|n" code="" txn="" drd="" err="" ts="">
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xmlc14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha256"
/>
<Reference URI="">
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#envelopedsignature" />
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>
<DigestValue></DigestValue>
</Reference>
</SignedInfo>
<SignatureValue></SignatureValue>
</Signature>
</ResetRes>
Element: ResetRes

Root element of response XML
Attributes:

ret – this is the main authentication response. It is either “y” or “n”.

code – unique alphanumeric “registration response” code having maximum length
40. Agency is expected to store this for audit.

txn – Registration specific transaction identifier. This is exactly the same value that
is sent within the request.

ts – Timestamp when the response is generated. This is of type XSD dateTime.
©UIDAI, 2016
uidai.gov.in
P a g e | 21
Version 1.5

drd – Device Response Data. This data must be sent back all the way to host
registration application which should de-code and pass it to registered devices for
decrypting and storing the contents. Structure is:
o base-64(encryptAES-256(Ki+1+tid+Si+1, DKiHash)
“Ki+1” is the 32-byte AES-256 key.
“tid” is the same value as what was in input.
And “Si+1” is the next 10-byte seed for HOTP generation during
biometric data encryption
o Registered device should decrypt this and replace Ki with Ki+1 and replace
Si with Si+1

err – Failure error code. If authentication fails (“ret” attribute value is “n”), this
attribute provides any of the following codes (for latest updates on error codes, see
https://developer.uidai.gov.in/site/api_err):
o “RS-100” – tid not recognized.
o “RS-500” – Invalid encryption of device input block
o “RS-510” – Invalid Reset XML format
o “RS-530” – Invalid AUA code
o “RS-540” – Invalid Reset XML version
o “RS-550” – Request expired (“Reset-->ts” value is older than 1 hour)
o “RS-560” – Timestamp value is future time (value “Reset-->ts” is ahead of
server time beyond acceptable threshold)
o “RS-565” – Duplicate request (this error occurs when exactly same reset
request was re-sent by agency)
o “RS-565” – Agency license key has expired
o “RS-566” – Invalid non-decryptable license key
o “RS-569” – Digital signature verification failed
o “RS-570” – Invalid key info in digital signature
o “RS-999” – Unknown error
©UIDAI, 2016
uidai.gov.in
P a g e | 22

Aadhaar Registered Devices Specification

Transcription

Similar documents

Electronic Verification Code (EVC)

Computer Settings For NAUTIKOS

FAQ UID

Whitepages Pro Caller Identification API

OMNITRAC LASER TRACKING SYSTEM

API and Mashup Tooklit - GeoJet Information Solutions

Untitled - Petromak

4G Corporate Brochure - 4G Identity Solutions

Online Quarterly Retirement Account Statements Annual

Identity Security Trends in the Mobile Era