What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Android Application Security Essentials

Chapter 1. The Android Security Model – the Big Picture

Welcome to the first chapter of Android Application Security Essentials!

The Android stack is different in many ways. It is open; more advanced than some of the other platforms, and imbibes the learning from attempts to develop a mobile platform in the past. In this first chapter, we introduce the basics of the Android security model from the kernel all the way to the application level. Each security artifact introduced in this chapter is discussed in greater detail in the following chapters.

We kick off the chapter with explaining why install time application permission evaluation is integral to the security of the Android platform and user data. Android has a layered architecture and a security evaluation of each architectural layer is discussed in this chapter. We end the chapter with a discussion of core security artifacts such as application signing, secure data storage on the device, crypto APIs, and administration of an Android device.

Installing with care

One of the differentiating factors of Android from other mobile operating systems is the install time review of an application's permissions. All permissions that an application requires have to be declared in the application's manifest file. These permissions are capabilities that an application requires for functioning properly. Examples include accessing the user's contact list, sending SMSs from the phone, making a phone call, and accessing the Internet. Refer Chapter 3, Permissions, for a detailed description of the permissions.

When a user installs an application, all permissions declared in the manifest file are presented to the user. A user then has the option to review the permissions and make an informed decision to install or not to install an application. Users should review these permissions very carefully as this is the only time that a user is asked for permissions. After this step, the user has no control on the application. The best a user can do is to uninstall the application. Refer to the following screenshot for reference. In this example, the application will track or access the user location, it will use the network, read the user's contact list, read the phone state, and will use some development capabilities. When screening this application for security, the user must evaluate if granting a certain power to this application is required or not. If this is a gaming application, it might not need development tool capabilities. If this is an educational application for kids, it should not need access to the contact list or need to access the user location. Also be mindful of the fact that a developer can add their own permissions especially if they want to communicate with other applications that they have developed as well and may be installed on the device. It is the onus of the developer to provide a clear description of such permissions.

At install time, the framework ensures that all permissions used in the application are declared in the manifest file. The OS at runtime then enforces these permissions.

Android platform architecture

Android is a modern operating system with a layered software stack. The following figure illustrates the layers in Android's software stack. This software stack runs on top of the device hardware. Android's software stack can run on many different hardware configurations such as smartphones, tablets, televisions, and even embedded devices such as microwaves, refrigerators, watches, and pens. Security is provided at every layer, creating a secure environment for mobile applications to live and execute. In this section, we will discuss the security provided by each layer of the Android stack.

Linux kernel

On top of the device hardware sits the Linux kernel. The Linux kernel has been in use for decades as a secure multi-user operating system, isolating one user from the other. Android uses this property of Linux as the basis of Android security. Imagine Android as a multi-user platform where each user is an application and each application is isolated from each other. The Linux kernel hosts the device drivers such as drivers for bluetooth, camera, Wi-Fi, and flash memory. The kernel also provides a mechanism for secure Remote Procedure Calls (RPC).

As each application is installed on the device, it is given a unique User Identification (UID) and Group Identification (GID). This UID is the identity of the application for as long as it is installed on the device.

Refer to the following screenshot. In the first column are all the application UIDs. Notice the highlighted application. Application com.paypal.com has the UID app_8 and com.skype.com has the UID app_64. In the Linux kernel, both these applications run in their own processes with this ID.

Refer to the next screenshot. When we give the id command in the shell, the kernel displays the UID, GID, and the groups the shell is associated with. This is the process sandbox model that Android uses to isolate one process from the other. Two processes can share data with each other. The proper mechanics to do so are discussed in Chapter 4, Defining the Application's Policy File.

Although most Android applications are written in Java, it is sometimes required to write native applications. Native applications are more complex as developers need to manage memory and device-specific issues. Developers can use the Android NDK toolset to develop parts of their application in C/C++. All native applications conform to Linux process sandboxing; there is no difference in the security of a native application and Java application. Bear in mind that just as with any Java application, proper security artifacts such as encryption, hashing, and secure communication are required.

Middleware

On top of the Linux kernel sits the middleware that provides libraries for code execution. Examples of such libraries are libSSL, libc, OpenGL. This layer also provides the runtime environment for Java applications.

Since most users write their apps on Android in Java, the obvious question is: does Android provide a Java virtual machine? The answer to this question is no, Android does not provide a Java virtual machine. So a Java Archive (JAR) file will not execute on Android, as Android does not execute byte code. What Android does provide is a Dalvik virtual machine. Android uses a tool called dx to convert byte codes to Dalvik Executable (DEX).

Dalvik virtual machine

Originally developed by Dan Bornstein, who named it after the fishing village of Dalvik in Iceland where some of his ancestors lived, Dalvik is a register-based, highly optimized, open-sourced virtual machine. Dalvik does not align with Java SE or Java ME and its library is based on Apache Harmony.

Each Java application runs in its own VM. When the device boots up, a nascent process called Zygote spawns a VM process. This Zygote then forks to create new VMs for processes on request.

The main motivation behind Dalvik is to reduce memory footprint by increased sharing. The constant pool in Dalvik is thus a shared pool. It also shares core, read only libraries between different VM processes.

Dalvik relies on the Linux platform for all underlying functionality such as threading and memory management. Dalvik does have separate garbage collectors for each VM but takes care of processes that share resources.

Dan Bornstein made a great presentation about Dalvik at Google IO 2008. You can find it at http://www.youtube.com/watch?v=ptjedOZEXPM. Check it out!

Application layer

Application developers developing Java-based applications interact with the application layer of the Android stack. Unless you are creating a native application, this layer will provide you with all the resources to create your application.

We can further divide this application layer into the application framework layer and the application layer. The application framework layer provides the classes that are exposed by the Android stack for use by an application. Examples include the Activity manager that manages the life-cycle of an Activity, the package manager that manages the installing and uninstalling of an application, and the notification manager to send out notifications to the user.

The application layer is the layer where applications reside. These could be system applications or user applications. System applications are the ones that come bundled with the device such as mail, calendar, contacts, and browser. Users cannot uninstall these applications. User applications are the third party applications that users install on their device. Users can install and uninstall these applications at their free will.

Android application structure

To understand the security at the application layer, it is important to understand the Android application structure. Each Android application is created as a stack of components. The beauty of this application structure is that each component is a self-contained entity in itself and can be called exclusively even by other applications. This kind of application structure encourages the sharing of components. The following figure shows the anatomy of an Android application that consists of activities, services, broadcast receivers, and content providers:

Android supports four kinds of components:

Activity: This component is usually the UI part of your application. This is the component that interacts with the user. An example of the Activity component is the login page where the user enters the username and password to authenticate against the server.
Service: This component takes care of the processes that run in the background. The Service component does not have a UI. An example could be a component that synchronizes with the music player and plays songs that the user has pre-selected.
Broadcast Receiver: This component is the mailbox for receiving messages from the Android system or other applications. As an example, the Android system fires an Intent called BOOT_COMPLETED after it boots up. Application components can register to listen to this broadcast in the manifest file.
Content Provider: This component is the data store for the application. The application can also share this data with other components of the Android system. An example use case of the Content Provider component is an app that stores a list of items that the user has saved in their wish list for shopping.

All the preceding components are declared in the AndroidManifest.xml (manifest) file. In addition to the components, the manifest file also lists other application requirements such as the minimum API level of Android required, user permissions required by the application such as access to the Internet and reading of the contact list, permission to use hardware by the application such as Bluetooth and the camera, and libraries that the application links to, such as the Google Maps API. Chapter 4, Defining the Application's Policy File, discusses the manifest file in greater detail.

Activities, services, content providers, and broadcast receivers all talk to each other using Intents. Intent is Android's mechanism for asynchronous inter-process communication (IPC). Components fire off Intent to do an action and the receiving component acts upon it. There are separate mechanisms for delivering Intents to each type of components so the Activity Intents are only delivered to activities and the broadcast Intents are only delivered to broadcast receivers. Intent also includes a bundle of information called the Intent object that the receiving component uses to take appropriate action. It is important to understand that Intents are not secure. Any snooping application can sniff the Intent, so don't put any sensitive information in there! And imagine the scenario where the Intent is not only sniffed but also altered by the malicious application.

As an example, the following figure shows two applications, Application A and Application B, both with their own stack of components. These components can communicate with each other as long as they have permissions to do so. An Activity component in Application A can start an Activity component in Application B using startActivity() and it can also start its own Service using startService().

At the application level, Android components follow the permission-based model. This means that a component has to have appropriate permission to call the other components. Although Android provides most of the permissions that an application might need, developers have the ability to extend this model. But this case should be rarely used.

Additional resources such as bitmaps, UI layouts, strings, and so on, are maintained independently in a different directory. For the best user experience, these resources should be localized for different locales, and customized for different device configurations.

The next three chapters talk about the application structure, the manifest file, and the permission model in detail.

Data storage on the device

Android provides different solutions for secure data storage on devices. Based on the data type and application use case, developers can choose the solution that fits best.

For primitive data types such as ints, booleans, longs, floats, and strings, which need to persist across user sessions, it is best to use shared data types. Data in shared preferences is stored as a key-value pair that allows developers to save, retrieve, and persist data.

All application data is stored along with the application in the sandbox. This means that this data can be accessed only by that application or other applications with the same signature that have been granted the right to share data. It is best to store private data files in this memory. These files will be deleted when the application is uninstalled.

For large datasets, developers have an option to use the SQLite database that comes bundled with the Android software stack.

All Android devices allow users to mount external storage devices such as SD cards. Developers can write their application such that large files can be stored on these external devices. Most of these external storage devices have a VFAT filesystem, and Linux access control does not work here. Sensitive data should be encrypted before storing on these external devices.

Starting with Android 2.2 (API 8), APKs can be stored on external devices. Using a randomly generated key, the APK is stored within an encrypted container called the asec file. This key is stored on the device. The external devices on Android are mounted with noexec. All DEX files, private data, and native shared libraries still reside in the internal memory.

Wherever network connection is possible, developers can store data on their own web servers as well. It is advisable to store data that can compromise the user's privacy on your own servers. An example of such an application is banking applications where user account information and transaction details should be stored on a server rather than user's devices.

Chapter 7, Securing Application Data, discusses the data storage options on Android devices in great detail.

Rights protected content such as video, e-books, and music, can be protected on Android using the DRM framework API. Application developers can use this DRM framework API to register the device with a DRM scheme, acquire licenses associated with content, extract constraints, and associate relevant content with its license.

Key benefits

Understand Android security from kernel to the application layer

Protect components using permissions

Safeguard user and corporate data from prying eyes

Understand the security implications of mobile payments, NFC, and more

Description

In today's techno-savvy world, more and more parts of our lives are going digital, and all this information is accessible anytime and anywhere using mobile devices. It is of the utmost importance that you understand and implement security in your apps that will reduce the likelihood of hazards that will wreck your users' experience. "Android Application Security Essentials" takes a deep look into Android security from kernel to the application level, with practical hands-on examples, illustrations, and everyday use cases. This book will show you how to overcome the challenge of getting the security of your applications right. "Android Application Security Essentials" will show you how to secure your Android applications and data. It will equip you with tricks and tips that will come in handy as you develop your applications.We will start by learning the overall security architecture of the Android stack. Securing components with permissions, defining security in a manifest file, cryptographic algorithms and protocols on the Android stack, secure storage, security focused testing, and protecting enterprise data on your device is then also discussed in detail. You will also learn how to be security-aware when integrating newer technologies like NFC and mobile payments into your Android applications. At the end of this book, you will understand Android security at the system level all the way to the nitty-gritty details of application security for securing your Android applications.

Who is this book for?

If you are looking for guidance and detailed instructions on how to secure app data, then this book is for you. Developers, architects, managers, and technologists who wish to enhance their knowledge of Android security will find this book interesting. Some prior knowledge of development on the Android stack is desirable but not required.

What you will learn

Get familiar with Android security architecture

Secure Android components using permissions

Implement cryptography algorithms and protocols to secure your data

Protect user information both at rest and in transit

Test apps for security

Understand security considerations for upcoming use cases like NFC and mobile payments

Guard the corporate data of enterprises apps

What do you get with Print?

Instant access to your digital eBook copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Download this book in EPUB and PDF formats

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Frequently bought together

$43.99

$48.99

$48.99

Total $ 141.97

Shaju Mathew Feb 17, 2014

The first four chapters are rudimentary, with some specific topics not discussed commonly in other books such as: how to share data across multiple packages by running as the same user-id, underlying Linux kernel & dalvik details, binder mechanism. The second half of the book(Chapter 6 - 10) are specific to Android Security. Chapter 5 gets into Android mobile security aspects in detail, and discusses relevant topics such as storage, DRM(applicable to tablet streaming devices/applications like the Kindle, netflix). Chapter 6 deals with encryption, RSA hash, etc that are relevant to real-world android applications. Chapter 7 reviews mechanisms to do property-store & caching using native Android features. Chapter 8 discusses DeviceAdmin features, and Chapter 9 focuses on security-focused testing. The last chapter discusses futuristic advances in the field.Overall, a useful book with a focus on security aspects on Android.

Amazon Verified review

Luca Morettoni Dec 07, 2013

I don't totally agree with the author in the section "Who this book is for" where she wrote "This book is an excellent resource for anyone interested in mobile security", I think every developer (not only the Android ones) need to develop every piece of code with the security concepts in mind!Our application need to be fast, beautiful but also secure! Think about all the personal information that we have in out phone or tablet, open any possible door to malicious apps could be a nightmare!In the book, after a brief introduction on Android application concepts, you start to analize every part of an application under the security point of view, in the book you can also find two good chapters about the crypto API and the security tests. I hope in the future editions of the book the author could expand this two parts with more examples and code snippets!The best chapter is the 7th, about the securing of application data. Every Android application store a lot of user information and is very easy to loose your device: if you're working on an application that store credit card informations or other sensible data (like medical informations or enterprise access tokens) this chapter will drive you to choice which information store and how to secure the storage!At the end of the book you have also a very nice chapter about the "future" of the mobile system and some discussion about the security perspective.Finally, the book is a good reading about the security over Android application, is not the reference guide about crypto API but is a great reading about security best practices.

Android Application Security Essentials: Security has been a bit of a hot topic with Android so this guide is a timely way to ensure your apps are safe. Includes everything from Android security architecture to safeguarding mobile payments.

What do you get with Print?

Android Application Security Essentials

Chapter 1. The Android Security Model – the Big Picture

Installing with care

Android platform architecture

Linux kernel

Middleware

Dalvik virtual machine

Application layer

Android application structure

Application signing

Data storage on the device

Crypto APIs

Device Administration

Summary

Page 1 of 8

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs

Android Application Security Essentials: Security has been a bit of a hot topic with Android so this guide is a timely way to ensure your apps are safe. Includes everything from Android security architecture to safeguarding mobile payments.

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Dalvik virtual machine

Android application structure

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs