Aadhaar authentication is the process wherein Aadhaar Number, along with other attributes, including biometrics, are submitted online to the Aadhaar system for its verification based on information or data or documents available with it. During the authentication transaction, the resident’s record is first selected using the Aadhaar Number and then the demographic/biometric inputs are matched against the stored data which was provided by the resident during enrolment/update process.
Registered devices provide three key additional features compared to public devices
- Device identification – every device having a unique identifier allowing traceability, analytics, and fraud management.
- Eliminating use of stored biometrics – biometric data is signed within the device using the device key to ensure it is indeed captured live. Then the Registered Device (RD) Service of the device provider must form the encrypted PID block before returning to the host application.
- A standardized RD Service provided by the device providers that is certified. This RD Service (exposed via Service interface defined in this spec) encapsulates the biometric capture, any user experience while capture (such as preview), and signing and encryption of biometrics all within it.
Compliance Levels
Level 0 Compliance
Device security implementation has level 0 compliance if the signing and encryption of biometric is implemented within the software zone at host OS level. In this case, management of private keys need to be addressed carefully to ensure it is protected from access by users or external applications within the OS. All device providers should at a minimum obtain level 0 compliance and should not have mechanism to easily obtain the private key or inject biometrics. See later part of document for keystore implementation
Level 1 Compliance
Device security implementation has Level 1 compliance if the signing and encryption of biometric is implemented within the Trusted Execution Environment (TEE) where host OS processes or host OS users do not have any mechanism to obtain the private key or inject biometrics. In this case, management of private keys need to be fully within the TEE. Any storage outside the TEE will require the keys to be wrapped using the TEE instance specific AES 256 bit keys.
ACPL has its own management server with two server and two HSM to manage the RD services.
Regarding RD services and various SDK for Fingerprint scanners please click on acpl.in.net