Tuesday, August 1, 2017

The Aadhaar / Privacy case in SC.

The SC is currently considering cases pertaining to Privacy issues surrounding Aadhaar. A few aspects that are relevant to this discussion, have not been brought up prominently so far:

1) Many countries have citizen databases, which include confidential information about citizens. Aadhaar is probably the ONLY example in the world where the Govt actually GIVES OUT information in its database to private parties. (I have not been able to find any other example of a country where the Govt shares information in its database with private entities). This is quite remarkable. Perhaps the Privacy arguments need to focus around whether the Govt can give out citizen data, instead of focusing on whether Govt can collect citizen data.

Some may point out (correctly) that data is given out only after user consent. However, we know that in most cases citizens barely read the consent fine print. Secondly, it is always possible to word the consent in a manner that is deliberately vague, and enables usage of the same data for other purposes.

Perhaps there is a reason why no other country actually GIVES OUT data from citizen databases.

2) The early implementations at UIDAI required the individual to furnish his/her information to the receiving entity, and the receiving entity could only verify that information with a YES / NO response from UIDAI. It was up to the individual to decide what pieces of personal information s/he wanted to share with a particular receiving entity. Today, a receiving entity can fetch ALL pieces of client information in the UIDAI database (except bio-metrics).

3) Collection of bio-metrics is being "normalized". Under the guise of eKYC, so many organizations have begun asking for bio-metrics, that we no longer find it unusual. Recently, there was news that air-travelers would be allowed to fly only after they had authenticated themselves at the airports with their fingerprints. It would be interesting to see how people react when this actually happens.

Sharing your bio-metrics is like sharing your password - except, this is a "password" that you can never change even if its compromised.

A recent news said that almost 93 cr (i.e. 930 million) people had done bio-metric eKYC during July 17, and presented this as a 'proof' that residents were OK with sharing their bio-metrics. The fact is that in most cases, residents are denied service if they decline. A poor person agreeing to provide bio-metrics to get his PDS ration hardly constitutes 'proof'.

4) A citizen has no way to easily ascertain whether a particular device recording his fingerprints is compliant with UIDAI guidelines. Because of 3) above, it is easy for fraudulent entities to trick people into giving their fingerprints on non-UIDAI devices. While Govt bears no direct responsibility for such fraudulent acts, surely its the Govt that is responsible for 3) above.

The Govt may want to consider reverting back to its earlier YES/NO verification system instead of sharing UIDAI data. It may also want to define the circumstances / purposes for which biometrics of citizens can be captured.

Tuesday, June 6, 2017

eKYC, KUA - Latest UIDAI circular specifies fees, etc.

UIDAI has last week (on May 31 2017) published a circular for AUA/ KUA agreements.

Salient points in this circular are the requirements that an agency will need to provide a Bank Guarantee of Rs 25 Lakhs and a license fee of Rs 20 Lakhs (for a 2 year license) to become a KUA. The intention behind this exercise seems to be to weed out any spurious agencies acting as KUAs, and ensure that those seeking to become KUA have financial viability and a genuine business need to obtain eKYC data.

This is certainly a welcome step by UIDAI to impose some sort of financial filters on who can become a KUA.

Recently, we have heard some KUAs offering third-parties the ability to obtain eKYC data by making them sub-KUAs. Perhaps UIDAI would come up with regulations governing data sharing by KUAs and liabilities in this regard.

Friday, May 26, 2017

eSanad should become eSa-NAD

Recently the HRD ministry along with NIC launched a portal for online verification of educational documents. The initiative is titled eSanad, and CBSE has already joined in.

Read more here:



The name "eSanad" could be a coincidence but there is no reason why this should not become eSa-NAD. I am of course referring to NAD (National Academic Depository), which is intended to store the educational records of all students. A few thoughts:

1) Government entities have demonstrated the ability to host and manage large amounts of personal confidential information (UIDAI is an example). There is no reason to believe that a Govt entity wont do a good job of managing an Academic Depository (for one, the data will be much lesser, and lot less sensitive).

2) The Govt (HRD / IT Ministries) could frame rules requiring all Depositories under NAD to share / backup the data they gather with eSanad. This will ensure that verifiers have a single location from where this data can be legitimately accessed, rather than having to register with multiple Depositories.

3) CBSE had earlier tried storing their records with the Depositories (NSDL / CDSL). They have now chosen to go with eSanad - a Government initiative hosted by NIC.

4) To reiterate the point made in an earlier post on the topic of NAD, the eSanad authority should publish APIs (just as UIDAI has done) to enable developers to build much needed applications for document verification.

eSanad will hopefully lead to faster realization of an Academic Depository, and put an end to the menace of fake educational credentials.

Friday, May 19, 2017

More on eKYC - an obvious, direct verification mechanism

The earlier post raises an important question: Is there an easier way to perform eKYC without becoming a KUA? 

The answer to that question is thankfully a "YES". But before we get to that, let us ask the question,  What exactly is eKYC?

I find it is useful to view the  UIDAI database as comprising the following groups of information:

1) The Aadhaar number (a unique number for every user)
2) Personal Information of the holder - such as full name, address, gender, date of birth, etc.
3) Biometric Information of the holder - such as Finger-prints, Iris scan, Photograph, etc.
4) Ownership Information of the holder such as Email Address, Phone number, etc.

Performing an eKYC involves ascertaining the following two separate facts, subject to consent of the concerned individual:

A) Ascertaining that the Personal Information & Ownership Information being presented by the holder of an Aadhaar number matches the Personal Information & Ownership Information stored in the UIDAI database against that Aadhaar number.
This is achieved by obtaining the Personal and Ownership Information from UIDAI in an authenticated manner.

B) Ascertaining that the individual presenting the Aadhaar number is who he / she claims to be, i.e., the genuine holder of that Aadhaar number.
This can be achieved in one of two ways. The Biometric-way relies on the assumption that if the individual is able to present biometric (fingerprint / iris) information that matches the Biometric Information stored in the UIDAI database, the individual is who he/she claims to be. The OTP-way relies on the assumption that if the individual can demonstrate ownership of the listed Phone number and Email Address (2 Factor Authentication), the individual is who he/she claims to be.

In the KUA approach, usually the biometric information of the individual is captured and sent to UIDAI along with the presented Aadhaar number. In return UIDAI sends back the Personal Information stored its database against this Aadhaar number.

This KUA approach helps ascertain both A)  and B) above. A) is ascertained because information is provided by UIDAI directly from its own database and B) is ascertained because the individual's biometric is matched with that in the UIDAI database.

Consent is obtained via acceptance of "terms of service", as well as the assumption that the person willingly provided his biometrics.

Following the KUA approach imposes significant contractual obligations, including IT maintenance and audit costs. Thankfully, there also exists an easier way to ascertain A) and B), while ensuring individual consent.

This alternative method is the direct electronic-equivalent of an individual submitting his/her own self-attested paper-based identification documents - something we have been doing for decades for KYC. It requires an individual to simply submit his self-attested eAadhaar document.

The Personal Information of the individual is present in the eAadhaar document that can be freely downloaded from the UIDAI website by any individual. This eAadhaar document is digitally signed by UIDAI. The Personal Information contained in this digitally signed document is therefore authentic, and satisfies the requirement of A) above.

What remains is to be ascertained is B), i.e., that the individual concerned is the genuine owner of that particular Aadhaar number. This can be done by getting the individual to self-attest (digitally sign) the eAadhaar document being submitted. The signature process outlined by UIDAI implicitly ascertains that the person signing is the genuine owner of that Aadhaar number. Further, the receiver can do additional verification by verifying the photograph on the eAadhaar document. Consent is ensured by making it a part of the self-attestation process.

In this alternative mechanism of eKYC, the UIDAI-signed eAadhaar document (including photo) is submitted by the individual aadhaar-holder directly to the recipient. It therefore represents a clear & direct method to perform eKYC. There is no need to go through AUA / KUA approval processes, and one can get started immediately.

Needless to say, care must be taken to securely maintain all eAadhaar documents submitted by users.

Tuesday, May 9, 2017

Sharing eKYC Data - NOT to be done!

UIDAI has on several occasions reiterated the need for eKYC data to be kept confidential. Our own reading is that eKYC data should never be shared between two separate corporate entities, no matter what the relationship between them.

When sensitive data is 'shared' between two entities, it is theoretically no longer secure. This is because each of the two entities can now claim that any data-leakage happened from the other entity.(i.e., It provides each of them an avenue to repudiate any possible data leakage).

Any entity, large or small that wants eKYC data of residents should therefore obtain it from UIDAI directly, submit itself to the rules and regulations of UIDAI, and maintain all data securely. (This seems to be the view of several large companies as well - which encourage entities to directly work with UIDAI rather than go via them.)

Here is a blog link that makes for an interesting read & has some more relevant information on the topic:


Saturday, February 11, 2017

Making NAD successful

The National Academic Depository Bill requires all educational institutions in India to store their student credentials with SEBI approved depositories (presently limited to NSDL and CDSL). This Bill came about in response to the menace of fake degrees and certificates being presented in order to secure employment / admissions by unscrupulous entities. The Bill seeks to create central repositories where potential employers can verify the authenticity of candidate's educational credentials. This is a laudatory objective, given how rampant the problem of fake credentials and certificates is, in India.

The Govt of India is keen to get this rolled out quickly (see here and here), and the HRD minister seems keen as well.

Some observations:

1) Implementing the NAD is a massive Operational Challenge. Unless an eco-system is put in place, its adoption / implementation is unlikely to happen within a reasonable frame of time. While the depositories are large organizations and they have the backing of the law, it is unrealistic to expect them to have the man-power or the reach to connect with and bring on-board every single educational institution in the country.

2) Most of the initiatives under Digital India have focused on creating 'eco-systems' rather than a single entity becoming responsible for entire implementation. Probably the best example is the UIDAI, which has published Aadhaar 'APIs' or Application Programming Interfaces, that allow third parties to build applications and reach out to end-users. This is the single most important factor in the rapid adoption and success of Aadhaar based programs, and credit is due to the visionary leadership of UIDAI. If UIDAI had taken upon itself the responsibility of building every single application and attending to every single customer, it's unlikely the Aadhaar program would have been as successful as it has been. Another excellent example is the UPI interface, which will allow parties to build payment related applications for specific customer verticals / use-cases.

3) Educational Institutions are likely to require training / hand-holding in the adoption stages as well as on an on-going basis if they are to participate in the NAD. Educational credentials are generated semi-annually (at least), so in addition to initial on-boarding, educational institutions will need to process educational credentials for NAD at least two times annually. A large number of service providers in the education space already work with educational institutions all over India. (Truecopy Credentials is one of them). The Depositories should probably consider leveraging this existing eco-system to quickly enhance the adoption of NAD. Would it not be a win-win for all parties? (Depositories quickly build up their database, Educational Institutions get the on-premise service they need, and service providers earn a business - thereby providing more employment).

To summarize, the Depositories should consider exclusive focus on building out the backend technology and an API (Just like UIDAI). They should publish this API (can be of "paid-subscription" variety) and then train & qualify service providers to work with educational institutions. These service providers would effectively become stake-holders in growth and propagation of the system. With such an ecosystem in place, there is a good chance that most educational institutions in India would become part of the NAD within 2 years. 

Tuesday, February 7, 2017

Issues with verifying legally valid Digital Signatures in India

When PDF documents with valid Indian Digital Signatures are opened in Acrobat (Adobe) PDF readers, some users may see errors (the digital signatures don't get automatically verified).

Some Acrobat (Adobe) PDF readers need to be configured to be able to validate Indian Digital Signatures.

Detailed explanations of a couple of common issues & how-to resolve them are below:



Thursday, February 2, 2017

More on eSignature verification in Adobe Readers

This post continues an earlier post on Validation of Indian Digital Signatures in the Acrobat PDF reader.

In an earlier post, we discussed about including the Root certificate of Govt of India as a Trusted Certificate. In this post we will talk about another item dealing with Digital Signatures in India.

Aadhaar-based eSignatures are created using a one-time Digital Signing Certificate issued by the competent issuing authority under Govt of India. Not only is this Digital Signing Certificate for one-time use, but its signing validity is restricted to 30 minutes. This means that the document has to be signed within 30 minutes of the issuance of this certificate. (NOTE: Once signed, the signature is valid for ever. Only the signing process has to be completed within 30 mins).

For applications where Aadhaar-based signatures are used, the above works very well. The signed documents when opened in Adobe PDF readers or Acrobat DC will see the usual blue band at the top with a Green tick that says that the signature is valid.


Some users have recently reported that when they open an Aadhaar eSigned file, they do not see the green tick, but a yellow icon as below...

Question: Why does the signature validate correctly in certain readers, and not in others?

To understand this, we dig a bit deeper and find that the Signature doesnt verify because Adobe Reader does not have access to the CRL files for the corresponding certificates. (CRL = Certification Revocation Lists).

Clicking on the "Check revocation" button does not seem to help.

The reason for this is that Adobe Reader does not access the CRLs if the time on the user's computer is outside the Signing Interval. (This is particularly cumbersome for Aadhaar-type certificates whose signing interval is limited to only 30 mins!)

How then do you get a Signature Valid message with a Green Tick?

Here are two possible solutions:

Option 1) You can include the CRL files in the Adobe cache. Here is how you do that:

Download this zip file crl.zip, and copy its contents (4 files) to the following folder:

On Windows 8 & Above:

On Windows 7.x & Below:
 C:\Documents And Settings\Adobe\Acrobat\DC\Security\CRLCache


Option 2) You can open one Aadhaar eSigned file within few minutes of it being signed . Then you will be OK even if you open other files after a longer time  😲  (that's because when you open the first file, the Adobe reader fetches the CRLs and also stores them to cache).