Aadhaar Authentication Application Security Standardaadhaar.jharkhand.gov.in/Aadhaar_Authentication... · 2020. 11. 18. · Aadhaar Authentication Application Security Standard includes

Aadhaar Authentication Application Security

Standard (for Web, Mobile and Thick Client Applications)

2 | P a g e

Document Control

S. No. Type of Information Document Data

1. Document Title UIDAI - Aadhaar Authentication Application Security Standard

2. Document Code UIDAI – AAASS

3. Date of Release 13-Nov-2020

4. Document Superseded First Version (2020)

5. Document Revision No V1.0

6. Document Owner UIDAI

7. Document Author(s) Deepali Sharma (ADG -Auth), Rajinder Singh (Consultant)

Document Approvers

S.No. Approver Approved Through/ Nominee Comments

1. Shri. Pronab Mohanty (DDG –

Auth)

2. Shri. Pankaj Kumar (CEO)

Document Change Approvals

Version No. Revision Date Nature of Change Date Approved

Version 1.0 NA First version (2020) 12-Nov-2020

3 | P a g e

Purpose of this Document

Aadhaar Authentication Application Security Standard includes technical and operational

requirements set by the Unique Identification Authority of India (UIDAI) to protect Aadhaar

number holder data. The standard applies to all entities that perform Aadhaar authentication

and store, process or transmit Aadhaar number holder data. The standard is applicable to web-

based applications, mobile applications and thick client applications leveraging Aadhaar

authentication.

The standard first defines the platform agnostic security requirements across each of the three

platforms and thereafter, the additional security requirements applicable to the individual

platforms. The standard is structured as follows:

Section 1 Introduction to the Aadhaar Authentication Application Security Standard: This

section lists down the domains (goals) defined in the standard.

Section 2 Aadhaar Authentication Application Security Standard – Common Requirements: This

section defines the common minimum-security requirements applicable to the web, mobile and

thick-client applications used for Aadhaar authentication purposes. This section also includes the

minimum-security requirements that are specifically applicable to each of the applications - web,

mobile and thick-client, in addition to the common requirements. The following sub-sections are

defined across each domain(goal):

• Common Requirements – Minimum-security requirements applicable to web, mobile and thick-client applications used for Aadhaar authentication purposes

• Additional Requirements for Web Applications - Minimum-security requirements applicable only to web applications used for Aadhaar authentication purposes

• Additional Requirements for Mobile Applications - Minimum-security requirements applicable only to mobile applications used for Aadhaar authentication purposes

• Additional Requirements for Thick-client Applications - Minimum-security requirements applicable only to thick-client applications used for Aadhaar authentication purposes

Section 3 and subsequent sub-sections expand on the requirements defined in section 2.

Audience for this document

Architects: This document shall be used by application architects to design the authentication

mobile applications.

Developers: This document shall be used by the developers who are involved in developing the

authentication applications.

4 | P a g e

Feedback and Suggestions on the standard

Feedback and Suggestions on the standard is solicited / invited / appreciated. We will try to

address as many relevant feedback / suggestions as possible in the future versions of this

document. It will help in enhancing / refining the standard further and making it more

comprehensive and up to date with recent advancements in the field of information security

and threat landscape.

Any such query / feedback / suggestion, related to content of this standard, may kindly be sent

to us through email to [email protected].

5 | P a g e

Table of Contents

1. Introduction to the Aadhaar Authentication Application Security Standard (AAASS) ...................... 6

2. Aadhaar Authentication Application Security Standard - Requirements ....................................... 8

3. Aadhaar Authentication Application Security Standard – Detailed Requirements .........................18

Goal 1: Protect Aadhaar Holder Data ..........................................................................................18

Goal 2: Architecture, Design and Threat Modelling ......................................................................22

Goal 3: Authentication API compliance and Encryption ................................................................24

Goal 4: Delivery of consent message for Aadhaar authentication within application ........................25

Goal 5: Operator Authentication and Session Management ..........................................................28

Goal 6: Secure Network Communication.....................................................................................29

Goal 7: Aadhaar Authentication Logs ..........................................................................................30

Goal 8: Application Logs ............................................................................................................32

Goal 9: Application Version Control ............................................................................................33

Goal 10: Information Storage and Privacy ...................................................................................34

Goal 11: Application Configuration Management ........................................................................36

Goal 12: Secure Application Development and Management ........................................................38

Goal 13: Cryptography, Key Management and HSM .....................................................................41

Goal 14: Resiliency against Reverse Engineering ..........................................................................42

4. ANNEXURE: Checklist ............................................................................................................44

4.1 Aadhaar Authentication Application Security Standards – Checklist for Web Applications ...........44

4.2 Aadhaar Authentication Application Security Standards – Checklist for Mobile Applications .......48

4.3 Aadhaar Authentication Application Security Standards – Checklist for Thick Client Applications .53

6 | P a g e

1. Introduction to the Aadhaar Authentication Application

Security Standard (AAASS)

Aadhaar Authentication Application Security Standard has been developed by UIDAI to assist developers and

various system integrators and other TSPs (Technical Service Provider) engaged by requesting entities in

developing authentication applications. The standard also provides developers with standard best practices and

testing requirements to build a secure application by leveraging other standards and best practices such as PA-

DSS, OWASP Top 10, OWASP MASC, SANS 25 etc.

At a high level, the standard details out requirements for the following domains:

S. No.

Domain (Goal) Applicability

Goal 1

Protect Aadhaar holder data

Applicable to web, mobile and thick-client applications

Goal 2

Architecture, Design and Threat Modelling

Goal 3

Authentication API compliance and Encryption

Goal 4

Delivery of consent message for Aadhaar authentication within application

Goal 5

Operator Authentication and Session Management

Goal 6

Secure Network Communication

Goal 7

Aadhaar Authentication Logs

Goal 8

Application Logs

Goal 9

Application Version Control

Goal 10

Information Storage and Privacy

Goal 11

Application Configuration Management

Goal 12

Secure Application Development and Management

Goal 13

Cryptography, Key Management and HSM

Goal 14

Resiliency against Reverse Engineering Applicable to only mobile and

thick-client applications

7 | P a g e

Prior to deployment of the application in the production environment, a requesting entity shall ensure

that the application meets all the requirements of the AAASS satisfactorily.

8 | P a g e

2. Aadhaar Authentication Application Security Standard -

Requirements

Minimum-security requirements for web, mobile and thick-client applications used for Aadhaar

authentication purposes across each of the goals defined in section 1 are listed below.

Follow the given hyperlinks in the table to view the requirements in detail.

S. No.

Applicability Requirements Referenced from the Aadhaar Act/

Regulations/ other standard / guideline / best practice

GOAL 1: Protect Aadhaar holder data

G1 Common Requirements

1. Mask Aadhaar number on input

2. Mask Aadhaar number on display

3. Do not send Aadhaar number in the URL in cleartext

4. Ensure Aadhaar number is not auto populated

5. Encrypt transmission of Aadhaar number across open, public networks

6. Perform Aadhaar number validation checks

7. Provide Virtual ID as an alternative input option

8. Wherever possible capture domain specific identifier or ANCS token or Virtual ID at the front-end

1. Industry best practices (banking)

2. PA-DSS1 (Requirement 2 – 2.1) 3. PA-DSS (Requirement 5 -5.2.10),

OWASP ASVS 4.02 (Control 3), Aadhaar (Sharing of information) Regulations 2016, Clause (6) (Point 4)

4. PA-DSS ((Requirement 11 - 11.2), Industry best practices

5. Aadhaar (Sharing of information) Regulations 2016, Clause (6) (Point 4), PA-DSS (Requirement 1)

6. Aadhaar API specifications (version 2.5), Aadhaar Auth regulations Clause (19) b

7. UIDAI circular dated 10 January 2018 – Implementation of Virtual ID, UID token and Limited KYC – Point number 3(1)

8. Requesting Entity Checklist v2.0

Additional Requirements for Web Applications

9. Ensure there is no local storage of Aadhaar Number / PID block

9. Auth Regulations Chapter III Clause 17. (1) (a), (b) and (c)

Additional Requirements for Mobile Applications

10. Ensure there is no local storage of Aadhaar Number / PID block in Shared preference folder


1 Payment Card Industry (PCI) Payment Application Data Security Standard (PA DSS) version 3.2 2 Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS) 4.0

9 | P a g e

Additional Requirements for Thick-client Applications

11. Ensure there is no local storage of Aadhaar Number / PID block in system volatile memory


GOAL 2: Architecture, Design and Threat Modelling


1. Ensure all third-party components used by the application are verified

2. Ensure that security controls are enforced on both the client side and server side

3. Ensure that the high-level architecture is verified

4. Ensure that the security testing is performed as part of the development lifecycle

1. OWASP MASC 0.9.3 2. OWASP MASC 0.9.3 3. OWASP MASC 0.9.3 4. OWASP MASC 0.9.3


No additional requirements


5. Ensure that connecting clients use the current version of the mobile application

6. Ensure that the remote endpoints are verified

5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3


7. Ensure that connecting clients use the current version of the thick client application

8. Ensure thick client application architecture is secure

7. OWASP MASC 0.9.3

GOAL 3: Authentication API compliance and Encryption


1. Refer the latest UIDAI API specifications for implementing API available on UIDAI website

2. Ensure application authentication API is protected using appropriate access control

3. Ensure PID block is encrypted on capture

1. Aadhaar API specifications (Version 2.5)

2. OWASP ASVS 4.0 (Control 13), SANS Top 25

3. Auth Regulations, Chapter II, Clause 7 (2) and (3), Clause 9 (1) and (5)

4. UIDAI circular on use of registered devices.

5. Auth Regulations Chapter II Clause 8 (2)

10 | P a g e

4. Ensure use of Registered Devices for capturing biometrics

5. Ensure latest API specifications is in use

6. Implement OTP verification controls in front-end application

6. PA DSS (Requirement 1 – 1.1.2), Industry best practices (banking)







GOAL 4: Delivery of disclosure of information / consent message for Aadhaar authentication within the application


1. Ensure disclosure of information / consent is provided prior to Aadhaar authentication

2. Implement the functionality to change the text of disclosure of information/consent to local language

3. Ensure disclosure of information/consent checkbox is not ticked by default

4. Ensure provision for sharing disclosure of information/ consent message with differently abled persons is in place

5. Ensure disclosure of information/consent is provided separately each time before carrying out authentication

6. Ensure appropriate consent implementation in case Aadhaar authentication is mandatory by law

Note: Compliance to the disclosure of information / consent requirement also depends on the implementation and not just including the text and controls in the application.

1. Authentication Regulations Chapter II, Clause 6. (1)(2), Aadhaar act section 8



4. Requesting Entity Compliance Checklist V2.0. dated 30.01.2019 - Point number 1(j)

5. Aadhaar act section 8, Authentication Regulations Chapter II, Clause 6. (1)(2)

6. Sharing of Information Regulation, Chapter II, Clause 5. (1b)

11 | P a g e

7. Ensure appropriate consent implementation in case Aadhaar authentication is voluntary by law

7. Sharing of Information Regulation, Chapter II, Clause 5. (1b)







GOAL 5: Operator Authentication and Session Management


1. Ensure operator authentication is performed for accessing the application

2. Implement two factor authentication for the operator login

3. Implement Password hygiene controls

4. Ensure ‘Remember Me’ option is disabled, and login credentials are not stored anywhere

1. UIDAI Information Security Policy - External Ecosystem AUA-KUA version 3.5- Section 2.11 (2)

2. OWASP ASVS 4.0 (Control 2) 3. UIDAI IS Policy version 3.5

section 7, PA DSS (Requirement 3 – 3.1.2), OWASP Secure coding, OWASP ASVS 4.0 (Control 2), SANS Top 25

4. OWASP MASC 0.9.3




5. Ensure authentication is performed at the remote endpoint

6. Ensure that the remote endpoint uses randomly generated access tokens to authenticate

7. Ensure that the remote endpoint terminates the existing session when the user logs out

8. Ensure that the remote endpoint implements an exponential back-off

5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3 7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3 9. OWASP MASC 0.9.3


12 | P a g e

9. Ensure that biometric authentication, if any, is not event-bound

GOAL 6: Secure Network Communication


1. Ensure that data is encrypted on the network using TLS

2. Ensure that the TLS settings are in line with current best practices

3. Ensure that the app verifies the X.509 certificate of the remote endpoint

4. Ensure that application doesn’t rely only on insecure communication channels (email or SMS) for critical operations





5. Ensure that the app either uses its own certificate store, or pins the endpoint certificate

5. OWASP MASC 0.9.3


GOAL 7: Aadhaar Authentication Logs


1. Ensure for each Aadhaar authentication request (auth, e-KYC etc.) audit log is generated with all the mandatory fields

2. Ensure logs are stored online for 2 years and archived for 5 years (even if the application has been decommissioned, requirement for log maintenance prevails)

1. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 18. (1) and Notice for AUA/KUA [F. No.-11020/205/2017-UIDAI (Auth-I)] dated 25/July/2017

2. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 18. (1)





13 | P a g e



GOAL 8: Application Logs


1. Ensure Aadhaar Application logs are maintained

2. Ensure Application facilitates centralized logging

1. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 18. (1)

2. PA DSS (Requirement 4 – 4.1 - 4.5), OWASP ASVS 4.0 (Control 2)







GOAL 9: Application Version Control


1. Ensure a unique application version number is maintained using a version control system

2. Ensure different nomenclature is used for pre-production and production application version

3. Ensure a Change Management Form is maintained for each application level change

1. PA DSS (Requirement 5 -5.3), OWASP ASVS 4.0 (Appendix C)

2. PA DSS (Requirement 5 – 5.3) 3. UIDAI Information Security

Policy - External Ecosystem AUA-KUA version 3.5-, Section 2.14, PA DSS (Requirement 5 – 5.3), OWASP best practices







GOAL 10: Information Storage and Privacy

14 | P a g e


1. Ensure core biometric information is not stored anywhere in the application/system

2. Ensure that e-KYC data is stored in an encrypted manner within the database tables

3. Ensure resident Data (e-KYC and Aadhaar) is not stored on a server connected to the internet

4. Ensure that no sensitive data is written to application logs

5. Ensure that no sensitive data is shared with third parties

6. Ensure that the application does not store any sensitive data in temporary memory

1. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 17. (1) (a), (b) and (c)

2. Authentication) Regulations 2016 Chapter III Regulation number 16. (3), PA DSS (Requirement 2 – 2.3)

3. PA DSS (Requirement 9) 4. OWASP MASC 0.9.3 5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3




7. Ensure that system credential storage facilities are used appropriately

8. Ensure that the keyboard cache is disabled on text inputs

9. Ensure that the clipboard is deactivated on text fields

10. Ensure that no sensitive data is included in backups.

11. Ensure that the app removes sensitive data from views while running in background

12. Ensure that the app does not hold sensitive data in memory longer than necessary

13. Ensure that the app enforces a minimum device-access-security policy

7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3 9. OWASP MASC 0.9.3 10. OWASP MASC 0.9.3 11. OWASP MASC 0.9.3 12. OWASP MASC 0.9.3 13. OWASP MASC 0.9.3



14. OWASP MASC 0.9.3 15. OWASP MASC 0.9.3 16. OWASP MASC 0.9.3

15 | P a g e

15. Ensure that no sensitive data is included in files, registry or computer memory


GOAL 11: Application Configuration Management


1. Ensure the configuration parameters are not hardcoded in the application code

2. Ensure environment variables or DB calls are used to invoke application parameters

3. Ensure license keys are stored in config or properties file

4. Ensure proper mapping between sub-AUAs and their respective sub-AUA code is maintained (if applicable)

1. OWASP ASVS 4.0 (Control 14) 2. OWASP ASVS 4.0 (Control 14),

PA DSS (Requirement 5 – 5.1) 3. OWASP ASVS 4.0 (Control

3,5,9,13,14) 4. Aadhaar Authentication User

Agency Agreement version 4.0 Clause 3.1




5. Ensure that the app is signed and provisioned with valid certificate.

6. Ensure that the app has been built in release mode

7. Ensure that debugging code has been removed

8. Ensure that the error handling logic is verified





9. OWASP MASC 0.9.3 10. OWASP MASC 0.9.3

GOAL 12: Secure Application Development and Management


1. Ensure that the application is tested for at the minimum OWASP Top 10, SANS Top 25 controls before go-live testing. Result of testing should be documented

1. Authentication) Regulations 2016 Chapter III, Regulation number 14. (1) (h) ,19, OWASP Top 10, SANS Top25, PA DSS (Requirement 7 – 7.1-7.3)

2. OWASP Secure coding guidelines

16 | P a g e

2. Ensure OWASP secure coding guidelines are referred to, for code best practices

3. Ensure periodic source code reviews and VAPT assessments are conducted for the application

4. Ensure measures are deployed to prevent tampering of deployed code

5. Ensure applications are developed in a way to prevent common coding vulnerabilities in software development processes

6. Ensure secure development trainings are provided to the developers

7. Ensure an updated application documentation is maintained

3. Authentication) Regulations 2016 Chapter III, Regulation number 14. (1) (h), PA DSS (Requirement 7 – 7.1-7.3)

4. OWASP ASVS 4.0 (Control 1, 10), PA DSS (Requirement 5 -5.1.5)

5. PA DSS (Requirement 5 -5.1.7) 6. PA DSS (Requirement 14 –14.1-

14.3) 7. PA DSS ((Requirement 5 -5.1.5)




8. Ensure that all inputs from external sources are validated

9. Ensure that the app does not export sensitive functionality via custom URL

10. Ensure that JavaScript is disabled in WebViews unless explicitly required

11. Ensure that the object serialization in API is verified



12. Ensure a registration process is built into the application to ensure only authorized personnel can install and use the application

GOAL 13: Cryptography, Key Management and HSM


1. Ensure HSM is provisioned for Key Management

1. Notice for AUA/KUA [F. No.-11020/204/2017-UIDAI (Auth-I)] dated 22/June/2017 Point 4, OWASP ASVS 4.0 (Clause 2)



17 | P a g e


2. Ensure that the app does not rely on symmetric cryptography with hardcoded keys

3. Ensure that the app doesn't re-use the same cryptographic key for multiple purposes

4. Ensure that the app does not use deprecated cryptographic protocols



GOAL 14: Resiliency against Reverse Engineering


No common requirements




1. Ensure that the app implements two or more functionally independent methods of root detection

2. Ensure tamper detection is implemented

3. Ensure SSL pinning is implemented

4. Ensure detection of widely used reverse engineering tools

5. Ensure detection of emulator 6. Ensure detection of

modification of process memory

7. Ensure all executable files and libraries belonging to the app are verified

8. Ensure code obfuscation is implemented

1. OWASP MASC 0.9.3 2. OWASP MASC 0.9.3 3. OWASP MASC 0.9.3 4. OWASP MASC 0.9.3 5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3 7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3






Press ALT + Left Arrow Key to go back

18 | P a g e

3. Aadhaar Authentication Application Security Standard –

Detailed Requirements

Goal 1: Protect Aadhaar Holder Data

Requirement Description

Common Requirements Requirement 1: Mask Aadhaar

number on input

• Application should mask the Aadhaar number/ VID while entering in the input field. Aadhaar number/ VID input field should be treated as a password field with Aadhaar number/ VID getting masked while being inputted.

• If any physical copy/form is collected which has Aadhaar number mentioned

on it, then before storing the hard copies, Aadhaar number should be

redacted. This is in case the law does not permit full storage of Aadhaar

number.

Note: In order to reduce the instances of

incorrect data entry by the operator /

resident, which may be the case due to

masked data display, application can implement functionality to allow users to

see Aadhaar number entered by placing Show/Hide icon within the Aadhaar

number input field.

Requirement 2: Mask Aadhaar

number on display

• Aadhaar number displayed anywhere on the application screen should be

masked by default. The application should not display full Aadhaar number

for any of the user roles.

• In internal systems as well, Aadhaar number shall be displayed only if there

is a legitimate business reason, otherwise the same shall remain masked

completely or only the last 4 digits shall be displayed for legitimate business

reason.


19 | P a g e

• Aadhaar number shall not be printed on any receipt/slip given by the

agency. If there is any business requirement to display/print Aadhaar

number, only the last 4 digits shall be displayed.

What is Masking of Aadhaar Number?

• Masking is done to ensure that the Aadhaar number is redacted / removed

in such a manner that there are no means available to retrieve the complete

12-digit Aadhaar number.

• Mask Aadhaar number when displayed; the first eight digits should be

redacted / removed and last four digits are the maximum number of digits

that you may display.

Masking Convention

Correct Incorrect XXXX-XXXX-1234 1234-XXXX-1234 1234-XX34-XXXX

Requirement 3: Do not send

Aadhaar number in the URL in

cleartext

• While sending out Aadhaar number/ VID from one page to another, ensure that it is transmitted securely and in an encrypted manner. Aadhaar number should never be sent out as a part of URL in get requests.

Get and Post Requests

Requirement 4: Ensure Aadhaar number is not

auto populated

• Aadhaar number/ VID should not be auto populated by the application.

• Aadhaar number/ VID should not be stored in volatile memory or cache.

Incorrect

Correct

GET requests https://www.test.com/test/demo_form.php?aadhaarNo=123412341234

Post requests url = ' https://www.test.com/test/python/demopage.php'

myobj = {'aadhaarNo': '{Encrypted Aadhaar Number}'}


20 | P a g e

Aadhaar Number should not be auto populated

Requirement 5: Encrypt

transmission of Aadhaar number

across open, public networks

• Aadhaar number/ VID when transmitted across open, public networks (internet) should be encrypted using strong cipher suites.

• Use strong cryptography and security protocols such as SSL/TLS, SSH or IPSec to safeguard sensitive Aadhaar holder data during transmission over open, public networks (e.g. Internet, wireless technologies etc.).

• Acceptable: o Encryption algorithms and key lengths as recommended by NIST. o The current recommendations by NIST and standards used by UIDAI

are as follows: ▪ RSA 2048 for asymmetric encryption ▪ AES 256 for symmetric encryption ▪ SHA-256 for hashing

• Not Acceptable / Should not be used (Due to several known vulnerabilities in them):

o Ciphers less than 128 for symmetric and less than 2048 for asymmetric encryption

o Null cipher suites (no encryption) o No anonymous Diffie-Hellman (no authentication) o Weak protocols, e.g. SSLv2 o Weak Hash algorithms - MD5 Hash, SHA-1

• Hash Algorithm: o MD5 - Should not be used. It is weak and there are practical known

attacks for it. o SHA: - SHA-1 disallowed after 2013 for digital signature. SHA-256+

are acceptable.

Requirement 6: Perform Aadhaar

number validation checks

• Application should perform input validation checks at the time of capturing Aadhaar number/ VID to avoid sending junk data to UIDAI.

• Aadhaar number length check o Ensure length of Aadhaar number length is 12 and in case of VID the

length should be 16. o Ensure Aadhaar number/ VID entered is numeric and no alphabets or

special characters are entered. o Ensure Aadhaar number/ VID entered is a valid verhoeff number.


21 | P a g e

Aadhaar number validation checks to identify junk / incorrect data

Requirement 7: Provide Virtual ID as an alternative

input option

• Ensure that there is a provision to input Virtual ID in lieu of Aadhaar number.

• Application screen should have an option to provide Virtual ID in addition to Aadhaar number as input. Similar changes in the backend should be made to handle Virtual ID as input.

Application should provide option to enter Virtual ID

Requirement 8: Wherever

possible capture domain specific

identifier or ANCS token or Virtual ID at the front-

end

• Wherever possible, only the domain specific identifier should be captured at the device end and not the Aadhaar number. For e.g. ― Wherever possible, AUAs should only capture their domain specific identifier (bank a/c no, ration card no, along with family member id, LPG customer account no, etc.)

• On the AUA server, when forming the authentication input XML, retrieve the Aadhaar number from AUA database using domain specific identifier.

• In place of using Aadhaar number to ensure secrecy of the number, it is recommended to use temporary tokens mapped to the Aadhaar number – such as Virtual ID or ANCS token.

Note: Aadhaar Number Capture Service Token or ANCS Token” means an encrypted Aadhaar number generated for an Aadhaar number by the Authority for completion of an authentication transaction. ANCS Token shall be valid for a short period of time as prescribed by the Authority from time to time.

Note: ANCS token and Virtual ID cannot be retained by the entities in their permanent storage systems.

Additional Requirements for Web Applications Requirement 9:

Ensure there is no local / temporary

storage of Aadhaar number

/PID block

• Ensure that Aadhaar number/Virtual ID inputted by the user is not stored in any form in permanent or temporary storage. For OTP based authentication, the same may be stored until the OTP transaction is successful or OTP has expired.

• Ensure that PID block is not stored anywhere within the system.

Additional Requirements for Mobile Applications Requirement 10:


• Ensure that Aadhaar number/Virtual ID inputted by the user is not stored in any form in permanent or temporary storage. For OTP based authentication,


22 | P a g e


/PID block in Shared

preference folder

the same may be stored until the OTP transaction is successful or OTP has expired.


Additional Requirements for Thick-client Applications Requirement 11:



/PID block in system volatile

memory

• Ensure that Aadhaar number/Virtual ID inputted by the user is not stored in any form in permanent or temporary storage. For OTP based authentication, the same may be stored until the OTP transaction is successful or OTP has expired.


Goal 2: Architecture, Design and Threat Modelling


Common Requirements Requirement 1: Ensure all third-

party components used by the application

are verified

• Ensure all third-party components used by the application, such as libraries

and frameworks, are identified, and checked for known vulnerabilities.

• Ensure all third-party components have been assessed (associated risks)

before being used or implemented. Additionally, verify that a process is in

place to ensure that each time a security update for a third-party component

is published, the change is inspected, and the risk is evaluated.

Requirement 2: Ensure that

security controls are enforced on both the client side and server

side

• Ensure security controls such as input validation, authentication, authorization etc. should not only be enforced at client side. These controls should also be checked at the remote endpoint.

Requirement 3: Ensure that the

high-level architecture is

verified

• Verify that a high-level architecture for the application and all connected

remote services has been defined and security has been addressed in the

architecture.

• Verify that data considered sensitive in the context of the application is

clearly identified.

• Verify all app components are defined in terms of the business functions

and/or security functions they provide.

•


23 | P a g e


security testing is performed as part

of the development

lifecycle

• Ensure that security testing is performed as part of the software

development lifecycle and not only after completion of development of the

application.

Additional Requirements for Mobile Applications Requirement 5:

Ensure that connecting clients

use the current version of the

mobile application

• Verify the version of the application which is connecting to the server.

• Only allow the latest version of the application to communicate with the

AUA/KUA server.


remote endpoints are verified

• Ensure that the application verifies the remote endpoint (server) before

establishing a connection with it.


Ensure that connecting clients

use the current version of the

thick client application

• Verify the version of the application which is connecting to the server.

• Only allow the latest version of the application to communicate with the

AUA/KUA server.

Requirement 8: Ensure thick

client application architecture is

secure

• Thick client application follows client-server architecture. They may have two-tier or three-tier architecture.

• In two-tier architecture, the application interacts directly with the database. This is usually seen in legacy applications and is considered insecure. An example of a thick client application can be a JAVA or VB.NET, Visual Basic application that communicates with a database.

• In three-tier architecture, the application interacts with the webserver which in turn interacts with the database.

• Below is the list of vulnerabilities that should be mitigated on thick clients on top of the business logic checks.

Vulnerabilities Thick Client based vulnerabilities

Improper error handling Applicable

SQL Injection Applicable

Cross Site Scripting Not applicable – browser-based vulnerability

Clickjacking attacks Not applicable – browser-based vulnerability


24 | P a g e

Parameter Tampering Applicable

Insecure Storage Applicable

Denial of Service Applicable

Reverse engineering Applicable

Broken access control Applicable

Session management Applicable

Goal 3: Authentication API compliance and Encryption


Common Requirements Requirement 1: Refer the latest

UIDAI API specifications for implementing API

available on UIDAI website

The current API specifications in use are:

• Authentication API Specification - https://uidai.gov.in/images/resource/aadhaar_authentication_api_2_5.pdf

• e-KYC API Specification - https://uidai.gov.in/images/resource/aadhaar_ekyc_api_2_5.pdf

• OTP API Specification - https://uidai.gov.in/images/resource/aadhaar_otp_request_api_2_5.pdf

Requirement 2: Ensure

application authentication

API is protected using appropriate

access control

• To ensure critical API endpoints can only be accessed by authorized

personnel, and applications, access control mechanism must be in place to

access the authentication APIs.

• Implement authentication check at the API gateway to ensure only

authorized user can access the application.

• Implement captcha before each API call.

• Validate Referrer header at the server side.

Requirement 3: Ensure PID block is encrypted on

capture

• PID block data should be encrypted as per the API specifications. In the

current implementation encryption is done with a dynamic session key using

AES-256 symmetric algorithm (AES/GCM/NoPadding). Session key, in turn, is

encrypted with 2048-bit UIDAI public key using asymmetric algorithm

(RSA/ECB/PKCS1Padding).

• For OTP based transaction, PID block encryption should be as per the API

specifications.

• OTP should not travel from client side to server side in plain text.

https://uidai.gov.in/images/resource/aadhaar_authentication_api_2_5.pdf

https://uidai.gov.in/images/resource/aadhaar_ekyc_api_2_5.pdf

https://uidai.gov.in/images/resource/aadhaar_otp_request_api_2_5.pdf


25 | P a g e

Requirement 4: Ensure use of

Registered Devices for capturing

biometrics

• Application should capture the biometric information of the Aadhaar

number holder using certified and registered biometric devices.

• Application should not allow usage of non-registered devices for capturing

biometrics by implementing a technical control to detect if the biometric

device being used is registered on not.

Requirement 5: Ensure latest API

specifications is in use

• The application should use the latest Authentication API, e-KYC API, OTP API,

Tokenization API.

Requirement 6: Implement OTP

verification controls in front-end application

• Restrict OTP resend to a maximum of 3 tires.

• Disable the option to resend OTP for 90 seconds or more.

• In case there is incorrect OTP submission and authentication failure for two

or more times, application should redirect to the first page after showing

appropriate message. Aadhaar number input and consent should be taken

again for the new transaction.

• OTP should be masked while entering.

Goal 4: Delivery of consent message for Aadhaar authentication within

application

Note: Compliance to the disclosure of information / consent requirement also depends on the

implementation and not just including the text and controls in the application.


Common Requirements Requirement 1:

Ensure disclosure of information /

consent is provided prior to

Aadhaar authentication

• Application should ensure that the disclosure of information/consent

message is provided before Aadhaar authentication.

• Disclosure of information/consent message should be given prior to

submission of Aadhaar number in the application.

Requirement 2: Implement the functionality to

change the text of disclosure of

information/cons

• Ensure that the text of disclosure of information/consent is provided to the

user in their local language of choice.


26 | P a g e

ent to local language

Requirement 3: Ensure disclosure

of information/cons

ent checkbox is not ticked by

default

• While implementing the electronic consent, it should be ensured that the consent checkbox is not ticked by default on the application.

Consent checkbox should not be pre-ticked

Requirement 4: Ensure provision

for sharing disclosure of information/

consent message with differently abled persons is

in place

• Ensure appropriate provisions for sharing disclosure of information/consent message with differently abled divyangjans are there in place.

• For example, in case of visually challenged persons, one such provision can be to have an option within the application to speak out consent message displayed on the application screen.

Not Allowed <input type="checkbox" name="Aadhaar Consent" value="Consent" checked> Allowed <input type="checkbox" name="Aadhaar Consent" value="Consent" >


27 | P a g e

Requirement 5: Ensure disclosure

of information/cons

ent is provided separately each

time before carrying out

authentication

• It is mandatory to provide disclosure of information/consent each time

before carrying out authentication. Ensure that the application is taking

consent each time.


appropriate consent

implementation in case Aadhaar authentication is

mandatory by law

• In cases where Aadhaar number is required mandatorily for availing

services/benefits, the same should be mentioned in the disclosure of

information/consent message along with the law/regulation mandating it.


appropriate consent

implementation in case Aadhaar authentication is voluntary by law

• In cases where there are alternatives to submission of Aadhaar number, the same should be displayed on the application screens prominently. Also, the alternatives should be mentioned in the disclosure of information/consent message.

• Consent must be taken from the Aadhaar number holder to demonstrate that the user voluntarily chose Aadhaar authentication over other available alternatives.

Alternatives to Aadhaar displayed in the application


28 | P a g e

Goal 5: Operator Authentication and Session Management


Common Requirements Requirement 1: Ensure operator authentication is

performed for accessing the application

• Application should implement operator authentication using a unique

username and password for each operator.

• Ensure that one concurrent session per user is allowed at a time i.e. parallel

login sessions are not allowed for the operator.

Note: Optionally MAC binding / device binding functionality to restrict one

operator from logging in through multiple devices can also be implemented for

operator assisted applications.

Requirement 2: Implement two

factor authentication for the operator login

• Ensure two factor authentication (2FA) is implemented for operator login. AUA/KUA is advised to use strong second factor like OTP / TOTP etc. for operator login. The OTP / TOTP here is non-Aadhaar based unless mandated by law to leverage Aadhaar based OTP / TOTP authentication for operator login.

• Ensure that second factor of authentication exists at the remote endpoint (server) and the 2FA requirement is consistently enforced.

Two Factor Login

Requirement 3: Implement

Password hygiene controls

• New credentials should be created for each operator.

• Default passwords should be changed on first login.

• Password complexity, session timeout period, account lockout threshold etc.

should be set as per the UIDAI IS policy for AUA/KUAs.

• Passwords should not be hard coded in the source code of the application.

• Automated logon processes should be disabled.

• Access to admin/root password should be with authorized users only.


‘Remember Me’ option is

disabled, and login credentials

are not stored anywhere.

• Ensure that the application does not store user credentials and use the same for future logins.

• Ensure that the application does not allow browsers / mobile device / desktop utilities to store user credentials for future use.


29 | P a g e

Additional Requirements for Mobile Applications and Thick-client Applications Requirement 5:

Ensure authentication is performed at the remote endpoint

• Ensure that all authentication related activities are performed at the remote endpoint (server side).


remote endpoint uses randomly

generated access tokens to

authenticate

• Ensure remote endpoint uses randomly generated access tokens to authenticate client requests without sending the user's credentials.


remote endpoint terminates the existing session when the user

logs out

• Ensure that user session is terminated at server side after a user logs out or closes the application.


remote endpoint implements an

exponential back-off

• Ensure that the remote endpoint implements an exponential back-off, or temporarily locks the user account, when incorrect authentication credentials are submitted excessive number of times.

Requirement 9: Ensure that biometric

authentication, if any, is not event-

bound

• Ensure that biometric authentication, if any, is not event-bound (i.e. using an API that simply returns “true” or “false”). Instead, it is based on unlocking the keychain / keystore.

Goal 6: Secure Network Communication


Common Requirements Requirement 1: Ensure that data is encrypted on

the network using TLS

• Ensure that data is encrypted on the network using TLS. A secure channel should be used consistently throughout the app.

• Application should use TLS/SSL protocols when accessed via public networks


30 | P a g e

o If the application transmits, or facilitates transmission of Aadhaar data over public networks, the authentication application must support use of strong cryptography and security protocols (for example, SSL/TLSIPSEC, SSH, etc.) to safeguard Aadhaar data during transmission over open, public networks.

o Only trusted keys and certificates should be accepted. o The protocol in use should only support secure versions or

configurations. o The encryption strength should be appropriate for the encryption

methodology in use.


TLS settings are in line with current

best practices

• Ensure that TLS settings are in line with current best practices, as long as they are supported by the mobile operating system.

Requirement 3: Ensure that the app verifies the X.509 certificate

of the remote endpoint

• Ensure that the app verifies X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a valid CA should be accepted.

Requirement 4: Ensure that application

doesn’t rely only on insecure

communication channels (email

or SMS) for critical operations

• The application shall not rely on a single insecure communication channel (email or SMS) for critical operations, such as registration and account recovery. Additional channels which can be explored includes:

o Token o Push Notification o QR Code

Additional Requirements for Mobile Applications and Thick-client Applications Requirement 5: Ensure that the

app either uses its own certificate

store, or pins the endpoint certificate

• Ensure that the app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if it signed by a trusted CA.

Goal 7: Aadhaar Authentication Logs



31 | P a g e

Common Requirements Requirement 1: Ensure for each

Aadhaar authentication

request (auth, e-KYC etc.) audit log is generated with all the mandatory

fields

• Aadhaar authentication logs should mandatorily contain –

o Aadhaar reference key3 (Global KUA)

o UID Token (both Global and Local KUA)

o Parameters submitted as part of request XML

o Parameters received (from UIDAI) as part of authentication response

o Record of disclosure of information and consent

• Ensure Aadhaar authentication logs do not contain Aadhaar number.

• Ensure device identifiers are stored in the logs.

• Ensure that date and time stamp for request and response is included in log

entries.

• Aadhaar number/ VID captured during user input should not be stored

anywhere in the system.

Note: Aadhaar number can only be stored in the Aadhaar Data Vault and only those entities which receive complete Aadhaar number from the UIDAI in authentication response can store Aadhaar number (that too in the Aadhaar Data Vault). All other agencies which have not been allowed to store Aadhaar number cannot store Aadhaar number anywhere within their systems.

Requirement 2: Ensure logs are

stored online for 2 years and

archived for 5 years (even if the application has

been decommissioned, requirement for log maintenance

prevails)

• Ensure that Aadhaar authentication logs are maintained online for a period

of 2 years.

• Upon expiry of the 2-year period, the logs shall be archived and stored for a

period of 5 year or the number of years as required by the laws or

regulations governing the entity (whichever is later).

• The logs shall be deleted upon expiry of the aforementioned period unless

required to be retained by a court of law or for pending disputes.

3 For reference key implementation, refer UIDAI circular https://uidai.gov.in/images/resource/Circular_Reference_Key_02082017.pdf


32 | P a g e

Goal 8: Application Logs


Common Requirements Requirement 1: Ensure Aadhaar Application logs are maintained

• The application must log all user access and should be able to link all

activities to individual users (Operators).

• Log shall contain identifier for type of event.

• Ensure date and timestamp for each event is logged.

• Ensure success or failure indication for each transaction is included in log

entries.

• Application must provide automated audit trails to reconstruct the following

events at the minimum:

o All actions taken by any individual with administrative privileges as

assigned in the application.

o Invalid logical access attempts.

o Use of, and changes to the application’s identification and

authentication mechanisms (including but not limited to creation of

new accounts, elevation of privileges, etc.), and all changes,

additions, deletions to application accounts with root or

administrative privileges

o Initialization, stopping, or pausing of the application audit logs.

o Creation and deletion of system-level objects within or by the

application.

o Access to application audit trails managed by or within the

application.


Application facilitates

centralized logging

Examples of this functionality may include, but are not limited to:

• Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.

• Providing functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for prompt, centralized logging.


33 | P a g e

Goal 9: Application Version Control


Common Requirements Requirement 1: Ensure a unique

application version number is maintained using a version control

system

• Production and pre-production environment should be physically and logically separated.

• Code repository tools such as SVN, GIT, SCCS, etc. can be used.

Requirement 2: Ensure different nomenclature is

used for pre-production and

production application

version

• The application developer must document and follow a software-versioning methodology as part of their system development lifecycle (SDLC).

Requirement 3: Ensure a Change

Management Form is

maintained for each application

level change

• Change management form with detailed description of the changes

implemented along with the version control information should be

maintained.

• Change-control procedures must be followed for all application changes.

• Change control procedures must follow the same software development

process that is followed during new releases.

• Maintain documentation of impact of change.

• Document approval of change by appropriate authorized parties.

• Conduct functionality testing to verify that the change does not adversely

impact the security of the system.


34 | P a g e

Goal 10: Information Storage and Privacy



Ensure core biometric

information is not stored anywhere

in the application/syste

m

• PID block and core biometric information as defined in API specifications

should not be stored anywhere.

Requirement 2: Ensure that e-KYC data is stored in

an encrypted manner within the database

tables

• Ensure that the e-KYC data is stored in the databases in encrypted manner.

• Ensure the KYC data is not shared over a public network in plain text.

Requirement 3: Ensure resident Data (e-KYC and Aadhaar) is not

stored on a server connected to the

internet

• Resident data shall not be stored on servers with access to internet.

• Data storage component of the application shall not be on the same server or in the same network zone as the server on which the AUA/KUA application is running.

Requirement 4: Ensure that no

sensitive data is written to

application logs

• Ensure sensitive information such as user credentials, resident information etc. is not written to the application logs.


sensitive data is shared with third

parties

• Ensure that no sensitive data is shared with third parties unless it is a

necessary part of the architecture and is allowed by law.


application does not store any sensitive data

even in temporary

memory

• PID block and core biometric information as defined in API specifications

should not be stored anywhere including any temporary storage such as

application cache / browser cache / application temporary files.

• Storage of core biometric data including the PID block is strictly prohibited.



35 | P a g e


system credential storage facilities

are used appropriately

• Ensure that the system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys.


keyboard cache is disabled on text

inputs

• Ensure the keyboard cache is disabled on text inputs that process sensitive data.


clipboard is deactivated on

text fields

• Ensure the clipboard is deactivated on text fields that may contain sensitive data.


sensitive data is included in backups.

• Ensure that sensitive data such as user credentials, eKYC data etc. is not included in backups.


app removes sensitive data

from views while running in

background

• Ensure that sensitive information is not viewed in the mobile while the application is running in background.


app does not hold sensitive data in memory longer than necessary

• Ensure the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.

Requirement 13: Ensure that the app enforces a

minimum device-access-security

policy

• Ensure the app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.


Ensure that system credential storage facilities

• Ensure that the system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys.


36 | P a g e

are used appropriately


sensitive data is included in files,

registry or computer memory

• Ensure that the application does not write sensitive data in files, registry or computer memory.


app does not hold sensitive data in memory longer than necessary

• Ensure the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.

Goal 11: Application Configuration Management



Ensure the configuration

parameters are not hardcoded in the application

code

• Ensure that application configurations such as database IP, database credentials etc. are not hardcoded.


environment variables or DB calls are used to

invoke application parameters

• Use environment variables or database calls to invoke application parameters.

Requirement 3: Ensure license

keys are stored in config or

properties file

• As a rule of thumb, ensure that no sensitive details such as license key are hardcoded in the application code that is distributed to the public/operators for usage.

Note: Security of license key is one of the most important aspect of developing and maintaining a secure Aadhaar authentication application. Storage of license


37 | P a g e

key in the application code (front-end) or any other system without having proper access control and security measures in place is strictly prohibited.

Requirement 4: Ensure proper

mapping between sub-AUAs and

their respective sub-AUA code is maintained (if

applicable)

• Ensure that mapping of sub-AUA and their code is maintained in the application to ensure proper log trail.

• Ensure that only sub-AUA license key and code is used when catering to sub-AUA requests.

Additional Requirements for Mobile Applications Requirement 5: Ensure that the

app is signed and provisioned with valid certificate.

• Ensure that the application code is signed and provisioned with a valid certificate issued by a CA.

Requirement 6: Ensure that the app has been

built in release mode

• Ensure that app has been built in release mode, with settings that are appropriate for a release build (e.g. non-debuggable).


debugging code has been removed

• Ensure that debugging code has been removed, and the app does not log verbose errors or debugging messages.

Requirement 8: Ensure that the error handling logic is verified

• Ensure that error handling logic in security controls denies access by default.

Additional Requirements for Thick-client Applications Requirement 9: Ensure that the

app is signed and provisioned with valid certificate.

• Ensure that the application code is signed and provisioned with a valid certificate issued by a CA.

Requirement 10: Ensure that the error handling logic is verified

• Ensure that error handling logic in security controls denies access by default.


38 | P a g e

Goal 12: Secure Application Development and Management


Common Requirements Requirement 1: Ensure that the application is

tested for at the minimum OWASP Top 10, SANS Top

25 controls before go-live

testing. Result of testing should be

documented

• Application should be tested against OWASP Top 10, SANS Top 25 controls at

the minimum before go-live testing. Result of testing should be documented.

• Actual Aadhaar data should not be used for testing. Only dummy data

available on UIDAI website shall be used.

• Test data and accounts should be removed before release.

Requirement 2: Ensure OWASP secure coding guidelines are referred to, for

code best practices

• Code changes should be reviewed by individuals other than the originating

code author, and by individuals who are knowledgeable in code-review

techniques and secure coding practices. Code reviews will ensure that the

code is developed according to secure coding guidelines.

• Appropriate corrections should be implemented prior to release.

• Code-review results should be reviewed and approved by management prior

to release.

• Code-review results should be documented with management approvals,

code author, code reviewer, and what corrections were implemented prior

to release.

Requirement 3: Ensure periodic

source code reviews and VAPT assessments are

conducted for the application

• Applications assessment should include, at the minimum: o Identification of new security vulnerabilities using reputable sources for

obtaining security vulnerability information. o Assigning a risk ranking to all identified vulnerabilities, including

vulnerabilities involving any underlying software or systems provided with or required by the application.

o Test applications and updates for the presence of vulnerabilities prior to release.

Requirement 4: Ensure measures are deployed to

prevent tampering of

deployed code

• Implement anti tamper mechanisms such as verifying the download source of application, verifying the application hash etc. to prevent application tampering.

• For web apps, implement checks on the application source code, such as File Integrity Monitoring (FIM) solution etc. to identify any unauthorized changes to the code at server side.

• For Mobile apps, implement features to prevent dynamic analysis of application using tools such as Frida, Xposed etc.


39 | P a g e

• For thick client apps, implement anti-tamper mechanism such as signature verification etc. on the application at client and server side.

• Implement mechanisms to prevent debugging of application code through obfuscation etc.


applications are developed in a way to prevent common coding vulnerabilities in

software development

processes

• At the minimum the application should cover the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.):

o Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws

o Buffer Overflow o Insecure cryptographic storage o Insecure communications o Improper error handling o Cross-site scripting (XSS) o Improper access control such as insecure direct object references,

failure to restrict URL access, and directory traversal) o Cross-site request forgery (CSRF) o Broken authentication and session management

Requirement 6: Ensure secure development trainings are

provided to the developers

• Provide trainings on secure development practices for application

developers, that are applicable to the developer’s job function and

technology used, for example:

o Secure application design.

o Secure coding techniques to avoid common coding vulnerabilities

(for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25,

CERT Secure Coding, etc.).

o Managing sensitive data in memory.

Requirement 7: Ensure an updated

application documentation is

maintained

• Acceptable usage guidelines/ SOPs for applications should be documented and shared with operators.

• Develop a secure SDLC process and document the application development as per the SDLC.

• At the minimum the application documentation must include: o Technical Manual (Functional Requirement Specifications,

Technology Stack). o Software Source Code build process. o Usage Instructions. o Instructions for troubleshooting. o Deployment Diagram. o License specifications of libraries used. o API specifications along with endpoints, sample response, error

codes.



40 | P a g e

Requirement 8: Ensure that all

inputs from external sources

are validated

• Ensure all inputs from external sources and users are validated and, if necessary, they should be sanitized. This includes data received via UI, IPC mechanisms such as intents, custom URLs, and network sources.


app does not export sensitive functionality via

custom URL

• Ensure app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected.

Requirement 10: Ensure that JavaScript is disabled in

WebViews unless explicitly required

• In case the application requires the use of web views, JavaScript must be disabled in the same.

• For cases where JavaScript is needed for implementing application functionality, proper input sanitization must be performed.


object serialization in API is verified

• Ensure object serialization, if any, is implemented using safe serialization APIs.


Ensure a registration

process is built into the

application to ensure only authorized

personnel can install and use the

application

• Implement registration process in application such as product key based registration, account base registration, machine-based registration etc. to ensure that application is installed by authorized personnel only.

• Implement controls to restrict the number of registrations per product key/ account.


41 | P a g e

Goal 13: Cryptography, Key Management and HSM


Common Requirements Requirement 1: Ensure HSM is

provisioned for Key Management

• Use of HSM is a mandatory requirement for storing various keys pertaining to Aadhaar related operations.

• Develop code to make API calls to the HSM device.

• Given below is a code snippet for HSM API call that can be used as reference:

Additional Requirements for Mobile Applications and Thick-client Applications Requirement 2: Ensure that the

app does not rely on symmetric cryptography

with hardcoded keys

• Ensure that the app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.

Requirement 3: Ensure that the app doesn't re-use the same

cryptographic key for multiple

purposes

• Ensure that the application does not use the same key for multiple purposes. Eg: Keys used to encrypt locally stored data shall not be used for any other purpose such as encrypting user credentials etc. in the application.


app does not use deprecated

cryptographic protocols

• Ensure that the app does not use cryptographic protocols or algorithms that are widely considered deprecated for security purposes.


42 | P a g e

Goal 14: Resiliency against Reverse Engineering


Additional Requirements for Mobile Applications Requirement 1: Ensure that the app implements

two or more functionally independent

methods of root detection

• Ensure that app implements two or more functionally independent methods of root detection and responds to the presence of a rooted device either by alerting the user or by terminating the app.

Requirement 2: Ensure tamper

detection is implemented

• Ensure app detects and responds to tampering with executable files and critical data.

Requirement 3: Ensure SSL pinning is

implemented

• Ensure SSL pinning is implemented so that an adversary could not intercept the traffic at application level as well as network level.

Requirement 4: Ensure detection

of widely used reverse

engineering tools

• Ensure that app detects the presence of widely used reverse engineering tools, such as code injection tools, hooking frameworks and debugging servers.

Requirement 5: Ensure detection

of emulator

• Ensure that app detects and responds to being run in an emulator using any method.

Requirement 6: Ensure detection of modification of process memory

• Ensure that app detects and responds to modifications of process memory,

including relocation table patches and injected code.

Requirement 7: Ensure all

executable files and libraries

belonging to the app are verified

• Ensure all executable files and libraries belonging to the app are either

encrypted on the file level and/or ensure that the important code and data

segments inside the executables are encrypted or packed. Trivial static

analysis should not reveal important code or data.

Requirement 8: Ensure code

obfuscation is implemented

• Ensure that code is properly obfuscated and is non-readable.

Additional Requirements for Thick-client Applications Requirement 9: Ensure tamper

• Ensure app detects and responds to tampering with executable files and critical data.


43 | P a g e

detection is implemented

Requirement 10: Ensure all

executable files and libraries

belonging to the app are verified

• Ensure all executable files and libraries belonging to the app are either

encrypted on the file level and/or ensure that the important code and data

segments inside the executables are encrypted or packed. Trivial static

analysis should not reveal important code or data.

Requirement 11: Ensure code

obfuscation is implemented

• Ensure that code is properly obfuscated and is non-readable.


44 | P a g e

4. ANNEXURE: Checklist

4.1 Aadhaar Authentication Application Security Standards – Checklist for Web

Applications

S.No Goals Requirements Compliance (Yes /No) Remarks

1.


Mask Aadhaar number on input








9. Ensure there is no local storage of Aadhaar Number / PID block

10.


Ensure all third-party components used by the application are verified




14.


Refer the latest UIDAI API specifications for implementing API available on UIDAI website




45 | P a g e





20.


Ensure disclosure of information / consent is provided prior to Aadhaar authentication







27.


Ensure operator authentication is performed for accessing the application



30. Ensure ‘Remember Me’ option is disabled, and login credentials are not stored anywhere.

31.


Ensure that data is encrypted on the network using TLS




46 | P a g e



35.


Ensure for each Aadhaar authentication request (auth, e-KYC etc.) audit log is generated with all the mandatory fields


37.

Application Logs

Ensure Aadhaar Application logs are maintained


39.


Ensure a unique application version number is maintained using a version control system



42.


Ensure core biometric information is not stored anywhere in the application/system







47 | P a g e


48.


Ensure the configuration parameters are not hardcoded in the application code




52.

Secure Application Development and Management

Ensure that the application is tested for at the minimum OWASP Top 10, SANS Top 25 controls before go-live testing. Result of testing should be documented







59. Cryptography, Key Management and HSM

Ensure HSM is provisioned for Key Management


48 | P a g e

4.2 Aadhaar Authentication Application Security Standards – Checklist for Mobile

Applications

S.No. Goals Requirements

Compliance (Yes /No)

Remarks

1.










9. Ensure there is no local storage of Aadhaar Number / PID block in Shared preference folder

10.






14. Ensure that connecting clients use the current version of the mobile application

15. Ensure that the remote endpoints are verified

16.








49 | P a g e



Remarks


22.









29.








35. Ensure that the remote endpoint terminates the existing session when the user logs out.




50 | P a g e



Remarks

38.







43.




45.

Application Logs



47.





50.







51 | P a g e



Remarks




57. Ensure that the keyboard cache is disabled on text inputs

58. Ensure that the clipboard is deactivated on text fields

59. Ensure that no sensitive data is included in backups.

60. Ensure that the app removes sensitive data from views while running in background


62. Ensure that the app enforces a minimum device-access-security policy

63.







68. Ensure that the app has been built in release mode

69. Ensure that debugging code has been removed


71. Secure Application Development



52 | P a g e



Remarks

72. and Management

Ensure OWASP secure coding guidelines are referred to, for code best practices






78. Ensure that all inputs from external sources are validated

79. Ensure that the app does not export sensitive functionality via custom URL

80. Ensure that JavaScript is disabled in WebViews unless explicitly required

81. Ensure that the object serialization in API is verified

82.






86.

Resiliency Against Reverse Engineering Requirements

Ensure that the app implements two or more functionally independent methods of root detection


88. Ensure SSL pinning is implemented

89. Ensure detection of widely used reverse engineering tools

90. Ensure detection of emulator


53 | P a g e



Remarks

91. Ensure detection of modification of process memory



4.3 Aadhaar Authentication Application Security Standards – Checklist for Thick Client

Applications

S.No Goals Requirements


Remarks

1.










9. Ensure there is no local storage of Aadhaar Number / PID block in system volatile memory

10.






14. Ensure that connecting clients use the current version of the thick client application

15. Ensure thick client application architecture is secure


54 | P a g e



Remarks

16.








22.









29.








55 | P a g e



Remarks


35. Ensure that the remote endpoint terminates the existing session when the user logs out.



38.







43.




45.

Application Logs



47.






56 | P a g e



Remarks

50.









57. Ensure that no sensitive data is included in files, registry or computer memory


59.








65. Secure Application Development and Management




57 | P a g e



Remarks






72. Ensure a registration process is built into the application to ensure only authorized personnel can install and use the application

73.






77. Resiliency Against Reverse Engineering Requirements

Ensure tamper detection is implemented



Documents

Aadhaar Authentication Application Security Standardaadhaar.jharkhand.gov.in/Aadhaar_Authentication... · 2020. 11. 18. · Aadhaar Authentication Application Security Standard includes