Security Analysis of mAadhaar
Be forewarned. This is a technical post. I have tried to reduce the complexity of the topic for non-technical users, but it may still not be enough.
How are OTPs generated?
How does Aadhaar mobile authentication work?
The resident must link his mobile number with Aadhaar number either during enrollment or through a demographic update.
Once done apps that use Aadhaar authentication can use SMS OTP. Apps which are given the Read SMS permission in android don’t even require the resident to type in the OTP and can read the OTP automatically.
What is the security problem with this model?
Almost all the android apps can be reverse engineered using tools such as dex2jar, enjarify and apktool. This makes it easy to analyse the app and create a cloned version that can automatically perform Aadhaar authentications in the background without the resident ever knowing about it.
The normalization of apps that demand read SMS permission and the thoughtless manner in which everyone grants this permission makes it very easy for such a malware to succeed. Some may argue that they are not stupid enough to install malware on their phones, but successful malware detection in the play store has been close to rock bottom and embedded malware on innocuous apps have been raising consistently.
The malware only needs the Aadhaar number of the resident to perform mobile authentication. Given the pervasive coercion of having to provide Aadhaar numbers for everything it is too easy to get a resident to share their Aadhaar numbers to an app in their own phone.
How can the above security problem can be addressed?
If the resident’s phone never requests the back end for generating the OTP, then it can not be used by the malware as well. But how can they both generate an OTP independently which matches with each other? The short answer is “Time”.
The current time can be used as an OTP password, if both the back end and the phone always synchronize their time. But how can this prevent a fraud from using his phone to get Aadhaar details of another person via time synchronisation?
We need one more input, the shared secret which is available to the resident and which cannot be obtained by the fradulent person. The shared secret can be anything and all we then need is a mathematical function that when given the shared secret and the current time, always gives out the same OTP.
The mathematical function used to generate the OTP is HMAC SHA1. An example of how it can generate Time based OTP’s given a secret and a counter (time is an always increasing counter) has been described in RFC 4226 and RFC 6238 as shown below:
How can Time based OTP can be compromised?
If the shared secret is known by an attacker, then T-OTP can be compromised since the current time and the algorithm (function) is always known.Hence the shared secret must never be guessable or snoopable.
The problem then becomes how to make both parties agree to a shared secret which cannot be guessed or snooped. The solution for the snooping problem is to never transmit the shared secret on the wire between two parties (either via Internet or via SMS). This is very similar to how Credit Card and Debit card PINs are sent over normal mail without any context and not over email.
For instance setting up a two factor authentication using TOTP for your GitHub account, requires scanning the QR Code displayed in your acccount by the Google authenticator app (Example from GitHub below)
The QR code is nothing but a shared secret between the two parties. And by ensuring that the shared secret is never sent on the wire, the authenticator app offers very good 2FA security.
How does the UIDAI and mAadhaar App agree on the shared secret?
- When the resident downloads the app on their registered mobile phone, the app asks for their Aadhaar number.
- It then attempts to perform the normal SMS OTP authentication (Aadhaar authentication) by contacting the UIDAI back end.
- Since the App requests Read SMS permission, it can auto read the SMS OTP by itself. As an added security feature, it does not allow manual input of the SMS OTP to prevent social engineering attacks, where the resident is fooled into sharing the SMS OTP to a cyber thief.
- Once the normal SMS OTP is authenticated by the back end, it exchanges the shared secret with the back end over HTTPS (SSL) by calling an API.
This looks safe enough. What then is the problem?
- Recall that the original problem is an App reading the SMS OTP and making surreptitious calls in the back end. That problem has not gone away in the mAadhaar implementation. It can still be done and has to be done just once.
- The cleanest way is for sharing the secret has always been the fully offline implementation which UIDAI can’t do because Aadhaar authentication only allows either SMS OTP or Biometric identifiers.
- So unlike Google authenticator or other such apps, there is no such concept as an UIDAI account to which one needs to login for scanning the shared secret.
- This is because an Aadhaar number is not an account (like GMail etc.) It is just a random number.
- Besides there are vulnerabilities in the SSL client used in the mAadhaar app, that allows a hacker to perform the Man In the Middle Attack (MITM) to steal the shared key exchanged between the mAadhaar app and the UIDAI back end.
- Once the shared key is known, it is too easy to generate a Time based OTP in another device as both the algorithm and the current time (IST) is always known, thus defeating the purpose of TOTP.
- The SSL client vulnerability and other vulnerabilities has been disclosed to the authority but cannot be put out in the public domain until it has been fixed.
How do you know if mAadhaar is real?
One of the uses of mAadhaar is that it could be used as an alternate ID proof which does not require one to carry a physical copy.
But here is the most important question? How does a CISF person checking it would know that it is real? After all it is just a mobile app that displays ID information and it is too easy to create a fake android application that can be programmed to display whatever one wants to.
This predicament is very similar to how a few candidates were refused entry for the NEET PG exams even though they were genuine persons who had a copy of e-Aadhaar signed by UIDAI itself.
And as usual UIDAI know how to wash it’s hands out of such episodes.
What then is the point of insisting of Aadhaar identification either as a physical copy or as e-Aadhaar or as m-Aadhaar, when it is too easy to forge? The short answer is the belief that it can’t be forged and is the most safe and secure ID.
The UIDAI must be credited for launching a marketing campaign in “seeding” this belief but marketing campaigns about safe and secure IDs are much easier to pull off than designing a safe and secure ID. A widely believed false claim on security is worser than having a non secure ID and is ripe for exploitation by unscrupulous actors.
Between belief and reality lies vulnerability.
PS:
I will put out a FAQ on why Aadhaar is superfluous for eKYC and how an efficient eKYC can be designed without Aadhaar which also takes into account privacy concerns of citizens.
