The recent leak of Aadhar data (Aadhar number and other sensitive information) has brought back into focus the privacy and security issues with the program. There are a few concerns people talk about pertaining to Aadhar:
Multiple authentications without consent: A consumer is expected to provide his personal data (demographic/biometric) along with his Aadhar number for authenticating with private providers (telecom, banks etc.). Using this information, the entity tries to authenticate the user to determine if he is indeed the rightful owner of the Aadhar number.
There have been cases of biometrics being stored by the agency, and being repeatedly used to authenticate the holder. An alternative could be that the holder’s consent is required for every authentication request.
Unnecessary access to data: A simple authentication of a person by a telecom operator requires the user to provide his personal data to the operator. The operator then authenticates the user by calling the UIDAI services. While this is acceptable in case of KYC (such as banks) where the data is required by the entity, why do telecom operators need to know personal data ? The user should be able to authenticate himself with UIDAI, and merely provide the proof of authentication to the service agency.
Of course, these worries become alarming only if the Aadhar User Agency or AUA (entities seeking Authentication through UIDAI) indulges in malpractices such as sharing user data without consent, combining databases with other AUAs etc. Eventually, as long as there are no strict laws restricting the use of Aadhar data, one should assume that data collected by these organisations is not private.
Blockchain technology provides a sound solution to the problem of authentication without compromising on privacy. Generally, a blockchain is a public database, to which anyone can write data. This data can be of any form . A popular example is the Bitcoin blockchain, where users can add transactions to the blockchain, transferring a certain amount of Bitcoin currency to another user. The most notable characteristics of a blockchain are immutability and public access. Once some data has been written to the blockchain, it cannot be erased/changed. Furthermore, all the data is publicly viewable.
This fits particularly well for an identity verification system. Every entity which wants to authenticate a user/customer has to publicly request for it. Also, every request for authentication should be approved by the user, and only then forwarded to the government. Furthermore, the user should provide his data directly to the government.
The solution proposed is as follows:
- The AUA adds an authentication request to the blockchain. It specifies the user it wants to authenticate, and the purpose for which authentication is required.
- The user approves the request, then adds his personal data to the blockchain, encrypted such that only the government can decrypt it. (This provision of data can happen off the blockchain as well — on a government website for example)
- The government then looks at the request from the AUA, and the data provided by the user, and calls its internal services to verify if the data provided by the user indeed corresponds to him/her.
- The government appropriately marks the request as rejected/approved.
- The AUA then queries the blockchain to see if its request has been approved by the government.
All the steps above which involve writing to the database are publicly accessible. Thus, the request from the AUA, the approval by the user, and the approval by the government — all are verifiable at any later point in time.
If this entire behaviour can be codified, and the code itself can me made immutable, we can be assured that no human intervention can change/game the system. Ethereum can help us here.
Ethereum is public blockchain. It has its own currency (ether). However, its strength lies in its ability to store code. Pieces of code (called smart contracts) can be stored on the blockchain. These contracts can be made to solve any particular use case. They are publicly accessible, and the functions defined in these can be called by anyone on the ethereum network. A few points to keep in mind:
- Every user on the Ethereum network is given a unique public address.
- People can transact (exchange ether) with each other using their public addresses.
- Additionally, every smart contract is also similar to a user — it has its own public address. People can send ether to this smart contract. The contract can send ether to others. In effect, a contract is like any other human, except that its behaviour is driven by code.
- A contract exposes certain functions/methods. Other users can call these function. Each of these calls is stored on the blockchain (like any other transaction). These calls cause the contract to behave in certain predefined ways — for example send ether to someone, update its own program data etc.
Keeping this in mind, have a look at this contract, which codifies the behaviour stated above.
The notable advantages of this system:
- User approval is explicitly required for every request an AUA raises. The government cannot directly approve the authentication request.
- Only the govt. can access the data provided by the user. This data can be encrypted/decrypted using symmetric private keys, which are shared only between the govt. and the user.
The code (and all the requests made to it) are public, and can never be erased owing to the nature of the blockchain technology. This differs greatly from code which is locked in servers inaccessible to public scrutiny.
This transparency can help restore some of the faith lost in authentication programmes.