Back in 2013, Apple has added a fingerprint reader to its then new iPhone 5s. Around that time, OEMs manufacturing Android devices have also started equipping their devices with fingerprint sensors. It turned out that Apple and Android OEMs came to severely different results. In this article, we’ll have a look at fingerprint reader implementations in pre-Marshmallow Android devices and see why they were a terrible idea.

Android Smartphones with Fingerprint Readers

In July 2016, we published a research on Android fingerprint sensors. The article Fingerprint Unlock Security: iOS vs. Google Android (Part II) is available in our blog; please feel free to refresh your memory on Android implementation of fingerprint reader.

To sum it up, the lack of official fingerprint API and associated security policies in Android versions prior to 6.0 Marshmallow made handset manufacturers come up with their own implementations and their very own policies. Since few Android OEMs have any expertise in security, the results were ranging from terrible to outright scary. Samsung Galaxy S5, S6, S7, Motorola Moto Z, SONY Xperia Z5, LG G5, Huawei Ascend Mate 7, Meizu Pro 5 and a bunch of other phones equipped with fingerprint scanners without proper support on the native API level messed up with just about everything they could lay their hands on.

The Way It Should Be

As we already discussed in the old article, Google Compatibility Definition document lays out straightforward requirements for OEMs releasing Android devices designed to run Google services on them. In order to run Google services out of the box, manufacturers must sign an agreement with Google and pass stringent certification tests in one of Google approved certification labs. Devices and their pre-installed software must pass all of those tests in order to receive a compliancy certificate. In particular, devices must conform to security requirements outlined in p. 7.3.10. Fingerprint Sensor of Google Compatibility Definition.

Let’s quote it again:

7.3.10. Fingerprint Sensor Device implementations with a secure lock screen SHOULD include a fingerprint sensor. If a device implementation includes a fingerprint sensor and has a corresponding API for third-party developers, it:

• MUST declare support for the android.hardware.fingerprint feature.

• MUST fully implement the corresponding API as described in the Android SDK documentation [Resources, 95].

• MUST have a false acceptance rate not higher than 0.002%.

• Is STRONGLY RECOMMENDED to have a false rejection rate not higher than 10%, and a latency from when the fingerprint sensor is touched until the screen is unlocked below 1 second, for 1 enrolled finger.

• MUST rate limit attempts for at least 30 seconds after 5 false trials for fingerprint verification.

• MUST have a hardware-backed keystore implementation, and perform the fingerprint matching in a Trusted Execution Environment (TEE) or on a chip with a secure channel to the TEE.

• MUST have all identifiable fingerprint data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the Trusted Execution Environment (TEE) as documented in the implementation guidelines on the Android Open Source Project site [Resources, 96].

• MUST prevent adding a fingerprint without first establishing a chain of trust by having the user confirm existing or add a new device credential (PIN/pattern/password) using the TEE as implemented in the Android Open Source project.

• MUST NOT enable 3rd-party applications to distinguish between individual fingerprints.

• MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.

• MUST, when upgraded from a version earlier than Android 6.0, have the fingerprint data securely migrated to meet the above requirements or removed.

• SHOULD use the Android Fingerprint icon provided in the Android Open Source Project.

Source: Google Android Compatibility Document

There are other security requirements that are applicable to devices running Android 6.x and 7.x out of the box such as secure verified boot and full-disk encryption enabled out of the box. These security requirements do not apply to devices released with earlier versions of Android, even of those are being upgraded to Android 6 or 7. However, p. 7.1 is applicable to all devices including those upgrading from previous versions of Android to Android 6 or 7.

In human words, this means that smartphones released with Android 6 or 7 out of the box must adhere to the following security standards:

1. The bootloader should be locked by default. The state of bootloader lock must be advertised via appropriate API. Since this API was not available in earlier versions of Android, devices upgrading to Android 6 or 7 (rather than receiving it out of the box) are exempt.
2. Unlocking the bootloader must trigger full wipe of user data upon first boot.
3. Fingerprint data must be securely stored within a trusted zone. Fingerprint data must be encrypted with encryption keys derived from the user’s passcode.
4. As a result of p.2, fingerprint authentication must not be possible immediately upon reboot.
5. It must not be possible to extract fingerprint data by simply reading the storage memory (eMMC or UFS).

Generally speaking, breaking just one of those rules may be enough for an intruder to break in to the device, forge or extract authentication credentials.

The Way It Is

Google has developed a very strong security policy for devices receiving Android 6 or 7 out of the box. This policy still stands in the part related to fingerprint authentication when it comes to updating to Android 6 from an earlier version of Android. However, what about devices that were released with a fingerprint sensor and never saw the light of Android 6.0?

This is not an idle question. Let’s have a look at the current Android version distribution chart:

As we can see, Android 6.0 takes 29.6% of the market, while Android 7 is currently at 0.7%. What about the other 69.7% of Android devices? They are running Android 5.x (33.4%) or older. It is those devices we are worried about.

Let us take, for example, a flagship device made by a German company Gigaset.

Gigaset ME was introduced in September 2015, and went on sale in early 2016. Equipped with Snapdragon 810, 32GB of memory and a modern USB-C port, this smartphone is a strong contender even today.

While design and hardware are on the excellent level, this smartphone suffers from the typical Android problem: the lack of updates. In common with most Android devices, it never received a single OS version update for the year it was on the market (to be fair, there were several minor updates with bug fixes and general improvements). Now that it’s being phased out, the chance it would ever see an update to Android 6 is slim to none.

Gigaset ME is equipped with a rear-mounted capacitive fingerprint scanner.

Combined with Android 5.1, this is a call for disaster.

We purchased one of these smartphones and probed it in our lab. We discovered the following.

• The smartphone came with unlocked bootloader out of the box. Not that it matters though, because…
• The smartphone exposes access to Qualcomm HS-USB 9008 mode. The correct drivers and utilities are publicly and easily available from third parties allowing low-level read and write access to the phone’s memory regardless of bootloader state.
• Root access is not available out of the box, but ADB root can be easily obtained by simply entering a “secret code” in the phone’s dialer app. While root access is protected with a password, that password was reverse-engineered in a matter of minutes based on the partition dump.
• Configuring the device and dumping the content of the 32GB eMMC 5.0 chip proved that encryption is NOT enabled out of the box.
• Fingerprint data is stored in open access. It is not encrypted with the user’s passcode. One can use a fingerprint to unlock the smartphone immediately after the first boot. One can also install a custom recovery to bypass fingerprint unlock entirely, booting directly into the home screen even if fingerprint unlock was enabled.

Should this smartphone run Android 6 or 7, it would have never passed through Google certification. Could this be the reason why it stays on an old version of Android?

Conclusion

Google made great improvements to Android security model in Android 6.0, and further strengthened security in Android 7. Unfortunately, this has relatively little effect on the market as the majority (69.7% at the time of this writing) of Android smartphones runs Android 5.x or older. With this many devices running old, insecure versions of Android, speaking of fingerprint unlock security is still a bad joke.