At Google I/O, Android security chief Adrian Ludwig discussed the details of both the security features introduced in Android M and all the new ones coming in Android N. The latest version improves on M’s security, but it also introduces new sandboxing features and restrictions that should make malware infections less likely.
Although Android is typically considered as a not-so-secure platform, mainly because the majority of Android devices aren’t updated on time (or at all in some cases), Google has found ways to limit the exploitation of those vulnerabilities.
One of the main ways to do that is through its own anti-malware services, both on the server (Play Store) side as well as on the user side. When certain types of exploits are discovered, those services block them so they don’t affect the vast majority of users. However, that doesn’t mean there aren’t potentially tens of thousands, if not hundreds of thousands, of users that can’t be infected with a certain malware before Google discovers it. As such, other device-level protections are also needed.
Hardware-Backed Keystore (Now Mandatory)
Ludwig said that a major security feature of Android these days is the hardware-backed “keystore,” which is available in the vast majority of Android devices thanks to various implementations of ARM’s TrustZone.
Although TrustZone has been mainly implemented by chip makers and OEMs to enable stricter DRM protection, Google started making it available to application developers in the past few years. Starting with Android L, developers could store RSA, ECDSA, AES, and HMAC keys in the TrustZone modules. In Android N, the hardware-backed keystore will become mandatory for all devices.
In the new version of Android, developers will gain new keystore-related APIs, which will also be able to verify whether their keys are stored in secure hardware or not, and to specify for how long the key can be used after the user authenticated to the app. The developers can also set up their apps in such a way that the data is not decrypted unless the user authenticates.
Fingerprint And Smart Lock Authentication
Google said that since fingerprint authentication was introduced, secure lock screen usage has increased from about 50 percent to over 90 percent. Nexus users tend to be more security conscious, so it’s likely that fingerprint authentication has increased the usage of secure lockscreens even more on other devices.
Google also said that Smart Lock detection has reduced secure lock screen prompts by 50 percent. Smart Lock is the feature that enables the smartphone to be tied to a smartwatch or other Bluetooth device and remain unlocked as long as it’s in that Bluetooth range.
Other than revealing these details, Google didn’t mention any new changes for fingerprint authentication in Android N.
Secure Networking
Android M introduced a feature that allowed developers to explicitly say whether the app uses clear traffic or not. Until then, developers could not easily tell whether certain third-party components of their apps, such as ad libraries, would use encrypted traffic or not.
In Androd N, user-installed certificates are no longer trusted by default. This could pose a problem for Kazakhstan’s government, which last year encouraged mobile and PC users to install its certificate for “national security” reasons. Android will use only one Certificate Authority store across all devices (so OEMs won’t be able to add other certificates in various countries, either). This should ensure that Android devices can have the same level of “trust” everywhere.
Storage Encryption
Over the past year and a half, there has been much discussion about default storage encryption on mobile devices, usually in the context of the FBI arguing against it in the media. Google originally promised mandatory encryption in Android 5.0, but at the time not many devices had access to ARMv8’s more universal crypto accelerator. Therefore, Google began requiring storage encryption on “capable” devices (50+ Mbps flash read speeds and ARMv8 chips) only in Android 6.0.
In Android N, Google introduced a new feature called “Direct Boot,” which is supposed to eliminate the hassle of inputting a password at boot and allowing other apps to show notifications or other information before the user unlocks the device (through a fingerprint or other lock screen authentication method).
Android N will use two types of storage encryption: device encryption and credentials encryption. The device encryption will be tied to the device, and the key will be stored in TrustZone hardware, which should be protected against key extraction. Application data will be encrypted only with “credential encryption,” so only the user will have access to that data.
Google seems to give developers latitude in how advanced (and therefore how dangerous) they want to make their Direct Boot-aware apps and recommends that, for example, users of an email application should only be able to read emails, but not send or delete them, until they authenticate. It’s also not clear why the system would even allow the users to delete their emails from the Direct Boot mode, if their credentials are supposed to be protected behind the user authentication mechanism.
The Direct Boot feature seems to have been born as mainly a user convenience feature, but it remains to be seen if allowing other third-party apps to insert themselves into the boot process pre-user authentication is a good idea in the long term, security-wise.
Strictly Enforced Verified Boot
If in Android M the phone would warn the user only that the boot was modified by unknown code, in version N the device will not boot if the boot process has been maliciously modified.
Google also introduced bit-level error correction in the verified boot feature, which can erase changes that would, for instance, keep a device rooted after it’s been rooted.
Checking Device Health
The SafetyNet API that Google provides through the Play services framework allows a developer to check a device’s health, so they can see whether the device has been tampered with and check how long it’s been since the last security update.
This could be especially useful for enterprise applications where developers or companies would want to disable the applications from working on devices that haven’t been updated in a while. This is exactly what Google has been doing as well, internally, through the BeyondCorp security infrastructure that it has been setting up over the past year or two.
This kind of feature could also encourage OEMs to offer updates for at least some of their devices for much longer than they currently do, if they want enterprise customers to buy them. Android could be much more successful in the enterprise if it had a better update story to tell. Enterprise customers want devices that are updated for years, because they tend to update devices much more slowly than average consumers. Therefore, a device that is updated only for a year, or once every six months, is not of much use.
Sandboxing
Android N benefits from many more sandboxing features that it didn’t have before. Google has already talked recently about Android’s mediaserver library hardening, which was achieved through code sanitization to eliminate integer overflows, as well as by splitting it into multiple sandboxed components.
In Android N, Google also introduced a Linux kernel security feature called “seccomp” that was introduced to Linux operating systems 11 years ago, but only more recently started gaining adoption with the rise of containers, which take advantage of it.
Seccomp can better sandbox first party apps such as Chrome, the mediaserver, and other Android processes, as well as third-party applications. Google is the one that configures SELinux protections on Android, but developers can also now use seccomp to better protect the system against compromises in their own apps.
Other System Restrictions & Improvements
Adrian Ludwig mentioned that there’s increased randomness for the ASLR security feature, but it’s not clear whether 64-bit devices can now finally take full advantage of 64-bit applications. For instance, Google’s own Stagefright mediaserver library used to be 32-bit, even on 64-bit devices.
Google also introduced some limitations to the Device Administrator APIs so that certain malware such as ransomware can’t lock you out of your device, and so users can still uninstall Device Admin apps from the Device Owner mode. The ability of some apps to draw over system dialogs or other apps has been restricted, as well.
Android N will also introduce a more seamless update process for devices--something it borrowed from Chrome. Future devices will have two system partitions. The updates will automatically install in the background for the non-active partition, and at reboot, the updated image will go live.
Overall, Android N seems to have added a significant number of security features, most importantly all the new sandboxing features, as well as the increased restrictions for what apps are allowed to do.
Lucian Armasu is a Contributing Writer for Tom's Hardware. You can follow him at @lucian_armasu.
