How are fingerprints secure on Samsung A70

Question

I use keepass to store my passwords and the keepassdx app to access that database on my Android phone. It offers the option to allow me to unlock with a fingerprint, if I set up fingerprint Auth on my phone.

Setting up fingerprints obviously means taking a scan, and I must assume that that scan, or some version of it, is then stored on my phone. The initial screen says about Knox which I believe is some sort of security layer/service of Samsung's.

I've always been against using biometric data because you can't change it, so if it's stolen you're in big trouble, proportional to the number of places you've used that data.

With trends towards webauthn and FIDO2 I feel like I'm wearing a tin foil hat by not giving my phone my biometrics. I'm unlikely to be the target of a well funded attack but I do need to be responsible with the data in my possession.

If like to understand

• how is the scan data stored - I've read that in 2015 some Samsung phones basically stored a bitmap image!
• does it leave the phone?
• does it mean Samsung (or Google!) have my fingerprints?
• how do apps interact with fingerprint scanners? Presumably apps don't get access to the print, but does each app get a unique key pair or something? Or does the API simply return a Boolean: yes authorised,or not.
• what is Knox's role? Why doesn't Android provide a native solution? Do I need Knox or would it be better to delete/disable it?

Answer 1

All android 8+ devices that are licensed for Google apps are mandated to provision Trusted Execution Environment (TEE). In Samsung devices, Knox is a discrete EAL 6+ TEE chip mounted on the SoC. It stores cryptographic secrets and fingerprint data in encrypted form inside its isolated storage. Similarly, in Google Pixel, this discrete TEE chip Is called Titan M. Lower end Samsung Exynos and Qualcomm Snapdragon SoCs are also equipped with integrated TEE.

Android interacts with TEE using Keymaster Hardware Abstraction Layer (HAL) which is a stable userspace ABI that communicates with TEE. HALs are implemented by the vendor and are part of android specification so they are natively supported by all android 8+ devices.

Apps use BiometricManager API to support fingerprint authentication natively. BiometricManager communicates with FingerprintService which is a system service that handles communication with Biometric HAL which communicates with the fingerprint sensor driver inside TEE. Fingerprint sensor communicates directly with the sensor driver through Serial Peripheral Interface (SPI) channel so even android cannot read fingerprint data during transit or even if the root access is acquired on the OS. The driver then computes the fingerprint data and TEE verifies if enough of the mathematically derived values match with the enrolled fingerprint data.

TEE only replies with success or failure response and lets the app know about authentication result through system keystore service. Based on the result, password managers can request TEE to decrypt the master key only if user authentication succeeds. This is how it's done in practice, fingerprint authentication is bound to some key (or session token) that needs to be decrypted by TEE only after successful user authentication.

Using memory corruption to fake the authentication result for the calling app will not decrypt the master key. TEE refuses decryption if the master key is bound to user authentication and requires user to authenticate. If the password manager is compromised, that still won't be enough for the attacker to access the master key. It is also possible for apps to verify if the TEE itself is not fraudulent by using hardware-backed key attestation.

It may look secure but fingerprints can be accurately copied and if the clone is accurate enough, the attacker will be able to succeed authentication under 3 attempts without compromising the device.

---

Fingerprint HIDL