Table I
GOOGLE NEXUS S HARDWARE MODULES.
Modules Hardware
CPU Samsung Intrinsity S5PV210 1Ghz
GPU PowerVR SGX 540
Mother board Samsung S3C SoC
RAM 512 MB, 345MB Application Processor accessible
ROM 1981 MB , partitioned as boot/system/userdata/cache and radio
External Storage 13.3GB VFAT partition
Camera 5 MegaPixels Sensor S5KA3DFX
Wifi+BlueTooth+FM Boardcom BCM 4329, 802.11a/b/g/n
Touch Screen Input Atmel MaxTouch 224
Digital Compass AK8973 compass
Accelerometer KR3DM sensor
Near Field Communication NXP PN544 NFC
and eventually cause a denial of service attack. VirusMe-
ter [24] models the power consumption and detects the mal-
ware based on power abnormality. However, the use of linear
regression model with static weights for devices’ relative rate
of battery consumption is a non-scalable approach [27].
Bickford et al. [14] uses three example rootkits to show
that smart phones are just as vulnerable to rootkits as desktop
operating systems. However, the ubiquity of smart phones
and the unique interfaces that they expose, such as voice,
GPS and battery, make the social consequences of rootkits
particularly devastating. Cloaker [16] is a non-persistent
rootkit that does not alter any part of the host operating
system (OS) code or data, thereby achieving immunity to all
existing rootkit detection techniques which perform integrity,
behavior and signature checks of the host OS. Cloaker
leverages the ARM architecture design to remain hidden
from current deployed rootkit detection techniques, therefore
it is architecture specific but OS independent. Bojinov et al.
proposed a mechanism of executable ASLR that requires
no kernel modifications for defending remote code injection
attacks for mobile devices [15]. TaintDroid [18] addresses
the security issues with dynamic information flow and
privacy on mobile handheld devices by tracking application
behavior to determine when privacy-sensitive information
is leaked. This includes location, phone numbers and even
SIM card identifiers, and to notify users in realtime. Their
findings suggest that Android, and other phone operating
systems, need to do more to monitor what third-party
applications are doing when running in smart phones. Our
encryption filesystem protects the static data on storage in
complimentary.
III. BACKGROUND & THREAT MODEL
A. Background
Google’s Android is a comprehensive software frame-
work for mobile devices (i.e., smart phones, PDAs), tablet
computers and set-top-boxes. The Android operating system
includes the system library files, middle-ware, and a set
of standard applications for telephony, personal information
management, and Internet browsing. The device resources,
like the camera, GPS, radio, and Wi-Fi are all controlled
through the operating system. Android kernel is based on
an enhanced Linux kernel to better address the needs of
mobile platforms with improvements on power management,
better handling of limited system resources and a special
IPC mechanism to isolate the processes. Some of the system
libraries included are: a custom C standard library (Bionic),
cryptographic (OpenSSL) library, and libraries for media
and 2D/3D graphics. The functionality of these libraries
are exposed to applications by the Android Application
Framework. Many libraries are inherited from open source
projects such as WebKit and SQLite. The Android runtime
comprises of the Dalvik, a register-based Java virtual ma-
chine. Dalvik runs Java code compiled into a dex format,
which is optimized for low memory footprint. Everything
that runs within the Dalvik environment is considered as
an application, which is written in Java. For improved
performance, applications can mix native code written in
the C language through Java Native Interface (JNI). Both
Dalvik and native applications run within the same security
environment, contained within the ‘Application Sandbox’.
However, native code does not benefit from the Java ab-
stractions (type checking, automated memory management,
garbage collection). Table I lists the hardware modules of
Nexus S, which is a typical Google branded Android device.
Android’s security model differs significantly from the
traditional desktop security model [2]. Android applications
are treated as mutually distrusting principals; they are iso-
lated from each other and do not have access to each others’
private data. Each application runs within their own distinct
system identity (Linux user ID and group ID). Therefore,
standard Linux kernel facilities for user management is
leveraged for enforcing security between applications. Since
the Application Sandbox is in the kernel, this security model
extends to native code. For applications to use the protected
device resources like the GPS, they must request for special
permissions for each action in their Manifest file, which is
an agreement approved during installation time.
Android has adopted SQLite [12] database to store struc-
tured data in a private database. SQLite supports standard