From Toys to Tools
Security Considerations for the Next Generation of Android Mobile Connected Devices
As mobile devices such as smartphones and tablets gain ever more processing power and capabilities, the data stored on them becomes more valuable to their owners and more enticing as a target for hackers, criminals and malware. At the same time, businesses are dealing with a new fact of life: data crucial to the mission of the enterprise is spread across an increasing array of devices that the organization does not fundamentally control. With the rise in the number of these devices and the value of data stored in them comes the understanding that security needs to be multi-faceted and designed in from the lowest levels of SoC applications processor through to the applications that run on them and carry their data to the cloud. This article puts a particular emphasis on the Android environment, both because it represents a rapidly growing opportunity and because it is changing the way the mobile business has to view devices, users and what they can or cannot do with their devices on the network.
Security Issues in the Android Environment
Android is both relatively young and very open, so it presents much more of a challenge than the tightly controlled environments of the past. In addition, the performance and connectivity capabilities of today’s mobile devices create a range of issues from a security perspective:
Competing, and not necessarily compatible, security interests
Users store their own private data on these devices; data that ranges from relatively uncritical information like log-in credentials for gaming networks and social media services like Facebook and Twitter to much more sensitive personal information, such as credit card and bank account data for payment transactions or account access. Enterprise data that can include proprietary or classified information, identification and authentication credentials and other sensitive information is often stored side-by-side with this personal data. Compromising access to one set of data can lead directly to access to all information stored on the device through its user interface, storage subsystems or even over the air.
Richness and diversity of available apps
Apps and the ease with which they can be installed on devices create risks that include the possibility of malicious software being installed that compromises private or confidential data on the device. To some extent, this risk could be reduced if app store operators required validation and security analysis of applications prior to distributing them, and devices required that applications be signed and authenticated by a trusted entity prior to installation and use. This has proved difficult in practice, and the landscape is very uneven between different device ecosystems. Security interests have been intermixed with business models and even ideology about how devices and their ecosystems should work.
Apple is famous for denying iTunes access to otherwise legitimate applications by refusing to sign those applications as a means to restrict who can supply apps on that platform or what functions those apps can provide, effectively barring access of those apps to the iPhone market. In contrast, the Android ecosystem has been a wild-west show. The current authorization model is reputation-based, with application providers vouching for themselves through self-signed apps. Some high-profile incidents of malicious software being distributed in the Android ecosystem have led to tightening of the access controls, but the system is still far from ideal from a security point of view.
Cloud-based services
The rapid proliferation of cloud-based services in the ecosystems of these devices makes it easy to inadvertently expose data that should remain private. Android devices, for example, use the Google Gmail service to authorize access to the Marketplace app store, as well as to synchronize and back up data between devices, applications and accounts on other platforms and devices. Many applications install themselves with this mechanism enabled by default to synchronize and consolidate data across apps and user accounts. Most enterprises probably do not want internal contact lists synchronized through third-party servers in the cloud, yet it is all too easy for this to happen, whether deliberately or inadvertently.
Competing Interests Drive Different Security Requirements
To better understand how to meet the requirements for the different uses of these devices, it is useful to consider some basic security issues:
Access to 3G and 4G wireless networks
This is generally handled by the device itself, with little user interaction and control. Authorization for a device to access a particular mobile network is authenticated using SIM cards or other stored authorization credentials in the device. These authorization credentials are not used for any other purpose, and have been made inaccessible to users to prevent fraud and theft of service.
Access to private user data
Security requirements for consumer or personal-use applications are the simplest to understand. Users should be able to require that access to certain information in their device require their explicit authorization, even if only through a simple yes/no dialog. After this kind of data is stored in a device, users want to be able to prevent any access to it if the device is lost or stolen.
Device locking and authentication
The most basic user authentication model in Android devices (after a simple swipe-to-open) is to control access to the user interface (UI) using an authentication widget (e.g., a PIN entry screen). Ideally, no sensitive data would be available when the device UI is locked; however, it frequently is. In some cases, this data is required to perform background tasks on behalf of users (e.g., synchronizing email). In other cases, it is there simply because it is brought into the device with its related app the first time it is run and never released regardless of whether it will be used again. A far better approach is to load sensitive data only when it is needed or when it will be used again soon, and discard it from memory as soon as it is no longer needed. Access to this kind of data should be locked when the user interface is locked.
Unencrypted data storage
Most apps use default unencrypted storage to store data in the device. Combined with the poor granularity of these access controls, no real visibility of what data is being accessed and how it is being used, this leaves users vulnerable to sensitive data being exposed. A far greater risk is that all data in the platform is available by gaining root access to the device. Malware that exploits latent system defects has appeared that uses this method to gain access to stored data.
Enterprise policies
Enterprises entrust data access to employees to further the objectives of the business. The data is often shared among applications to enable those activities. Many enterprises want to enforce policies designed to protect access to data in devices if they are lost or stolen. A missing tablet or cellphone with gigabytes of data storage and VPN or even Exchange server credentials can represent a potentially wide open portal to an enterprise’s most sensitive information.
Multimedia applications
The most demanding applications are those that deliver premium multimedia program content to users to render on high-resolution (HD) displays. Satisfying the needs of the content delivery industries, which drive operators to demand enhanced security features from device OEMs, has the potential to make platforms more secure for all types of users.
Some Issues with the Status Quo
Current mobile system designs have several security issues. First, Android’s Linux kernel is a monolithic OS; compromising one critical component of it can leave the platform wide open. Android is not alone in this; Apple’s iOS is based on the monolithic BSD UNIX, and the Windows phone platform is also a monolithic system. As production platforms go, Android’s Linux tracks kernel development quite closely; so security improvements in the mainstream kernel are deployed relatively quickly to Android, and Google’s Android team has been quite responsive to reported security issues.
Android uses a unique Linux user and group per app1 to assign rights to applications, and thereby separate applications from each other. What is lacking is any notion of a trusted part of the system with data that is logically and physically isolated from software running in the native Linux environment. The OS kernel would ideally be such a component, but the use of standard C-calling interfaces leads to the possibility of well-known attacks that can reveal data stored or used in the kernel. The benefit of providing such a trusted environment is that critical data can be stored in it and processed without making it vulnerable to exposure in an attack on the OS and its applications.
Running each app in its own process, as its own user and in its own group is designed to separate apps and their data from each other. It works well enough if apps do not need to cooperate with each other to get things done. If an app needs to use services offered by a different app, it has to start that app itself and extend permission for that app to use data it owns to the app supplying the service. But this makes it difficult to extend the platform in a general way. This, combined with perceived functionality shortcomings in the default platform, leads some users to root their devices to extend them with basic features. This, in turn, opens the door for malware or even other apps to access all data in the device.
 |
| ARM TrustZone is one solution to the problem of separating security-sensitive data from the general applications environment. TrustZone is a secure execution mode of the same processor that runs the application. While operating in secure mode, the processor can access system resources that are not available in the normal-mode application. Android is one example of a rich OS that can run in a TrustZone-enabled device. There is currently no standard implementation of a TEE in TrustZone-enabled Android devices. |
 |
| A typical application for a TrustZone-enabled Android device such as a tablet or smartphone is to act as a high-definition media renderer (display) for protected content stored in a home media server. In this application, authorization of the renderer decryption of the program content is performed inside the TrustZone TEE on behalf of the application that supplies the user interface. Decryption keys for the program are never available in decrypted form outside the TEE. |
Google Can Lead the Way
Driven by content distributors such as Netflix, the Android system needs to evolve to provide enforceable separation of security domains to prevent the wholesale redistribution of protected media content through platform hacks. This evolution has security benefits for all users of Android devices. Individual consumers will benefit from standardized interfaces and support that can protect their identity credentials used for all kinds of applications, from e-wallets to bank accounts to web and social media log-in credentials. Enterprise users similarly benefit from the ability to protect user credentials and enhanced security of corporate data stored in the device. Unfortunately, this is a large evolution that will involve changes to application-processor architectures, as well as the creation of standardized APIs, OS services and recommended practices in Android by Google. Without that leadership, solutions will be piecemeal and deployed application by application. This will involve unnecessary bloating of application code, uneven security properties and vulnerabilities and disparate hardware support – ranging from none at all to well-designed solutions similar to hardware security modules.
Another significant issue is that security software and encryption are easy to get wrong, and it makes sense to centralize these in the system to ensure that vulnerabilities are less likely to occur and easier to fix in one place when they do occur than if each app developer supplies its own solution. Apple has taken this approach with iOS, supplying features such as a standardized security service provider in the OS, as well as a simple, flexible storage system for sensitive apps data that offers encrypted storage and configurable parameters to control when that data may exist in unencrypted memory.
Android users would benefit from a consistent, full-featured and extensible set of facilities for cryptography and secure data management, as well as reliable means to determine what features are available in the particular hardware platform. The current documented cryptographic API is based on the javax.crypto class. The actual cryptographic work in this class is performed by a “provider,” of which there are several available. The standard provider in the system development kits is the well-regarded Bouncy Castle kit, and there is also at least one provider based on the OpenSSL libraries. The problem is that that the actual set of ciphers and other functions included is inconsistent between OEMs for shipped products.
Notable here is spotty support for the Advanced Encryption Standard (AES) and the SHA-2 family of digest functions. A more fundamental issue is that these classes do not lend themselves to integration and support of hardware, especially hardware that encapsulates the use of sensitive data like private symmetric and asymmetric keys. Instead, cryptographic key data is handled directly by the applications that use it, making it more vulnerable to malware or malicious users.
There is some progress on this front, but there is still room for much more. The DRM management classes are clearly designed to allow rights and constraints objects to be associated with a particular content stream. The idea is that an application can load an opaque blob holding decryption keys and other rights data to a DRM plugin that knows how to decrypt and interpret these data. The associated data is passed via the Media Player through a content engine channel to the DRM plugin that may then apply the DRM scheme to decrypt the content on its way to the display. Given DRM plugins with appropriate supporting hardware, this will satisfy the needs of the content-distribution industries.
There are a few things missing in this model that would make this framework, or a similar one, much more applicable to user and enterprise applications:
- A general capability to import and bind a key to the platform that will allow applications to generate their own keys that are encrypted and only usable in that particular device, and only within the plugin. Applications can store the key data in their private but unencrypted storage, secure in the knowledge that they cannot be used outside of the current hardware.
- A platform capabilities certificate signed by the device manufacturer that allows apps to determine what features are available; for example the presence or not of an on-board hardware security module.
- The ability to encrypt or decrypt a general serialized stream of data using the plugin, as a means to provide secure storage of large data objects. While the content distribution industries are generally interested in assuring that the decrypted output from a DRM scheme can only be delivered to the GPU without interception or duplication, a general-purpose capability will frequently need to receive the output from the engine itself. These kinds of features must be carefully designed so that a general-purpose capability cannot be used to subvert content DRM security, as well as to protect against bound keys being abused outside the application that owns them.
Starting with Android 3.0 (Honeycomb) there has been a device administration class (android.app.admin) that can enforce various security policies of interest in enterprise applications, such as password aging and strength rules, the use of storage encryption for embedded storage in the device and initiation of a device wipe (erasing stored internal data). Even here this support is tentative. Storage encryption may not be available on all platforms, and the device-wipe operation is only triggered after a reboot (initiated by the wipe function) rather than immediately. While this will trip up unsophisticated adversaries, or nullify the risk of data exposure that a lost device represents, it leaves open the possibility that an attacker can simply remove power from a device and recover data from its memory later.
Android has become extremely popular as a mobile computing platform through a combination of great features, high performance, attractive hardware with decent battery life and a thriving ecosystem of applications developers. The security model for Android continues to evolve, and with a little leadership from Google, it can become a robust platform for all kinds of applications and users, from social media junkies to corporate users. It can also be a great mobile multimedia engine for all kinds of free and licensed content. The need for strong protection of premium content is making ASIC and system software suppliers pay more attention to overall issues of system security. This in turn has the potential to benefit all Android users if some care is taken to provide a general framework that apps can use to secure their data on behalf of their owners.
¹It is actually possible for two apps, but no more than two, signed by the same private key to be installed with the same user identity. In practice, this means that both apps must be from the same publisher.
Mike Borza is founder and chief technology officer of embedded security specialist Elliptic Technologies Inc. He was also a founder and chief technology officer of network security appliances company Startle Networks. At Chrysalis-ITS (now Safenet), he worked with customers of the Luna series of network security processors as director of applications engineering. Earlier in his career, he was involved in biometric identity management systems design, safety-critical systems engineering, and optoelectronics design and manufacturing. Borza was a founding director of business networking forum The Ottawa Network. He has been an active contributor to the Security Task Group of IEEE 802.1 and was an editor of the 802.1AR Secure Device Identifier standard.
