Android made a debut with a bang in 2008. With its open source operating system, self signed apps, and freedom to upload your app on the Market; it was developers dream come true. Fast forward to today, malware for Android is growing by leaps and bounds and there is a plethora of worms and viruses infecting the Android ecosystem. Where did we go wrong?
I love my Android phone and am a huge proponent of open source technologies. But open sourced software comes packed with risks. The risks arise from it being open- sourced and very well understood. If you look from my eyes, Android has a very elegant security model. We need to understand it and make use of its security artifacts. In the next few paragraphs, I have tried to paint a very basic picture of what the Android Security model looks like.
Android Software Stack
Androids software stack is multi-layered and each layer adds to the security of the Android platform. On top of the device hardware, sits the Android operating system, which is a Linux derivative. This is where all the device drivers reside. Linux permissions provide the application sandbox so an applications data is isolated from other applications. Think of it as a multi-user platform where each user is an application.
Figure 1: Android Software Stack
The middleware consist of native libraries like libc and SSL, and the core Android runtime called the Dalvik Virtual Machine, that facilitates the execution of Java based applications. Java programmers, beware! Dalvik is NOT a security boundary. There is no security manager in Android and Dalvik does not do any security checks on your code. All permissions are enforced in the operating system.
The middleware also has application framework libraries that applications build upon. Activity Manager for instance manages the lifecycle of an activity, Package Manager manages the installation of packages, and Content Providers provide the database used by applications.
Android provides crypto libraries to do most crypto functions like symmetric and asymmetric encryption, hashing, random number generation, SSL, and certificate signing.
Most application developers work on the application layer. This is where your application and also the pre-installed applications like browser, mail, calendar reside. Applications use the permission-based model as a security mechanism.
Android Application Basics
Lets review Androids application structure to understand the permission-based model better. A typical Android application is build of components. A stack of these components along with a Manifest file makes up an Android application.
The components could be the UI elements (activities), the background processes (services), database files (content providers) or broadcast receivers that are mailboxes for your app. All Android components are protected by permissions. Calling components should have appropriate permissions to call a component. The application can also decide to hide some components that it deems sensitive.
The manifest file is the policy file that holds the application together. Besides other things, it declares the components, defines access rules, component interaction, and how components are exposed to the world. The manifest file declares all the permissions that an application will require. Some examples include permission to send an SMS from the users phone, access contact list, access device camera or Bluetooth. These are the permissions that are displayed to the user when they install the app. Be mindful of what you agree to as Android will not ask for user permission when an application is running.
Components talk to each other using Intents. Intents are asynchronous messages and can be sent by malicious applications as well. So it is always a good idea to validate them before acting on them. Using Intent Filters, a component can reduce the scope of Intents it receives, but by no mean is it a security boundary. Android also has the ability to do remote RPC but that is a blog post for later.
All Android applications are self-signed. This puts a lot of faith and trust in the hands of developers. The main idea of signing an app in Android ecosystem is to establish authorship and persistence of the application. Two applications can only share data if they have the same signature. Likewise, an app can register for auto updates only if both the installed app and the app on Google Play have the same signature.
Device Security Features
Newer versions of Android have increasing device security features that will be of special interest to IT professionals wanting to do device management and controlling their employees devices more tightly. Remote wipe has been around since early versions of Android and version 2.2 introduced the device administration API for enterprise applications with capabilities like locking the device and disabling phones camera. The Ice Cream Sandwich added address randomization and the ability to access the device keychain to store certificates and CAs securely. It also made full device encryption available for phones.
Putting it All Together
Android provides both the consumers and developers some neat artifacts to make their phones and apps more secure. Consumers should protect their phones by setting up a password and getting their device file system encrypted. Be mindful of what apps you install on your phone. Instead of zipping through the install process, read the permissions requested by an application. When in doubt, leave it out. If you think there is an app that is acting weird, or has slowed down your phone, minimize your risks by uninstalling it.
As a developer, you can never go wrong by following the principle of least privilege. Do not make a component visible if you can do without it. Define appropriate permissions on components. Validate both your input and the data blob you receive from Intents. In some cases like in Binder, you can check the caller identity as well. Refrain from passing any sensitive data through Intent, use a content provider or shared preferences instead.
Android is a powerful software stack and so much fun. No wonder it is powering crucial functions in microwaves, cars, watches, phones, tablets, TVs and plenty of other devices. Best of all, as a developer, I can engineer it to suit my needs.