Making Android More Secure

The open platform calls for a different approach to security.

By Erica Naone

Google entered the mobile phone market with a splash, promising that its Android operating system would be wide open to developers. This was very different from the traditional approach--mobile phone carriers in the United States have typically exercised tight control over which software can be run on their devices. Apple's popular iPhone, though a recent entry, was no exception. Apple closed off aspects of its device to third-party applications and had to approve all applications sold through its market.

Credit: Technology Review

But as phones become more like desktop computers, they become subject to the same security risks that abound on the Internet. To ensure Android's success, Google had to come up with a new approach to security for mobile phones. Rich Cannings, Android Security Lead at Google, spoke this week at the Usenix Security Conference in Montreal, Quebec, regarding the company's design.

There's always a balance to strike between being open and being secure, Cannings says. "I could make the most secure mobile phone ever, but no one would use it." A truly secure mobile phone certainly couldn't access the Internet, he says, and it might not even be able to send text messages or receive calls.

Instead of eliminating all risks and, therefore, all features, Google's approach is to minimize what attackers can do if they are able to get access to a device. For inspiration, Google looked to the Web, Cannings says. Web applications are protected by the "same origin policy," which under normal circumstances prevents one website from exchanging information with any other website that a user may have open.

To translate this type of approach to an operating system, Cannings says, the company treated each application as a different user of the device. When multiple users share a single desktop machine, the operating system is designed to protect them from each other by giving each its own account. From one account, it's not possible to see files in other accounts, or to affect another user's data. In the same way, the Android operating system treats each application as a separate user, so that if an attacker breaks into the Web browser, for example, he won't be able to access the address book.

But just separating each application wasn't secure enough. There's no reason, for example, for a Pac-Man application to be able to access the Internet, Cannings says. So the Android security team limited each application's access to the phone unless it asked permission from the user. Here, they were faced with another challenge.

"Most humans have a difficult time analyzing unknown risks," he says. When users have to handle their own security, they often become numb to the risks and click OK every time a dialogue box alerts them to a problem. Android is designed to ask once, when the application is being installed. It also shows the user only the most important alerts, while offering an option to see the full list.

It isn't only applications that Android secures. The team also looked at bits of software that are common entry points for attackers. For example, Cannings says, the software that runs media, such as audio and video on a Web browser, is very complex and a common target. In Android, that software runs apart from the browser in a separate media server, so that if it is compromised, an attacker can't access the passwords and cookies stored in the browser.

Charlie Miller, a security researcher at Independent Security Evaluators who has found and reported several bugs in the Android platform, says that Google's technique of placing each application on an Android phone into a separate sandbox can certainly be effective. For example, Miller did find a bug in the software that Android used to play mp3s, but found that the access he gained with his exploit didn't allow him to attack other applications on the phone.

However, Miller thinks Google relies too heavily on this one method of protection. "It is a good security piece, but in my opinion, there should be more layers," he says. An attacker could find a bug in the operating system that allowed him to break through the walls between applications, which would make bugs in media software just as dangerous as before, he says.

Miller adds that systems such as the iPhone will stop unauthorized applications from executing code. Google's system, on the other hand, allows any type of code to run, which puts more tools in the hands of the attacker.

Finally, Miller says, "Google has this other obstacle: that they make the operating system, but they don't control the phone." The first time he spotted a bug in Android, Miller notified Google and the company patched the Android source code the same day. This solution, however, didn't protect phones already in use. "They were basically at the mercy of T-Mobile [which currently offers the Android phones for sale in the US] to roll the patch out and push it out to all the phones that were in the world," Miller says. While some vendors may be responsive to security concerns on their phones, he believes that others might never roll out patches at all.

Cannings says that when a bug is found, Google notifies its carriers--currently 32 companies in 21 countries--and works to provide them with test builds of its proposed solutions. When the carriers are satisfied, they push the fix out to their customers.

No product is ever truly secure, Cannings says, but Google is working to prepare Android for the malware attacks that will inevitably come as smartphones become more popular.

http://www.technologyreview.com/computing/23241/