Mobile Forensics and Android Security

This article will give you a brief introduction to mobile forensics and dive into an overview of key security features of Android security.

Today’s digital era has given rise to a number of technological advances, be it the next-gen technologies like internet of things (IOT), artificial intelligence, virtual reality or seemingly simple smartphones.

Smartphones have surpassed being a luxury in life to being the basic necessity to survive in this world. Numerous statistics show that over 50% of people worldwide use smartphones today.

The development of data storage and specifications of these phones has transformed this device from being a simple call and messaging communication device to a multi-purpose device. The smartphones today, in addition to calling and messaging, can also support other activities such as sending emails, surfing the internet, recording videos, creating and storing documents, identifying locations with Global Positioning System (GPS) services, and managing business tasks. In other words, mobile devices are now repositories of sensitive personal information.

This itself corroborates that the greater the number of smartphones, the greater the risk making mobile forensics indispensable in today’s world.

Mobile forensics

Mobile forensics deals with extracting, recovering, and analyzing data present on a mobile device through various techniques. Simply put, it works with the content stored on the device, such as the contact details, call and message details, photos and videos, stored voice messages, and browsing history. Using various techniques, mobile forensics recovers this data with integrity for a bigger purpose.

Quite often, the data sitting in a device is more valuable than the device itself. There are several reasons for the ever growing need of mobile forensics. Here are just a few of them:

· Use of mobile phones to store personal information — In today’s world, our phone is our go-to device. We store a lot of information in our phones. It is said that we can know a lot of about a person by simply browsing through their mobile device and apps, be it their tastes or even their personalities.

· Increased use of mobile phones to perform online activities — In the age of internet, technology has made it easier to not require a laptop or computer to do online activities or even conduct business. A simple internet connection can turn your smartphone into an even smarter device for browsing, shopping, networking, or even gaming.

· Uses of mobile phones in several crimes — A lot of criminal cases have been uncovered through mobile forensics. Using mobile forensics, law enforcement can get access to every contact, call, SMS, or email that the suspect had sent or received or, perhaps even better, every location that the phone had been. The fact that mobile forensics has played a crucial role in solving cases such as the 2010 Times Square car bombing attempt and Boston marathon bombings, reaffirms the increasing role of mobile forensics in solving many cases.

The Role of Operating Systems

Mobile forensics is primarily dependent on the operating system of the device. We are all familiar with Google’s Android and Apple’s iOS, which are the most popular smartphone operating systems in the industry. Since these operating systems are constantly updating, mobile forensics should also maintain pace with them through constant evolution.

Now, let’s take a look at Google’s Android when it comes to mobile forensics.

Android security

Android as a platform has certain features built into the architecture that ensure the security of users, applications, and data. Although they help in protecting the data, these security features sometimes hinder investigators from accessing important information. The security features and offerings are incorporated aim to achieve three things:

· To protect user data

· To protect system resources

· To make sure that one application cannot access the data of another application

Here’s a brief overview of the key security features in the Android operating system.

Security at OS level through the Linux kernel

The Android operating system is built on top of the Linux kernel. By having the Linux kernel at the heart of its platform, Android tries to ensure security at the OS level. Also, Android has built a lot of specific code into Linux to include certain features related to the mobile environment. Android comes with the following key security features through the Linux kernel:

· A user-based permissions model

· Process isolation

· Extensible mechanism for secure IPC

Permission model

Android implements a permission model for individual apps. Applications must declare which permissions they require. Android permissions are categorized into four levels: normal, dangerous, signature, and signature/system. Newer versions of Android prompt the user the first time each permission is required while the app is in use. This model allows a user to use an app without granting all permissions requested by the application, though functionality may be decreased.

Application sandboxing

In order to isolate applications from each other, Android takes advantage of the Linux user-based protection model. In Linux systems, each user is assigned a unique User ID (UID) and users are segregated so that one user does not have access to the data of another. Thus, each Android application assigned a UID is run as a separate process.

What this means is that, even if an installed application tries to do something malicious, it can do it only within its context and with the permissions it has. This application sandboxing is done at the kernel level. The security between applications and the system at the process level is ensured through standard Linux facilities, such as user and group IDs that are assigned to applications.

By default, applications can’t read or access the data of other applications and have limited access to the operating system. If Application A tries to read Application B’s data, for example, the operating system protects against this because Application A does not have the appropriate user privileges. Since the application sandbox mechanism is implemented at the kernel level, it applies to both native applications and OS applications. Hence, the operating system libraries, application framework, application runtime, and all applications run within the Application Sandbox. Bypassing this sandbox mechanism would require compromising the security of the Linux kernel.

SELinux in Android

Starting with Android 4.3, Security-Enhanced Linux (SELinux) is supported by the Android security model. Android security is based on discretionary access control, which means applications can ask for permissions, and users can grant or deny those permissions. Hence, malware can create havoc on the phones by gaining permissions.

Android uses SELinux to enforce mandatory access control that ensures applications work in isolated environments; this includes applications running as root or superuser. Hence, even if a user installs a malicious app, the malware cannot easily access the OS and corrupt the device. SELinux is used to enforce Mandatory Access Control (MAC) over all of the processes, including the ones running with root privileges. SELinux operates on the principle of default denial. Anything that isn’t explicitly allowed is denied. SELinux can operate in one of two global modes: permissive mode, in which permission denials are logged but not enforced, and enforcing mode, in which denials are both logged and enforced.

Application signing

All Android apps need to be digitally signed with a certificate before they can be installed on a device. The main purpose of using certificates is to identify the author of an app. These certificates do not need to be signed by a certificate authority, and Android apps often use self-signed certificates. The app developer holds the certificate’s private key. Using the same private key, the developer can provide updates to their applications and share data between applications.

In the debug mode, developers can sign the app with a debug certificate generated by the Android SDK tools. You can run and debug an app signed in debug mode but the app cannot be distributed. To distribute an app, the app needs to be signed with your own certificate. The key store and the private key that are used during this process need to be secured by the developer as they are essential to push updates.

Secure inter-process communication

System services run in separate processes and have more privileges. In order to organize data and signals between these processes, an Inter-Process Communication (IPC) framework is needed. In Android, this is achieved with the use of the Binder mechanism.

The Binder framework in Android provides the capabilities required to organize all types of communication between various processes. Android application components such as Intents and content providers are also built on top of this Binder framework.

Using this framework, it is possible to perform a variety of actions such as invoking methods on remote objects as if they were local, synchronous and asynchronous method invocation, and sending file descriptors across processes.

Binder communication model

All communications between the processes using the Binder framework occur through the Linux kernel driver, /dev/binder. The permissions to this device driver are set to world readable and writable, meaning any application may write to and read from this device driver. All communications between client and server happen through proxies on the client side and stubs on the server side. The proxies and the stubs are responsible for sending and receiving the data and the commands sent over the Binder driver.

Each service (also called a Binder service) exposed using the Binder mechanism is assigned a token. This token is a 32-bit value and is unique across all processes in the system. A client can start interacting with the service after discovering this value, which can be done with the help of Binder’s context manager. Basically, the context manager acts as a name service providing the handle of a service using the name of this service. In order to get this process working, each service must be registered with the context manager. Hence, a client needs to know only the name of a service to communicate.

The name is resolved by the context manager and the client receives the token that is later used for communicating with the service. The Binder driver adds the UID and the PID value of the sender process to each transaction. Each application in the system has its own UID and hence this value is used to identify the calling party. The receiver of the call may check the obtained values and decide if the transaction should be completed. Hence, the security is enforced and the Binder token acts as a security token as it is unique across all of the processes.

If this article has invoked the interest of learning about Android forensics, you can explore Learning Android Forensics — Second Edition, a comprehensive guide to Android forensics, from setting up the workstation to analyzing key artifacts. Learning Android Forensics — Second Edition will introduce you to the most up-to-date Android platform and its architecture, and provide a high-level overview of what Android forensics entails.