By the end of this current year, 1.4 billion smartphones will be in use: 798 million of them will run Android, 294 million will run Apple’s iOS, and 45 million will run Windows Phone, according to a new study by ABI Research.
This is an incredible number of smartphone users which are connected to the big wide web. But how secure are they ? Is it possible for a mobile operating system to be secure ? Or is it insecure from the roots up ?
As you already might guess I will only be covering the Android part, not surprisingly they have the bigger marketshare. So, how do you ‘test’ a secure mobile system ?
A system can be locked down extremely but this can have an impact on the user friendliness, where do you draw the line ? How do we test if a given Android system is secure. Do we forget the user friendliness or are we considering the bigger picture : a secure , user friendly, Android system. I think considering the bigger picture is a more realistic impact as it includes the user’s behavior, which makes up a great part of the system’s security.
Let’s take a look at the security mechanisms Android has implemented for save distribution of applications. Android applications are shared through the Google Play Store. Android has two important security mechanisms which involve distribution and installation of apps in order to protect the installing user from malicious actions.
- applications need to be signed
- applications need permissions to access phone functions
Applications need to be signed with a special unique key that a developer can obtain. The signing of an application can be thought of as providing the application of a digital certificate. With this certificate Android aims on establishing trust relationships between applications. For example consider an app which we call “AppX”. If “AppX” is first installed, it is signed with a specific private key. If the developer upgrades “AppX” to “AppX2″, he needs to use the same key which he used to sign “AppX”. This creates a trusted relationship between “AppX” and “AppX2″, because only the developer that holds the key for “AppX” can develop an upgrade for the app. But is this waterproof ?
Probably u know the answer already because else I wouldn’t have hinted it. Well, no this is not waterproof. A rather invasive bug was found in the signing process.
The core issue is that Android package (APK) files are parsed and verified by a different implementation of “unzip a file” than the code that eventually loads content from the package: the files are verified in Java, using Harmony’s ZipFile implementation from libcore, while the data is loaded from a C re-implementation.
The way that these two implementations handle multiple files with the same name occurring in the zip file differs. The way the Java implementation reads the file is that it goes through the “central directory” and adds each entry to a LinkedHashMap. The key the entry is stored using is the name of the file.
Later, the PackageParser goes through each entry in the zip file, verifying that the file was signed with a consistent signature. This code iterates over the LinkedHashMap. The result is that only the last entry with a given name is considered for signature verification: all previous duplicates are discarded.
Source : Saurik
This is a rather technical explanation of the bug, so a more noob explanation follows. As .APK files are nothing more than JAR files, this is where the problem lies. Where a JAR stands for Java ARchive, a sort of folder with all your Java code. If you want to ensure the integrity of a JAR as a self-contained entity such as an Application then the ability to sign individual files is not a requirement. In fact it is difficult to see in what circumstances the ability to sign individual files and only individual files could be a requirement.
Because it is only possible to sign individual files, a signed JAR is really nothing more than a collection of files which may or may not be signed and the verification of a signed JAR is a very convoluted way of determining into which category each file belongs. All of which leads us to question of what signed JARs are actually for ?
The ability to package files in this way was presumably considered useful when the specification was produced but it is clear that it is a decidedly sub-optimal way of attempting to ensure the integrity of an Application made up of a number of files which have been packaged as a ZIP file.
While signed JARs undoubtedly constitute a flexible mechanism for doing something, its just not clear what, they do so at a cost.
As we have seen the cost is the complexity of the verification process and the inconclusiveness of the result.
The process of verification is ridiculously complicated and consequently dangerously error-prone which is not what you want from something which is a key part of ensuring the security of your platform. (Source : Simon Lewis)
Now, what can a user do about this ? Nothing much actually. The bug is known for some time now, the only actions Google has taken so far was to change something in the .APK submission in the play store. A fix to the devices is coming with Android 4.3 . Older devices need to install the CyanogenMod custom ROM. They have included the 4 LINE BUGFIX, which google failed to deliver OTA.
Next up on the list was “Permissions”. Every app needs specific permissions to access phone functions. As an example I will include permissions my currently developing app needs :
<uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /> <uses-permission android:name="android.permission.WRITE_INTERNAL_STORAGE" /> <uses-permission android:name="android.permission.READ_LOGS"/> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> <uses-permission android:name="android.permission.WAKE_LOCK" /> <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" />
These permissions look like they’re asking a lot, but the only access they give to the phone are :
- The use of internet
- Ability to write to SD card(= caching images) and internal memory (= for settings)
- Read error log on crash to send back a detailed error log to me
- Google Cloud Messaging service
- Accessing the network state , to check if there’s an internet connection
- And wake lock, my app uses a service that needs to run with or without the app running , so the services needs a wake lock
These permissions will be shown to the user upon install. So this is the part where the user’s common sense plays a big part. If you want to play a game and the game asks for a whole list of permissions, the game is usual spyware. It will collect as much info as it can and will send it back to a server. The maintainers of this server will use the information to sell to advertising companies. So reading through the permissions is not time lost, as they can be pretty invasive on the privacy of the phone user.
So I did not reach a conclusion, as it as a whole research on its own (maybe a master thesis ? ;-) ). But I hope I gave some pointers that there’s a huge gap between user friendliness and optimal security of a mobile system. Any comments or questions, shoot !