RxFingerprint | Android Fingerprint authentication and encryption | Authentication library

_{Updated 2019-10-14}

No, you can't access the fingerprint. You can only get a "thumbs up" or "thumbs down" from the Biometric API. This is intentional by design.

You can, however, leverage the Android Keystore for hardware-backed cryptographic operations, and require user re-authentication to release the key. This pretty much does what you want.

Generating a password-like seed from a fingerprint is impossible. As James K Polk commented, fingerprints vary when scanned, and they are never legibly stored directly on the device.

When a fingerprint is being enrolled, its image is temporarily stored on secure device memory, where it is processed to generate validation data and a fingerprint template (these are all inaccessible to the Android OS). The raw image is then discarded. When a finger is scanned, the image is compared to the validation data generated before, and if it matches to a certain degree of certainty, a user is deemed as authenticated.

Biometric operations are conducted inside of Android's Trusted Execution Environment (TEE). This is a completely isolated OS running either on a protected part of the CPU on a separate coprocessor on modern devices (SE).

It's a virtually untouchable environment with a restricted interface and hardware barriers put in place to protect against tampering with the chip and forced extraction of biometric validation data and cryptographic keys.

Going back to your original question, no, you can't get any unique finger identification. This would be inherently insecure, as any application could read the secret!

What you can do, is leverage Android's hardware-backed Keystore and require device-level authentication to release hardware-backed cryptographic keys (setUserAuthenticationRequired(true)). This means generating a random secret which is securely saved to the Keystore, requiring a finger swipe to release the key to userspace. I can't stress the word hardware-backed enough.

You have no control over which finger is can be used and whether vendor-specific implementations allow bypassing of biometrics with the device unlock pattern, for example.

The Keystore's purpose is to protect cryptographic keys. Keys can only be retrieved by the application that owns them once sufficient requirements have been met, such as recent or immediate biometric authentication.

Keys can be protected against malicious extraction, and on modern devices, hardware bound, meaning they never leave the secure hardware (TEE/SE), and therefore are never exposed to your Android application. Any cryptographic operations, such as AES encryption/decryption, are securely executed outside of userspace (on secure hardware), and enrolling new fingerprints/changing the lock pattern will permanently invalidate the key. In this mode of operation, the Keystore entry merely serves as an "interface" to conduct crypto operations inside of the secure hardware, the true secret is never exposed to your application.

There is a Fingerprint/Biometric API, which is there purely for convenience, allowing you to quickly confirm an action by requiring the user to authenticate. It boils down to a "yes"/"no" answer from the TEE/SE, and vary greatly depending on the phone manufacturer!

The Keystore is a hardware-backed vault for cryptographic keys. Devices running API-level 28+ also have access to Strongbox Keymaster, if the device hardware supports it, which restricts cryptographic operations to a dedicated security CPU with more secure storage.

These features are device/vendor specific! And could be compromised/insecure! Warn users before enabling fingerprint authentication if you aren't sure about the device. The only truly secure encryption method is prompting the user every time for the decrypt key (in this case, the mind is the hardware-backed store). Having it stored anywhere, even in live memory, is always a calculated risk.

Doing cryptography right is extremely difficult. I highly advise that you research and try to understand the basics, and what additional security Android has to offer, before attempting to use this in production.