What we are solving and why it is important (section 1)
Over the last several years, innovations in the advancement of computing and communication hardware
have allowed mobile phones to evolve into affordable general-purpose computing platforms. In the
fourth quarter of 2010 alone, 101.2 million smart phones were sold worldwide, a growth of 88.6% from
a year ago (1). These phones are equipped with a rich set of hardware interfaces and software
applications that allow personal and corporate users to interact with both the cyber and physical world
through internet access, email, SMS, and location based services. To support the increasing complexity
of software and hardware, Linux, Windows, and Symbian based operating systems with tens of millions
of lines of code have been deployed to manage smart phone resources. With the increased adoption of
smart phones into our daily lives and their large attack surface, it is no surprise that malware writers
have begun targeting mobile phones. In a study conducted by F-Secure in 2007, 373 unique instances of
malware were found to target mobile platforms (2).
This paper aims to increase security of mobile platforms by providing a comprehensive study along with
a mitigation mechanism aimed at a subset of malware known as kernel-level rootkits. A rootkit is a tool
that enables administrative-level access to a computer allowing it to stealthily carry out malicious goals.
For example, a rootkit may employ stealthy techniques such as hiding processes and open files used to
carry out malicious activities to avoid detection. While occurrences of rootkits targeting mobile
operating systems have been limited to research publications (3) (4), it is only a matter of time until
malware developers begin leveraging rootkits against smartphone operating systems.
We plan to implement our mitigation mechanism on the Android software stack that is built on top of
the Linux operating system. We chose this platform because (a) Android software along with Linux
operating system are freely available, thereby allowing us to study and modify data structures at will;
and (b) the existing Android development environment provides debugging and emulation tools that
ease experimentation.
To limit the exposure of sensitive data to rootkits, we plan to add encryption into the Linux kernel and
Android application libraries. While the Android framework enforces security permissions at the
application level to prevent unauthorized access to sensitive data (i.e. GPS, contacts, email, SMS) (5),
rootkits can undermine these permissions due to the fact that they operate within the kernel where
they have full access to all of the system resources. Our proposed encryption module ensures that data
is stored in an encrypted format and is only decrypted when presented to an application that the user
has granted sufficient privileges to. We understand that this approach has limitations. We are assuming
the user has carefully assigned privileges to trustworthy applications. We also realize that rootkit
developers could reverse engineer our encryption mechanism and compromise our approach. Given the
present state of rootkit prevention on smart phones, we feel that our approach significantly raises the
level of effort required by rootkit developers to gain access to sensitive data.
Related Work – How other people solved and why they fell short (section 2)
Rootkit detection and/or prevention is a common problem that has been researched heavily in the
realms of servers and personal computers. But, there is less research in the area that is specific to smart
phones such as the Android. However, many of the proposed detection methods for rootkits on desktop
computers still apply to smart phones, but they are often not feasible due to operational differences and
computational needs (Ref: 3). An example of this is that rootkit detection applications exist that aim to
continually scan contents of memory and/or the file systems looking for invalid modifications.
Rootkit detection and prevention techniques have been heavily researched in the context of servers and
personal computers. While this research applies to Android’s underlying operating system, Linux, the
techniques used are not feasible on mobile platforms due to operational differences and computational
needs. For example, [7,8,9] make use of computation-intensive periodic scans of memory looking for
invalid modifications (Ref: 3). This type of detection mechanism is too computational intensive for an
Android mobile device and would ultimately drain the battery life. A similar approach that has been
proposed is to offload the scanning computations to an outside source such as a computer that the
Android phone could be connected to(Ref: 6). The proposed solution in this approach is to download
changed files from the mobile device onto a remote computer connected via USB where rootkit
detection software is run.. This design removes the downside of the battery life being consumed on the
mobile device, however, it falls victim to only being able to do scans at varying times that the mobile
phone user plugs the device into a remote computer. In addition, the method used to acquire data from
the phone could be compromised by a rootkit.
The most notable defense strategies applicable to Android are that of additional hardware support on
the device and the use of detection/prevention methods inside a virtual machine monitor (VMM) on the
mobile device (Ref: 3). An example of additional hardware support would be to introduce a TPM chip on
the Android phone and remotely verify the integrity of the phone(Ref: 3). This approach could also drain
too much battery life if the solution was not efficient and we aim to propose a solution that requires no
hardware modifications. This approach suffers from adding additional hardware to a platform that is
already very restrictive in terms of cost and hardware footprint. The idea of building detection methods
into a VMM running on the mobile device is most likely the best option for success in general. Having
access to code that lives below the operating system is the most complete way to ensure that rootkits
can be prevented since no other rootkit or malware would have access to the VMM layer. The problem
with this approach is that no VMM is currently in existence for Android mobile phones and that the
proposed solution risks being to computationally intensive (Ref: 3). The benefit to our approach is that
the solution is applicable to any future type of rootkit as well as those currently in existence since we
aim to protect all sensitive data on the device. We also feel that our design is less intensive in terms of
battery usage due to the fact that sensitive information is only encrypted/decrypted on demand and to
finite amounts of data rather than frequently scanning all of memory and/or the file system at regular
time intervals.
(Optional) What is difficult about this problem (section 3)
Currently no VMM known that works for Android (so adding security beneath the OS kernel is not a
largely known possibility right now)
Most techniques are very computation intensive (and power consumption is a big focus for Android)
Our plan and why it is better than other approaches (what we plan to do) (section 4)
- Encrypt sensitive data on the phone (SMS, voicemail, GPS data, contacts, etc.) so that it cannot be
easily consumed by a rootkit/malware that was not given specific access to that data
- Monitor Android applications 'Intents' against what data they actually access (and report violations)
based on what the application is permitted to do (i.e. if an application does not have an intent to look up
the GPS information, then if it tries to grab that data we detect this)
Anticipated results (section 5)
We anticipate being able to demonstrate that some piece of malware or rootkit on the phone that was
never explicitly given access to sensitive data is not able to retrieve decrypted data. In essence, if a piece
of malware that was never given this special permission (capability), then if it tries to access something
it should not the event is detected, logged, and prevented or mitigated (by giving encrypted data to the
piece of malware).
We should be able to do some research about the power efficiency of our approach. We should aim to
increase power usage by no more than some percent or something along these lines (we ought to be
able to come up with some reasonable measurement that can be proven or not).
Works Cited
1. Canalys. Google’s Android becomes the world’s leading smart phone platform. [Online] January 31,
2011. http://www.canalys.com/pr/2011/r2011013.html.
2. F-Secure Corporation. Sate of CELL PHONE Malware in 2007. http://www.usenix.org. [Online] 2007.
http://www.usenix.org/events/sec07/tech/hypponen.pdf.
3. Rootkits on Smart Phones: Attacks, Implications and Opportunities. Bickford, Jeffrey, et al. New York :
ACM, 2010. Eleventh Workshop on Mobile Computing Systems & Applications.
4. This is not the droid you're looking for... Trustwave SpiderLabs. s.l. : DEF CON 18, 2010.
5. Google. Security and Permissions. Android Developers. [Online]
6. On Rootkit and Malware Detection in Smartphones [Online]
7. A. Baliga, V. Ganapathy, and L. Iftode. Automatic inference and enforcement of kernel data structure
invariants. In Proc. Annual Computer Security and Applications Conference, 2008
8. N. L. Petroni Jr., T. Fraser, J. Molina, and W. A. Arbaugh. Copilot - a
coprocessor-based kernel runtime integrity monitor. In Proc. USENIX
Security Symposium, 2004
9. N. L. Petroni and M. Hicks. Automated detection of persistent kernel control-flow attacks. In Proc.
ACM Conference on Computer and
Communications Security, 2007
*****************************************************************************
Notes for Section 2 that I moved down here (after writing it)
*****************************************************************************
Detecting and preventing rootkits is challenging, even on desktop systems any detection mechanism
must work beneath the operating system.
Specialized hardware – impractical for mobile footprint where space is limited
VMM – good for servers, but too resource intensive for embedded platforms. Also, little work has been
done on developing vmms for smart phones (reference state of vmm on smart em
Off-load scanning of files to remote system - rootkit detection based on file hashes (each time the
phone is connected to a PC via USB, the PC downloads any files that changed and computes a hash of
them and compares it to a previous hash) [Ref: 6]
Kernel level rootkit detectors (chkroot) have been ported to android, but resource constraints have
limited their approach (frequent scans drain battery) , and relies upon a large body of existing rootkits.
Anomaly detection learning algorithms computationally intensive and require a large data store. To
avoid resource limitations, other scanners (On Rootkit and Malware Detection in Smartphones) have
offloaded to pc.
- (Other rootkit detectors as well. The problem with these is that they are very resource
intensive and require lots of computations. This is not a good thing for Android due to battery power.)
Our approach protects against generic and future rootkits by encrypting information. Only requires
battery power when a user attempts to access sensitive information (much less frequent that scans?)