The Inside Man

By Anivar Aravind and Anand Venkatanarayanan

Ola Qarth story is interesting in many ways. First the contradictions.

“We are hoping the police will help us identify how it was done when they arrest the suspects. The investigation is on and we would not like to comment. However, there has been no breach, no leakage and no theft of data. and we have been able to maintain the security,’’ said an a UIDAI official.

How is it as the headline says “Hacking Aadhaar data” is done, there has also been no breach, no leakage and no theft? But then Aadhaar has always been Schrödinger’s cat and this should not be any surprise. We can now start our own investigation into this curious incident for fun, while the cyber crime division does it’s own.

Nothing is truly lost

Even though the android application in the story is taken down from play store, in the internet, nothing is truly lost. A copy of the app. was cached at APK Pure and the screen shots posted shows that it can validate either an Aadhaar number, Name (OR) Aadhaar number, mobile number combination. The name of the app is “mygov.aadhaar.ekyc”, so we can surmise that it is using the eKYC feature of Aadhaar to do the same.

The first version of the App is available on 27–01–2017 and the last version was available 01–06–2017 and so the FIR is accurate that the incident-that-did-not-happen did happen between 27–01–2017 and 27–07–2017 (the day in which the app is taken down).

Peeking in

Once we get the APK file, it is easy to look at what is inside it. But if you own a Mac Book, the following commands will help to disassemble the code.

Once done, we can decompile the APK to a JAR using dex2jar as shown below:

Now looking at the JAR file and disassembling using JD GUI will show us the network calls the code makes:

So the forms do nothing but call one of these APIs in a back end server, and post back the results. These are:
“https://aadhaar-api.appspot.com/ekyc/generateOTP/"
“https://aadhaar-api.appspot.com/ekyc/authbyOTP/";
“https://aadhaar-api.appspot.com/ekyc/authbyname/";

So what exactly is appspot.com? It is google cloud platform where you can host any web application.

And it is still up and running, even though the HTTPS end point is taken down and is non functional.

What about the requests themselves? Here we can look at the JSON objects in the code and surmise how they are POSTed to the back end.

So details are fetched via the JSON shown below and in the mobile number case “name” field is replaced with “mobile” number field to fetch the responses.

What about the response from the back end? The code for handling mobile number is interesting. It is shown below:

So this is definitely a eKYC API response and the UIDAI is correct as usual that no biometrics are stolen, which is really what they mean by saying “Everything is safe”. But is the response a standard eKYC Response or is a response from some other wrapper? Let us find out.

From the eKYC API Spec. 2.0. published by UIDAI, the response structure contains the following:

Scanning the JSON input fields and the XML fields in the response, we can indeed confirm that there is an exact match and this is indeed the eKYC API albeit converted by JSON<->XML that is coming over the wire. So what exactly is the issue and why did UIDAI file the FIR?

For that we have to look at the common error codes that are returned by the eKYC API.

So all ASA, KSA, AUA, KUA encryption keys are kosher or otherwise it would not have been possible to decrypt the response and send it back to the android app. This brings the next interesting question? Who is the KUA (KYC User Agency) whose license key is being used?

Hunting down the KUA Key

The following picture explains how eKYC API can be called.

There are 252 KUA agencies who are given license by UIDAI to provide eKYC Services and one of these keys are being used to make the above calls. Here we are in the realm of speculation, since we are not the cyber crime division. But still let us go further.

1. We can remove banks and financial agencies from the list, since we truly believe that they would not be that stupid (or else we have different set of problems) and would be using PCI-DSS for these.
2. We can also remove the telcos. from the list for the same reasons.
3. We can also remove government departments for the same reasons, even though they are known to be leaky about their databases. (Hopefully they have kept their KUA license keys some where safe).
4. That leaves only a handful of those 252 KUAs, whose key could have been used (Remember we are speculating here, and can never know for sure. So if you are one of these organisations, don’t get worked up. Only the Cyber crime division’s word is the final one).
   * (n) Code Solution.
   * Capricorn Identity Services Pvt. Limited.
   * eMudhra Consumer Services Limited
   * Khosla Labs.

It is also likely that the eKYC API is being used from a sandbox and we can get a list of those from India Stack. Here again the list is narrow.
* Khosla labs.
* eMudhra.
* Auth Bridge
* On Grid
* Quagga Tech.
* Digio Tech.

And the next puzzling part about eKYC API is, why does not the app ask for OTP or ask for the Read SMS Access, in the name/number case?

The only conclusion is that it is using the demographic authentication, which is allowed by the authentication spec.

And we also know from a deleted spec. (Stored by Wayback machine) that demographic authentication does not send any notifications to residents.

This of course breaks the eKYC consent framework at it’s heart. When people use an unknown mobile app to do self eKYC, it means the purpose for which they are doing it is largely left to the owner of the App. This is a big problem. Who knows how many other such Apps used this loop hole to get one hundred sim cards and re-issue them to our friends across the border?

Conclusion

Irrespective of which organization’s KUA license key is used, UIDAI has reason to be upset. Unlike the AUA case where sub-AUAs are allowed, there is no such thing as sub-KUA. KUA keys are not supposed to be shared.

The puzzling part of course is that UIDAI can precisely know which KUA is being used to make those calls, but they still expect the cyber crime division to help them out. Extracting out the KUA key from the back end server would be child’s play for UIDAI once they get access to it.

Hence either they are incompetent (but they detected the eKYC key usage which rules out that possibility) or this case can actually show, how eKYC is broken at it’s heart, which explains the panic about the list of users’ who authenticated themselves (unknowingly) through this good governance android app.

(This article is released under CC-BY license. Media organisations are free to repost this article in entirety or use the analysis here in the correct context without distorting it, as long as they provide a back link to this post)