Aadhaar has been designed as a digital identity platform, which is inclusive, unique and authenticable to participate in any digital transaction. This has transformed service delivery in our country, providing huge convenience to citizens and substantial reduction of leakages. Direct benefit transfer, subscription to various services and authentication at the point of service delivery are some benefits.
The UID project has been aware of privacy and data protection issues since the very beginning and has taken every step, as per the best practices available in the world, to ensure they are not violated. The general law on privacy is beyond the ambit of the UIDAI. With the Aadhaar Act in place, let us discuss the provisions relating to privacy and data protection in the Act.
UIDAI’s strategy document
Unlike many countries, India does not have a law on privacy. The law relating to it has been evolved by the courts through various judicial pronouncements over the years. Interestingly, the former UIDAI chairman, Nandan Nilekani, had written to the PM as early as in May 2010 suggesting a need for the privacy law. The government prepared a draft bill on Right to Privacy but it was not turned into a statute. Since then the law has been in the making.
Despite the absence of a formal legislation, UIDAI seems to have been aware of privacy concerns from the beginning and claims to have incorporated these in the design of Aadhaar. In its strategy document (‘UIDAI Strategy Overview: Creating a Unique Identity Number for Every Resident in India’, 2010), the authority states: “The UIDAI envisions a balance between ‘privacy and purpose’ when it comes to the information it collects on residents. The agencies may store the information of residents they enrol if they are authorised to do so, but they will not have access to the information in the UID database. The UIDAI will answer requests to authenticate identity only through a ‘Yes’ or ‘No’ response.”
The UIDAI recognised the potential risks in the area of privacy and put in place a mechanism to deal with them. Two such risks are:
Security and privacy of resident data: Aadhaar by design ensures security and privacy of residents’ data collected through enrolment process. Access to authentication services are given only to authorised ecosystem partners of UIDAI. Under no scenario, biometric data of residents is shared.
Risk to privacy and security of residents’ demographic and biometric data: UIDAI has deployed robust security infrastructure to prevent any unauthorised dissemination of demographic or biometric data of residents stored in central identities data repository (CIDR). Biometric data is never shared with any entity or individuals.
Thus, privacy and security of resident data seems to have been the focus of the UIDAI’s approach in designing the project. There have been many approaches to data protection and privacy. One of the most accepted approaches, which has become a kind of world standard, is called Privacy by Design (PbD).
PbD is an approach to systems engineering which takes privacy into account throughout the whole engineering process. It is an example of value-sensitive design, i.e., to take human values into account in a well-defined manner throughout the whole process and may have been derived from this.
The concept of PbD is related to the concept of Privacy Enhancing Technologies or PET. This term was used for the first time in the report ‘Privacy-enhancing technologies: the path to anonymity published in 1995’ (Hustinx, 2010). Since 1995, the concept of PET has been fully accepted and become a kind of standard. A number of countries have invested in creating better understanding and promotion of PET. One of the original proponents of PbD, Dr Ann Cavoukian, information & privacy commissioner, Ontario, Canada, has laid down seven foundational principles required to achieve the desired goal.
PbD advances the view that the future of privacy cannot be assured solely by compliance with regulatory frameworks; rather, privacy assurance must ideally become an organisation’s default mode of operation (Cavoukian, 2011).
The seven foundational principles are: proactive not reactive; preventative not remedial; privacy as the default setting; privacy embedded into design; full functionality – positive-sum, not zero-sum; end-to-end security – full lifecycle protection; visibility and transparency – keep it open; and respect for user privacy – keep it user-centric.
Proactive not reactive; preventative not remedial: The PbD approach is characterised by proactive rather than reactive measures. It is not an afterthought. It requires established methods to recognise poor privacy designs, anticipate poor privacy practices and outcomes, and correct any negative impacts, well before they occur in proactive, systematic and innovative ways.
Privacy as the default: This principle is particularly informed by the following fair information practices (FIPs).
(i) Purpose specification: The purpose for which personal information is collected, used, retained and disclosed shall be communicated to the individual (data subject) at or before the time the information is collected.
(ii) Collection limitation: Collection of personal information must be fair, lawful and limited to that which is necessary for the specified purposes.
(iii) Data minimisation: Collection of personally identifiable information should be kept to a strict minimum.
(iv) Use, retention and disclosure limitation: The use, retention and disclosure of personal information shall be limited to the relevant purposes identified to the individual, for which he/she has given consent, except where otherwise required by law. Personal information shall be retained only as long as necessary to fulfil the stated purposes, and then securely destroyed.
Privacy embedded into design: Privacy must be embedded into technologies, operations and information architectures in a holistic, integrative and creative way. A systemic, principled approach to embedding privacy should be adopted − one that relies on accepted standards and frameworks, which are amenable to external reviews and audits.
Wherever possible, detailed privacy impact and risk assessments should be carried out and published, clearly documenting the privacy risks and measures taken to mitigate them, including consideration of alternatives and selection of metrics.
The privacy impacts of the resulting technology, operation or information architecture, and their uses, should be demonstrably minimised, and not easily degraded through use, misconfiguration or error.
Full functionality – positive-sum, not zero-sum: This seeks to accommodate all legitimate interests and objectives in a positive-sum “win-win” manner, not through a dated, zero-sum approach, where unnecessary trade-offs are made. PbD avoids the pretence of false dichotomies, such as privacy vs security, demonstrating that it is possible, and far more desirable, to have both.
End-to-end security – lifecycle protection: PbD having been embedded into the system prior to the first element of information collected, extends securely throughout the entire lifecycle of the data involved – strong security measures are essential to privacy, from start to finish. This ensures that all data are securely retained, and then securely destroyed at the end of the process, in a timely fashion. Thus, PbD ensures cradle to grave, secure lifecycle management of information.
Visibility and transparency: It assures all stakeholders that whatever the business practice or technology involved, it is in fact operating according to the stated promises and objectives, subject to independent verification. This PbD principle tracks well to fair information practices in their entirety, but for auditing purposes, special emphasis may be placed upon the following FIPs: accountability, openness and compliance.
Respect for user privacy: PbD requires architects and operators to keep the interests of the individual uppermost by offering such measures as strong privacy defaults, appropriate notice and empowering user-friendly options. Respect for user privacy is supported by the following FIPs:
(i) Consent: The individual’s free and specific consent is required for the collection, use or disclosure of personal information, except where otherwise permitted by law. Consent may be withdrawn at a later date.
(ii) Accuracy: Personal information shall be as accurate, complete, and up-to-date as is necessary to fulfil the specified purposes.
(iii) Access: Individuals shall be provided access to their personal information and informed of its uses and disclosures.
(iv) Compliance: Organisations must establish complaint and redress mechanisms, and communicate information about them to the public, including how to access the next level of appeal.
Application of PbD in Aadhaar
The second foundational principle ‘privacy as the default’ lays down some basic principles relating to collection and usage of personal information. These relate to privacy of users’ personal data. There are following operating principles here: purpose specification, collection limitation, data minimisation use, retention, and disclosure limitation.
Minimal data collection: You must justify collection of every data element from the perspective of its need and usage. Ideally, you should begin with zero data. Then you should add necessary data element.
In Aadhaar’s case, a demographic data standards and verification procedure (DDSVP) committee, constituted by the UIDAI, recommended that only four aspects of demographic information should be collected. These are name, date of birth, gender and communication address.
On the issue of biometric data, the UIDAI collects photograph and images of both iris and all ten fingerprints. Photograph is certainly an essential data for identity establishment. The biometric data (iris and fingerprints) are also essential for ensuring uniqueness.
It optionally collects mobile number and email ID. This helps in communicating with the resident for any activity.
Thus, we find that there is no information which is unnecessary and unrelated to the purpose of this identity project. The principle of purpose specification is satisfied.
Data use limitation: The UIDAI clarifies in its strategy document that the data collected will only be used for issuance of Aadhaar number and later for providing authentication service. In fact, consent of the resident is taken whether he/she would like to share their demographic data with the bank for opening an account.
Keeping the resident informed and the right to access their own data: This relates to informing the resident about data usage. The strategy document does not specify if the resident will be informed about it at the time of enrolment. However, the resident’s consent is taken relating to data usage.
The Aadhaar Act has the following provisions on keeping the resident informed about data usage and the right to access their own data (Section 3(2)).
Resident consent and information for authentication: While authentication process, defined in the strategy document as also in law, implies that the owner of the data participate in the process of authentication, the Act makes an explicit provision making the entity requesting for authentication responsible for informing the resident about the authentication (Section 8(1,2 & 3)).
Hence, the resident is always informed of the purpose, nature of information to be shared during and the use of information received during authentication. And all these responsibilities are cast upon the entity utilising the authentication facility of UIDAI through law, the violation of which is punishable (Section 40 of the Act).
Random numbers: The second design principle is to issue random numbers with no intelligence. The strategy document states: “Loading intelligence into identity numbers makes them susceptible to fraud and theft. The UID will be a random number.” It was done so with a view to protect privacy and profiling of Aadhaar holders.
Further, Aadhaar is a 12-digit number with the 12th digit being the check digit. With 11 digits, you can construct about 100 billion numbers. Considering that there are 1.3 billion numbers required for India, the system will be using merely 1.3% of the available numbers. As these are randomly distributed over the entire space (of 100 billion possible numbers), it is not possible to even guess a number. It ensures compliance with the principle of data anonymisation.
Data sharing policies: No data download is permitted, search is not allowed on any attribute. For example, you cannot search the database by giving some search criteria like a name or Aadhaar number.
There are only a few ways in which one can interact with Aadhaar database. One of these is authentication. It is a process wherein Aadhaar number, along with other attributes (demographic/biometrics/OTP) is submitted to UIDAI’s CIDR for verification. The CIDR responds with a “yes or no”. No personal identity information is given as part of the response. Only authentication user agencies can submit such requests.
However, data can be shared based on an explicit authorisation from the data owner, i.e., the concerned Aadhaar holder. This process is called electronic-KYC (eKYC).
Biometrics are never to be shared, except in certain situations like national security or a competent court’s orders. The law lays down these processes in a detailed manner.
Legal provisions relating to data sharing: According to Section 29 (2), the identity information, other than core biometric information, collected or created under this Act may be shared only in accordance with the provisions of this Act and in such manner as may be specified by regulations.
The subsection 3 says, No identity information available with a requesting entity shall be:
(a) used for any purpose, other than that specified to the individual at the time of submitting any identity information for authentication; or
(b) disclosed further, except with the prior consent of the individual to whom such information relates.
The Subsection 4 says, No Aadhaar number or core biometric information collected or created under this Act in respect of an Aadhaar number holder shall be published, displayed or posted publicly, except for the purposes as may be specified by regulations.
The Aadhaar Act also has stringent provisions relating to data sharing. Section 3(2)(b) specifies that the resident will be informed at the time of enrolment relating to data sharing: “(b) the nature of recipients with whom the information is intended to be shared during authentication”;
Protection of information: Chapter VI of the Act deals with protection of information. Section 28 casts the responsibility of data protection to the authority. The authority ensures security and confidentiality of identity information and authentication of individual records.
Biometric information is given a special treatment in the Act. Section 30 defines it as “sensitive personal information” within the meaning of the IT Act. As per Section 43A of IT Act, “sensitive personal data or information means such personal information as may be prescribed by the central government in consultation with such professional bodies or associations as it may deem fit.”
And there are stringent provisions for the body entrusted with handling sensitive personal data. If such a body “is negligent in implementing and maintaining reasonable security practices and procedures and thereby causes wrongful loss or wrongful gain to any person, such body corporate shall be liable to pay damages by way of compensation, not exceeding five crore rupees, to the person so affected.” [Section 43A of IT Act 2000]
Exceptions to data sharing provisions: Adequate safeguards have been provided in the Act relating to safety, security and protection of data. However, it does make exception to this general rule in two specific cases listed in Section 33 of the Act, quoted below:
33 (1) “any disclosure of information, including identity information or authentication records, made pursuant to an order of a court not inferior to that of a District Judge”
33 (2) any disclosure of information, including identity information or authentication records, made in the interest of national security in pursuance of a direction of an officer not below the rank of joint secretary to the government of India specially authorised in this behalf by an order of the central government.
Even within these exceptions, safeguards are provided relating to review of cases by a high-powered oversight committee and limiting the duration of this sharing.
Federated data model: Besides minimal data, the UIDAI does not keep any data except the logs of authentication done by a person. It only knows the date/time and the agency through which authentication was done, and not the purpose. Thus, the transaction details remain with the concerned agency, not the UIDAI. This is the best model of keeping data where each data owner has the responsibility of data confidentiality and security. This principle is articulated in Section 32(3) of the Act, which ensures no aggregation of information about an individual.
Data protection technologies: Aadhaar enrolment is done by the UIDAI registrars through enrolment agencies, which are private. This could pose serious data breach. This has been eliminated by ensuring that enrolment is done through standardised software and it is encrypted at the time of enrolment itself through an encryption key as strong as 2048 bits. Thereafter, the data is kept encrypted all the time – during transit and at the CIDR. It is momentarily opened for reading during processing. This has ensured not even a single case of data breach from the UID system. Even if the enrolment machine is stolen, the data cannot be misused as it is encrypted. These practices satisfy end-to-end security and lifecycle protection of the resident data.
Publication of Aadhaar number
Though Aadhaar numbers are random, section 29(4) of the Act prohibits its publication except for the purposes specified by regulations. The regulations also reiterate this provision and provide that no entity shall make public any database or record containing the Aadhaar numbers unless they have been “redacted or blacked out through appropriate means, both in print and electronic form”.
The purpose of these restrictions is that while Aadhaar numbers themselves are not confidential, their publication in various public records will make it easy to collate information about persons. Collation of data, as explained before, has become relatively easy in the digital world even otherwise.
The recent controversy regarding certain websites publishing Aadhaar numbers and bank account details of beneficiaries of various government programmes seems to have come in conflict with the prohibition of Section 29(4). This publication has been done in compliance with the RTI Act which makes it mandatory to publish the details of beneficiaries of various subsidy programmes being executed by every public authority. Hence prima-facie, the provisions of RTI Act and Aadhaar Act seem to be in conflict. While RTI Act mandates transparency, the Aadhaar Act prohibits publication of Aadhaar numbers. The best way to resolve this is to partially mask the Aadhaar numbers on websites. This will be the best balance between transparency of public records and privacy of individuals.
Sharma is the chairman of TRAI. The views expressed are personal.