Researchers customize Android for sophisticated smartphone lockdown

20.10.2011
for the past month and a half have been working to customize Google’s Android software to lock down smartphones so that sensitive data isn’t exposed once a user leaves approved locations. They’re hopeful the technology – part of a project dubbed GhostBox -- will be production-ready by year-end.

The software would be loaded on a smartphone or tablet computer and policies for hundreds or hundreds of thousands of devices could then be controlled remotely via a server.

One application might be to give medical personnel access to patient data from a smartphone within certain hospital rooms but cut off access outside such rooms, protecting the data in the event the device is lost, compromised by malware or  if the phone user attempts to misuse the data. Other applications could include safeguarding military data or putting parental controls on kids, according to project lead Jules White, assistant professor in the Department of Electrical and Computer Engineering.

MORE NETWORK RESEARCH: Follow our and  

BACKGROUND:  

Hamilton Turner, a Ph.D. student working on the project within the schools’ , answered a few of my questions to clarify how the technology works. 

How does the software actually work?

The software is a custom version of Android, so it would be loaded onto the smartphone that you want to lock down, such as a Nexus S. Once the software is on the Android device, multiple security features can be enabled and disabled from a remote location. For example, we can force specific phones to require 2-factor authentication, where a user needs both an ID badge and a password to unlock the device. In a military domain, these badges would obviously be unique and personal security badges. Additionally, we are working with multiple technologies on the phone to determine where the phone is physically. The GPS is used occasionally, but we are focusing on more fine-grained localization methods such as Bluetooth proximity, near-field communication [NFC], or using light/sound as a data transfer medium. As the user enters or leaves a "secure" location, there are thousands of policies that we can enforce that change vanilla Android behavior - we can selectively enable/disable the camera, the GPS, the settings on the phone, installing or uninstalling applications, using various applications, allowing copy/paste in some applications and not in others, etc. Technologically, we do this by applying interceptors to key services. If a user attempts to do something restricted, the phone simply ignores that attempt, alters it or reports it. More secure versions could naturally react to an attempt to do something insecure more strictly, such as logging the attempt or locking the phone. 

Additionally, we have created a data jail to secure email, SMS, contacts, etc. -- secure data can be loaded remotely from servers on entry into a room and automatically wiped without trace (it never touches disk) on exit from the room, meaning that if the phone is shut off the data is erased. These applications can simply integrate the secure data with the unsecure, thereby requiring no change to the user workflow. For example, secure emails show up in the standard email application, listed along with unsecure emails -- the only change is a tiny lock icon indicating each secure email. The users interact with the application as normal.  

What was the key breakthrough in developing this technology?

Adding interceptors to the Android services and the creation of a custom "data jail" technology to ensure that app doesn't get transferred to another process or stored on disk. They enable us to allow or reject thousands of user behaviors on Android, while the device is running. Additionally, the policy for allowed/disallowed behaviors can be pushed from a remote server and changed while the phone is executing, which does not interrupt the user's current workflow at all.  How does this technology compare to existing commercial offerings?

There are a number of 'remote data wipe' applications available. Most only allow either a) a wipe of the entire phone, or b) the password to be changed remotely. As far as we know, there is no other option that allows policy control at the fine-grained levels we have created or creating physical boundaries (e.g., rooms) that define where data can be accessed. Commercial applications only allow control of 50 or so policies, which are typically centered around controlling the Android system settings. Our work goes much farther than that, allowing extremely fine grained control of many parts of Android beyond just system settings. Additionally, we are the only solution we know of that allows integration with secure data, such as contacts and email, while ensuring that the sensitive data remains in memory and no traces of that data remain on a device.  

Got any companies sniffing around yet to use this commercially?

We are working with various defense contractors and are planning to meet with Google Federal soon. 

Overall, how big of a concern do you think smartphone security is these days/going forward?

Smartphone security is a huge concern. These devices enable a faster, more efficient communication with the world, but as users are adding features to their smartphones (calendars, email, contacts, social network logins, bank applications) they are making that device more of a security risk if it is lost or stolen. As smartphones become more prevalent, we have been seeing digital attacks targeted at every major platform. Smartphones are incredibly useful as devices, but trading all personal security for that usefulness is not the choice that consumers should be forced into.  

Anything else worth noting?

The source code for the project will likely be available near the end of this year. If we have time, we will integrate our work with the latest Ice Cream Sandwich version of Android.

Circle Bob on

in Network World's Anti-malware section.