Get started Bring yourself up to speed with our introductory content.

Improving Android device security for enterprises with Android N

Android device security is getting a boost with its newest version, Android N. Expert Michael Cobb explains the effects on enterprise users, and the changes in encryption.

Security is a key differentiator in the enterprise mobile market, and the reputation of the Android operating system...

has always lagged behind the likes of iOS and Blackberry OS. Google is hoping that its next version, Android N, will finally make network administrators as comfortable with Android devices as those of its rivals. This tip will explore some of the Android N security changes, how they will affect enterprise users and if there are areas that Google still needs to address with mobile security.

The biggest problem affecting Android device security is the distribution and installation of updates. Millions of devices are still running KitKat 4.4 or older versions, leaving them vulnerable to attack. There are two reasons why so many users don't have the latest updates: firstly, many ignore update notifications, and secondly, Google is reliant on OEMs and carriers to push out the updates Google releases to its users. Google is hoping that seamless updates in Android N will at least solve the first.

Google's Chrome OS already benefits from seamless updates and Android N will update in a similar fashion by using two separate system partitions: one for the old system image and one for the updated image. The OS will automatically download system updates in the background and switch to the new version on the next device reboot. Security always works best when it's simple and unobtrusive; seamless updates means no user interaction is needed to install a patch or system update, other than rebooting the device.

While seamless updates are as much a user experience enhancement as a security upgrade, the redesign of the Mediaserver component delivers a real improvement in Android device security. Android N has divided Mediaserver and its permissions into multiple sandboxed components to better adhere to the security principle of least privilege. Android N uses a Linux kernel security feature called seccomp to sandbox apps such as Chrome and the Mediaserver, and developers can also use it to better protect the system against compromises in their own apps. This change is aimed at preventing future vulnerabilities from having such a wide impact as Stagefright. The Stagefright vulnerability leveraged the access media files have to the Android system to take over an Android device. Not only does seccomp limit a vulnerability to a single component rather than the entire device, but independently updatable components can also be patched a lot faster outside of a full system update. This is a similar move to when Google split off the WebView component from the main operating system.

The other big change in Android N that highlights the never-ending tradeoff between security and convenience is encryption. Until now, Android has used block-level encryption or block-layer full-disk encryption to encrypt the entire device storage. While a secure method of encryption, it can have a notable impact on performance; many OEMs disable encryption, sacrificing Android device security for speed. To allow companies to make budget-priced Androids that offer encryption without performance degradation, Android N has moved to file-level encryption for Authenticated Encryption with Associated Data. AEAD along with a Direct Boot feature introduces a two-level security scheme: device encryption and credentials encryption.

Android N Security Changes

-          Seamless updates

-          Multiple sandbox components

-          File-level encryption for AEAD

Encrypted data and apps storage explained

Security teams and in-house app developers need to understand how data and apps are encrypted in both types of storage. Device encrypted storage is encrypted with a key tied to the device, stored in TrustZone hardware widely available as part of Android device security. The key only becomes available after a device has performed a successful verified boot. To reduce downtime, Android N runs in Direct Boot mode when the device is powered on, but not yet unlocked by the user. Apps and data in device encrypted storage are accessible in Direct Boot mode before the user has unlocked the device. This is so apps like SMS, phone and alarms will be able to run in the background to show notifications or other information before the user unlocks the device after a reboot -- the lack of this functionality is a genuine reason why some users delay installing updates.

Data and apps in credential encrypted storage, the default storage location, can't be accessed until the device is unlocked, as it is encrypted with a key associated with the user's credentials, such as his PIN or password. Note that if the user enables the lock screen after unlocking the device, it doesn't lock the credential encrypted storage. Developers should restrict the functionality of an app running in Direct Boot mode until the user has authenticated himself, and personal and sensitive data should be placed in credential encrypted storage.

Although file-level encryption is less processor intensive, the downside is that some areas of the file system, like the swap partition, could include unencrypted data. It also means that users are reliant on each app correctly implementing encryption of any sensitive data the app uses or generates. In Android N there are new keystore-related APIs, which will be able to verify whether 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. Developers should also make use of the SafetyNet Attest API to check device compatibility, integrity and safety. For example, enterprise apps could disable applications from working on devices that haven't been updated.

Android device security keeps improving with each OS version, and isolating and deprivileging components will reduce the number of bugs that can turn into dangerous vulnerabilities. Silent and seamless updates will reduce IT management overhead, but even Google admits that the update process is Android's Achilles heel. Google has tried to pressure OEMs into committing to monthly updates, but with little success. Network operators also need to test updates to ensure they don't cause network disruption, adding further delays. Until the millions of legacy Android devices are updated, the Android ecosystem will be a favorite target for hackers, so enterprises need to assess which versions of Android they are happy to have connect to their network and access its resources. For example, even devices that can upgrade to Android N will not have the Direct Boot feature because it's too risky for end users to create the dual-system partitions it requires. Those enterprises wanting to take advantage of Android N may well have to incentivize employees into upgrading to newer, higher-end devices, capable of benefiting from its latest security enhancements.

Next Steps

Read about the security challenges in Android device management

Learn about the basics of Android app security

Discover some Android features for improving mobile security

This was last published in September 2016

Dig Deeper on Disk and file encryption tools

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Do the new Android N security features fit in with your enterprise's policies? What other Android security features should be added?
Cancel

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close