Towards a More Secure Aadhaar

Abstract

Aadhaar is the national identities project of Government of India. The main benefit of Aadhaar is expected to be better decision making using modern analytics as citizens use such an identity to avail services from various government as well as private service providers; this necessarily involves building a huge store with necessary information on citizens such as mapping of ids to biometrics. Such stores raise many security and privacy concerns and therefore should be designed and analyzed very carefully. The threat model for such systems should address both internal and external attackers. Previous writings and research work [12] in this area have discussed problems such as illegal profiling and tracking of individuals, authentication without consent, collusion of multiple service providers leading to correlation of user data, and use of fake biometrics. While some analyses have focussed on cryptography to provide a solution, a comprehensive and workable solution for, say, illegal profiling, is still lacking, and there are also many problems from a systems perspective that need to be addressed such as access control models to constrain the access to sensitive data as well as integrity of its metadata. In this paper, we discuss solutions to such problems, esp illegal profiling.

A Crypto-book Algorithm

Fig. 3.

Architecture of Crypto-book places in

The architecture of Crypto-book is shown in Fig. 3. The description of the 4 entities in Crypto-book are as follows:

• 1. The federated identities producer(F): like UIDAI, Facebook, Google who provide identities and provide single sign on service

• 2. Credential Producer(CP): who verifies federated identities and provides partially blind credentials to consumer

• 3. Credential Consumer (CC): who takes as input the credentials produced by credential producer to produce pseudonyms that are presented to third party applications

• 4. Third party applications (A): These applications use the identities provided by F, after authentication by the user at interface provided by F.

Crypto-book uses blind signatures to produce pseudonyms which are presented to third party applications. Blind signatures are cryptographic primitive in which a requester can request a signer to sign a message where signer does not learn the content of the signed message. For blind signature, requester first obscures the message m with some secret to produce $m'$ which is then signed by the signer to produce blinded signature $s'$; Because requester knows the secret he can remove the blinding factor and send m and unblinded signature s to the receiver. A verifier can then verify the signature using public key of the signer [8]. The following are important steps in Crypto-book; here, the client is the user, credential producer is the signer and credential consumer is the verifier.

1.1 A.1 Producing Credentials

To obtain a t “at-large” credential for use with consumer with identity idc, a client first generates a random value r which identifies the credential. The client hashes this value r with the identity of the consumer to produce message $m =H(r, idc)$. The client then contacts at least t of the n credential producers with signature requests, uniquely blinding the message m to produce $m'$ for each request. Before signing the message, each credential producer verifies the client’s federated identity and, if successful, returns blinded signature $s'_i$ to the client. The client unblinds the signatures from each of the credential producers to obtain a vector of unblinded signatures $s_1, s_2, ... s_t$ which serves at the at-large credential for anonymous identity r with credential consumer c.

1.2 A.2 Consuming Credentials

To authenticate with a credential consumer requiring a threshold t at-large credential, a client must provide the credential consumer with the value r defining their anonymous identity along with a vector $s_1, s_2, ... s_t$ of signatures from at least t unique credential producers. The consumer first hashes this value with its own identity to produce message $m = H(r, idc)$. The consumer, using the public keys of the credential producers, then verifies that each signature is, in fact, valid for message m and, if successful, authenticates the client as anonymous identity r.