Aadhaar. Security Policy & Framework for UIDAI Authentication. Version 1.0. Unique Identification Authority of India (UIDAI)

Transcription

1 Aadhaar Security Policy & Framework for UIDAI Authentication Version 1.0 Unique Identification Authority of India (UIDAI)

2 Table of Contents ACRONYMS AND TERMS INTRODUCTION SECURITY CONSIDERATION AUAS, SUB-AUAS, AND DEVICES Policies for AUAs and Sub-AUAs Authentication Devices Policies for Authentication Devices: ASAS (NETWORK & TRANSMISSION) Policies for ASA APPENDIX A: SECURITY POLICY SPECIFICATIONS & STANDARDS FOR REFERENCE UIDAI, 2011 Page 2 of 12

3 Acronyms and Terms UIDAI CIDR PID AUA ASA OTP DOS/DDOS NIPS NIDPS DMZ SSL VPN Unique Identification Authority of India Central Identities Data Repository Personal Identity Data Authentication User Agency Authentication Service Agency One Time Password / PIN Denial of Service / Distributed Denial of Service Network Intrusion Prevention System Network Intrusion Detection and Prevention System De-Militarized Zone Secure Socket layer Virtual Private Network UIDAI, 2011 Page 3 of 12

4 1. Introduction Aadhaar Authentication is the process wherein, Aadhaar number along with the Aadhaar holder s personal identity data is submitted to the Central Identities Data Repository (CIDR) for matching, following which the CIDR verifies the correctness thereof on the basis of the match with the Aadhaar holder s identity information available with it. An Aadhaar holder s Personal Identity Data (henceforth referred to as PID) includes his or her demographic details, one-time password (OTP with a limited validity period) sent to the Aadhaar holder s cell phone (stored in the CIDR) and the Aadhaar holder s biometric information (fingerprint and iris scan). UIDAI, in its Aadhaar Authentication Framework document has listed the various authentication types that it offers. For each service that they wish to enable by Aadhaar authentication, user entities choose an authentication type depending on their business requirements. The PID collected by the user entity for authentication is determined by the authentication type chosen. This document addresses the security considerations for the Aadhaar based Authentication and specifies the standards, policies and specifications for various stakeholders in the Aadhaar ecosystem. These stakeholders include the AUAs, Sub- AUAs and Devices and ASAs. For further details on stakeholders and the Aadhaar Authentication ecosystem, please refer the Operating Model document. For details on various types of Authentication offered by UIDAI, please refer the Aadhaar Authentication Framework. UIDAI, 2011 Page 4 of 12

5 2. Security Consideration Aadhaar authentication, as envisaged, is expected to become a national online identity service which is used across various domains and applications on a day to day basis. Any online service will come under various attacks including organized large scale attacks. This means that the importance of this service being secured and available is utmost critical. At a high level, security objectives and key strategies can be summarized as below: 1. Securing resident data that is captured during authentication Aadhaar authentication requires resident data such as demographics and biometrics to be captured and packaged to be sent to CIDR for matching. It is very important that the data captured on the front end devices and applications be secured before transmitting over the network. End to end encryption of personal identity data (PID block) is necessary to ensure that data is not read, stored, or tampered with for malicious purposes. 2. Securing end to end network - Securing network at multiple levels between the front end authentication points to CIDR is necessary to ensure protection against network attacks which result in denial of service (DoS). It is also important to ensure high availability and redundancy even if some parts of network are compromised or unavailable. AUAs and their partners (sub-auas, application providers, etc.) must put appropriate network security in place to ensure their systems are protected from attack. It is hence recommended that standard network practices such as usage of encrypted channel, usage of digital certificates, IP filtering, authentication of systems and devices, network protection through firewalls and NIPS, auditing, etc. are put in place. 3. Securing CIDR- An online service such as Aadhaar authentication will come under direct network attack from both denial of service (DoS) and data theft perspective. It is extremely important that authentication service be fully protected from external unauthorized systems. CIDR must ensure multiple levels of network security through creation of DMZ, application zone, and data zones and protecting all the zones using multiple firewalls, network intrusion prevention systems, and strong access control and audit schemes. If authentication service is exposed over a public network such as Internet to partners, it is expected to come under DoS/DDoS (Distributed DoS) attacks even if CIDR is internally protected. Since many applications and services in the country will heavily depend on Aadhaar authentication to be available, it is strategically important to not expose Aadhaar authentication over any public network (such as Internet) and not create single point of attack that can potentially affect many services. It is hence critical to expand the secure zone beyond CIDR and allow authentication service to be exposed through multiple network end points. Creation of ASA as a network service provider and exposing authentication service ONLY through secure private connections using leased UIDAI, 2011 Page 5 of 12

6 lines is strategic to ensure multiple end points always exist to provide authentication service in a secure and always available fashion. Following diagram summarizes the security layers across the system: Figure: Security layers for Aadhaar Authentication This framework envisages considering security risks related to Aadhaar authentication at various stakeholder levels. Mitigation strategies for probable vulnerabilities have been identified and these mitigation strategies lead to the formulation of a security policy for the Aadhaar systems. 2.1 AUAs, Sub-AUAs, and Devices As UIDAI starts issuing Aadhaar numbers, the AUAs would need to scale. The key threats to the AUA are mentioned below along with the mitigation mechanism. AUA is responsible for ensuring security of authentication data that come through them. This includes security at the device level, Sub-AUA level, within AUA network, and AUA to ASA network. AUAs need to ensure Sub-AUAs take adequate measures when bringing them on-board. In order to ensure security of data captured for authentication, there is a requirement to establish a trust mechanism between devices and sub-auas under AUA and between UIDAI, 2011 Page 6 of 12

7 AUA and ASA. Appropriate security measures such as device registration/authentication, Sub-AUA registration/authentication, operator registration/authentication in the case of assisted applications, data and transaction audits, security of network from device to AUA and then AUA to ASA, etc. need to be addressed. Standard security practices may be used to address the above Policies for AUAs and Sub-AUAs S.No Security Policy / Recommendatory For better decoupling and independent evolution of various systems, it is necessary that Aadhaar number be never used as a domain specific identifier. In addition, domain specific identifiers need to be revoked and/or re-issued and hence usage of Aadhaar number as the identifier does not work since Aadhaar number is permanent lifetime number. For e.g., instead of using Aadhaar number as bank customer id or license number or student id, etc., always have a local, domain specific identifier and have the mapping in the backend database. It is recommended to deploy digitally signed applications on the devices with some AUA specific mechanism to identify trusted devices and applications. For device authentication, digital certificate or other mechanisms may be used. In the case of assisted devices and applications where operators need to mandatorily perform application functions (not a self-service application), operators should be authenticated using some authentication scheme such as password, Aadhaar authentication, smart card based authentication, etc. PID block captured for Aadhaar authentication must be encrypted during capture and should never be sent in the clear over a network. The encrypted PID block should not be stored unless it is for buffered authentication for a short period of time and after transmission, it should be deleted. Biometric and OTP data captured for the purposes of Aadhaar authentication should not be stored on any permanent storage or database. UIDAI, 2011 Page 7 of 12

8 7 The meta data and the responses shall be stored for audit purposes for over a period of time (minimum 6 months) It is mandatory that network between AUA and ASA be secure. It is strongly recommended to have leased lines or similar secure private lines between ASA and AUA. If a public network is used, a secure channel such as SSL should be used. All AUAs should follow standards such as ISO to maintain Information security. AUAs and their partners who participate in conducting Aadhaar authentication should ensure compliance to prevailing laws such as IT Act. Software to prevent malware/virus attacks may be put in place and anti-virus software installed to protect against viruses. Additional networks security controls and end point authentication schemes may be put in place. It is recommended that some periodic standard certification and audit process be established for applications, devices, and overall networks across the ecosystem and also to ensure the compliance to standard security policy and procedure. It is highly recommended that the AUA shall deploy as part of its systems, a Fraud Analytics module that is capable of analysing authentication related transactions to identify fraud cases and patterns Note: In case of Sub-AUAs providing the service and the AUA becoming an aggregator, the AUA is responsible for ensuring that the Sub-AUA follows the above policies / recommendations. 2.2 Authentication Devices Authentication devices are the first line of defense into the UIDAI system. Various authentication devices are mobile, PoS locations, computers through internet etc Policies for Authentication Devices: S.No Security Policy / Recommendatory 1 Wherever possible, only the domain specific identifier should be captured at the device end and not the Aadhaar number. For e.g., UIDAI, 2011 Page 8 of 12

9 a) 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.) b) On the AUA server, when forming the authentication input XML, retrieve the Aadhaar number from AUA database using domain specific identifier 2 3 PID block captured for Aadhaar authentication must be encrypted during capture and should never be sent in the clear over a network. The encrypted PID block should not be stored unless it is for buffered authentication for a short period of time and after transmission, it should be deleted. Biometric and OTP data captured for the purposes of Aadhaar authentication should not be stored on any permanent storage or database. 4 A trusted environment must be created at the device side In the case of assisted devices and applications where operators need to mandatorily perform application functions (not a self-service application), operators should be authenticated using some authentication scheme such as password, Aadhaar authentication, smart card based authentication, etc.. It is recommended that some periodic standard certification and audit process be established for applications, devices, and overall networks across the ecosystem and also to ensure the compliance to standard security policy and procedure. Additional factors may be used to strengthen authentication of operators, devices, and residents wherever needed. 8 In terms of data storage, authentication devices must comply with all applicable laws and regulations of the country like IT Act 2.3 ASAs (Network & Transmission) As described earlier, if authentication service is exposed over a public network such as Internet to partners, it is expected to come under DoS/DDoS (Distributed DoS) attacks even if CIDR is internally protected. Since many applications and services in the country will heavily depend on Aadhaar authentication to be available, it is strategically UIDAI, 2011 Page 9 of 12

10 important to not expose Aadhaar authentication over any public network (such as Internet) and not create single point of attack that can potentially affect many services. It is hence critical to expand the secure zone beyond CIDR and allow authentication service to be exposed through multiple network end points. Creation of ASA as a network service provider and exposing authentication service ONLY through secure private connections using leased lines is strategic to ensure multiple end points always exist to provide authentication service in a secure and always available fashion. Since ASA is a network provider, it needs to address network security aspects, DOS/DDOS attacks, filter out invalid requests and invalid AUAs. Network transmission is important to secure the data during the transmission. Even though the data will be encrypted it is important to secure the communication between various devices Policies for ASA S.No Security Policy / Recommendatory 1 ASA shall connect to the CIDR only through a leased line Software to prevent malware/virus attacks may be put in place and anti-virus software installed to protect against viruses. Additional networks security controls and end point authentication schemes may be put in place. The Meta data and the responses shall be stored for audit purposes for over a period of time (minimum 6 months). Encrypted PID block and license keys, that came as part of authentication should never be stored anywhere in its system. It is mandatory that network between AUA and ASA be secure. It is strongly recommended to have leased lines or similar secure private lines between ASA and AUA. If a public network is used, a secure channel such as SSL should be used. All ASAs should follow standards such as ISO to maintain Information and network security. ASAs and their partners who participate in conducting Aadhaar authentication should ensure compliance to prevailing laws such as IT Act. UIDAI, 2011 Page 10 of 12

11 Appendix A: Security Policy Specifications & Standards for Reference The standard policies are applicable to AUA, ASA& CIDR ISO Standard Security Controls ISO/IEC ISO/IEC ISO/IEC ISO/IEC Information security management system Management responsibility Internal ISMS audits Management review of the ISMS ISMS improvements Risk Assessment and Treatment Security Policy Organization of Information Security Asset Management Human Resources Security Physical Security Communications and Ops Management Access Control Information Systems Acquisition, Development, Maintenance Information Security Incident management Business Continuity Compliance Defining ISMS scope, boundaries and ISMS policy Conducting information security requirements analysis Conducting risk assessment and planning risk treatment Design the ISMS Information security measurement overview Management responsibilities Measures and measurement development Measurement operation Data analysis and measurement results reporting Information Security Measurement Program evaluation and improvement UIDAI, 2011 Page 11 of 12

12 ISO/IEC ISO/IEC FIPS PUB Establish Context Risk Assessment Develop Risk Treatment Plan Risk Acceptance Implement Risk Treatment Plan Monitor and Review Risks Security management Guidelines Asset Management Guidelines Security Requirements for Cryptographic Modules UIDAI, 2011 Page 12 of 12