Kenneth van Wyk: The good and bad of Android and iOS

The good and bad of iOS and Android

A lot of people ask me which mobile platform is the most secure. They would probably like a definitive answer, but unfortunately, things aren't so black and white. There's plenty of good in the worst platform, and plenty of bad in the best. If you have a few minutes, though, I can tell you the best and worst things about the two market leaders today, Android and iOS. But you might end up feeling like one of those undecided voters who, with less than a week before the election, can't choose between the Republican and Democratic presidential candidates.

The Good and Bad of Android

Both platforms separate apps from one another in a sandbox, but my preference is for Android's approach. Is the Android approach more secure than Apple's? The jury is still out on that question. No, my preference relies entirely on my being an old Unix hand, and the Android approach is one that any Unix or Linux geek can understand and work with. With Android, each app has a unique UID and GID (user and group IDs), as in a traditional Unix-style model. This uses the tried-and-proven Unix-style discretionary file-access controls to allow an app to get to its own files and not affect others.

When you couple that sandboxing with the application manifests that Android uses, you have a pretty elegant sandbox model. Each Android app has a manifest in which it declares the privileges it needs. At installation time, the user decides whether to allow or disallow these privileges.

That's the good news for Android. Now let's consider the bad news.

That same sandbox model has some pretty bad user interface issues. For one thing, there's no "line-item veto." Users have to accept or reject all or nothing when installing an app. And they do that after they've gone to the app market and decided to install the app, possibly after paying for it. Once they've gotten to that point, how many users are going to reject the privileges? Not many, I'd wager.

And that's not my biggest Android gripe. The worst thing is Android's market fragmentation. When you buy an Android device, it's up to your product vendor to support future Android updates. When Apple releases a new version of its iOS, every iPhone, iPad and iPod Touch user has the option right away of installing it. Not so with Android. When Google releases a new version of Android -- something it does with startling regularity -- your product vendor has to then port that release for your product. Most of them take their sweet time, or don't bother with it at all.

Now, if you're a techie-inclined hobbyist, you're rolling your eyes right now and saying that's not a problem, because you know how to root your device and put generic OS releases on it. Good on you. But you surely won't be alarmed to hear me say that you aren't like most people, and I'm principally referring to generic consumers here.

For those people, it can take months for an Android release to become available for their devices, and it might not happen at all. Many product vendors just stop supporting older devices -- and by "older" I mean six months or more. That's right: You might be locked into a two-year contract with your service provider, but there's a good chance that you will never see any of Google's updates made available for your device. Seriously, at the rate Google releases new versions, you could find yourself two or three releases behind by the time that contract expires.

It is in the security area that this most matters. The fragmentation of the Android market means that app developers can't start using all the cool new security (and functional) improvements in an OS release for a long time after it's been released by Google. At least, not without disenfranchising much of their potential market. So things like keychain storage for authentication credentials just aren't widely used by Android apps yet. App developers instead have to invent their own way of securely storing such data, with predictably random results.

Apple's Security Pros and Cons

OK, so how about Apple's iOS? What's the best and worst there?

Apple's closed and regulated App Store has served its users well so far, despite the many bitter complaints from the tech community. The App Store has a vast selection, and the all-encompassing digital signature hierarchy ensures that only signed and approved apps can be installed. (Again, I'm referring to white-bread consumers here, not the niche market of jailbreakers who bypass the App Store.)

Between Apple's App Store curation and the strict enforcement of signed apps, iOS users have enjoyed a largely malware-and-Trojan-free environment -- something that Android can't even approach. Despite its restrictive nature, the App Store process gives the consumer a pretty darned safe (vs. secure) mobile app world to work and play in.

On the other hand, data protection via encryption has been a near-complete failure for iOS. Back when the iPhone 3Gs came out, we got hardware AES-256 encryption. Hooray, said the security world -- until we saw the details. Indeed, today's iOS devices all do whole-disk encryption in addition to encrypting every file on the file system. That encryption is AES-256 performed in hardware. On paper, this sounds military grade, but in practice it's not even comic-book grade, because Apple stores the primary encryption keys (the EMF! and Dkey keys) in plaintext in Block 1 of the solid-state hard drive.

In cases when an attacker has possession of a lost or stolen iOS device, only encrypted files that are further protected with keys derived from the device's unique hardware ID and the user's passcode, such as email, keychains and a few others, are somewhat protected from trivial compromise. But those AES keys can be broken in most cases, since most consumers use nothing more than a four-digit PIN to passcode lock their devices -- and many use nothing at all.

The impact of this is that app developers cannot rely on Apple's otherwise brilliant hardware AES-256 encryption to protect users' files. They too have to invent their own means of protecting data, and that also has predictably random results.

In the end, both platforms have hugely useful features, and consumers are flocking to them by the millions. But declaring a security winner is simply not feasible. Security-minded consumers are forced to choose the lesser of two evils -- which seems highly apropos in this election season.

With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.

Read more about security in Computerworld's Security Topic Center.

Join the Computerworld Australia group on Linkedin. The group is open to IT Directors, IT Managers, Infrastructure Managers, Network Managers, Security Managers, Communications Managers.

More about: AES, Apple, Brother, Carnegie Mellon University, CERT, Google, Linux, Mellon, Para-Protect, Topic
Comments are now closed.
Related Coverage
Related Whitepapers
Latest Stories
Community Comments
Tags: Mobile/Wireless, Apple, security, Networking, Access control and authentication, wireless, application security, mobile
Whitepapers
All whitepapers

Microsoft concedes Chromebooks are work-worthy

READ THIS ARTICLE
DO NOT SHOW THIS BOX AGAIN [ x ]
Sign up now to get free exclusive access to reports, research and invitation only events.

Computerworld newsletter

Join the most dedicated community for IT managers, leaders and professionals in Australia