Overview
The application eco-system built around Aadhaar is vulnerable to malware. In this article we will describe this vulnerability in detail and how the conflicting requirements between utility, security, delegation and profit making, created the perfect environment for this vulnerability to come about in the Aadhaar system, as acknowledged by Nandan Nilekani himself.
Security and Utility
The safest car is the one that is parked in a garage, as it can never be involved in an accident, but it also has zero utility. The same is true for “Aadhaar data”, the term which means a combination of Aadhaar number, Demographic information, Phone number, Email address and the biometric identifiers. If it is securely hosted and never leaves the central repository (CIDR), then it’s utility is very limited.
To increase utility, the Aadhaar system allows two uses:
- Yes/No authentication, which allows residents to be verified with their Aadhaar number and biometrics or OTP delivered to their mobile.
- KYC (Know Your customer) authentication, which returns demographic data to a service provider when they submit their Aadhaar number and biometrics or OTP.
The entities that allow such use are regulated by UIDAI and are referred as AUA (Authentication User Agency) and KUA (KYC User Agency). The regulations not only specify the security measures that they have to undertake but also financial eligibility constraints that they have to satisfy (for unregulated private entities referred as Category 3).
Since License keys of AUA/KUA/ASA’s can be suspended if financial norms are not adhered to, how can private entities cover their costs and run a viable business? It is through a combination of delegation and transaction costing.
Delegation and Security
- AUAs are allowed to enter into contracts with other entities (referred as sub AUA) through a MOU (NIC sample). The most important aspect of the MoU is the requirement that it is possible for the AUA to trace back every single sub AUA who made the authentication request for auditing and fraud prevention.
For each SUB AUA application, NIC will assign a unique code to be included in application’s request XML.
2. It can be confirmed that sub AUA’s are explicitly allowed by looking at the authentication specification (Page 11 of 33).
sa — (mandatory) A unique “Sub-AUA” code. AUAs are expected to manage these codes within their system and ensure uniqueness within their system. This allows auditing and business intelligence to be provided at SA level.
3. Sub AUA’s are a form of sub licensing, which is allowed by UIDAI regulations, but every licensee must be registered. In other words, sub licensing is a form of delegation.
4. The Aadhaar regulations (Regulation 15.2), however prohibit sub KUAs, while explicitly allowing sub AUAs.
A requesting entity may permit any other agency or entity to perform Yes/ No authentication by generating and sharing a separate license key for every such entity through the portal provided by the Authority to the said requesting entity. For the avoidance of doubt, it is clarified that such sharing of license key is only permissible for performing Yes/ No authentication, and is prohibited in case of e-KYC authentication.
5. It can be confirmed that sub KUAs are prohibited by looking at eKYC authentication specification and noting that it does not allow sub KUA fields.
Why would UIDAI prohibit sub KUA but allow sub AUA? It is to minimize abuse and to ensure traceability. Since eKYC is mandatory for SIM cards and is accepted as a valid form of providing identity and address proof for opening bank accounts, mutual fund accounts, allowing sub KUAs, enables abuse via delegation.
Delegation creates multiple layers of obscurity and hence it becomes difficult to investigate the true source of abuse, in the case of a fraud report. Hence banning it is the only possible and reasonable solution.
Utility and Transaction costs
The undisputable fact is that businesses in india do suffer from regulatory burdens which increase compliance cost. One of the requirements behind the India Stack initiative is to ameliorate the impact of the compliance cost for businesses. Aadhaar eKYC is a component of the stack. There are a few sandboxes listed on the page which are provided by:
- Khosla Labs
- eMudhra
- AuthBridge
- Handy Online
- Quagga Tech
- Digio Tech
For a non-technical user, a sandbox is a sanitised environment which allows experimenting with the eKYC functionality before going live. Since sub KUAs are prohibited by UIDAI regulations, it is possible to check the list of KUAsand find out that only the following providers, do have the KUA license.
- Khosla Labs
- eMudhra
The other sandbox providers hence are not KUA licensees, but since the law forbids sub KUAs, they can only be technology partners for other KUAs (This is legal). What would be the business model of these entities? (Only entities for which information is available is listed below)
It is obvious that the downstream cost model of the sandbox providers closely resemble the upstream financial requirements that are imposed by the UIDAI, which consists of
- An upfront non-refundable license fees.
- Charge for every transaction.
So in effect KUAs are buying a certain number of eKYC transactions from UIDAI at a wholesale price and reselling these transactions to others at a retail price. As the downstream costs are a fraction of the upstream costs, even to cover their costs, the sandbox providers must have several downstream customers.
Each of these downstream customers must of course be distinguished at the KUA level since the KYC APIs do not allow sub KUAs by design. So how do the sandbox providers distinguish between their downstream customers? There are two sources for understanding this in depth.
- Service documentation.
- Android applications which use these services.
Quagga Technologies
Quagga provides both eKYC and authentication services through a single service. They also provide an Android SDK (Software development Kit), which is only available after due diligence and verification. Their documentation specifies how they distinguish between various downstream users.
Every downstream user or entity is now assigned a QT_API_KEY, which is used by Quagga to distinguish them. This is required not only for verification but also for billing purposes as their pricing model indicates. And how hard is it for anyone to obtain the API Key without breaking into Quagga or the customers of Quagga?
We just need a disassembler and an android application that uses the Quagga APIs.
Disassembler
The development process that is followed in Android application development is shown below:
The reverse process of getting the source code and configuration from a released application is also possible via the disassembler tool chains such as dex2jar, enjarify and apktool as shown below:
Sample Application
Usually development kits come up with a sample application (like a marketing sample). A google search reveals that there was a free Aadhaar verify application in the play store, which was been taken down.
The App was indeed available as on May 21st, as this quora post by Sanket Mehta indicates and was updated on July 27th and was cached by various mirror services.
We are now ready to check if it is possible to reverse engineer the QT_API_KEY from the sample application, using the disassembler.
Success! We are able to extract out the secret API Key from the Quagga sample application with just a decompiler. The method described above took just 5 minutes and can be done on any android application that uses the Quagga end point.
Quagga Response
An emailed questionnaire sent to both Quagga and UIDAI outlining the above issue elicited the following response from Quagga (UIDAI did not respond).
Regarding the API key in android app, please check our latest documentation. We discovered this vulnerability and removed the old SDKs from the system. Now our API keys can only be used at backend for generating a random access token and that token has to be passed through into the SDK to start the transaction at frontend. This makes the API keys secure and also the randomness of the token and expiry helps the any misuse of access.
The response assumes that it is not possible to reverse engineer the android app containing the SDK (Software development kit), which we successfully demonstrated in the previous section. A further query to Quagga outlining this issue was not replied to, though to be fair, it is a problem that plagues the entire android application ecosystem.
The statement that using a SDK secures the QT_API_KEY is inaccurate. It is very easy to reverse engineer android applications to get the QT_API_KEY (it must be stored somewhere). It is also easy to look at the AAR file to figure out what the activity does and emulate it. At that point of time, an attacker simply has to do what the SDK does without the SDK and I am sure all the SDK does is *hide the calling of some REST API*. In general security by obscurity is a terrible idea with the android eco system because of the capability to reverse engineer the source code.
You have to think about a better way to do this. Until then the vulnerability is not going away. The threat model here is someone using the SDK to figure out the actual REST API to use and calling the REST API w/o the SDK, thereby defeating the purpose of the SDK.
Making of a Malware
It is now trivial to design a malware which can use the above vulnerability and perform eKYC through an OTP in the background without either the user or the UIDAI being aware of it, if the following conditions are met:
- An Aadhaar holder must be tricked into revealing their Aadhaar number to the malware. Given the recent push towards making Aadhaar mandatory for getting a SIM cards, it is quite possible to launch a phishing call, pretending to be a telco. agent to register the SIM with the Aadhaar number for verification purpose by downloading an app.
- Public statements from UIDAI CEO that Aadhaar number is not a secret will ensure that the success rate of such phishing calls will be very high indeed.
- The android app containing the malware must have “Read SMS” access to silently read the OTP and make the back end call using a stolen API KEY from any one of the SDK customers (API Keys are meant to be kept secret, but the right way to secure them is very hard in the android application ecosystem)
The malware could be made more silent and efficient, if one of the phone manufactures were tricked or persuaded into installing it as part of the base operating system, which could then silently delete the incoming OTP from ever reaching the SMS Inbox (Government of India seems to have woken upto this problem recently).
Conclusion
Securing the CIDR is a relatively easy problem for UIDAI but ensuring that every single android app. is not vulnerable to malware is a very hard problem because of the following:
- Using OTP as a valid authentication mechanism is a design choice that cannot be reverted easily. Unlike a credit card PIN which is known only to the holder, an authentication attempt that only uses OTP can be defeated easily by automation as the above section indicates.
- OTP is a reasonable choice for second factor authentication, but is usually a poor choice for first factor authentication, particularly in the indian context, since most users do not pay attention to android application permissions.
- Any one of the 252 KUAs or their technology partners could design an API that is directly callable from an API Key which can be harvested from other applications in the play store. The capability to reverse engineer applications in the mobile application ecosystem would defeat the “Security by Obscurity” paradigm that UIDAI is comfortable with.
- A few eKYC apps are pulled down from Play store last week. While the pulling down of these apps were not noticed, a quick analysis via the disassembler as described above did show that all of them are vulnerable to API Key harvesting techniques (Names available on request)
Postscript
- The vulnerability described above was reported to both UIDAI CEO and Quagga over email on August 15th (Emails available on request)
- UIDAI CEO chose not to respond or acknowledge the email .
- Quagga responded to the all the emailed questions (except one as noted above) and it was clear from the responses they are fully in compliance with the Aadhaar regulations. (Emails available on request).
- It is unclear, if architecture issues (using OTP as a first factor authentication) should be reported to CERT.IN or NCI-IPC and hence were not reported.https://medium.com/@venkatanarayanan.anand/insecure-app-making-abd8548c3092
https://medium.com/@venkatanarayanan.anand/insecure-app-making-abd8548c3092
Leave a Reply