Starting with Android 6.0 Marshmallow, Google will begin to require OEMs to support new features that should significantly increase the security of Android devices.
Storage Encryption
Last year, Google began encrypting its Nexus devices by default, which looked like the beginning of a new era in Android device security. Storage encryption has been available in Android for a long time, but it had been hidden deep in the settings menu, which means most people weren't even aware it existed, or perhaps they didn't want to risk enabling it.
However, Google made the mistake of not using the AES hardware accelerator from Qualcomm in the Nexus 6 and left the encryption and decryption to the CPU itself. This resulted in the Nexus 6 having rather poor performance both in the real world and especially in benchmarks, when compared to an unencrypted version of the device.
ARMv8-A introduced some AES instructions by default into the architecture of all the chips that were based on it, which helped accelerate the encryption and decryption of the device's storage. However, not many devices were using ARMv8-A chips at the time, so Google decided against requiring OEMs to support default storage encryption. Now, things have changed, as more devices have started using 64-bit ARMv8-A processors, so encrypting them by default shouldn't be an issue anymore.
Storage encryption can help keep personal and sensitive data safe against thieves. When you want to sell your device to buy a new one, it also ensures that those who buy it won't be able to retrieve any of your data (which can happen even if you do a factory reset on an unencrypted phone).
Therefore, starting with Android 6.0, Google is requiring all OEMs to encrypt their devices by default. This will be necessary to pass Google's compatibility tests and have their devices certified.
However, there are still a few exceptions to this new rule. One is that the encrypted storage performance must pass 50 MB/s. This means lower-end devices that don't have fast flash storage in the first place, and may still come with 32-bit chips that don't support accelerated AES encryption, will be exempt.
Devices that didn't ship with Android 6.0 or don't have a secure lock screen, such as the Android Wear smartwatches, will not be required to be encrypted, either.
Fingerprint Sensors
For now, Google is only encouraging manufacturers to implement fingerprint sensors into their devices, but those who do will be required to respect the fingerprint standard that Google introduced in Android Marshmallow. This should ensure better security overall for Android devices, because as we've seen before, many OEMs can make some catastrophic mistakes when it comes to securing users' fingerprints.
The requirements include using a fingerprint sensor that has a false acceptance rate (FAR) not higher than 0.002 percent and a false rejection rate (FRR) not higher than 10 percent. In other words, the chance for someone else to unlock your device should be lower than 1 in 50,000 (security-related), and the chance for the fingerprint reader to not recognize you should be lower than 10 percent (convenience-related).
It's good that Google is imposing a minimum standard here, because otherwise some OEMs could be trying to use fingerprint readers that have a much lower FAR or a much higher FRR in order for them to be fast enough at a much lower price. However, this would either expose users to security issues or it would frustrate them too much when trying to use the fingerprint reader.
Even an FAR of 0.002 percent may not be quite enough if the attacker already has a portion of your fingerprint and can algorithmically generate the rest of it millions of times until it matches your fingerprint and then can use that to unlock your device. However, so far we haven't heard of such attacks being practical yet, so we can assume the current FAR levels are safe enough.
The compatibility document also included requirements such as:
Rate limiting attempts for at least 30 seconds after five false trials for fingerprint verification.Having 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.Having all identifiable fingerprint data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the Trusted Execution Environment (TEE).Securing the fingerprint when upgrading to Android 6.0 from an older version in a way that respects all the requirements, or removing it.
Verified Boot
Devices that will support storage encryption by default, as per the above requirements, will also need to support the "verified boot" feature, which guarantees the integrity of the device's software. The feature, which is based on the Linux kernel dm-verity, will perform a multi-stage platform verification on each boot sequence.
Each stage, starting with an immutable hardware key that is the root of trust, will be checked for the integrity and authenticity of all the bytes before code is executed in the next stage. The verification goes all the way up to the system partition.
Devices that ship without verified boot won't be able to upgrade to a version that supports it, because at that point the device can't be fully trusted anymore.
______________________________________________________________________
Lucian Armasu joined Tom’s Hardware in early 2014. He writes news stories on mobile, chipsets, security, privacy, and anything else that might be of interest to him from the technology world. Outside of Tom’s Hardware, he dreams of becoming an entrepreneur.
You can follow him at @lucian_armasu. Follow us @tomshardware, on Facebook and on Google+.
