Dr Rakesh Mohan Goyal, a computer industry expert, and an occasional writer for Moneylife who has audited authentication centres of Aadhaar had filed an affidavit in the Supreme Court. Dr Goyal told the apex court that people at enrolment centres were retaining and storing biometric data and the Identification Authority of India (UIDAI) has no way of knowing.
According to the affidavit, biometrics of Indians are available to private entities, can be and are being stored in logs. This is that because of the architecture of Aadhaar, UIDAI has very little control over this, it says.
Dr Goyal also submitted a paper, based on 25 audits, that talks about six ways of hacking. The affidavit says that there is no way of knowing, after an audit, whether the storage is continuing or has stopped.
The computer security expert, who filed the affidavit, says he want bring to the attention of the Supreme Court, “Inherent design faults in the Aadhaar project that severely compromise the safety and security of citizens' biometric data; and to my knowledge and in the course of my audit work I have found that biometrics captured in the Aadhaar authentication process are being stored by entities other than UIDAI and Central Identification Data Repository (CIDR).
“In other words, the biometrics of Indians are available to private entities were bring / can be stored by them in logs, cache, temp variables, etc. The purpose of this affidavit to bring to notice the potential high risk to the biometric information, which is being stored and can be stored or shared, in the Aadhaar authentication eco-system. It is relevant to point out that because of the architecture and applicable processes of the Aadhaar authentication system, even the UIDAI has very little control over this issue, as of today. It is of great concern that the biometric information is being and/or easily can be stored or shared or reused by the third party requesting entities, i.e. the Authentication User Agencies / KYC User Agency (AUAs/KUAs) during the authentication process under the Aadhaar scheme,” Dr Goyal says in the affidavit.
He says, UIDAI and CIDR holds all Aadhaar related data. Aadhaar data repository has two types of consumer data in it. Apart from Aadhaar holder’s data, the CIDR must be storing authentication transaction data, log data, financial data and access control and other master or parameter data. There are two types of Aadhaar holder’s data, one demographic data, including name, address, gender, date of birth, mobile number and email address and other biometric data like photo, fingerprints and iris scan data.
(An image from UIDAI website showing types of Aadhaar data)
As per The Aadhaar (Targeted Delivery of Financial and Other Subsidies, Benefits And Services) Act, 2016 (or say Aadhaar Act) and rules u/s 43A of Information Technology Act 2000 (amended in 2008), biometric information is Sensitive Personal Data and Information (SPDI).
As per section 29 of the Aadhaar act, Core biometric data (fingerprint and iris scan) (a) must not be shared with anyone and (b) used only for generation of Aadhaar number and authentication.
According to the affidavit, in the Aadhaar authentication eco-system, as it exist today, high risk exist that core biometric data is either stored and shared and UIDAI has very little control over it.
Dr Goyal says, “After UIDAI discovered a serious security incident and took action against eSuvidha, eMudra and Axis Bank in February 2017, it issued an order to get all AUAs, KUAs, ASAs and KSAs re-audited by CERT-In empanelled IT Security auditors. My company is one of CERT-In empanelled IT Security auditors. We have audited 25 AUAs and KUAs after that. I personally was involved in 15 of these audits hands-on and was supervising auditor in other 10 audits.”
“This exercise was a great learning exercise and gave me an insight into the security practices followed by AUAs and KUAs, to acquire, use and secure biometric and demographic data. Many of these practices were, or can be, used to store or reuse or share core biometric data. Further, I believe that I have an inclination to identify or pick potential vulnerabilities and mis-use as per the Murphy’s law; in IT systems, management processes and techno-legal processes. With my observations of security practices at AUA and KUA and inclination to identify potential vulnerabilities, I have discussed some potential ways to store or reuse or share core biometric data by AUA and KUAs. This is by no means an exhaustive list as there may exist some better vulnerabilities identifier than me,” Dr Goyal added
He then explained data flow and system flow at UIDAI regarding Aadhaar, including data acquisition, storage and authentication. In data acquisition, the resident register for new Aadhaar number by providing demographic and biometric data or amends both these types of data. In second stage, data acquired by residents is stored in CIDR or UIDAI at its data centres. In last stage, an Aadhaar holder is authenticated for various services. These services may include, services as per the Aadhaar act, that is “Targeted Delivery Of Financial And Other Subsidies, Benefits And Services” or other services such as linking Aadhaar with income tax PAN and/or bank account and/or mobile phone.
Authentication can be either using one time password (OTP) on registered mobile number or using biometric scanning devices to scan core biometric and authenticate the Aadhaar holder.
According to the affidavit submitted by Dr Goyal there are two types of authentication. One where CIDR responses in plan yes or no and second where CIDR provides demographic data to verifier like a bank or telecom company or an intermediatory to populate their database with name, address, gender, date of birth, email and mobile number as provided by UIDAI. The authentication in case of OTP is authentication of registered mobile phone and not of real person.
Dr Goyal admitted that he has no idea of security of CIDR and related infrastructure, except normal vulnerabilities exist in devices, operating system, database, servers and other components of infrastructure.
Existing controls by UIDAI on AUA/KUA security
Currently UIDAI has an AUA Audit Compliance Checklist created on 17 May 2013, against which the security validation or audit is done. It has some mandatory security requirements and some recommended security requirements. The general mandatory controls are seven and mandatory controls for devices are four. These are also defined on UIDAI website as below -
Mandatory Security Requirements
1. Aadhaar number should be never used as a domain specific identifier.
2. In the case of operator assisted devices, operators should be authenticated using mechanisms such as password, Aadhaar authentication, etc.
3. Personal Identity Data (PID) block captured for Aadhaar authentication should be encrypted during capture and should never be sent in the clear over a network.
4. The encrypted PID block should not be stored unless it is for buffered authentication for a short period, currently configured as 24 hours.
5. Biometric and OTP data captured for the purposes of Aadhaar authentication should not be stored on any permanent storage or database.
6. The meta data and the responses should be logged for audit purposes.
7. Network between AUA and ASA should be secure.
Mandatory Security Requirements
1. PID block captured for Aadhaar authentication should be encrypted during capture and should never be sent in the clear over a network.
2. The encrypted PID block should not be stored unless it is for buffered authentication for a short period of time.
3. Biometric and OTP data captured for the purposes of Aadhaar authentication should not be stored on any permanent storage or database.
4. In the case of operator assisted devices, operators should be authenticated using mechanisms such as password, Aadhaar authentication, etc.
In the checklist, there are further eight recommendatory controls, which are not mandatory for on-boarding as AUA. Apart from above controls, eight standards and APIs are defined. Thus, this is 28-point check-list. The whole AUA and KUA IS security is covered using these controls only, the affidavit says.
According to Dr Goyal, the AUA Audit Compliance Checklist appears to be made at least three-four years back. “The properties of pdf file show creation date as 17 May 2013. It appears that the creator(s) of checklist have either no or very limited exposure to AUA security ground realities. Further, considering security challenges encountered and dynamic evolution of security vulnerabilities during last three-four years, the checklist is still same vintage,” he added.
