sign in sign up
<<
Home , Assembly language, Buildroot, Motorola A780, OpenEmbedded, Openmoko, Opkg

The Pennsylvania State University The Graduate School

PROVIDING VERIFIABLE INTEGRITY ON MOBILE

PLATFORMS

A Thesis in Electrical Engineering by Anuj Sawani

2008 Anuj Sawani

Submitted in Partial Fulfillment of the Requirements for the Degree of

Master of Science

August 2008 The thesis of Anuj Sawani was reviewed and approved∗ by the following:

Trent Ray Jaeger Associate Professor of Science and Engineering Thesis Co-Adviser

George Kesidis Professor of Electrical Engineering and and Engineering Thesis Co-Adviser

Ken Professor and Head of the Department of Electrical Engineering

∗Signatures are on file in the Graduate School. Abstract

Mobile phone systems are becoming as advanced and powerful as desktop comput- ers. They now provide services beyond telephony, such as browsing the internet, personal information management or even playing games. However, third-party ap- plications, such as mobile games, could execute malware on the phone and threaten to affect the integrity of trusted like clients. The goal is to prevent trusted or code from being affected by untrusted software with mini- mum overhead. The phone has limited processing power and we to show that an optimized security running on the phone does not affect the performance significantly. We use the Security Enhanced (SELinux) framework combined with Policy Reduced Integirty Measurement Architecture (PRIMA) to provide in- tegrity guarantees to remote parties. Each of these components have been ported to work with an ARM-based platform. Further, the SELinux policy loaded at boot time also ensures that the trusted software is not compromised at any time. On average, we found that the phone takes approximately 0.03 seconds to perform an integrity measurement on a 150KB file. This negligible overhead does not affect performance significantly while assuring integrity of the phone. Our work shows that the approach is practical and will provide a basis for the future development of a standard security framework for systems.

iii Table of Contents

List of Figures vii

List of Tables viii

Acknowledgments ix

Chapter 1 Introduction 1 1.1 The Mobile Era ...... 1 1.2 Open Mobile Phone Systems ...... 2 1.2.1 Linux as a Mobile Platform ...... 3 1.3 Thesis Contribution ...... 3 1.4 Thesis Structure ...... 5

Chapter 2 Background 7 2.1 Mobile Phone Architecture ...... 7 2.1.1 Linux-based Mobile Phones ...... 7 2.1.2 Software Stack ...... 9 2.2 SELinux and Integrity Measurement ...... 11 2.2.1 Trusted Platform Module (TPM) ...... 11 2.2.2 Integrity Models ...... 12 2.2.3 Integrity Measurement Architecture(IMA) ...... 13 2.2.4 Policy Reduced Integrity Measurement Architecture (PRIMA) 14 2.3 Cross-compiling for ARM CPU ...... 15

Chapter 3 Related Work 17

iv 3.1 Software based Integrity Measurement on Embedded Platforms . . 18 3.1.1 SWATT and Genuinity ...... 18 3.1.1.1 Attack on Genuinity ...... 19 3.1.2 Pioneer ...... 19 3.1.3 Energy and Execution Time Analysis of Software based TPM 20 3.2 Hardware based Integrity Measurement on Embedded Platforms . . 20 3.2.1 ARM TrustZone ...... 20 3.2.2 ’s Authenticated Flash ...... 22 3.3 Linux-based Solutions ...... 22 3.3.1 Montavista’s Mobilinux ...... 22 3.3.2 ’s MotoAC ...... 23

Chapter 4 Vulnerability and Security Analysis of Mobile Platforms 24 4.1 Threat Model ...... 24 4.1.1 Physical device ...... 25 4.1.2 Wireless Attacks ...... 25 4.1.3 DoS attacks ...... 26 4.1.4 Network attacks ...... 26 4.1.5 Worms and Virus ...... 26 4.2 Linux Platform ...... 27 4.2.1 Montavista Linux ...... 27 4.2.1.1 Motorola A780 ...... 27 4.2.1.2 Motorola A1200 ...... 31 4.2.2 OpenMoko ...... 33 4.3 Platform ...... 35

Chapter 5 Approach 36 5.1 The Goal ...... 36 5.2 System Architecture ...... 37 5.3 SELinux ...... 38 5.4 Integrity Measurement ...... 38 5.5 System Security ...... 39

Chapter 6 Building a Mobile Platform with Integrity Measurement 41 6.1 Experimental Setup ...... 41 6.1.1 Evaluation Board ...... 42 6.1.2 OpenMoko Phone ...... 43

6.2 Cross-compiling with OpenEmbedded ...... 44 6.2.1 Basic concepts of OpenEmbedded ...... 45 6.3 Enabling SELinux ...... 46 6.3.1 SELinux Policy design ...... 47 6.4 Modifications ...... 48 6.4.1 Kernel ...... 49 6.4.1.1 JFFS2 and xattr support ...... 50 6.4.2 RootFS ...... 50 6.4.3 Software Installer ...... 50 6.5 Verifying integrity measurement ...... 51 6.5.1 Package Installer ...... 52 6.5.1.1 Install a trusted package ...... 52 6.5.1.2 Install an untrusted package ...... 52 6.5.1.3 Invoke installer by an untrusted process ...... 53 6.6 Performance Results on Mobile Hardware ...... 53

Chapter 7 Conclusion 56

Bibliography 58

vi List of Figures

2.1 Organization of on-board flash memory of Linux mobile phones . . 8 2.2 Openmoko Software Stack ...... 10 2.3 The decision process of SELinux ...... 12

3.1 ARM TrustZone System Architecture ...... 21 3.2 Intel’s Authenticated Flash ...... 22

4.1 Motorola A780’s Mode ...... 30 4.2 The functioning of gsmd ...... 34

5.1 The proposed mobile phone system architecture ...... 37

6.1 Overview of the integrity framework ported for mobile phone hard- ware ...... 42 6.2 The OMAP 5912 OSK Evaluation Board ...... 43 6.3 Implementation of the filtering interface in the software installer . . 49

vii List of Tables

4.1 A possible mapping of mux devices ...... 32

6.1 Comparison of boot time on the Openmoko phone ...... 54 6.2 Time taken to measure files of varying sizes ...... 54 6.3 Output of openssl speed sha1 - speed measurement of SHA1 hash 55

viii Acknowledgments

First and foremost, I would like to offer my sincerest gratitude to my advisor, Dr. Trent Jaeger, who has supported me with his knowledge, guidance, patience and encouragement during the course of my research. He steered me in the right direction whenever I needed it and without him, this thesis would not have been possible. I would also like to thank my student colleagues, Divya Muthukumaran, Mo- hamed Hassan and Josh Schiffman with whom I collaborated during my research. Each of us with our own expertise complemented each other perfectly as a team. I am grateful to the Penn State Systems and Internet Infrastructure Security (SIIS) laboratory where I did my research. I would also like to thank my committee members, Dr. George Kesidis and Dr. Ken Jenkins for supporting my thesis and research. Finally, I thank my parents for supporting me throughout my studies at the university.

ix Chapter 1

Introduction

1.1 The Mobile Era

In the last decade, cellular phones have evolved tremendously. In the beginning, mobile phones were huge impractical devices whose functions supported only mak- ing calls or receiving calls. Very soon, they started supporting short messaging services while the size of mobile phones became smaller. But now, mobile devices are capable of performing every function that a can perform. We now term these phones as smart phones. These phones are very powerful com- puting devices that are capable of functions like Email, Web Browsing, Personal Information Management and run custom applications. In 2007, more than 1.15 billion phones were sold worldwide. This large number emphasizes the widespread reach of mobile phones currently. Most users of these phones install third party applications at some point of time while using the phone. Now, there is no guarantee that these applications will not perform malicious activity on the phone. In most cases, these applications have read and write access to the phone’s filesystem. Hence, they are capable of affecting the phone’s functionality without the user’s knowledge. Some of the applications that are installed on the phone could turn out to be worms or virus that are coded to spread through any communication channel it can find. The mobile phones usually provide various channels for communica- tion with other devices. These channels include Infrared, , Wifi, USB, GPRS/EDGE/EVDO, etc. 2

An important point to note for smart phones is that the operating systems have now become standard for phones. Most operating systems have released a mobile version which are compatible with various phone models. Currently, the market is dominated by three most common operating systems: Symbian, Windows and Linux. Hence, there is a lack of diversity in the market which allows attackers to target these operating systems while creating worms or virus. The complexity of these devices does add functionality to the user, but it also opens up many doors for malware to slip in. Hence, with all these views in mind, the need for security on mobile phones is obvious.

1.2 Open Mobile Phone Systems

A new trend to open up mobile platforms has gained momentum in the past year. Why do we need open source mobile systems? A fully featured, fully open source mobile handset could help reduce the cost of mobile telecommunications and give users access to a rich set of low cost applications for personal use. On the other hand, certain companies prefer a standard and familiar that makes it easier for users to use the device. But, with the flexibility offered by open source mobile devices, it has been gaining popularity very rapidly. Though there have been various initiatives to bring out a completely open source mobile software stack, two of the most notable ones are Google’s Android [1] and FIC’s Openmoko [2]. Google’s Android is a software platform and based on Linux. Developers can write applications for the platform using -like code using Java libraries provided by Google. Contrary to what Google claims, Android is not completely open-source as some parts of the code are still proprietary. Openmoko is an initiative led by FIC and they provide a completely open mo- bile platform. They allow developers to write applications for the platform targeted at the mobile hardware sold by them. To prove the openness of their mobile platform, they have even gone to the extent of releasing the CAD files for the handset’s case design. But, along with the openness of the mobile platform, comes the responsibility of using this freedom wisely. With complete knowledge of the underlying system, 3 attackers could devise very powerful and customized attacks targeted at mobile devices or the cellular networks. Hence, there is a urgent need to find a tamper- proof method to secure these devices without compromising on the advantages offered by open platforms.

1.2.1 Linux as a Mobile Platform

Linux is known to be one of the most robust operating systems available. With its high functionality, flexibility, and proven track record as an operating system, it is logical to introduce it into the mobile phone market. The kernel’s modular nature provides the option of removing components that are not required in the target platform. Further, the kernel being open-source provides various improve- ments being submitted from the developer community. The open-source nature also allows developers to customize the system to suit the target hardware. For example, Openmoko’s software stack is based on Linux stripped down to boot and operate faster on ARM-based hardware. Also, many other organizations have now taken on Linux as a primary platform for their handsets. Further information on embedded Linux devices can found at [3]. Recently, Motorola, NEC, NTT DoCoMo, Panasonic Mobile Communications, , and Vodafone established an independent foundation known as the LiMo Foundation [4]. The foundation aims to deliver richer mobile systems to consumers and reduce the time to market for building and delivering these platforms. Further, they encourage the Linux community to play a more active role in the development of mobile applications. Finally, the objective is to develop a world-class Linux- based platform for mobile phones.

1.3 Thesis Contribution

While mobile phones transition from just phones to smart devices, they are triggering new security risks and threats. The main aspect to note is that the mobile devices will provide more diverse functionality in the future, while the mobile handset architecture will become more unified in terms of operating system, standardization and open specifications. Hence, the mobile systems will become 4 increasingly vulnerable to attacks targeted at the mobile platform. Looking at the present scenario, there are already a variety of mobile applica- tions that should be executed in a secure and trusted environment. An example of such an application would be the existence of a mobile banking client from most major banks. Unfortunately, with the co-existence of all the applications on the same device, it is difficult to isolate one from the other. Thus, we look into how the security of current Linux-based mobile systems can be circumvented. This perspective of an attacker helps us to identify the various channels of attack and also provides a fairly detailed understanding of Linux on mobile devices. Finally, we use the lessons learnt from the attacks and form a powerful as well as dynamic security framework for mobile devices. Hence, the thesis statement can be summarized as: Implementation of Mandatory Access Control (MAC) in a that is capable of providing integrity guarantees to remote parties based on the identification and implementation of possible attacks on current Linux-based mobile devices The work presented in this thesis mainly provides a detailed study of designing, building and implementing a security framework on a mobile platform. Specifically, the contribution of the thesis can be listed as follows:

Comparison of Software and Hardware based Integrity We provide a tax- onomy on the available possibilities of software-based integrity measurement techniques. Introducing a hardware chip in mobile phones results in an ex- pensive addition, hence, the option of a software-based trusted computing base is explored.

Analysis of Linux mobile platforms To clearly understand the requirements of a secure framework, we first performed a study on the various channels of attack possible for mobile platforms. Then, we compromised two different Motorola phones that are based on Linux. Finally, we analyzed the lack of security on the open-source OpenMoko mobile platform and proposed a design to approach the problem of providing integrity on phones.

Building a mobile phone platform with integrity measurement We used the Openmoko phone as our target device and cross-compiled all required 5

code to work with the phone. We ported SELinux and PRIMA to work with the ARM-based CPU and the required kernel version. The SELinux policy was enforced over the file system to prevent unwanted information flows. We also modified the installer to leverage this integrity framework and showed that the installer worked correctly with sample packages. Finally, the performance of our framework is tested and is proved to be a practical approach to improving security of mobile phones.

1.4 Thesis Structure

This thesis is structured as follows. In Chapter 2, we first provide an overview of the general architecture of mobile phones, specifically Linux mobile phones. Then, we provide an introduction to SELinux and integrity measurement in Section 2.2. Finally, we describe the basic definitions and concepts required to understand cross-compiling in Section 2.3. In Chapter 3, the current research in the field of integrity measurement and security on mobile phones is discussed. In Section 3.1, we analyze the various proposed models to implement integrity measurement without the use a hardware chip. Then, in Section 3.2, the cutting edge technology of mobile platforms with hardware-based security is introduced. Further, Section 3.3 briefly mentions recent attempts to provide security on mobile phone systems. In Chapter 4, we study the various channels of attack for mobile platforms and discuss some example Linux based platforms. In Section 4.2, two phones, Motorola A780 and Motorola A1200, are analyzed and the security flaws are dis- cussed. Later, we also discuss the lack of security on the new open-source mobile platform, Openmoko. Finally, Section 4.3 briefly introduces the security model of the Symbian Platform. In Chapter 5, an architecture to provide integrity measurement on mobile plat- forms is proposed. The chapter outlines how SELinux, PRIMA and the installer work together to protect the integrity of the trusted software on the phone. Chapter 6 describes in detail the process to build SELinux, IMA and PRIMA into the Openmoko distribution. Section 6.1 describes the target platforms that we used to perform our experiments. Then, Section 6.2, gives a detailed walk-through 6 on how to cross-compile using OpenEmbedded. Section 6.3 describes the method to setup SELinux on the mobile system. In Section 6.4, all the modifications to the software stack are described. The end of the chapter describes our experiments to prove that our model works well on the phone, and we finally analyze the performance of the phone system after including all our modifications. Finally, Chapter 7 provides the conclusion and describes possibilities of extend- ing this work in the future. Chapter 2

Background

This chapter describes the concepts that are required to understand the thesis clearly. First, the architecture of Linux based mobile phones is discussed in Sec- tion 2.1. Specifically, the design of the Openmoko software stack is outlined in Section 2.1.2. Then, the of SELinux and Integrity Measurement are in- troduced in Section 2.2. With the basic understanding of mobile phones and the security framework, Section 2.3 details the use of cross- for our experi- ments.

2.1 Mobile Phone Architecture

Most mobile phones in the market follow a standard architecture with some vari- ations. Basically, a core operating system runs over the hardware. Above the operating system, the necessary services are active. Finally, applications are exe- cuted using these services. We note that a JAVA environment might be present that allows the installation of third-party applications. Since it is hard to gener- alize a common architecture, we emphasize on Linux phones. The next section describes the basic organization of Linux phones.

2.1.1 Linux-based Mobile Phones

The most challenging aspect of Linux on mobile phones is the fact that physical resources are limited. Processor speed, memory size and power consumption are 8

Figure 2.1. Organization of on-board flash memory of Linux mobile phones the main constraints when designing the system. The Advanced RISC Machines (ARM) family of processors is the most popular for smart phones. These phones are designed with 32MB to 256MB RAM and 32MB to 256MB of Flash ROM Memory which stores the phone operating system and oftware. The structure of the flash memory can be outlined as shown in Figure 2.1. Now, we describe each of these parts in further detail.

Bootloader The bootloader initializes the hardware and is the first set of in- structions that the phone will execute. After basic hardware initialization, the bootloader loads the kernel with the required boot parameters. Additional func- tionalities of the boot include firmware upgrade, self-upgrade and basic configuration. During the development phase of phone systems, the bootloader allows uploading of kernel and filesystem images to the flash memory.

Kernel The first few linux mobiles phones used the v2.4 series. But now, the v2.6 series has been ported to many architectures and can be used as an operating system on phones. The new open source mobile platform, Openmoko, 9 and Trolltechs Qtopia are both based on v2.6 and work seamlessly with mobile hardware. These kernels are configured to support the minimal set of hardware and features as mobile hardware is fixed by the manufacturer. For our implemen- tation on the evaluation board(Section 6.1.1), we used a v2.6 kernel with SELinux enabled. We included phone related drivers for the filesystem(ext3 with extended attributes), LCD backlight, keypad and the touch screen. We have also included IMA and PRIMA support.

Filesystem As the filesystem loaded onto flash memory, there are some limita- tions that can affect the choice of filesystem. , though known as the fastest writable media, has two important drawbacks:

• The memory is divided into large erasable blocks making it very inefficient for frequent writes of short data

• A typical flash memory cell has a limited number of write cycles(approx 100K cycles per block) before it fails.

For SELinux to work, a filesystem that supports extended attributes is needed. In Linux, the ext2, ext3, ext4, JFS, ReiserFS and XFS filesystems support extended attributes. Though some phones in the market use ext2/ext3, the JFFS2, or Journaling Flash 2, has been designed to address the drawbacks of flash memory.

Upgrade Space This memory space is provided in case future upgrades have larger memory requirements.

2.1.2 OpenMoko Software Stack

The Openmoko software stack is completely open-source and available for down- load in the source repository of Openmoko. It utilizes the v2.6 Linux kernel and includes device drivers for all the hardware on the mobile phone. As shown in Figure 2.2, the stack then includes the basic services over the Linux kernel. We note that some of these have been ported for the phone and the others have been written from scratch. This has been depicted using white outlines in the Figure 2.2. 10

Figure 2.2. OpenMoko Software Stack [Source: http://www.openmoko.com]

Also, it can be seen that Openmoko uses -Bus, a message bus system, to com- municate vertically and horizontally in the stack. D-bus provides a simple way for applications to talk to one another and to be available as services in the system. Above D-Bus, Openmoko supports many window managers. The distribution was first developed using GTK+ and Matchbox window manager, but recently, they have switched to a combination of and Window Manager. These recent changes do not affect us as our changes mostly lie within the kernel. The installer binary is the only file modified outside the kernel and it does not depend on the window managers or the graphical interface that has been implemented. An important low-level service in the stack is the gsmd or the GSM Daemon. It is the basic interface between the modem hardware and the higher-level appli- cations. Its function is to basically receive high-level requests from applications, translate them to AT commands and send it out to the modem. It is interfaced with the modem by using the modem and implements a shared li- brary called libgsmd. This API allows any program to utilize the GSM modem. Similarly, the GPS chip is also interfaced with gpsd, a GPS Daemon. These types of services have been termed as low-level framework service, while the services built over this are known as high-level framework services. Overall, the goal of Openmoko was to establish an open-source mobile operating environment. They were able to produce a near open-source distribution, but were 11 required to protect the proprietary sections of the hardware.

2.2 SELinux and Integrity Measurement

SELinux is a security framework implemented in the v2.6 kernel as a Linux Security Module (LSM). It was developed by the National Security Agency (NSA) and the SELinux community. A Security Enhanced Linux kernel enforces Mandatory Access Control (MAC) which provides a strong framework to protect a system from malicious software. It protects the system by defining access rights of every user, application, process and file. This set of access rights is stored in the SELinux policy. The policy provides the flexibility of designing the policy’s granularity depending on the system that needs to be protected. The enforcement mechanism of SELinux involves a subject and an object. A subject is usually a process while an object is a resource that the subject needs access to. Each object or subject is assigned a security context at all times. A security context is in the following format: user:role:type Hence, a valid security context consists of a user, role and type identifier that are defined by the policy. A request is made to the policy server and the permission is then granted or denied after looking up the security context of the subject and the of the object. This decision process is described in Figure 2.3. The security context of subjects and objects is applied from the installed policy, which also provides the permissions matrix for each subject. SELinux provides a very rich set of permissions that govern many kinds of operations. Permissions are not only limited to files, but can also be applied to directories, sockets, semaphores, etc. These permissions are stored as in an access vector defined as per the policy.

2.2.1 Trusted Platform Module (TPM)

Hardware-based integrity measurement is a mechanism that allows one system to prove its integrity to another remote system. A measurement is basically a cryptographic hash of data or code. These measurements are stored on a secure 12

Figure 2.3. The decision process of SELinux location on the hardware. This location or hardware chip is also expected to be tamper-proof. The Trusted Computing Group (TCG) [5] works on the Trusted Platform Module (TPM) chip and maintains the official specifications for the chip. The TPM chip is essentially a secure co-processor that can also store information like cryptographic keys. The TPM chip includes a hardware pseudo-random number generator for secure generation of cryptographic keys. Further, it includes commands to provide for remote attestation. For this, it stores a hash list summarizing the state of the hardware and software on a system. The TPM chip also includes the functionality of sealed storage. Sealed storage encrypts the data using a secret key stored within the TPM. The reason for using a hardware based solution is to push security down to the hardware level rather than a software solution. Hardware definitely is more tamper-proof than software making it harder for an attacker to compromise a system.

2.2.2 Integrity Models

Protecting the integrity of critical system applications has always been a goal of security practitioners. However, the integrity models that have been proposed over the years seem not to match the practical environment. Our challenge in the development of phone system policies is to find a practical integrity model. 13

The Biba integrity model [6] assigns integrity labels to processes and relates these labels in an integrity lattice. Biba integrity requires that normal processes not read data at labels of lower integrity in the lattice. Also, Biba integrity does not permit normal processes to write data at labels of higher integrity in the lattice. As such, no lower integrity data could reach our critical, high integrity application in a Biba system. Unfortunately, many critical applications, including software installers, read some low integrity data. Efforts to allow processes to read lower integrity data without compromising their integrity have not found acceptance either. LOMAC [7] requires that a process drop its integrity level to that of the lowest integrity data it reads, but some critical phone processes, such as the telephony servers, must be permitted to accept commands from low integrity subjects, but execute at high integrity. In general, we find LOMAC too restrictive, although we implement a variant of it for software installers. Clark-Wilson integrity [8] provides a more flexible alternative, by permitting subjects to read low integrity data if the immediately discard or upgrade the data, but Clark-Wilson requires full formal assurance of such processes. Another simpler version of the Clark-Wilson integrity model is called the CW-Lite integrity model. CW-Lite is weaker than Clark-Wilson in that it doesnt require full formal assurance, but CW-Lite requires processes to have filtering interfaces that immediately upgrade or discard low integrity data as Clark-Wilson prescribes. The focus then moves to identifying where low integrity data may be read and ensuring that programs use filtering interfaces to read such data. We aim to apply this view of integrity to phone systems.

2.2.3 Integrity Measurement Architecture(IMA)

Given the untrustworthy nature of mobile phones, there should be some guarantee that the phone is only running programs that are trusted to behave properly and that the security policy is correct. Integrity measurement is the proposed method to establish these guarantees. Integrity measurements consist of cryptographic hashes that uniquely identify the components that define system integrity (i.e., code and data). Remote parties verify the integrity of a system by verifying that the integrity measurements taken are consistent with the remote partys view of 14 integrity. Such measurements are conveyed in a message signed by an authority trusted to collect the measurement, and a signed integrity measurement is called an attestation. One of the many architectures to achieve integrity measurement is the Integrity Measurement Architecture (IMA) [9]. IMA is implemented as an LSM which triggers a measurement for each , or kernel module that is loaded at run-time. Further, it facilitates the secure storage of the measurement list within the TPM chip. This enables the detection of malware on the system and allows a remote party to attest the state of programs running on the system. However, for phone systems, IMA does not apply to phone systems very well. If any untrusted application is executed on the system, the IMA verification will result in the whole phone being untrusted. Further, if IMA alone is utilized, then data files are not measured and hence, untrusted input into trusted programs could result in undesirable behavior. We use SELinux’s MAC policy to isolate the untrusted and trusted files from each other.

2.2.4 Policy Reduced Integrity Measurement Architecture (PRIMA)

The Policy-Reduced Integrity Measurement Architecture (PRIMA) [10] addresses the problem of run-time integrity measurements by additionally measuring the implied information flows between processes from the systems security policy. This way, a verifier can prove that trusted components in the system are isolated from untrusted and potentially harmful inputs. Moreover, PRIMAs CW-Lite integrity enforcement model only requires the trusted portions of a system to be measured and thus reduces the number of measurements required to verify a system. In addition to the basic integrity measurements of code and static data, we identify the following set of measurements necessary for a remote party to verify CW-Lite integrity:

• MAC Policy: The mandatory access control (MAC) policy determines the system information flows.

• Trusted Subjects: The set of trusted subjects (TCB) that interact with the 15

target application is measured. The remote party must agree that this set contains only subjects that it trusts as well.

• Code-Subject Mapping: For all code measured, record the runtime mapping between the code and the subject type under which it is loaded.

At system startup, the MAC policy and the set of trusted subjects is measured. From these, the remote party constructs an information flow graph. The remote party can verify that all edges into the target and trusted applications are either from trusted subjects (that are verified at runtime only to run trusted code) or from untrusted subjects via filtering interfaces. Next, we measure the runtime information. Due to the information flow graph, we only need to measure the code that we depend on (i.e., trusted subjects code). All others are assumed untrusted anyway. Also, we measure the mapping between the code loaded and the trusted subject in which the code is loaded, so the remote party can verify that the expected code is executed for the subject. By measur- ing how the code maps to system subjects, PRIMA enables a remote party to verify that the system runs high integrity code, perhaps with acceptable filter- ing interfaces, in its trusted subjects, and that these subjects are protected from information flows from untrusted subjects by the MAC policy.

2.3 Cross-compiling for ARM CPU

Sometimes, it is not possible to write and build a program on the same platform. For example, many mobile phones have hardly 64MB of RAM or flash memory. This limited memory may not be sufficient to fit in a and its associated tools. Hence, cross-compilers enable the development of the application on one platform and executing it on another platform. They are capable of compiling programs using the instruction set of the target platform. To understand cross- compilers better, the main components of the C compiler are discussed below:

• Parser: Converts into language

• Assembler: Converts code into the bytecode that the CPU executes 16

• : Combines all the object files to form an executable in the format of the target platform

• Standard C library: Core functions used in the source are defined in the library. They are included by the linker while forming the executable.

Hence, in a cross-compiler, the application is built using the assembly language, linker, and C library designed for the target platform. For example, mobile phones usually use ARM-based CPUs. We can cross-compile an application on a CPU so that the application ultimately is executed on a ARM-based CPU. Therefore, a cross-compiler is just an alternate version of the C compiler that generates and applications for the target platform. Chapter 3

Related Work

Mobile phones are end-user devices that allow the malicious user to have infinite amount of time to break the integrity of the phone. It has always been a challenge to provide verifiable evidence to a third-party that the integrity of the system has not been compromised. Hence, there have been various attempts to provide a trusted computing base on mobile phones without affecting the cost or the perfor- mance. This chapter explores hardware and software based solutions that provide integrity guarantees and compares work that closely relates to the objective of this thesis. Essentially, real estate on a mobile phone system board is very expensive. Though hardware based attestation is well established, it is very costly to include a TPM chip inside mobile phones. Hence, we look into software based integrity measurement in Section 3.1 that provides guarantees similar to hardware based so- lutions. Further, we summarize some of the newer technologies for hardware based integrity measurement in Section 3.2. Finally, we discuss two recent attempts to provide a secure Linux based mobile operating system in Section 3.3. 18

3.1 Software based Integrity Measurement on Embedded Platforms

3.1.1 SWATT and Genuinity

SWATT [11] is a software based technique to verify the code running on an embed- ded device. This is not a boot time procedure, but a run-time procedure that can be activated at any time. In the approach mentioned in [11], the verifier sends a randomly generated challenge to the device. The verificiation procedure then per- forms a psuedorandom memory tranversal which iteratively updates a checksum of the memory contents that it accesses. Thus, the verifier matches this checksum to its own expected checksum to verify the state of the device. Even if the at- tacker manages to predict the memory locations that have been transversed, it can only divert to another memory location. This requires precious CPU cycles and hence can take a suspiciously long time. As the whole process is timed, memory redirection can be detected easily. Genuinity [12] is very similar to SWATT as it uses the same pseudo random tranversal. The only difference is that the unique fingerprint of the system is the TLB cache miss pattern rather than the checksum of memory contents. Again, similar to SWATT, the process is timed and any sort of memory misdirection can be detected. Both the approaches discussed seemed to be effective ways to establish the integrity of the run-time state of a mobile phone. But, the method requires prior knowledge of the microprocessor and the memory size of the device. This can be quite impractical knowing the diversity of devices used in the mobile phone market. Further, the systems are time-dependent and hence they depend on high throughput, low latency networks. The cellular network (GSM) is known to be lossy and only sufficient for voice and limited data applications. Hence, these solutions may not be effective given the nature of the targeted network. Also, the system has vulnerabilities as the root of trust is software-based which is not tamper-proof. As expected, the system was broken soon and software based integrity is still a challenge. The attack on the system is discussed in the next section. 19

3.1.1.1 Attack on Genuinity

Shankar et al [13] formed a novel attack against the Genuinity system. As men- tioned in [12], the security of Genuinity purely relies on the time taken for the target device to compute the checksum. But, it is possible to simulate the check- sum procedure and insert malicious code within the cut-off time (35% of native execution time). This attack, known as the substitution attack, basically inserts malicious code right after the checksum code. The checksum computation code fits in 2KB and the rest of the space on the page can be used to run the malicious code. In case, the psuedorandom transversal maps to any section of that code, the byte from the original code page is returned. This attack opens up the door to many variants and hence proving the ineffectiveness of the genuinity system.

3.1.2 Pioneer

Seshadri et al continued their work from SWATT [11] to develop a technique to provide verifiable code execution. This technique, named as Pioneer [14], is also software-based and is aimed at legacy computing systems. It is based on a challenge-response protocol between a trusted entity (dispatcher) and the un- trusted entity (untrusted platform). The untrusted platform consists of the veri- fication function and the executable and the dispatcher keeps a copy of the same. When a challenge is issued to the untrusted platform, it computes a checksum over the verification function first. Once trust is established of the verification function, the executable is hashed and verified. Basically, once assurance is provided that the executable is unmodified, it is invoked and is expected to be executed without being tampered. As always, these functions are all timed, and hence any variance from expected times is noted with suspicion. Again, Pioneer depends on prior knowledge of hardware making it difficult to implement it for mobile phones. Further, it depends on secure connections between the dispatcher and the untrusted platform. This guarantee is hard to achieve as we are using a wireless interface. Further, the wireless interface may introduce unnecessary delays causing false positives to be triggered. 20

3.1.3 Energy and Execution Time Analysis of Software based TPM

Energy conservation on mobile phones is of paramount importance. Aaraj et al performed interesting measurements in [15] and made useful observations. They evaluated the overhead due to TPM functions on a PDA. The tasks that were measured were trusted boot, secure file storage, secure VoIP and secure web browsing. They utilized a TPM [16] cross-compiled on the PDA to execute the required TPM commands. The main observation was that TPM functions by themselves did not cause a significant overhead. Instead, RSA op- erations consumed a significant amount of energy and CPU time. Hence, they proposed the use of ECC instead of RSA to TPM functions practical in a resource-constrained environment.

3.2 Hardware based Integrity Measurement on Embedded Platforms

Now, we have seen the problems associated with software based integrity attes- tation. Hardware-based attestation has been successful in providing sufficient tamper-proof guarantees of high integrity systems. The Trusted Computing Group (TCG) [5] has defined a set of standards that implement integrity measurements and store it in a tamper-proof co-processer (TPM). Further, they have extended the specification to support mobile phones and recently released version 1.0 of the TCG Mobile Trusted Module Specification [17]. Though no mobile manufacturer will be willing to include a dedicated TPM chip into the phone yet, ARM and Intel have proposed CPU extensions to support TPM-like functionality. It is pos- sible to implement software-based integrity measurements in cooperation with the hardware extensions discussed below.

3.2.1 ARM TrustZone

ARM developed the TrustZone technology [18] targeted at embedded devices like mobile phones or PDAs. TrustZone aims to provide a hardware enforced secure 21

Figure 3.1. ARM TrustZone System Architecture [Source: http://www.arm.com] environment and secure software to provide interfaces to other elements in the trusted chain. Essentially, TrustZone separates two parallel execution worlds: the non-secure or normal execution environment, and a trusted secure world. This system is achieved using internal modifications to the CPU architecture. A new secure state is added to the ARM architecture for both user and privileged modes. This secure state decides which world the system is running in. A Secure Monitor controls the switching between the secure and non-secure worlds and is achieved using the Secure Monitor (SMI) instruction. An example of a TrustZone system is illustrated in Figure 3.1 [18]. On the hardware side, TrustZone includes a secure on-chip boot ROM, one-time pro- grammable non-volatile memory, secure on-chip RAM and other resources to en- sure that trusted applications maintain their integrity. These components are very similar functionally to a TPM chip. As it will be possible to implement IMA [19] with the TrustZone framework, we hope to utilize it in future devices as TrustZone becomes available on phone devices. ARM has included TrustZone in certain ARM11 and Cortex line of processors. Currently, Apple iPhone, Conexant CX2427X, Motorola RIZR Z8 and Motorola RIZR Z10 have TrustZone support in the CPU. But, as the operating systems of these devices are closed-source, we are not aware if TrustZone is being utilized to enhance the security of the devices. 22

Figure 3.2. Intel’s Authenticated Flash [Source: http://www.arm.com]

3.2.2 Intel’s Authenticated Flash

Intel also contributed to support trusted computing by joining hands with ARM to release Authenticated Flash technology [20]. Basically, they integrated a RSA Engine, a SHA-1 engine and a hardware RNG into standard flash memory as shown in Figure 3.2 [20]. Not only does this provide protected memory, but it also saves a lot of power and battery on the device as the authentication is done within the flash memory itself using dedicated hardware. Both the above technologies, TrustZone and Authenticated Flash are compli- mentary to each other. When combined, they will produce a strong secure platform for embedded devices without increasing the cost significantly. We hope that future embedded devices will leverage these technologies to enhance the security.

3.3 Linux-based Mobile Security Solutions

3.3.1 Montavista’s Mobilinux

There has been recent effort by MontaVista Corporation to incorporate SELinux into their for mobile phones. Information on this product is lim- ited as it is a commercial product and priced very high targeted for large mobile phone manufacturers. A press release of Mobilinux 5.0 says it is the first oper- ating system to include MontaVista MicroSELinux [21], a miniaturized version of 23

Security-Enhanced Linux (SELinux). It claims to be the first Linux release for mo- bile phones that incorporates SELinux. While our work also emphasizes a small policy, we have designed the policy with stress on integrity and tied SELinux with the Policy Reduced Integrity Measurement Architecture(PRIMA).

3.3.2 Motorola’s MotoAC

Motorola also made an attempt to provide a SELinux-like system on the Motorola A1200 mobile phone. The operating system is based on a v2.4 linux kernel and includes a proprietary access control system known as MotoAC. On analysis of this system, MotoAC appears to be disabled by default and does not provide any advantage over their previous phone models. MotoAC has been analyzed further in Section 4.2.1. Chapter 4

Vulnerability and Security Analysis of Mobile Platforms

Mobile phone subscriber base increases every month by nearly 2-3 million sub- scribers in the US and currently stands at a total of 259 million subscribers [22]. With such a large subscriber base, and the ubiquitous nature of mobile phones, se- curity issues need to be addressed with paramount importance. To begin working on the security, we need to first identify the various channels of attack that exist on regular phones. This helps us design our security model in a better manner, plugging in the holes that currently exist in mobile platforms. In this section, our objective is to enumerate various threats and describe the need for security. We first describe the threat model of mobile phones in 4.1. Then, we describe our experiments with Symbian and Linux based phones. Further, in Section 4.2, we look into the Linux distributions, Montavista and OpenMoko. In this section, we provide common use cases and attacks that are not only practical, but also highly damaging. Most of our vulnerability experiments were aimed at hacking Motorola’s commercially available A780 and A1200 models.

4.1 Threat Model

When designing a secure system, it is essential that we know the attacks that we are up against. A threat model basically identifies the different attack vectors that can compromise a system. A secure system can be clearly defined if we satisfy 25 the three basic guarantees: confidentiality, integrity and availability. Hence, our attacks will be aimed at circumventing one or more of these guarantees. A list of the attack vectors is given below:

4.1.1 Physical device access

This attack vector is probably one of most dangerous and most damaging. Since mobile phones are usually carried around by the user, they are prone to theft or loss. If stolen, this allows an attacker to gain access to all user information, if it is not protected correctly. User data can include phone book, messages, pictures/media, bluetooth pairing or personal files. The attacker could also return the device after installing spyware or malicious software that records private information from the phone. Further, a malicious user could circumvent the mobile phone operating system to make it participate in a larger distributed attack against a common target or a cellular network. As of today, most devices do not provide sufficient layers of protection to pre- vent data from being stolen by an attacker. It would also be beneficial to network carriers to attest the state of the mobile phones to ensure that the integrity of the system has not been tampered with.

4.1.2 Wireless Attacks

Due to the convergence of various technologies in the mobile phone, there are various wireless channels for data transfer on the phone. Some examples include WiFi, Bluetooth, Infrared and GPRS/EDGE. The most obvious and common attack here would be an eavesdropping attack. Being passive, the user will not be aware that his conversation is being spied on. An example of this has been provided by [23]. They demonstrate the attack by using a directional antenna and a mobile PC supporting bluetooth. The tool can be used to pair with mobile hands-free kits that use default pass-keys. Further, as an active attacker, the wireless interface could also be used to read personal data from the phone and transfer malicious software to the phone. 26

4.1.3 DoS attacks

Denial of Service(DoS) attacks can be used to render mobile phones unusable for legitimate users. The most common DoS attack for mobile phones would be to drain the batteries of the phone. The battery is a limited resource and can render the device inoperable once it is depleted. The attacker can perform CPU intensive operations that would utilize a lot of power from the battery. Another form of DoS attack would be to jam the cellular network frequencies to prevent any calls from going through. Further, as discussed in the next section, there is also a possibility of overloading the cellular network provider with enough requests that it will not be able to serve a legitimate caller.

4.1.4 Network attacks

Recent research by Traynor et al [24] has shown that the GSM network can be overloaded and a distributed DoS attack is capable of bringing the network down. The GSM standard essentially uses a band-limited control channel for setting up voice calls as well as transmitting messages. Hence, by sending a large number of messages, it is possible to deny a legitimate user from making a voice call. If a distributed attack can be carried out, then one could bring the whole network down by overloading the Home Location Register(HLR), a critical component of the network. Similarly, different channels of attack can be used to overload the network. The attacker could spread malicious software among many mobiles to achieve a distributed attack.

4.1.5 Worms and Virus

Though worms and viruses are not as widespread and deadly as those for the computer, they are increasingly becoming a nuisance with Symbian and Windows platforms. To emphasize this, a summary of mobile threats between 2004-2005 are summarized in [25]. Worms and Virus can be programmed to act as spyware, and actively spread through the channels discussed in the previous sections. Now that we have a clear picture of the existing threats to mobile phones, the urgent need for integrity and security is obvious. As part of the contribution of 27 this thesis, we discuss our experiments with common mobile operating systems and highlight how they can be compromised.

4.2 Linux Platform

Many manufacturers are adopting Linux as the platform of choice for their mobile phones. As stated by [26], Linux will be running on nearly 31% mobile devices. Motorola was one of the earlier adopters of Linux. As part of the experiments, two phones, Motorola A780 and A1200 have been analyzed. For the analysis, we look at the security framework utilized and the various vulnerabilities that result due to the weak framework.

4.2.1 Montavista Linux

Motorola partners with embedded Linux vendor MontaVista to produce their linux phones. Montavista is a leading provider of embedded linux distributions with their flagship product known as Mobilinux. But, the popular A780 and E680 phones use a Linux 2.4.20 kernel and standard libraries. Further, though the A1200 model is fairly new, Motorola continues to use the outdated v2.4 kernel. Their linux distribution is known as EZX and is fairly similar in both the phones. We started our experiments with the A780 and then continued it on the A1200.

4.2.1.1 Motorola A780

The Motorola A780 is a smart phone that is based on Motorola’s EZX platform. It consists of two processors, the Application processor and the Baseband processor. This division of the processors allows the baseband processor to provide dedicated resources to time-sensitive GSM operations. The application processor, which is ARM7 based, serves the operating system as well as the applications running on the phone. The phone consists of only 48MB of RAM and 32MB of on-board flash memory to store the bootloader, kernel, rootfs and some miscellaneous files.

LinLoader The Motorola A780 provides support for a memory expansion slot that accepts microSD cards. Further, it also allows the user to install applications 28 on the memory card as an alternative to the limited flash memory available on the phone. Though this might have been a boon to the user, it opens up the possibility for installations on the memory card. On the memory card, we found that each application had a directory under .system/QTDownload. To provide a reference to the application, the EZX system maintains a list of applications and the settings in the file .system/java/PlugCardDB. Now that we know how the applications can be installed manually, a framework can be setup to run any script/executable using a short script. This script known as LinLoader basically consists of the following lines:

#!/bin/ echo $* >/tmp/run.log export QTDIR=/usr/lib/ezx $2

The origin of the script is unknown, but the code is straightforward. As we can see, it is a simple . First, it sets up a log file which is optional. Then, the necessary execution environment is setup by providing the to the libraries. Finally, LinLoader invokes exec to execute the application that needs to be run. To install LinLoader on the phone, we copy this script to .system/QTDownload/loader and then add the necessary record in the PlugCardDB file mentioned earlier. This opens up the EZX system to run any file that we require to be executed.

Telnet into the phone With LinLoader loaded on the phone, we can now run any shell script and have access to all the files on the phone. The phone already has the inetd running which provides the telnet service. But, by default, the phone presents itself as a mass storage device to the host computer. Hence, to enable ethernet over USB, we need to run the following script using linloader.

#!/bin/bash echo MotNet > /proc/usbd-switch ifconfig usbl0 up 192.168.1.2 netmask 255.255.255.0 mtu 900

After connecting the phone via USB to the Linux host computer, we run the script above using LinLoader. The Linux host needs to have the usbnet, zaurus, 29 cdc acm modules installed and enabled. The above script makes the phone switch from mass-storage mode to the USB LAN mode. Now on the host, we configure the IP address of the host’s network interface using the following command: ifconfig usb0 192.168.1.1 netmask 255.255.255.0 mtu 900

Finally, we can telnet to the phone by, telnet 192.168.1.2

The username ’root’ can be used without a password which is a major security flaw by itself. Though most of the root filesystem cannot be written to, the /var and /tmp directories are open to read as well as write. Additionally, the memory card was mounted and writable by the user. But, we were allowed to read any file on the rootfs and make copies of the data on writable parts of the rootfs. This not only allows a malicious user to spy on important personal data, but also launch DoS attacks by filling up the flash memory on the phone. Further, as we had access to the shell as root, any active and important process could be killed to affect the basic functions of the phone. We noted that GPRS dumped data into a ring buffer file that can be read by a browser or application. Unfortunately, this file is not restricted to any particular application. Hence, it could be read by any process including a malicious process. This data is just IP packets that can be decoded to produce useful data. This was another major security flaw that we noted in the EZX platform.

Booting and flashing customized firmware The Motorola A780 is equipped with a bootloader mode that can be activated by pressing the camera and jogdial button while powering it on. This brings up the screen as shown in Figure 4.1. The bootloader provides two functions: from a memory card and re-flashing the firmware. The former function allows a user to boot a kernel and root filesystem without actually flashing the memory. This enables the user to test the system with a customized OS without making the phone non-functional. The bootloader can also be used to flash data onto the phone’s onboard memory. The structure of the phone’s flash memory is divided into various sections known as codegroups. There are various tools available online to re-flash any codegroup on the phone. 30

Figure 4.1. Motorola A780’s Bootloader Mode

Also, it is possible for a malicious user to extract any codegroup, inject or modify code in that codegroup and flash it back. The phone system will still boot fine without any checks on the codegroup’s integrity. This method allowed us to modify the root filesystem and write to areas that were earlier marked as read-only.

Cross-compiling native applications Cross-compiling is the process of com- piling programs on a certain system for executing it in another system that does not use the same CPU. In this case, we cross-compiled programs for the ARM CPU of the A780 on a x86 Linux host computer. Though it is possible to use gcc compiled for the ARM architecture, the compiler can get very messy due to various dependencies. Hence, a more detailed and systematic approach to cross-compiling is discussed in Section 6.2. These native applications can be run using LinLoader and hence, any malicious C program can be executed on the phone. This process can cause significant havoc considering the kind of access that native applications has to the system’s resources.

Opening up the TAPI server A significant part of our experiment was to prove how vulnerable the GSM network is to attacks from malicious devices. Further, the 31 user would not like invisible programs that utilize paid services over the network to communicate with the outside world. Hence, our goal was to write a C program that bombarded the GSM network with requests and execute this program from the phone. On analysis, the phone uses the tapisrv process to receive network related requests, forms the required AT-command and sends it out to the necessary device driver. The tapisrv is basically a Telephone Application Program Interface(TAPI) which acts as an interface between the applications and GSM modem framework. The device file is the interface to the GSM modem which finally sends it out over- the-air to the base station. Different services are served on different device files and is multiplexed to the GSM modem using a kernel module known as mux cli. The various mux device file functions are listed in Table 4.2.1.1. mux0 to mux7 are command mux devices while the rest are used for data. Hence, we are interested in only command mux devices, or more specifically, mux0 which handles voice calls and network management. To understand the interaction of tapisrv with the system, strace, a utility used to read the system calls made by a program, was attached to tapisrv. Then, a call was made and the system calls were logged. Using this information, we were able to write our on C program using the same sequence of system calls to make a phone call to any number. Thus, the mux device files accepted requests from any application without differentiating between a good and bad program. We can already see how this can be used for DoS attacks. A legitimate call made could be terminated by sending a simple ATH command to mux0. Hence, these methods described above can be used to compromise a phone and cause havoc with the phone as well as the network. These flaws are not isolated to only this phone, but can be extended to many other phones or platforms.

4.2.1.2 Motorola A1200

The Motorola A1200 was the successor to the A780 with a few hardware upgrades. It uses the Intel XScale processor at a higher clock speed of 312Mhz and hence provides faster UI response times. But, the A1200 runs the same EZX platform as the A780 with many enhancements. Noting the various avenues of attack with the A780, Motorola removed the inetd service from the default firmware. Further, 32

Description Command Data Control Channel - - Voice Call / Network MM 0 SMS MO 1 SMS MT 2 Phonebook SIM 3 Misc 4 CSD / Fax 5 8 GPRS 1 6 9 GPRS 2 7 10 Logger CMD 11 Logger Data 12 Test CMD 13 AGPS 14 NetMonitor 15 Table 4.1. A possible mapping of mux devices the later versions of the firmware even disabled the installation of LinLoader. Our experimental phone also had one of the later versions of the firmware which pre- vented a user from installing Linloader using the method described for the A780. Fortunately, it was still possible to flash the firmware on the A1200. With inputs from the Motorolafans community [27], the access restrictions were placed using a single config file called ezx flexbit.cfg. This file consisted of an access vector that enabled or disabled various functions of the phone. Hence, we obtained a version of the configuration file that did not prevent the installation of LinLoader. Once LinLoader was working, we installed a third-party application installer known as MPKG installer. This installer enabled us to download the inetd and sshd packages and allow them to run flawlessly on the phone. Hence, we reached the same level of compromise as we did for the A780. While installing and running java applications, we noted that there was a layer of security provided by MIDP2.0 that checked an application’s access permissions. But, this was only enforced for applications that are not signed by Motorola. We later found that it was very easy to overcome this layer. Each application’s working directory consisted of a file known as registry.txt which can simply be edited to change the values of the following properties:

DRM-Mode: Allowed 33

Is-Trusted: 1 Domain: Manufacturer

This change gives the java application complete read/write acceess to file sys- tem.

MotoAC An interesting feature that was seen in the Motorola A1200 was the presence of a SELinux-like LSM framework built into the kernel. The security policy was not analyzed as it was in the binary format on the phone. After further exploration, we found an application in the rootfs that displays the current status of the access control framework. When the application /etc/ac getflexbit was executed, its output proved that MotoAC was disabled by default. As the source of the kernel is available, we found that it was possible to enable MotoAC by a simple from user-space. syscall(__NR\_security, AC_POLICY_MAGIC, AC_SYSCALL_ENABLE, &state);

The usefulness of MotoAC is unclear as Motorola had made a decision of dis- abling it by default. But, enabling it manually may not be wise as there have reports of users locking the phone’s OS by enabling MotoAC. In conclusion, the Motorola A1200 is very similar to the A780 and was com- promised in a similar fashion. Though Motorola has tried to improve the security of the A1200, the framework has not been utilized.

4.2.2 OpenMoko

The OpenMoko platform is very unique as they have made an effort to develop a completely open source mobile phone software stack. They also provide a hardware platform on which this stack runs, but they do not limit the software stack to any particular hardware. The first version of the phone known as GTA01 was based on a ARM920T core, 128MB of RAM and 64MB of onboard flash memory. The phone’s software stack has already been discussed in Section 2.1.2. The OpenMoko phone was designed to be hacked. Obviously, security was their last concern as they were busy making the phone as open-source as possible. Hence, considering that source code for every component was available, we chose 34

Figure 4.2. The functioning of gsmd the OpenMoko platform as our experimental platform. Integrating security into this stack is identical to building a security framework for any Linux-based system. On analysis of the system, all parts of the flash memory have read and write access. The kernel, bootloader and root filesystem can be modified and re-flashed on the phone. This allows any malicious user to design a software stack that can be infested with malware without the user being aware of their existence. Further, there was only one user defined on the system - root. This administrative user did not even have a default password assigned. Most of the utilities on the phone were stripped down versions of the original and hence were definitely not security-aware. The phone uses Busybox [28], a utility which combines tiny versions of many common utilities into a single small executable. As shown in later sections, most of the important utilities in Busybox had to be reconfigured and Busybox had to be recompiled to include SELinux support. There is currently no support for java applications on the phone. It uses na- tive applications which are cross-compiled for the ARM CPU. Native applications do not execute in a sand-boxed environment like Java. They have unrestricted access to all the API’s, services and files. Hence, there is a need for a restrictive environment to execute native applications safely. Another critical component that has been left open to malware is the GSM component of the phone. The Figure 4.2 illustrates the functioning of GSMD, the GSM daemon on the phone. It shows how libgsmd is used and the API 35 provided by GSMD. The GSM modem is interfaced with GSMD using the UART interface. The UART interface is simply a parallel to serial converter or vice versa. Each application that needs to use the services of GSMD requires to open a socket and then transmit its requests. The requests are sent using commands provided by the libgsmd API. GSMD does not differentiate between applications that place requests and each application can send out any supported commands to the modem. Hence, it is possible for a dialer to make a call and another malicious program to either hang up or record the conversation. While designing our security framework, our goal is to deny operations similar to the example given above. Finally, considering the openness of the OpenMoko platform and the availability of the source of the complete software stack, this platform was chosen for the experiments performed later in Chapter 6.

4.3 Symbian Platform

The Symbian Platform is one of the most popular platforms in mobile phones. It is closed source and provides limited APIs for the development of third party applications. Symbian is based on a architecture where services are implemented outside the kernel. Basically, it utilizes a client-server model to im- plement most of its functions. There are many vulnerabilities in the Symbian platform as demonstrated by [29]. He was able to modify the contacts database using an application, transfer files using bluetooth, and send AT commands to the GSM modem. Also, being a popular OS, many worms have been targeted at Symbian. In versions prior to v9, once the user installs a program, Symbian allows unrestricted access to all the files and services. Symbian enhanced its security model from v9.x onwards to a per-process capability-based model [30]. At run-time, every process has a set of capabilities which decide its level of access. The access rules are based on directory path, eliminating the need for an access control list. Further, applications developed by a third-party need to be ”Symbian Signed” so that the phone treats it as a trustworthy application. This thesis will not review Symbian security in further detail; for a comprehensive review, please refer to [29]. Chapter 5

Approach

5.1 The Goal

To understand the goal clearly, let us look at an example of an application that we would like to protect. Consider a banking application provided by any major bank that provides functions like checking account balance, fund transfers, bill payment, etc. For proper operation, the application will need to access the following sections:

• Executable Binary and dependent libraries

• Configuration files

• Log files

• Temporary files

• Active Network connection

Now, if the user installs a game on the same , the game application might require access to one or more of the above resources. If the game is also given similar access, it can read or write to its own files as well as files used by the banking application. Now, our goal would be to isolate the trusted and untrusted execution environments on the phone. The design of the system is discussed in rest of the chapter. We will continue to use the example of the banking application and game to illustrate the approach clearly. 37

Figure 5.1. The proposed mobile phone system architecture

5.2 System Architecture

Our approach can be generalized for most mobile phones and is illustrated in Figure 5.1. The phone system consists of a root of trust that establishes the integrity of the system. We are not aware of a phone system that contains a hardware-based TPM chip, but ARM’s TrustZone [18] is being included in their new line of processors. Hence, we envision mobile devices leveraging TrustZone as a root of trust in the future. Next, the system uses an operating system kernel that supports Mandatory Access Control (MAC) and integrity measurement. The MAC policy will define the information flows allowed in the system. It is enforced using a reference monitor in the kernel that mediates all security sensitive operations. An example such a framework is the Linux kernel with SELinux support. Further, to include integrity measurement, we include PRIMA in the kernel to measure all information flows and the code that is loaded in the system. This ensures that the trusted subjects of the system remain intact and are not tampered with. We also identified the software installer to be a critical component of the sys- tem. This installer does not usually differentiate between trusted and untrusted packages. In some cases, software packages may include signed hash files that prove the authenticity of the package. Hence, we included hooks in the installer to enable isolation of trusted packages from untrusted packages. 38

Finally, we note that users might want to run untrusted applications like the game application alongside the trusted applications like the banking client. Hence, our goal is to allow both these applications to run without compromising on the integrity of the trusted applications.

5.3 SELinux

The enforcement of the MAC policy enables the trusted programs and the installer to be protected from untrusted input. In this section, we briefly describe the requirements of the policy. For more details on the policy design, refer to [31]. For the trusted programs, like the banking application, our goal is to isolate it from the untrusted programs. To implement this, we utilize the Biba integrity model [6] which is sufficient to prevent untrusted code from writing to trusted files or applications. This model also allows the game application to read configuration and library files to execute correctly. For the installer, the user would want to install untrusted applications and hence, it would not be practical to disallow untrusted inputs to the installer. Hence, we adopt the CW-Lite Integrity model [32]. According to this model, we include a filtering interface on the installer. The installer reads the label of the package being installed and runs with the necessary permissions. The installer is configured such that any program can call it in the phone system. But, if an untrusted program calls the installer or if the package being installed is untrusted, the installer runs as untrusted. Further details on the implementation of the installer have been discussed in Section 6.4.3.

5.4 Integrity Measurement

Even though the trusted programs are now protected using the MAC policy, it is also required that the phone system is able to prove its integrity to a remote party. We use the Integrity Measurement Architecture (IMA) and extend it to support Policy Reduced IMA (PRIMA). The Linux IMA measures files at load-time to ensure that all loaded code has not been compromised. Thus, any changes in the measured code will be noted in the measurement list. An IMA measurement 39 basically consists of a file name and hash value. Other values are tracked to determine if a measured file is modified. The file name enables identification of the expected hash value for the entry. The hash value is used in the computation of the TPM’s PCR value used to verify the integrity of the measurements themselves. PRIMA extends IMA by capturing the mapping between code and MAC pol- icy, while also measuring the MAC policy itself and other relevant policy specifi- cations. PRIMA measures the code/data, subject and optional role if the subject is trusted. The measurement entry can be denoted by md = (d||s||) where d is the code or data digest, s is the trusted subject, and r is an optional role iden- tifier. The aggregate is H(Xi + 1) = H(Xi||H(md)). The measurement list is extended with the measurement entry Mi+1 = Mi||md. The MAC policy ensures that the high integrity applications will not have any dependence of inputs from low-integrity sources. We also note that the information flows are also measured by measuring the MAC policy binary. This is achieved by adding a hook into the security load policy function in the SELinux source code. The measurement list includes only the trusted code or data and hence assures a verifier that the trusted software on the phone system is indeed trusted.

5.5 System Security

In this section, we describe how the MAC policy and the integrity measurement architecture function together to enable verification of the trusted software on the phone system. The MAC policy on the phone system ensures that the trusted programs are isolated from the untrusted programs. The policy does not prevent trusted pro- grams from interacting with another trusted program. In general, a verifier will trust all trusted programs on the phone if the verification is successful. Hence, all trusted programs are labeled as trusted. PRIMA measures all trusted programs and the MAC policy. Hence, if the measurements are acceptable to the remote party, the phone system is considered as a high-integrity system. Further, the MAC policy also defines the untrusted type. The installer always starts as trusted and protects itself through filtering interfaces. If the installer receives an untrusted package, it then switches to untrusted and continues to install 40 the untrusted package. But, the installer being untrusted will not be permitted to modify and overwrite any trusted files. There are two problems that can be associated with the installer. First, will the installer function correctly when it runs as untrusted? As untrusted, the installer will not be able to modify the configuration or scripts, but it will be allowed to read them. Hence, we tested the functioning of the installer as untrusted and did not see any issues. Second, how will the installer access log and temporary files? The untrusted installer will only be able to modify or create untrusted files and will not have any access to trusted files. This is strictly enforced by the MAC policy and hence, the untrusted files will remain isolated from the trusted. In conclusion, our phone system’s integrity can be definitely verified in a fool- proof manner to a remote party. Hence, the goal of executing an untrusted game alongside the banking application is made possible using our proposed framework. Chapter 6

Building a Mobile Platform with Integrity Measurement

In this chapter, we describe the process that was taken to implement SELinux and PRIMA on the phone. Further, we briefly discuss SELinux policy reduction. The goal of using the framework is to be able to verify that the integrity of the phone has not been compromised. Finally, some results and performance measures are analyzed in Section 6.6 for the mobile platform.

6.1 Experimental Setup

In this section, we describe the experimental setup which is the environment where the security framework has been implemented. The framework can be divided into distinct layers. Each layer depends on the previous layer by either modifying it or building over it. Figure 6.1 describes the layers that have been implemented and ported to our experimental platforms. Over the hardware, we run a v2.6 Linux kernel that has been patched to support drivers of the required hardware. Then, SELinux code is already available in the kernel and hence, we configure the kernel to build SELinux into the kernel. Over this security-enhanced kernel, we patch the Integrity Measurement Architecture which is implemented as a Linux Security Module (LSM). Finally, Policy Reduced IMA is ported to the kernel to measure the trusted subjects and lighten the load on the resource-limited phone. Two platforms were used to implement this software stack which are discussed in 42

Figure 6.1. Overview of the integrity framework ported for mobile phone hardware further detail in this section.

6.1.1 Evaluation Board

The initial design and development of mobile phones are typically carried out on evaluation boards that have hardware very similar to mobile phone hardware. Our implementation was performed on a Spectrum Digital Evaluation board (OMAP 5912 OSK) shown in Figure 6.2 with the following features:

• ARM CPU ARM926EJ-S operating at 192 MHz

• 32 MB DDR RAM

• 32 MB Flash ROM

We run the Linux kernel 2.6.18.1 on the evaluation board with the SELinux security module enabled and the PRIMA patches applied. The kernel is booted with the u-boot 1.3.1 bootloader. We cross-compiled the kernel and bootloader for the ARM platform using a toolchain generated using [33], a script for generating toolchains and root filesystems. It is essentially a set of Makefiles and patches that automates the process of cross-compiling a toolchain and root filesystem. We use the installer from the Linux OpenMoko distribution as our installer. It is the only software we use from outside the Qtopia distribution. Once the kernel is uploaded to the flash memory on the board, almost all further compilation is performed directly on the board. An exception is the compilation 43

Figure 6.2. The OMAP 5912 OSK Spectrum Digital Evaluation Board [Source: http://omap.spectrumdigital.com] of the SELinux policy which fails on the board due to memory constraints. It was compiled on an x86 machine and copied to the boards root filesystem. This is fairly simple as the policy binary is independent of the platform. Hence, we did not need to use cross-compilers to compile the SELinux policy. We use Journalling Flash File System 2 (JFFS2) with extended attributes sup- port as the file system format on the evaluation board. Further details on the use of JFFS2 has been discussed in 6.4.1.1. The evaluation board’s 32MB on-board memory turned out to insufficient for compilation and experimentation. Hence, due to storage space limitations of the evaluation board, we divided our root filesys- tem into two parts. The majority of the filesystem was flashed onto the memory on the board while the remaining(/usr and /tmp) was mounted via NFS from a remote machine. We note that SELinux does not trust NFS by default and gives the NFS-mounted files the same label, nfs t. On the phone, this would not be a problem as the root filesystem would not be mounted remotely.

6.1.2 OpenMoko Phone

The evaluation board discussed in the previous section consisted of hardware sim- ilar to mobile phones, except that it lacked a GSM modem. Hence, a realistic environment was required to test our framework. Thus, Openmoko’s platform suited our needs being a completely open-source software stack. The hardware configuration has already been discussed in Section 4.2.2. 44

Openmoko’s flash memory is organized similar to most Linux phones. We run the v2.6.24 Linux kernel with patches provided by Openmoko. Then, SELinux, IMA and PRIMA patches are applied to provide our integrity framework. Details of the patches on the kernel are discussed further in Section 6.4.1. The kernel is booted using a modified version of u-boot 1.3.2. The bootloader mode is used to re-flash the memory on the phone. We use dfu-util to flash partitions on the phone. It is a program that implements the Host (PC) side of the USB DFU (Universal Serial Bus Device Upgrade) protocol. The most common tasks using dfu-util can be summarized below.

Flashing the rootfs dfu-util -a rootfs -R -D /path/to/openmoko-devel-image.

Flashing the kernel dfu-util -a kernel -R -D /path/to/uImage

Flashing the bootloader dfu-util -a u-boot -R -D /path/to/u-boot.bin

All our compilation was carried out on the host PC due to limitations of re- sources on the phone. We use OpenEmbedded [34], a full featured development environment for embedded devices. The cross-compilation details are discussed in Section 6.2. Openmoko also adopts this environment as it is easy to customize the packages to include in the distribution. Unlike the evaluation board, we did not need to use NFS as there was sufficient free space on the flash memory.

6.2 Cross-compiling with OpenEmbedded

The Openmoko phone uses a software stack that is generated completely using OpenEmbedded [34]. OpenEmbedded is a tool which creates a fully usable Linux base for various embedded systems. It is capable of generating a complete and configurable distribution for different hardware architectures. It is supported on 45 any Linux distribution. Briefly, OpenEmbedded uses the , a task executor, OpenEmbedded metadata to perform the tasks and it uses monotone as its version control system. Further details on these tools can be found at [34].

6.2.1 Basic concepts of OpenEmbedded

OpenEmbedded uses bitbake to execute tasks and manage metadata. The whole environment depends heavily on inheritance. Before we understand the environ- ment, we need to clarify some of the jargon used with OpenEmbedded.

Packages These are the applications, libraries or components that are included in the distribution. They include the task files (.bb files), configuration files and patches.

Configuration Files The metadata defined in the configuration files are global and affect all packages that are being compiled. The configuration files also allow include directives to pull any other metadata.

Classes Classes are files that define variables in the compilation process for pack- ages. These class files can be inherited by any number of packages. Bitbake de- pends heavily on the inheritance mechanism to execute any task.

Tasks The bitbake file with a bb file extension is known as a recipe. This recipe is usually the package that needs to be compiled. A bb file is allowed to depend on one or more bb files.

Images After compilation of the package, the executable and the files to be installed are placed in the images folder. The folder also contains an ipkg file that can be loaded separately on a system. Further, these images are finally put together into the root filesystem of the distribution. Essentially, Bitbake executes parses metadata to compile the packages. For each recipe, it computes task depencies and builds a task graph which contains tasks from all recipes. Once it knows all the task dependencies, it builds them before compiling the package itself. To actually compile the package, it generates a shell 46 script and executes it. Now, being familiar with the terms used in Openembedded, we enumerate the steps executed in a build process of a package.

1. do fetch Downloads the package source from source URL described in the bb file.

2. do unpack Extracts the source to a temporary working directory.

3. do configure Sets the environment variables before compilation and checks if all the required tools are available for compilation.

4. do compile After configuration, uses the toolchain to compile the package

5. do install Moves the compiled files to the images folder

6. do package Compresses and places all files into an ipkg format

With the background of these commands, it is possible to compile and include any package in the distribution being generated by OpenEmbedded. For example, A simple ’bitbake sysvinit build’ would execute all the above steps and provide the result in the images folder. We note that the kernel build process was carried out separately and not within the environment. The kernel and root filesystem compilation is detailed in Section 6.4.

6.3 Enabling SELinux

As the Openmoko software stack runs a complete Linux kernel, enabling SELinux is not any different from enabling it on a PC. First, SELinux needs to be configured in the kernel. Then, cross-compile the required libraries, libselinux and libsepol and the required SELinux tools. Finally, sysvinit is modified to load the policy as soon as it is executed. To enable the SELinux framework in the kernel, the following CONFIG pa- rameters need to be included in the kernel configuration.

CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_CAPABILITIES is not set 47

# CONFIG_SECURITY_ROOTPLUG is not set CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 # CONFIG_SECURITY_SELINUX_DISABLE is not set CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1

Now, to include the SELinux libraries and tools in the Openmoko distribution, we create the tasks to compile the required packages: libselinux, libsepol, policycoreutils and sysvinit. An example of a bb task file for policycoreutils(package that includes core utilities for SELinux) is shown below.

HOMEPAGE = "http://www.nsa.gov/selinux/code/download-trunk.cfm" AUTHOR = "NSA" SRCREV = "${AUTOREV}" PROVIDES="policycoreutuils" SRC_URI = "http://www.nsa.gov/selinux/archives/policycoreutils-${PV}.tgz \ file://openmoko_makefile_policycoreutils.patch;patch=1" export DESTDIR=${D} inherit autotools do_compile_prepend() { mkdir -p ${WORKDIR}/image/usr/lib/ cp ${STAGING_LIBDIR}/libsepol.a ${WORKDIR}/image/usr/lib/ } do_stage() { autotools_stage_all }

Finally, sysvinit is modified using a patch which enables init to load the policy and mount selinuxfs. The selinuxfs pseudo filesystem exports the security server policy API to processes. Once the policy is loaded, init kills itself and loads up again to enforce the policy on init too.

6.3.1 SELinux Policy design

In Section 4.3, we noted that most malware appears on phones in the form of packages that are installed on the phone. Obviously, the installer’s integrity needs to be preserved. Further, if we can protect the integrity of the operating system and the core services, the phone’s functionality can be assured to be proper. 48

The core OS and services of the phone are protected by SELinux from un- necessary modification. Further, PRIMA ensures that boot-time measurements match the original and clean state. But, since the user tends to install packages downloaded from remote and unknown parties, it is essential to allow untrusted packages. Our work on measuring integrity on mobile phone systems [31] emphasizes on the policy design and the implementation of the software installer. The goal is to reduce the number of types in the SELinux policy to as few as possible. Further, we would like to classify all the packages installed on the system as either trusted, untrusted or kernel. This coarse classification allows the policy to be significantly simplified. Also, the size of the policy reduces which is advantageous on mobile systems with limited flash memory. With this simpler classification, we enforce the Biba Integrity model [6] by ensuring that the trusted programs are isolated from the untrusted programs. SELinux not only enforces this using the labels, but PRIMA measures trusted programs which provides verification of those programs. Further, the software installer follows the Clark-Wilson Lite Integrity Model [32]. The installer can start as either trusted or untrusted. If it is invoked as trusted, and receives a trusted package to install at its filtering interface, it will continue as trusted and install the package as a trusted program. On the other hand, if it receives an untrusted package, the installer dynamically transitions to untrusted and then continues to install the package. Depending on the context of the installer process, the files installed by the installer are labeled appropriately. Figure 6.3 illustrates the installer handling untrusted and trusted packages.

6.4 Modifications

A number of modifications were applied to the base Openmoko distribution. First, the modifications on the kernel are outlined in Section 6.4.1. Then, we note the additions to the original root filesystem in Section 6.4.2. Finally, we briefly mention the modifications made to in Section 6.4.3. 49

Figure 6.3. Implementation of the filtering interface in the software installer

6.4.1 Kernel

We take a vanilla Linux kernel v2.6.24 and apply all the patches provided by Openmoko. Then, the SELinux configuration is added to the kernel configuration as described in Section 6.3. To provide the integrity measurement architecture, the patches from [9] are applied. Now, we require the PRIMA functionality to be added to the kernel. We ported PRIMA patches that were originally applicable to v2.6.21, to work for v2.6.24. Finally, after these patches have been applied in the given order, the kernel is compiled using the make commands: make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- oldconfig make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- uImage 50

6.4.1.1 JFFS2 and xattr support

An important consequence of using SELinux is the requirement of the filesystem to support extended attributes. The extended attributes are used to store the labels of all the files in the filesystem. Fortunately, JFFS2, the filesystem used in Openmoko included support for extended attributes from Linux kernel v2.6.18. Hence, to enable extended attributes support, we set the parameter, JFFS2 FS XATTR=y in the kernel configuration.

6.4.2 RootFS

The modifications in the root filesystem mainly consisted of modified packages and additional tools to support SElinux. As discussed in Section 6.3, the SELinux libraries and core tools are included in the root filesystem. Further, Busybox is con- figured to support SELinux and the inbuilt tools are recompiled to include SELinux support. Then, the modifications to sysvinit (Section 6.3) are included. PRIMA also requires a list of trusted subjects to be stored in the /etc/selinux/subjects file. Depending on the policy design, the trusted subjects that need to be measured by the IMA framework are listed in the subjects file. Finally, we make an addi- tion to the start-up scripts, as shown below, to mount the securityfs provided by IMA. mount -t securityfs none /sys/kernel/security

6.4.3 Software Installer

The Openmoko distribution uses a modified version of ipkg as a software installer, known as opkg. To implement the functionality described in Section 6.3.1, we mod- ified the code to provide a filtering interface. This interface reads the label of the package being installed and self-transitions to either trusted or untrusted de- pending on the label. Further, we note that the installer was not able to label new files that were installed on the system. Hence, we had to make another minor modification to the function that extracted the package files to the required direc- tories. This hook utilized the function, setfscreatecon to label new filesystem objects and obtain the desired result. 51

6.5 Verifying integrity measurement

With our complete framework setup, the phone is switched on and allowed to boot. The IMA framework starts with the measurement of the kernel and then starts measuring all files invoked as any of the trusted subjects listed in the /etc/selinux/subjects file. The libraries loaded are only measured once and are not associated with any subject type. A sample of the measurement list is shown below.

10 ffffffffffffffffffffffffffffffffffffffff boot_aggregate 10 e56018bfcc61405d9def6a595d2e40b7b11c506a boot_aggregate kernel 10 b7ec816e296979508ad957a39828c4cb0f617c3f /lib/ld-2.6.1.so 10 5777a3856714930a119e5922840318fc152fefee /lib/libsepol.so.1 10 b3805df11ba69d00218609a7066d6e8839910b98 /lib/libselinux.so.1 10 07a4a300e567975bdad7b1d7b6028ad1d9ab655c /lib/libc-2.6.1.so 10 e8d6e9139a27ca5563b3f10c38cebd4a2982563e /lib/libdl-2.6.1.so 10 fc2c149b3b378e56f74ed73d674d0c9fc809c807 /sbin/init 10 572a8266a10daeb9337afa541809587865a29016 /sbin/init init_t 10 14ea03f46f4ccdf7a94b1954f14d69660780ecd2 /etc/init.d/rcS 10 204aab2eceb914a5d614f7cd073379d86d9a8293 /etc/init.d/rcS initrc_t 10 0d0b3505b7aefdd68453c2d81871463795a8d547 /lib/libm-2.6.1.so 10 3c9056068f47d0f6eed81a0baa68c786ce650799 /lib/libgcc_s.so.1 10 b7e3cb8b9d7fc77707dfa45d2396bfe422e31e1b /bin/mount.util-linux 10 9b4c037aeab94b3f445983f14535f5ad6f675d7d /bin/mount.util-linux initrc_t 10 b551845b63347c4246527ee99df08b58f3477cf0 /etc/init.d/rc 10 6ac389c672ae6b60d8e964dfec3e247d8f2e1cf7 /etc/init.d/rc initrc_t 10 81b44c01524ecc8e82645c5cafe0a3a1bcea9fa8 /bin/ 10 0b9e5a4f9ee7688af1c3a1aed6b5a714bb1e8c05 /bin/busybox initrc_t

The current hardware does not include a TPM chip and hence none of the mea- surements taken are actually verified by the phone. But, with the advent of ARM TrustZone and other similar technologies, we hope to provide TPM functionality in the future. Now, SELinux ensures that low-to-high information flows are prohibited keep- ing the integrity of the trusted files. PRIMA measures all the trusted subjects and the measurement list can be provided to any attestor that requires to verify the state of the phone. Hence, the trusted base in the system is not tampered with and this can be verified by a third party. 52

6.5.1 Package Installer

The integrity of the software installer is also very essential. The installer executable is labeled as trusted and hence, no untrusted program can modify or overwrite the installer. Further, the installer, labeled with a trusted subject type, does get measured by PRIMA. Now, to verify the functioning of the installer, we run three cases using the opkg installer:

6.5.1.1 Install a trusted package

We use the openmoko-contacts package that provides the address book for the Openmoko phone. We can safely assume that the address book needs to be trusted as it is responsible for storing large amounts of private information. To install the package, the package is first downloaded onto the phone by executing : opkg download openmoko-contacts2. Now, the package that has been downloaded is labeled as trusted exec t, a trusted type defined in the policy. Now, the installer is invoked to install the package: opkg install openmoko-contacts2 0.1.0+ svnr419-r4.01 armv4t.ipk. The following output is noted from the installer:

The installer starts as system_u:system_r:trusted_t:s0-s15:c0.c255 Context of the package - system_u:object_r:trusted_exec_t:s0 Type of the package - trusted_exec_t Installing openmoko-contacts2 (0.1.0+svnr419-r4.01) to root... Configuring openmoko-contacts2

As expected, the installer starts with the security context of trusted t. It then reads the label of the package as trusted exec t. Hence, the installer continues as trusted and installs the necessary files on the root filesystem. As desired, It is noted that the installer does not transition.

6.5.1.2 Install an untrusted package

We use the oh-puzzles package that provides a set of games for the Open- moko phone. In general, games should be untrusted on the phone and should not be allowed access to the filesystem on the phone. The only case where they may need to write to the filesystem is to store some game-related data like scores. For this purpose, the game can create a new untrusted file for its use. 53

In this way, we assure that the trusted and untrusted files are completely iso- lated. Now, similar to the previous case, the package is first downloaded: opkg download oh-puzzles. Then, the package is labeled as untrusted exec t, an untrusted type defined in the policy. Now, the installer is invoked: opkg install oh-puzzles 0.1+svnr22-r5 armv4t.ipk. The following output is noted from the installer:

The installer starts as system_u:system_r:trusted_t:s0-s15:c0.c255 Context of the package - system_u:object_r:untrusted_exec_t:s0 Type of the package - untrusted_exec_t The context of the installer has changed to system_u:system_r:untrusted_t:s0-s15:c0.c255 Installing oh-puzzles (0.1+svnr22-r5) to root... Configuring oh-puzzles

Again, the installer starts with the security context of trusted t. It reads the label of the package as untrusted exec t. It transitions to untrusted t and then continues to install the package. Hence, all files that are placed in the filesystem are also labeled untrusted ensuring the isolation of untrusted files from trusted files.

6.5.1.3 Invoke installer by an untrusted process

An important case that has been looked into is the invocation of the installer by an untrusted process. This scenario is very likely as once there is malware on the phone, it can call the installer to install packages that it depends on. This has also been handled using our model and can be demonstrated by installing an untrusted package. Hence, we wrote a test program that is labeled as an untrusted type which executes the installer. In this case, the installer simply starts as untrusted and it follows the same process as the previous case. Hence, even in this scenario, the integrity of the phone remains intact.

6.6 Performance Results on Mobile Hardware

Running a heavy-duty security framework does require considerable amount of resources. Since the phone runs a near-complete Linux stack, our worry was that the phone’s performance might become sluggish. Hence, to prove that the overhead 54

Kernel Type Boot Time Vanilla OpenMoko Kernel 1 min 39.0 seconds IMA Kernel 1 min 55.0 seconds PRIMA Kernel 1 min 52.7 seconds Table 6.1. Comparison of boot time on the Openmoko phone

File Size Time to measure (seconds) 150 KB 0.03 1.2 MB 0.16 4.1 MB 0.52 16.8 MB 2.08 Table 6.2. Time taken to measure files of varying sizes due to our implementation is insignificant, we analyzed some performance measures on the phone. First, the boot time is compared for three different scenarios: Vanilla kernel, IMA kernel and PRIMA kernel. The observed boot times are noted in Table 6.1. The difference of boot time from the PRIMA and vanilla kernel is approximately 13.7 seconds. Since this is only at boot time, it is only a one-time wait for the user. The value of the security framework enforced is far more than the cost of the extra boot-time. Further, there is also a saving of 2.3 seconds when PRIMA is used instead of IMA. This is attributed to only the trusted subjects being measured by PRIMA. Also, the measurements are taken only once as long as the binary and subject type does not change. Hence, a new measurement is added to list for every unique file and subject type. Now, every time the user boots the phone and uses it routinely, he will execute the applications that he uses on a regular basis. Once these applications have been measured, the measurement will not be taken again and thus, the performance will get better over time. Next, the integrity measurement itself is a CPU-intensive process. Every time a trusted program is started, it is measured and added to the measurement list. It is important to make sure that the measurement does not affect the performance of the phone. Hence, we note the time taken for measuring files of varying sizes in Table 6.2. We do not expect applications to have files greater than 16 megabytes and thus, we do not test for files greater than 16 megabytes. Further, we also check the time taken for the ARM-based phone to perform a 55

Fragment size Speed 16 bytes 743.42 Kb/sec 64 bytes 405.92 Kb/sec 256 bytes 1440 Kb/sec 1024 bytes 4007.64 Kb/sec 8192 bytes 8200.22 Kb/sec Table 6.3. Output of openssl speed sha1 - speed measurement of SHA1 hash

SHA1 hash. To test this, the openssl tool has a benchmark option which provides the speeds at which it can perform various hashes. The result of the SHA1 speed measurement are listed in Table 6.3. From Table 6.2 and Table 6.3, the values indicate that most of the time to perform a measurement is attributed to the SHA1 hash. Hence, the PRIMA and SELinux framework adds negligible overhead but the bottleneck is the hash process. It would be worthwhile to look into other hashing that can perform better on the mobile hardware. Chapter 7

Conclusion

The divide between desktop systems and mobile phone systems seems to be closing very rapidly. However, mobile phones will still have limited resources as compared to a desktop system. Hence, it is a challenge to design a security framework without costing precious CPU time on a mobile phone. But, the tremendous growth of mobile phone sales every year calls for a standard security design that can be incorporated into most systems without high costs or performance overhead. This thesis proposed one such system where we developed an optimized approach to provide integrity guarantees on the phone. First, we analyzed various mobile phone systems and identified the security issues that needed to be addressed. Then, we justified that it is practical to implement SELinux and PRIMA for mobile platforms. Using the SELinux policy, we demonstrated that the critical applications remain protected from untrusted applications on the phone. Further, PRIMA provided verifiable integrity of trusted software. Our goal of installing a mobile banking client and an untrusted game was proven to be feasable without affecting the integrity of trusted software on the phone. As future work, we plan to port this framework to devices that include a hard- ware TPM chip. The hardware chip along with a faster CPU should definitely improve performance of integrity measurements. The hashing was rec- ognized as a major bottleneck in performance through our experiments. Hence, we hope to utilize an optimized hashing algorithm targeted at resource-limited em- bedded devices. We also plan to optimize the SELinux policy further to leverage 57 the simplified phone environment. Finally, we plan to experiment with a variety of applications to assess our designs robustness. Bibliography

[1] “Google’s Android,” code.google.com/android/. [2] “OpenMoko Wiki,” http://wiki.openmoko.org/wiki/Main Page. [3] “Linux Devices,” http://www.linuxdevices.com/articles/AT94 23084269.html. [4] “LiMo Foundation,” http://www.limofoundation.org. [5] “Trusted Computing Group (TCG),” https://www.trustedcomputinggroup .org/.

[6] Biba, K. J. (1975) Integrity considerations for secure computer systems, Technical report mtr-3153, Mitre Corporation.

[7] Fraser, T. (2000) “LOMAC: Low Water-Mark Integrity Protection for COTS Environments,” in SP ’00: Proceedings of the 2000 IEEE Symposium on Security and Privacy, IEEE Computer Society, Washington, DC, USA, p. 230.

[8] Clark, D. D. and D. R. Wilson (1987) “A Comparison of Commercial and Military Computer Security Policies,” sp, 00, p. 184.

[9] “Integrity Measurement Architecture,” http://sourceforge.net/projects /linux-ima.

[10] Jaeger, T., R. Sailer, and U. Shankar (2006) “PRIMA: policy-reduced integrity measurement architecture,” in SACMAT ’06: Proceedings of the eleventh ACM symposium on Access control models and technologies, ACM, New York, NY, USA, pp. 19–28.

[11] Seshadri, A., A. Perrig, L. van Doorn, and P. Khosla (2004), “Swatt: Software-based attestation for embedded devices,” . URL citeseer.ist.psu.edu/seshadri04swatt.html 59

[12] Kennell, R. and L. H. Jamieson (2003) “Establishing the genuinity of remote computer systems,” in SSYM’03: Proceedings of the 12th conference on USENIX Security Symposium, USENIX Association, Berkeley, CA, USA, pp. 21–21.

[13] Shankar, U., M. Chew, and J. Tygar (2004), “Side effects are not suffi- cient to authenticate software,” . URL citeseer.ist.psu.edu/shankar04side.html

[14] Seshadri, A., M. Luk, E. Shi, A. Perrig, L. van Doorn, and P. Khosla (2005) “Pioneer: verifying code integrity and enforcing untam- pered code execution on legacy systems,” SIGOPS Oper. Syst. Rev., 39(5), pp. 1–16.

[15] Aaraj, N., A. Raghunathan, S. Ravi, and N. K. Jha (2007) “Energy and execution time analysis of a software-based trusted platform module,” in DATE ’07: Proceedings of the conference on Design, automation and test in Europe, EDA Consortium, San Jose, CA, USA, pp. 1128–1133.

[16] Strasser, M., “TPM Emulator,” http://tpm-emulator.berlios.de/. [17] “TCG Mobile Trusted Module Specification V1.0,” https://www.trustedcomputinggroup.org/specs/mobilephone/tcg- mobile-trusted-module-1.0.pdf.

[18] Alves, T. and D. Felton (2004) “TrustZone: Integrated Hardware and Software Security,” White Paper, ARM.

[19] Sailer, R., X. Zhang, T. Jaeger, and L. van Doorn (2004) “Design and implementation of a TCG-based integrity measurement architecture,” in SSYM’04: Proceedings of the 13th conference on USENIX Security Sympo- sium, USENIX Association, Berkeley, CA, USA, pp. 16–16.

[20] Alves, T. and J. Rudelic (2007) “ARM Security Solutions and Intel Au- thenticated Flash,” ARM, White Paper.

[21] Montavista (2008), “Montavista Mobilinux 5.0,” http://www.mvista.com/product detail mob.php.

[22] (2008), “Cellular Telecommunications Industry Association (CTIA),” http://www.ctia.org.

[23] “Car Whisperer tool, trifinite.org,” http://trifinite.org/trifinite stuff carwhisperer.html. 60

[24] Traynor, P., W. Enck, P. McDaniel, and T. L. Porta (2006) “Mit- igating attacks on open functionality in SMS-capable cellular networks,” in MobiCom ’06: Proceedings of the 12th annual international conference on Mobile computing and networking, ACM Press, New York, NY, USA, pp. 182–193.

[25] Times, E.-C. (2005), “Threat From Mobile Device Viruses a Sleeping Giant,” http://www.ecommercetimes.com/story/trends/44222.html.

[26] Judge, P. (2007), “Linux will be on a third of in 2012,” http://www.computerworld.com.sg/ShowPage.aspx?pagetype=2& articleid=6269&pubid=3&tab=Home&issueid=117.

[27] “MotorolaFans.com Community,” http://www.motorolafans.com.

[28] “BusyBox,” http://busybox.net/.

[29] Rao, V. (2007) Secuirty in Mobile Phones - Handset and Networks Perspec- tive, Master’s thesis, The Pennsylvania State University.

[30] Shackman, M., “Symbian OS v9 and Platform Security,” http://www.symbian.com/files/rx/file3202.pdf.

[31] Muthukumaran, D., A. Sawani, J. Schiffman, . M. Jung, and T. Jaeger (2008) “Measuring Integrity on Mobile Phone Systems,” 13th ACM Symposium on Access Control Models and Technologies (SACMAT).

[32] Shankar, U., T. Jaeger, and R. Sailer (2006) “Toward automated information-flow integrity verification for security-critical applications,” 2006 ISOC Networked and Distributed Systems Security Symposium (NDSS06).

[33] “Buildroot,” http://buildroot.uclibc.org/.

[34] “OpenEmbedded,” http://oe.linuxtogo.org/.

[35] Enck, W., P. Traynor, P. McDaniel, and T. L. Porta (2005) “Ex- ploiting open functionality in SMS-capable cellular networks,” in CCS ’05: Proceedings of the 12th ACM conference on Computer and communications security, ACM Press, New York, NY, USA, pp. 393–404.

[36] Kingpin and Mudge (2001) “Security Analysis of the Palm Operating Sys- tem and its Weaknesses Against Malicious Code Threats,” in 10th USENIX Security Symposium, pp. 135–152.

[37] Knudsen, J. (2003), “Understanding MIDP 2.0’s Security Architecture,” http://developers.sun.com/techtopics/mobility/midp/articles/ permissions/. 61

[38] Loscri, V. and S. Marano (2006) “A new bi-processor ,” in SUTC ’06: Proceedings of the IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing -Vol 1 (SUTC’06), IEEE Computer Society, Washington, DC, USA, pp. 104–111.

[39] Nakamoto, Y. (2004) “Toward mobile phone Linux,” in ASP-DAC ’04: Proceedings of the 2004 conference on Asia South Pacific design automation, IEEE Press, Piscataway, NJ, USA, pp. 117–124.

[40] Nakamura, Y. (2007) SELinux & AppArmor - Comparison of Secure OSes, Tech. rep., Hitachi Software Engineering Co., Ltd., http://tree.celinuxforum.org/CelfPubWiki/ELC2007Presentations? action=AttachFile&do=get&target=SecureOS nakamrua.pdf.

[41] Sandhu, R. S., E. J. Coyne, H. L. Feinstein, and C. E. Youman (1996) “Role-Based Access Control Models,” IEEE Computer, 29(2), pp. 38–47.

[42] Schneider, F. B. (2000) “Enforceable security policies,” ACM Trans. Inf. Syst. Secur., 3(1).

[43] Wright, C., C. Cowan, S. Smalley, J. Morris, and G. K. Hartman (2002) “Linux Security Module Framework,” in 2002 Ottawa Linux Sympo- sium.

[44] Zheng, P. and L. M. Ni (2006) “Spotlight: The Rise of the Smart Phone,” IEEE Distributed Systems Online, 7(3), p. 3.

[45] “AT Command set for GSM Mobile Equipment (ME) 3GPP TS 07.07,” http://www.3gpp.org/ftp/Specs/html-info/0707.htm.

[46] “Security Evaluation of Apples iPhone,” www.securityevaluators.com /iphone/exploitingiphone.pdf. [47] “National Security Agency. Security-Enhanced Linux (SELinux),” http://www.nsa.gov/selinux.

[48] “OpenEZX project,” http://www.openezx.org/.

[49] “Blackberry Features,” http://eu.blackberry.csom/eng/ataglance/sec urity/features.jsp. [50] “Trusted Mobile Platform Specification (IBM, Intel, and NTT DoCoMo),” http://www.trusted-mobile.org/.

[51] “Trusted APIs,” http://msdn2.microsoft.com/en-us/library/ms92 4486.aspx .